[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: coreutils bug with "ln x d/"
From: |
Paul Eggert |
Subject: |
Re: coreutils bug with "ln x d/" |
Date: |
Sun, 27 Jun 2004 11:07:30 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
address@hidden (Paul Jarc) writes:
> <URL:http://lists.gnu.org/archive/html/bug-coreutils/2004-02/msg00037.html>
> The main difference is that --syntactic/--as-is still lets you have
> the convenience of omitting the target basename if it's the same as
> the source, by providing a target that ends with "/". It still
> doesn't depend on the contents of the filesystem, like -D, so there
> are no surprises.
There are still some surprises with --syntactic, I'm afraid.
Before we go any further I'd like to rename the proposed --no-destdir
option to --no-target-directory, since in some sense it's the inverse
of the --target-directory option. Those two options are clearly
incompatible. (I discovered this while implementing the proposed option.)
Anyway, here's an example of a surprise with --syntactic. Suppose one
wants to write a reliable shell script that creates a symbolic link $y
like this:
ln -s -- "$x" "$y"
where x and y are derived from user data. Unfortunately, --syntactic
won't do this for us, as
ln --syntactic -s -- "$x" "$y"
might succeed without creating a symbolic link named $y. If $y
happens to end with "/" it will create a symbolic link named
$y$(basename "$x") instead. So to make our script more reliable,
we'll have to write something like this:
case $y in
*/) echo >&2 "target ends in /"; exit 1;;
*) ln --syntactic -s -- "$x" "$y";;
esac
and even this more-complicated code will fail on a DOS host, which
uses different syntax for path names.
In contrast,
ln --no-target-directory -s -- "$x" "$y"
has the desired semantics, even on a DOS host.
So, for portable, reliable shell script programming ---syntactic seems
to be less convenient than --no-target-directory.
One could argue that --syntactic is more convenient for interactive
use, since one could alias "ln" to "ln --syntactic" and then get
more-desirable behavior. But I'm dubious about this approach. If one
aliased only for command-line "ln", it would mean command-line "ln"
behaved differently from shell-script "ln" (not a good idea). And
also, it would make the aliased "ln" incompatible with POSIX (also not
a good idea).