I ran into this earlier today and thought I'd share. Shell fails. sh-4.2$ pwd /tmp/a sh-4.2$ mv /tmp/a /tmp/b sh-4.2$ pwd /tmp/b sh-4.2$ bash robert.keizer@qubit:/tmp/b$ mv /tmp/b /tmp/c robert.keizer@qubit:/tmp/b$ pwd /tmp/b robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*c$ drwxr-xr-x 2 robert.keizer robert.keizer 4.0K Apr 16 16:09 c robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*b$ robert.keizer@qubit:/tmp/b$ exit sh-4.2$ pwd /tmp/c sh-4.2$
It's important to note that bash has a built-in pwd command, which uses internal state information to determine the working directory, rather than doing the walk up the tree that /bin/pwd does. Here's an example that illustrates the difference: [root@localhost ~]# cd /usr/local/share [root@localhost share]# pwd /usr/local/share [root@localhost share]# /bin/pwd /import/share [root@localhost share]# On the system used above, /usr/local/share is a symlink to an NFS mounted file system. Bash's built-in pwd command shows the "logical" path, whereas /bin/pwd shows the actual path of the mounted file system. In your example, the internal state of bash still knows the working directory by its old name (before the second mv command changed it again). It's not clear what shell you were using prior to running bash (and after exiting it), but it may be using /bin/pwd in any case. Gilbert On 16/04/2014 3:12 PM, Robert Keizer wrote:
I ran into this earlier today and thought I'd share.
Shell fails.
sh-4.2$ pwd /tmp/a sh-4.2$ mv /tmp/a /tmp/b sh-4.2$ pwd /tmp/b sh-4.2$ bash robert.keizer@qubit:/tmp/b$ mv /tmp/b /tmp/c robert.keizer@qubit:/tmp/b$ pwd /tmp/b robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*c$ drwxr-xr-x 2 robert.keizer robert.keizer 4.0K Apr 16 16:09 c robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*b$ robert.keizer@qubit:/tmp/b$ exit sh-4.2$ pwd /tmp/c sh-4.2$
-- Gilbert E. Detillieux E-mail: <gedetil@muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609
To make things slightly more confusing: I found out that the single shell acts differently based on how it was executed. sh-4.2$ ls -alh /bin/sh lrwxrwxrwx 1 root root 4 Apr 2 12:47 /bin/sh -> bash sh-4.2$ So if bash was called as bash it'll use internal state, whereas if it was called with /bin/sh, it doesn't appear to. On Wed, Apr 16, 2014 at 3:25 PM, Gilbert E. Detillieux <gedetil@cs.umanitoba.ca> wrote:
It's important to note that bash has a built-in pwd command, which uses internal state information to determine the working directory, rather than doing the walk up the tree that /bin/pwd does.
Here's an example that illustrates the difference:
[root@localhost ~]# cd /usr/local/share [root@localhost share]# pwd /usr/local/share [root@localhost share]# /bin/pwd /import/share [root@localhost share]#
On the system used above, /usr/local/share is a symlink to an NFS mounted file system. Bash's built-in pwd command shows the "logical" path, whereas /bin/pwd shows the actual path of the mounted file system.
In your example, the internal state of bash still knows the working directory by its old name (before the second mv command changed it again). It's not clear what shell you were using prior to running bash (and after exiting it), but it may be using /bin/pwd in any case.
Gilbert
On 16/04/2014 3:12 PM, Robert Keizer wrote:
I ran into this earlier today and thought I'd share.
Shell fails.
sh-4.2$ pwd /tmp/a sh-4.2$ mv /tmp/a /tmp/b sh-4.2$ pwd /tmp/b sh-4.2$ bash robert.keizer@qubit:/tmp/b$ mv /tmp/b /tmp/c robert.keizer@qubit:/tmp/b$ pwd /tmp/b robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*c$ drwxr-xr-x 2 robert.keizer robert.keizer 4.0K Apr 16 16:09 c robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*b$ robert.keizer@qubit:/tmp/b$ exit sh-4.2$ pwd /tmp/c sh-4.2$
-- Gilbert E. Detillieux E-mail: <gedetil@muug.mb.ca> Manitoba UNIX User Group Web: http://www.muug.mb.ca/ PO Box 130 St-Boniface Phone: (204)474-8161 Winnipeg MB CANADA R2H 3B4 Fax: (204)474-7609 _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
In the bash(1) man page's INVOCATION section, it says: If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well. It goes on to describe the implications for which startup files may or may not be read, so if that matters, I would recommend reading the man page and trying things out. On 25/04/2014 12:54 PM, Robert Keizer wrote:
To make things slightly more confusing: I found out that the single shell acts differently based on how it was executed.
sh-4.2$ ls -alh /bin/sh lrwxrwxrwx 1 root root 4 Apr 2 12:47 /bin/sh -> bash sh-4.2$
So if bash was called as bash it'll use internal state, whereas if it was called with /bin/sh, it doesn't appear to.
On Wed, Apr 16, 2014 at 3:25 PM, Gilbert E. Detillieux <gedetil@cs.umanitoba.ca> wrote:
It's important to note that bash has a built-in pwd command, which uses internal state information to determine the working directory, rather than doing the walk up the tree that /bin/pwd does.
Here's an example that illustrates the difference:
[root@localhost ~]# cd /usr/local/share [root@localhost share]# pwd /usr/local/share [root@localhost share]# /bin/pwd /import/share [root@localhost share]#
On the system used above, /usr/local/share is a symlink to an NFS mounted file system. Bash's built-in pwd command shows the "logical" path, whereas /bin/pwd shows the actual path of the mounted file system.
In your example, the internal state of bash still knows the working directory by its old name (before the second mv command changed it again). It's not clear what shell you were using prior to running bash (and after exiting it), but it may be using /bin/pwd in any case.
Gilbert
On 16/04/2014 3:12 PM, Robert Keizer wrote:
I ran into this earlier today and thought I'd share.
Shell fails.
sh-4.2$ pwd /tmp/a sh-4.2$ mv /tmp/a /tmp/b sh-4.2$ pwd /tmp/b sh-4.2$ bash robert.keizer@qubit:/tmp/b$ mv /tmp/b /tmp/c robert.keizer@qubit:/tmp/b$ pwd /tmp/b robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*c$ drwxr-xr-x 2 robert.keizer robert.keizer 4.0K Apr 16 16:09 c robert.keizer@qubit:/tmp/b$ ls -alh /tmp/ | grep ^d.*b$ robert.keizer@qubit:/tmp/b$ exit sh-4.2$ pwd /tmp/c sh-4.2$
-- Gilles R. Detillieux E-mail: <grdetil@scrc.umanitoba.ca> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 0J9 (Canada)
participants (3)
-
Gilbert E. Detillieux -
Gilles Detillieux -
Robert Keizer