Message-Id: <199903170026.AAA60666@out5.ibm.net>
From: "Mark E." <snowball3 AT usa DOT net>
To: djgpp-workers AT delorie DOT com
Date: Tue, 16 Mar 1999 19:26:34 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: symlink question
In-reply-to: <199903161953.OAA20461@envy.delorie.com>
References: <199903161751 DOT RAA53418 AT out5 DOT ibm DOT net> (snowball3 AT usa DOT net)
X-mailer: Pegasus Mail for Win32 (v3.01d)
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

> "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.

Mark