www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/08/31/02:47:14

Date: Tue, 31 Aug 1999 09:29:12 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: pavenis AT lanet DOT lv
cc: djgpp-workers AT delorie DOT com
Subject: Re: symlink() & is_v2_prog() question
In-Reply-To: <B0000099888@stargate.astr.lu.lv>
Message-ID: <Pine.SUN.3.91.990831092851.9517D-100000@is>
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 Mon, 30 Aug 1999 pavenis AT lanet DOT lv wrote:

> 	one may need to invoke non-DJGPP application from DJGPP one. 
> 	As results symlinks will work in one but not in another one 
>         (example of non-DJGPP application is command.com)

It's true in general, although rare in practice.  Specifically,
COMMAND.COM is almost *never* called, unless the application requests
that explicitly.

Perhaps `__spawnve' (or one of its subroutines) could copy the file(s)
that are symlinks, if the program it is about to launch is a non-DJGPP
one?  That would require checking all the command-line arguments and
all the inherited file handles.

The copy-file simulation of symlinks doesn't have this problem, btw.

>        If we are going to support only part of functionality we have for
>        example in Linux, then something will still stay broken and
>        we'll still may have problems when running things that commes
>        from Unix.

I don't think I understand this.  Can you please elaborate?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019