Date:	Thu, 20 Apr 2000 05:30:52 -0400 (EDT)
Message-Id:	<200004200930.FAA15745@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	Rossz <rwentwor AT advent DOT com>
CC:	djgpp AT delorie DOT com
In-reply-to:	<8dl66e$dkk$1@nnrp1.deja.com> (message from Rossz on Wed, 19 Apr
	2000 20:50:29 GMT)
Subject:	Re: ln -s
References:	<8dl66e$dkk$1 AT nnrp1 DOT deja DOT com>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: Rossz <rwentwor AT advent DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Wed, 19 Apr 2000 20:50:29 GMT
> 
> I get a 2k file called another.h.exe.  Not at all what is expected.
> I've run across a number of scripts that attempt to assertain if
> symbolic links work, one example did something like this:
> 
>    ln -s stuff.h another.h || cp stuff.h another.h
> 
> This fails because ln's return code is 0.  ln should be modified to
> ALWAYS return a nonzero code when a symbolic link is attempted.

IMHO, it doesn't make sense to add a feature that breaks another one.
The simulated symlinks were in DJGPP from its earliest days, in
version 1.x, and they never did much harm.  I don't think we should
remove them now.

Instead, I think we need to augment this by making the ported `ln' (or
the underlying library fuinction `symlink') be smarter.  For example,
when faced with a non-executable file, it could copy it instead of
creating a stub.

Feel free to submit a patch.  I believe someone is working on a new
port of GNU Fileutils as we speak.

For the next release of DJGPP, somebody wrote a complete simulation of
Unix-style symlinks, which will work for *any* type of file.  Given
that, making "ln -s" fail would be a step in the wrong direction.

> This would fix a large number of script portability problems.

I'm not aware of a large number of such problems.  If you are
referring to GNU configure scripts or Makefile's that are created by
them, then this problem is currently solved by forcing the "ln -s"
test to fail in the config.site file distributed with the ported Bash.

On the other hand, many GNU tools need to make symlinks to executable
programs.  For those cases, "ln -s" does its job very well, and
actually *solves* portability problems.  Removing that feature will
break these cases.

If you have specific problems not covered above, please describe them.

> I suppose it
> could check the extension of the file and allow its bastardized symbolic
> link for EXEs but fail on others.

It's not enough to look at the extension.  You need to make sure it's
a DJGPP program, since the simulated symlinks won't work for others.
There's a library function to perform such tests (and `ln' uses it
already).

- Raw text -