Date: Thu, 20 Apr 2000 05:30:52 -0400 (EDT) Message-Id: <200004200930.FAA15745@indy.delorie.com> From: Eli Zaretskii To: Rossz 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 Precedence: bulk > From: Rossz > 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).