[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