Re: coreutils bug with "ln x d/"

[Paul Jarc]

Paul Eggert <address@hidden> wrote:
>   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.

Well, that's what it's supposed to do.  If that's not what the script
wants, it can construct $y in such a way as to guarantee that it
doesn't end with "/".  In particular, when at least one trailing
character of the link name is given literally rather than through a
variable, there will be no surprises.

>   case $y in
>   */) echo >&2 "target ends in /"; exit 1;;

Stripping off the "/" before calling ln would work too.

> and even this more-complicated code will fail on a DOS host, which
> uses different syntax for path names.

True, although many scripts aren't intended to be portable to DOS
anyway.  (The DOS version of --syntactic would have to check for
either "/" or "\" at the end, yes?)

> So, for portable, reliable shell script programming ---syntactic seems
> to be less convenient than --no-target-directory.

Maybe there's room for both.  If you're constructing the link name
yourself, and particularly if it (or even just the end of it, a common
case for me) is directly specified as a literal argument on the
command line, then --syntactic won't be surprising, and can offer some
convenience - you can omit the basename from the target if it's the
same as the source's.

If you're accepting a link name taken from some outside source, then
it's a question of whether you want to grant that source the same
convenience - if so, use --syntactic; if not, use
--no-target-directory.

> One could argue that --syntactic is more convenient for interactive
> use,

I would not be that one.  Interactively, tab completion looks at the
filesystem just like ln without any special options does, so I avoid
surprises that way.  I'm thinking --syntactic would be most useful in
scripts.


paul