Hide Forgot
Description of problem: bash-4.1$ export PS1="[\u@\h \W]$" [lkocman@dhcp-28-248 Desktop]$cd // [lkocman@dhcp-28-248 //]$pwd // [lkocman@dhcp-28-248 //]$ls bin cgroup etc lib lost+found misc net proc sbin srv tmp var boot dev home lib64 media mnt opt root selinux sys usr [lkocman@dhcp-28-248 //]$rpm -qf `which pwd` coreutils-8.4-12.el6.x86_64 [lkocman@dhcp-28-248 //]$ Version-Release number of selected component (if applicable): bash-4.1.2-8.el6.x86_64 coreutils-8.4-12.el6.x86_64 How reproducible: Steps to Reproduce: 1. export PS1="[\u@\h \W]$" 2. cd // 3. pwd Actual results: // (is this really wanted behaviour?) Expected results: / Additional info:
cd /// and more returns /
This does not involve coreutils, but rather bash's built-in pwd: $ bash -c 'cd //; env pwd' / $ bash -c 'cd //; pwd' // I've changed the component from coreutils to bash.
(In reply to comment #0) > Description of problem: > > bash-4.1$ export PS1="[\u@\h \W]$" > [lkocman@dhcp-28-248 Desktop]$cd // > [lkocman@dhcp-28-248 //]$pwd > // > [lkocman@dhcp-28-248 //]$ls > bin cgroup etc lib lost+found misc net proc sbin srv tmp var > boot dev home lib64 media mnt opt root selinux sys usr > [lkocman@dhcp-28-248 //]$rpm -qf `which pwd` > coreutils-8.4-12.el6.x86_64 > > [lkocman@dhcp-28-248 //]$ > > > Version-Release number of selected component (if applicable): > > bash-4.1.2-8.el6.x86_64 > coreutils-8.4-12.el6.x86_64 > > How reproducible: > > > Steps to Reproduce: > 1. export PS1="[\u@\h \W]$" > 2. cd // > 3. pwd > > Actual results: > > // (is this really wanted behaviour?) Yes it is. > > Expected results: > > / > > Additional info: See http://www.faqs.org/faqs/unix-faq/shell/bash/ E10
bash-4.1$ cd // bash-4.1$ /bin/pwd / bash-4.1$ pwd // Problem is bash.
Have you read the faq Roman posted in comment #10 ? Cite: " E10) Why does `cd //' leave $PWD as `//'? POSIX.2, in its description of `cd', says that *three* or more leading slashes may be replaced with a single slash when canonicalizing the current working directory. This is, I presume, for historical compatibility. Certain versions of Unix, and early network file systems, used paths of the form //hostname/path to access `path' on server `hostname'. " So the bash behaviour seems to be really intentional. I'll leave it up on you or Roman to close it again notabug .