Hi,
I wonder why such a thing is possible [michal@ozzy ~]$ cd / [michal@ozzy /]$ pwd / [michal@ozzy /]$ cd // [michal@ozzy //]$ pwd // [michal@ozzy //]$ cd /// [michal@ozzy /]$
Why can I change dir to // ?
Michał Piotrowski <mkkp4x4 <at> gmail.com> writes:
Hi,
I wonder why such a thing is possible [michal <at> ozzy ~]$ cd / [michal <at> ozzy /]$ pwd / [michal <at> ozzy /]$ cd // [michal <at> ozzy //]$ pwd // [michal <at> ozzy //]$ cd /// [michal <at> ozzy /]$
Why can I change dir to // ?
Good question - a directory listing shows it's in /, as expected, but $PWD is wrong, and only when there are exactly 2 /'s. The same thing happens in F13, F14, and Rawhide. It only happens in sh/bash, and not in csh/tcsh, ksh, or zsh.
Andre Robatino <robatino <at> fedoraproject.org> writes:
Good question - a directory listing shows it's in /, as expected, but $PWD is wrong, and only when there are exactly 2 /'s. The same thing happens in F13, F14, and Rawhide. It only happens in sh/bash, and not in csh/tcsh, ksh, or zsh.
More generally, it happens for anything like "//usr/bin" as well - you end up in the expected directory, but "echo $PWD" shows the double slash.
2011/1/17 Andre Robatino robatino@fedoraproject.org:
Andre Robatino <robatino <at> fedoraproject.org> writes:
Good question - a directory listing shows it's in /, as expected, but $PWD is wrong, and only when there are exactly 2 /'s. The same thing happens in F13, F14, and Rawhide. It only happens in sh/bash, and not in csh/tcsh, ksh, or zsh.
More generally, it happens for anything like "//usr/bin" as well - you end up in the expected directory, but "echo $PWD" shows the double slash.
Actually I'm testing things like
while [ true ]; do ls ///////////////////////////////////////////////////(1400 /) done
it works, but when I try
while [ true ]; do ls ///////////////////////////////////////////////////(5400 /) done
I get "too long file name" warning.
Also works for ~/// and ///dir1///dir2
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Andre Robatino <robatino <at> fedoraproject.org> writes:
More generally, it happens for anything like "//usr/bin" as well - you end up in the expected directory, but "echo $PWD" shows the double slash.
It also persists if you then cd using a relative path. The double slash in $PWD won't go away unless you cd using an absolute path.
Well, apparently it's deliberate behavior (not a bug). See this from 2005:
http://linuxfromscratch.org/pipermail/blfs-support/2005-December/057882.html
Andre Robatino <robatino <at> fedoraproject.org> writes:
Well, apparently it's deliberate behavior (not a bug). See this from 2005:
http://linuxfromscratch.org/pipermail/blfs-support/2005-December/057882.html
Which then raises the question - if bash is doing the right thing, are all the other shells doing the wrong thing (meaning should it be reported as a bug against them)?
2011/1/17 Andre Robatino robatino@fedoraproject.org:
Well, apparently it's deliberate behavior (not a bug). See this from 2005:
http://linuxfromscratch.org/pipermail/blfs-support/2005-December/057882.html
Fair enough
at least ls /././/././..//../ works and AFAICS doesn't crash anything.
On 01/16/2011 04:13 PM, Michał Piotrowski wrote:
2011/1/17 Andre Robatinorobatino@fedoraproject.org:
Well, apparently it's deliberate behavior (not a bug). See this from 2005:
http://linuxfromscratch.org/pipermail/blfs-support/2005-December/057882.html
Fair enough
at least ls /././/././..//../ works and AFAICS doesn't crash anything.
In my job as a programmer, I maintain a very old app that actually depends on "//" in pathnames behaving the same as "/". The "//" triggers some special app behavior while still being a valid pathanme when passed to the kernel filesystem. It works this way on Linux, Solaris, AIX, and SGI boxes.
Regards,
JOhn
On 01/16/2011 03:54 PM, Michał Piotrowski wrote:
Hi,
I wonder why such a thing is possible [michal@ozzy ~]$ cd / [michal@ozzy /]$ pwd / [michal@ozzy /]$ cd // [michal@ozzy //]$ pwd //
Because POSIX says that leading // is allowed (but not required) to have a separate interpretation from / (no other spelling gets this special treatment; leading /// must be identical to leading /). Some systems, like Cygwin, use this POSIX requirement to implement an alternate access space, where //server/share is used, in perfect compliance with POSIX, to represent windows remote share drives. Since bash is ported to cygwin, the bash maintainer chose to preserve // as special for all systems, whether or not it actually is special. On Linux, it happens to not be special. Other shells, like zsh, only treat // as special on platforms where it really is special, and collapse it to / otherwise.
However, you have not pointed out any bugs - since POSIX is explicit that // is special, you are better off avoiding // and not worrying about whether a program collapses // into /.