chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] process-execute and environment variables


From: Peter Bex
Subject: Re: [Chicken-users] process-execute and environment variables
Date: Mon, 11 Nov 2013 13:35:43 +0100
User-agent: Mutt/1.4.2.3i

On Sun, Nov 10, 2013 at 11:04:23PM +0100, Michele La Monaca wrote:
> Hi again,
> 
> I think process-execute and its siblings misbehave when handling
> environment variables. For example:
> 
> (process "ls" '())                                            ; works
> (process "ls" '() '())                                        ; fails
> (process "ls" '() '("LSCOLORS=ExFxBxDxCxegedabagacad"))       ; fails
> (process "/bin/ls" '() '())                                   ; works
> (process "/bin/ls" '() '("LSCOLORS=ExFxBxDxCxegedabagacad"))  ; works
> 
> The problem stems from the fact that process "resets" the entire
> environment (PATH included) when setting variables. I don't think this
> is the intended behavior (for sure it is not the most useful).
> 
> Sorry for not providing a patch but after the last one being rejected
> for no good reason, I'm a bit warier about how I spend my time. I am
> sure there is a good non-reason not to fix this one.

The non-reason being POSIX.  We're using execvp() in the "working"
cases, which searches the path for the program.  Unfortunately, POSIX
does not provide a path-searching version of exec() which passes the
environment, so we're forced to use execve() there which does not
search $PATH _at all_.

I agree this is completely inconsistent, but that's just the way
POSIX works.  There is a GNU libc extension called execvpe(), but
that's very unportable so we can't use it.

Having our own PATH-searching code in the "environment is passed" case
only is not an option, as it would produce further inconsistency.
So the only way around this that I can see would be to completely rip
out the whole exec stuff, and replace it with custom PATH-searching code.
This would duplicate a lot of libc, but is probably the cleanest way to
fix this.  Alternatively, we could just change the semantics to make
it never search the path.  This would be a breaking change, but at
least restore consistency.

The sad truth is that the POSIX module is way too low-level in most
points, but not everywhere.  Ideally, it should be split out away from
core into an egg where it can die.

For now, I think this should go on hold until after 4.9.0 has been
released.  Feel free to report a ticket if you still are bothered
by this.

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]