[buug] Re: ln -sf "bug" (& standards, etc.)
mp at rawbw.com
Sat Aug 7 21:36:29 PDT 2004
Quoting Ian Zimmerman <itz at buug.org>:
> Michael> I think the "good news" here is it appears these things are on
> Michael> relatively convergent paths - at least with regard to the most
> Michael> common options (-s and -f) (most notably some LSB deprecated
> Michael> features and most current LSB release candidate, and the most
> Michael> current specifications from The Open Group Specifications).
> Do you think GNU will remove the -n flag or reverse its semantics if it
> is removed by LSB? I bet against it. There's still the possibility
> that distributions will do it with a patch, but I don't like that
> much either, it breaks compiling from source.
My best guestimate would be GNU would likely do one of these things:
+ Since GNU doesn't do man pages, somewhere in the GNU info page,
perhaps add a bit of information on either or both of:
+ other implementations of ln may use -n differently
+ other implementations of ln default to the GNU ln -n behavior
+ implement a compile time option to deprecate GNU's -n (have it
silently ignored or issue a warning that it's being ignored but don't
treat that as an error) and have GNU's current -n effect be the default
behavior, and perhaps also add options (e.g. --dereference and -L) to
give the old default behavior. Perhaps also make such a compile time
option the default. Compile time option would also suitably adjust
the info page (and other distributions/ports would appropriately
update their man pages, etc.).
+ the above compile time option could also be something where an
environment variable (e.g. POSIXLY_CORRECT) influences the behavior,
but I think that would be a less preferred type of solution.
If GNU doesn't change to match the LSB it seems likely
distributions/ports will patch to eliminate conflicts with the LSB. At
least if GNU adds a compile time option (even if it's not the default),
that would significantly reduce downstream source divergence and
At least in my reading of it, seems GNU currently conflicts not only
with LSB 2.0rc2 (likely to be finalized soon and become the official LSB
standard) but also the current LSB 1.3 standard. The LSB 1.3 standard is
defined mostly in terms of the Single UNIX Specification, Version 2, but
with the -s from the Single UNIX Specification, Version 3. The
remainder of LSB 1.3 gives options as "Deprecated Differences". At least
if I read and give strict interpretation of LSB 1.3, I come to the
conclusion that nothing in LSB 1.3 implies or states that dereferencing
should be happening (other than it contains deprecated option to not
dereference - I'd think that option should have no effect, according
to my interpretation of LSB 1.3). Of course other interpretations are
possible. Perhaps that's an error (specification not as intended or
ambiguous) in the LSB 1.3 specification.
On the GNU documentation (info page) since it gives options to not
dereference (and no opposite option), it's implied that by default
dereferencing occurs - so I don't see GNU being inconsistent with itself
(just happens to not quite match to the LSB).
> Scripts should probably work around by testing if the target is a
> symlink, and if so remove it first; and LSB should _not_ specify one
> behavior or the other, just leave it undefined.
Yes, unfortunately, given the various (at least historic)
implementations and behaviors, prudence would dictate that in most
circumstances scripts should do relevant checking (existence of target
and possibly type of target both not dereferenced and dereferenced,
and/or testing the type/behavior of the ln command).
Hmmmm... I wonder what the current Debian Sarge ln(1) behavior and
documentation is. If it were to change "too late in the game", however,
that might significantly break other things (but those "errors" should
be limited to other non-LSB compliant scripts and such).
The Single UNIX Specification, Version 2:
More information about the buug