Re: coreutils bug with "ln x d/"

[Paul Eggert]

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