Date: Wed, 17 Mar 1999 11:29:41 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andris Pavenis <pavenis AT lanet DOT lv>
cc: "Mark E." <snowball3 AT usa DOT net>, djgpp-workers AT delorie DOT com
Subject: Re: symlink question
In-Reply-To: <Pine.A41.4.05.9903171010230.89100-100000@ieva01.lanet.lv>
Message-ID: <Pine.SUN.3.91.990317112522.11125N-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 17 Mar 1999, Andris Pavenis wrote:

> I'm using 'ln -s' in scripts and would not like if such possibility will
> be removed.

I agree that removing it would be bad.

> Best I can imagine is allowing 'ln -s' to succeed only for 
> DJGPP executables. 

If you compile `ln' with DJGPP v2.02, it will do that already.  But the 
problem raised by Mark isn't solved with the latest `symlink' in the 
library, because in that case there's no file to test for being a DJGPP 
executable.

Doing a hard link in such cases seems to catch the best of both worlds.  
In the case that somebody indeed wants a DJGPP-style symlink to a 
non-existent program (i.e. a stub that poins to a non-existent file), 
they could use stubify and stubedit directly.