Re: has this bug been fixed?
From: Stefaan A Eeckels (tengo_at_DELETEMEecc.lu)
Date: 08/23/04
- Previous message: Alexander W. Skwar: "Re: has this bug been fixed?"
- In reply to: Frank Slootweg: "Re: has this bug been fixed?"
- Next in thread: Baby Peanut: "Re: has this bug been fixed?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 23 Aug 2004 15:37:40 +0200
On 23 Aug 2004 12:16:31 GMT
Frank Slootweg <this@ddress.is.invalid> wrote:
> > Solaris: ln resolves the symlink
> > GNU/Linux: ln resolves the symlink
> > AIX: ln doesn't resolve unless the name ends in a slash
> > HP-UX: ln doesn't resolve unless the name ends in a slash
>
> Thanks, Stefaan!
You're welcome.
> Does the Solaris (ln(1)) manual page mention an option like Linux'
> "-n" option? I.e. can a person who *does* RTFM know that de default
> behaviour, apparently, is to dereference a symlink, because there is an
> option to not deference it?
No. There is a -n option to "ln", but it means something
different:
/usr/bin/ln
The following options are supported for /usr/bin/ln only:
-n If the link is an existing file, do not overwrite the
contents of the file. The -f option overrides this
option.
This is the default behavior for /usr/xpg4/bin/ln,
and is silently ignored.
So it would seem that the symlink is always resolved if it
exists (a quick test confirms this). The man page contains
the following:
NOTES
A symbolic link to a directory behaves differently than you
might expect in certain cases. While an ls(1) on such a link
displays the files in the pointed-to directory, an `ls -l'
displays information about the link itself:
example% ln -s dir link
example% ls link
file1 file2 file3 file4
example% ls -l link
lrwxrwxrwx 1 user 7 Jan 11 23:27 link -> dir
When you cd(1) to a directory through a symbolic link, you
wind up in the pointed-to location within the file system.
This means that the parent of the new working directory is
not the parent of the symbolic link, but rather, the parent
of the pointed-to directory. For instance, in the following
case the final working directory is /usr and not
/home/user/linktest.
example% pwd
/home/user/linktest
example% ln -s /usr/tmp symlink
example% cd symlink
example% cd ..
example% pwd
/usr
C shell users can avoid any resulting navigation problems by
using the pushd and popd built-in commands instead of cd.
> > Neither of the two non-resolvers documents the fact that
> > a final slash will cause the symlink to be resolved. So,
> > sadly, RTFM doesn't solve everything ;-)
>
> It is interesting that AIX behaves in the same way as HP-UX. It
> matches what I expect of AIX (and of BSD, Solaris and GNU/Linux (no
> experience with, i.e. no opinion on, IRIX)).
I think the standards can be read in many ways, and I'm not
amazed at all that HP and IBM would interpret them in the
strictest fashion. I must admit that as a long-time Solaris
user, the AIX/HP-UX behaviour seems counter-intuitive (I expect
a symlink to stand for the pointed-to object most, if not
all of the time, and regularly curse the non-resolving ls -l
behaviour).
Take care,
-- Stefaan -- "What is stated clearly conceives easily." -- Inspired sales droid
- Previous message: Alexander W. Skwar: "Re: has this bug been fixed?"
- In reply to: Frank Slootweg: "Re: has this bug been fixed?"
- Next in thread: Baby Peanut: "Re: has this bug been fixed?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|