[buug] ln -sf bug (& standards, etc.)

[Michael Paoli]

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.

<soapbox>
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 ?)).
</soapbox>

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).

references:

The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition:
http://www.opengroup.org/onlinepubs/009695399/utilities/ln.html

Linux Standard Base (LSB):
Core Specification 2.0rc2 (release candidate 2):
http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/command.html
mostly refers to:
ISO/IEC 9945:2003 Portable Operating System(POSIX)and The Single UNIX
Specification(SUS) V3
on the matter of ln(1)
LSB 1.3 (current standard):
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/ln.html
includes:
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
non-LSB-deprecated behaviors.
-n, --no-dereference
treats destination that is a symlink to a directory as if it were a
normal file.

HP-UX 11i v1:
http://docs.hp.com/hpux/onlinedocs/B2355-90689/00/01/176-con.html
HP-UX 11i v2:
http://docs.hp.com/hpux/onlinedocs/B2355-60103/00/02/218-con.html

Solaris 8:
http://docs.sun.com/db/doc/806-0624/6j9vek59a?a=view
Solaris 10:
http://docs.sun.com/db/doc/816-5165/6mbb0m9hv?a=view

GNU fileutils (used by Debian 3.0r2, and likely most other LINUX distributions):
http://www.gnu.org/software/fileutils/doc/manual/html/fileutils.html#ln%20invocation
(and remember, the N and U in GNU stands for Not Unix)

http://www.weak.org/pipermail/buug/2004-August/002503.html
http://www.weak.org/pipermail/buug/