Symlinks & Shells

Symlinks & Shells

Post by wrae.. » Thu, 11 Aug 2005 02:40:47



Hey folks,

I've come across a problem beyond my level of knowledge, so I'm looking
for some input from the list.  It revolves around how different shells
interpret or process symbolic links.  Allow me to provide some output
for demonstration.

[**Using bash shell**]

lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib


/lib

** Notice how the pwd is now the symlink path, not the true
destination.

[**Using sh shell**]
(sh)SERVER1# ls -al /lib
lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib
(sh)SERVER1# cd /lib
(sh)SERVER1# pwd
/usr/lib

** Notice how the pwd is now the destination of the symlink.

A user tells me this behaviour (of the sh shell) has changed recently,
despite my having done no relevant maintenance on the system.  What
would control this behaviour, and how could I make sh emulate bash in
this respect?  As far as I know, the common behaviour is not to
"change" directories, when following a symlink.  If a symlink directory
is /test, and you cd into it, you should be in the /test directory, not
whichever directory the link was pointing to.

Any insight would be appreciated.  Thanks.

Jordan

 
 
 

Symlinks & Shells

Post by PM » Thu, 11 Aug 2005 04:19:56



> Hey folks,

> I've come across a problem beyond my level of knowledge, so I'm looking
> for some input from the list.  It revolves around how different shells
> interpret or process symbolic links.  Allow me to provide some output
> for demonstration.

> [**Using bash shell**]

> lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib


> /lib

> ** Notice how the pwd is now the symlink path, not the true
> destination.

> [**Using sh shell**]
> (sh)SERVER1# ls -al /lib
> lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib
> (sh)SERVER1# cd /lib
> (sh)SERVER1# pwd
> /usr/lib

> ** Notice how the pwd is now the destination of the symlink.

What make you think it is a shell problem?

Hints:

% type pwd
% pwd
% builtin pwd -P
% builtin pwd -L
% /usr/bin/pwd
% man pwd
% man bash
etc.
PM

 
 
 

Symlinks & Shells

Post by wrae.. » Thu, 11 Aug 2005 04:48:09


Aah, I didn't even consider that.  Makes perfect sense now.  Thanks for
your assistance.  The problem has been resolved. :)

Jordan

 
 
 

Symlinks & Shells

Post by Michael Tosc » Thu, 11 Aug 2005 05:11:03


...

> [**Using bash shell**]

> lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib


> /lib

> ** Notice how the pwd is now the symlink path, not the true
> destination.

> [**Using sh shell**]
> (sh)SERVER1# ls -al /lib
> lrwxrwxrwx   1 root     root           9 Feb  1  2003 /lib -> ./usr/lib
> (sh)SERVER1# cd /lib
> (sh)SERVER1# pwd
> /usr/lib

> ** Notice how the pwd is now the destination of the symlink.

In bash pwd is a builtin, while sh uses the external /bin/pwd command.
The builtin pwd processes the outcome from the previous (builtin!) cd
commands.
The /bin/pwd does not know about any cd history, and must determine the
real path.

Quote:

> A user tells me this behaviour (of the sh shell) has changed recently,
> despite my having done no relevant maintenance on the system.  What
> would control this behaviour, and how could I make sh emulate bash in
> this respect?  As far as I know, the common behaviour is not to
> "change" directories, when following a symlink.  If a symlink directory
> is /test, and you cd into it, you should be in the /test directory, not
> whichever directory the link was pointing to.

The real path by the /bin/pwd command is more "natural".
So using
/bin/pwd
in scripts gives you always *this* behaviour.

The sh shell has not recently changed.
Maybe your user has used different PATH e.g. had found sh in /usr/xpg4/bin
and now in /bin (which is /usr/bin in reality).

--

 
 
 

Symlinks & Shells

Post by Sven Maschec » Thu, 11 Aug 2005 21:20:13



> In bash pwd is a builtin, while sh uses the external /bin/pwd command.

Like all traditional Bourne shells since SVR2, the Sun variants have
a built-in pwd ("type pwd"), which behaves like mentioned, though.
But sh in /usr/xpg4/bin is a ksh-related POSIX shell.
 
 
 

Symlinks & Shells

Post by Michael Tosc » Sat, 13 Aug 2005 04:34:57




>>In bash pwd is a builtin, while sh uses the external /bin/pwd command.

> Like all traditional Bourne shells since SVR2, the Sun variants have
> a built-in pwd ("type pwd"), which behaves like mentioned, though.
> But sh in /usr/xpg4/bin is a ksh-related POSIX shell.

You are right.
A "truss" proved that, too.

About the "type" command:
one can trust "type pwd" if one knows that "type" itself is a
shell-builtin.
Otherwise it would find /bin/type,
which reports the ksh-builtins :-/

--

 
 
 

Symlinks & Shells

Post by Sven Maschec » Sat, 20 Aug 2005 07:48:24



> one can trust "type pwd" if one knows that "type" itself is a
> shell-builtin. Otherwise it would find /bin/type, which reports the
> ksh-builtins :-/

An interesting one for t/csh users...  I believe you can
assume the existence of the type built-in in general (all
modern shells TTBOMK and all traditional shells since SVR2).