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 -