delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/19/17:04:09

From: Rossz <rwentwor AT advent DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: ln -s
Date: Wed, 19 Apr 2000 20:50:29 GMT
Organization: Deja.com - Before you buy.
Lines: 23
Message-ID: <8dl66e$dkk$1@nnrp1.deja.com>
NNTP-Posting-Host: 208.239.86.120
X-Article-Creation-Date: Wed Apr 19 20:50:29 2000 GMT
X-Http-User-Agent: Mozilla/4.5 [en] (Win95; U)
X-Http-Proxy: 1.0 x43.deja.com:80 (Squid/1.1.22) for client 208.239.86.120
X-MyDeja-Info: XMYDJUIDrossz
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In my opinion, DJGPP should stop trying to emulate symbolic links.
Currently, ln creates a stub program that calls the originally named
file.  This works great if it was an EXE, however, all too often the
file being linked is not an executable.  For example, if I attempt this:

    ln -s stuff.h another.h

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.  This
would fix a large number of script portability problems.  I suppose it
could check the extension of the file and allow its bastardized symbolic
link for EXEs but fail on others.



Sent via Deja.com http://www.deja.com/
Before you buy.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019