delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/08/25/09:38:34

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Fri, 25 Aug 2000 15:37:02 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
Subject: Re: Update __solve_dir_symlinks() patch
In-Reply-To: <200008251325.PAA29429@lws256.lu.erisoft.se>
Message-ID: <Pine.LNX.4.10.10008251532420.4936-100000@acp3bf>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Fri, 25 Aug 2000, Martin Stromberg wrote:

> Eli said:
> > I was afraid that removing FOO from /dev/env/FOO will cause it to
> > fail, since /dev/env doesn't have a meaning without the variable
> > name.  And the same with /dev/c/foo.
> 
> Idea: Shouln't (couldn't) /dev/env be a directory containing the
> environment variables as files or something?

Not as actual files. Impossible to keep in sync with 'getenv', esp. in the
context of multiple DJGPP apps multitasking. And no, we certainly do *not*
want to create \dev\env as an actual directory, on every drive. Nor on any
particular chosen drive, for that matter.

If at all, we could make 'unlink("/dev/env/FOO");' a synonym for removing
environment variable FOO, with an error returned if it doesn't exist.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


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