[buug] ln -sf bug (& standards, etc.)
mp at rawbw.com
Fri Aug 6 23:48:10 PDT 2004
Quoting Jon McClintock <jammer at weak.org>:
> On Fri, Aug 06, 2004 at 03:12:23PM -0700, Stefan Lasiewski wrote:
> The truth is in the man page, it just must be ferreted out:
> Interpreting man pages is indeed an art.
Well, ... most of the time the man pages are correct, ... but not always.
And then there's standards ...
Well, I also peeked at a wee bit of standard reference material.
I guess my general expectations with:
ln -sf foo bar
where bar is a symbolic link which resolves to a directory, would be
that bar would generally be "removed" (unlinked). Perhaps that's my
bias/expectations from the UNIX flavors I've mostly dealt with (at least
historically). Some of the documentation seems to also suggest that at
least historically there was a fair bit of variation in behavior and the
particular behavior of even the same options.
I also did a quick try on a Solaris 8 and HP-UX 11i v1 systems, ...
with HP-UX 11i v1 I got the behavior I "expected" (it was unlinked), and
with Solaris 8 I got the dereferenced behavior (link created in
directory referenced by existing symbolic link target). To complicate
the matter slighty more for Solaris 8, there are two ln commands -
different pathnames, different options/behavior.
I tend to think these things ought to be compatible. "Extensions" can be
good/okay ... particularly when they do things "better" (don't violate
principle of least surprise, do better / more useful things, etc.), ...
but I generally expect (or at least want to expect) that relatively
common basic options (e.g. -f and -s, and their use in combination)
should give quite consistent results/behavior. In the case of ln, I'd
expect and be least surprised if in the mentioned case of ln -sf, the
target would be unlinked by default, and perhaps some other option could
be added when dereferencing is desired (perhaps --dereference and a
single option letter (perhaps -L ?)).
Oh, it's also of note that the -n option, at least between Solaris and
GNU, do rather significantly different things.
I think the "good news" here is it appears these things are on
relatively convergent paths - at least with regard to the most common
options (-s and -f) (most notably some LSB deprecated features and most
current LSB release candidate, and the most current specifications from
The Open Group Specifications).
The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition:
Linux Standard Base (LSB):
Core Specification 2.0rc2 (release candidate 2):
mostly refers to:
ISO/IEC 9945:2003 Portable Operating System(POSIX)and The Single UNIX
on the matter of ln(1)
LSB 1.3 (current standard):
LSB Deprecated Differences
The behaviors specified in this section are expected to disappear from a
future version of the LSB; applications should only use the
treats destination that is a symlink to a directory as if it were a
HP-UX 11i v1:
HP-UX 11i v2:
GNU fileutils (used by Debian 3.0r2, and likely most other LINUX distributions):
(and remember, the N and U in GNU stands for Not Unix)
More information about the buug