Date: Wed, 15 Sep 1999 11:49:59 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: DJGPP Workers Subject: Re: More about symlinks In-Reply-To: <37DE4CD1.B02BC18B@softhome.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, 14 Sep 1999, Laurynas Biveinis wrote: > rmdir: $(rmdir_OBJECTS) $(rmdir_DEPENDENCIES) ln > $(LINK) $(rmdir_LDFLAGS) $(rmdir_OBJECTS) $(rmdir_LDADD) $(LIBS) > ./ln -s $@ grmdir > stubedit grmdir.exe argv0=rmdir > > It will be broken with new .exe symlink code - guess which file stubedit > will update. One way to fix this would be to replace "ln -s" with "stubify -g". The last two lines of the rule are added by the DJGPP-specific configuration scripts, so they are easily changed. > 1) Are there places like above in other GNU code ported to DJGPP? Perhaps; I don't remember. Sh-utils create some ``symlinks'' like this (e.g., gecho.exe that runs echo.exe), but they use stubify directly, so as not to depend on `ln' being installed. > 2) Is it acceptable solution for symlink() generate _both_ foo, which > is the real symlink and foo.exe, which is good ol' DJGPP .exe symlink? I'm afraid generating two files foo and foo.exe will have unwanted side effects. For example, the order in which the directories are searched for the program will become significant. Thus, invoking a program as "foo" and "../foo" might cause a different file to be run. So I think using "stubify -g" is a much better alternative. These gFOO symlinks are solely to allow the programs to be invoked from the DOS prompt, to work around internal commands of COMMAND.COM and its ilk. For this to work transparently, argv[0] must be the original name of the program, and real symlinks don't (and shouldn't) support that.