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