X-Authentication-Warning:	ieva01.lanet.lv: pavenis owned process doing -bs
Date:	Wed, 17 Mar 1999 10:13:49 +0200 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	"Mark E." <snowball3 AT usa DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: symlink question
In-Reply-To:	<199903170026.AAA60666@out5.ibm.net>
Message-ID:	<Pine.A41.4.05.9903171010230.89100-100000@ieva01.lanet.lv>
MIME-Version:	1.0
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

On Tue, 16 Mar 1999, Mark E. wrote:

> > "ln -s" should succeed in djgpp whenever it succeeds in Linux.  You
> > can symlink to a non-existing file in Linux.
> 
> That's fine. But our 'ln -s' is very limited, and it causes havoc with 
> configure scripts. configure scripts rightly detects that 'ln -s' with a 
> non-existant file works. The problem occurs when it tries to use it 
> on a file: 'ln -s hdr1.h hdr2.h'. The configure script expects the ln 
> call to succeed, and when it doesn't, the script usually aborts.
> 
> A sent a third note with one proposal. Here's another:
> I noticed in Bash 2.03's examples/loadables directory a ln.c. I 
> copied this to the builtins directory and managed to make it a 
> Bash builtin. What I was thinking was if Bash is currently in a non-
> interactive state (executing a script), then have 'ln -s' always report 
> an error. When the configure script gets the error, it will use plain 
> 'ln' instead. When it's in an interactive state (reading input from the 
> keyboard), 'ln -s' will work as usual. This way, the 'ln' hack only 
> affects scripts run by Bash and wouldn't require changing the 'ln' 
> in file utilities.

I'm using 'ln -s' in scripts and would not like if such possibility will
be removed. Best I can imagine is allowing 'ln -s' to succeed only for 
DJGPP executables. 

Andris

- Raw text -