headers
Pascal J. Bourguignon | 26 Mar 2012 18:12
X-Face
Face
Favicon

run-program :environment nil


(lisp-implementation-version) --> "1.0.1"

The documentation of extensions:run-program is misleading:

    :environment 
        An alist of STRINGs (name . value) describing the new
        environment. The default is to copy the environment of the current
        process.

The alist doesn't describe the NEW environment, it is only MERGED into
the current environment.

Now of course, I consider the current behavior to be a bug:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash"  …)

I would expect:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ()

and:

    (text-stream-contents (extensions:process-output
(Continue reading)

Permalink | Reply |
headers
Mark Evenson | 27 Mar 2012 14:26
Picon
Favicon

Re: run-program :environment nil


On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:

> 
> (lisp-implementation-version) --> "1.0.1"
> 
> 
> The documentation of extensions:run-program is misleading:
> 
>    :environment 
>        An alist of STRINGs (name . value) describing the new
>        environment. The default is to copy the environment of the current
>        process.
> 
> The alist doesn't describe the NEW environment, it is only MERGED into
> the current environment.

[…]

Which behavior would you prefer?

We certainly have imprecise documentation here.  The merged environment
behavior what is easiest with the underlying JVM API which is based
on the notion of UNIX exec().  In practice, I would venture that
that most people would expect the merged behavior, as it is the
common pattern for such wrappers around UNIX execv() and friends
which have to copy the environment anyways at an operating system
level before it replaces it with the new code.  (Ok, since every
contemporary OS probably has "copy-on-write" semantics here, I'll
stop making OS-dependent statements of doubtful utility).
(Continue reading)

Permalink | Reply |
headers
Ville Voutilainen | 27 Mar 2012 14:29
Picon

Re: run-program :environment nil

On 27 March 2012 15:26, Mark Evenson <evenson@...> wrote:
>> Also, in a shell environment, an empty variable is not the same as an
>> inexistant variable, so I cannot just loop over all the existing
>> variables to set them to an empty string.  I see no
>> SYSTEM::%PROCESS-BUILDER-ENV-REM function…
> This sounds like you really want the ability to constructs a clean
> NEW environment.  If we were able to implement that, would your
> need to iterate through existing variables disappear?

We could just as well evaluate all the options, which are roughly

1) merged environment
2) clean environment
3) allow editing/removing variables from either
Permalink | Reply |
headers
Ville Voutilainen | 27 Mar 2012 14:29
Picon

Re: [armedbear-devel] run-program :environment nil

On 27 March 2012 15:26, Mark Evenson <evenson <at> panix.com> wrote:
>> Also, in a shell environment, an empty variable is not the same as an
>> inexistant variable, so I cannot just loop over all the existing
>> variables to set them to an empty string.  I see no
>> SYSTEM::%PROCESS-BUILDER-ENV-REM function…
> This sounds like you really want the ability to constructs a clean
> NEW environment.  If we were able to implement that, would your
> need to iterate through existing variables disappear?

We could just as well evaluate all the options, which are roughly

1) merged environment
2) clean environment
3) allow editing/removing variables from either
Permalink | Reply |
headers
Rudi Schlatte | 27 Mar 2012 15:05
Picon
Gravatar

Re: run-program :environment nil


On Mar 27, 2012, at 14:26 , Mark Evenson wrote:

> 
> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
> 
>> 
>> (lisp-implementation-version) --> "1.0.1"
>> 
>> 
>> The documentation of extensions:run-program is misleading:
>> 
>>   :environment 
>>       An alist of STRINGs (name . value) describing the new
>>       environment. The default is to copy the environment of the current
>>       process.
>> 
>> The alist doesn't describe the NEW environment, it is only MERGED into
>> the current environment.
> 
> […]
> 
> Which behavior would you prefer?
> 
> We certainly have imprecise documentation here.  The merged environment
> behavior what is easiest with the underlying JVM API which is based
> on the notion of UNIX exec().  In practice, I would venture that
> that most people would expect the merged behavior, as it is the
> common pattern for such wrappers around UNIX execv() and friends
> which have to copy the environment anyways at an operating system
(Continue reading)

Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:43
X-Face
Face
Favicon

Re: run-program :environment nil

Rudi Schlatte <rudi <at> constantly.at> writes:

> SBCL takes an explicit environment parameter, using the current
> environment by default but never merging.  This seems like a sane
> approach.

Indeed, I forgot the default case.

run-program without an environment argument would be equivalent to:

      (run-program … :environment (getenv))

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:43
X-Face
Face
Favicon

Re: [armedbear-devel] run-program :environment nil

Rudi Schlatte <rudi <at> constantly.at> writes:

> SBCL takes an explicit environment parameter, using the current
> environment by default but never merging.  This seems like a sane
> approach.

Indeed, I forgot the default case.

run-program without an environment argument would be equivalent to:

      (run-program … :environment (getenv))

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Permalink | Reply |
headers
Rudi Schlatte | 27 Mar 2012 15:05
Picon
Gravatar

Re: [armedbear-devel] run-program :environment nil


On Mar 27, 2012, at 14:26 , Mark Evenson wrote:

> 
> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
> 
>> 
>> (lisp-implementation-version) --> "1.0.1"
>> 
>> 
>> The documentation of extensions:run-program is misleading:
>> 
>>   :environment 
>>       An alist of STRINGs (name . value) describing the new
>>       environment. The default is to copy the environment of the current
>>       process.
>> 
>> The alist doesn't describe the NEW environment, it is only MERGED into
>> the current environment.
> 
> […]
> 
> Which behavior would you prefer?
> 
> We certainly have imprecise documentation here.  The merged environment
> behavior what is easiest with the underlying JVM API which is based
> on the notion of UNIX exec().  In practice, I would venture that
> that most people would expect the merged behavior, as it is the
> common pattern for such wrappers around UNIX execv() and friends
> which have to copy the environment anyways at an operating system
(Continue reading)

Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:42
X-Face
Face
Favicon

Re: run-program :environment nil

Mark Evenson <evenson <at> panix.com> writes:

> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
>
>> 
>> (lisp-implementation-version) --> "1.0.1"
>> 
>> 
>> The documentation of extensions:run-program is misleading:
>> 
>>    :environment 
>>        An alist of STRINGs (name . value) describing the new
>>        environment. The default is to copy the environment of the current
>>        process.
>> 
>> The alist doesn't describe the NEW environment, it is only MERGED into
>> the current environment.
>
> […]
>
> Which behavior would you prefer?

I agree that for usual programs, merging is useful.
On the other hand, if you mess with the environment it's often for
security considerations, and there it's better to start with a blank
slate.

I certainly expected that :environment '() provide an empty environment,
just like execle/execvpe:
(Continue reading)

Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:56
Face
Favicon

Re: run-program :environment nil


The spam filter at tiger.common-lisp.net is wonky.

http://permalink.gmane.org/gmane.lisp.armedbear.devel/2244

"Pascal J. Bourguignon"
<pjb <at> informatimago.com> writes:

> Mark Evenson <evenson <at> panix.com> writes:
>
>> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
>>
>>> 
>>> (lisp-implementation-version) --> "1.0.1"
>>> 
>>> 
>>> The documentation of extensions:run-program is misleading:
>>> 
>>>    :environment 
>>>        An alist of STRINGs (name . value) describing the new
>>>        environment. The default is to copy the environment of the current
>>>        process.
>>> 
>>> The alist doesn't describe the NEW environment, it is only MERGED into
>>> the current environment.
>>
>> […]
>>
>> Which behavior would you prefer?
>
(Continue reading)

Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:56
Face
Favicon

Re: [armedbear-devel] run-program :environment nil


The spam filter at tiger.common-lisp.net is wonky.

http://permalink.gmane.org/gmane.lisp.armedbear.devel/2244

"Pascal J. Bourguignon"
<pjb <at> informatimago.com> writes:

> Mark Evenson <evenson <at> panix.com> writes:
>
>> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
>>
>>> 
>>> (lisp-implementation-version) --> "1.0.1"
>>> 
>>> 
>>> The documentation of extensions:run-program is misleading:
>>> 
>>>    :environment 
>>>        An alist of STRINGs (name . value) describing the new
>>>        environment. The default is to copy the environment of the current
>>>        process.
>>> 
>>> The alist doesn't describe the NEW environment, it is only MERGED into
>>> the current environment.
>>
>> […]
>>
>> Which behavior would you prefer?
>
(Continue reading)

Permalink | Reply |
headers
Ville Voutilainen | 27 Mar 2012 18:41
Picon

Re: run-program :environment nil

On 27 March 2012 16:42, Pascal J. Bourguignon
<pjb@...> wrote:
> I like the following API, which is implemented in clisp.
> (getenv)        --> the current environment as an a-list.
>                    (("LC_CTYPE" . "C") ("TERM" . "/bin/bash") …)
> (getenv "TERM") --> the string value, or NIL if the variable is not
>                    present in the environment.
>                    "/bin/bash"
> (setf (getenv "LC_CTYPE") "en_US.UTF-8")
>                    changes the environment for the current process and
>                    its future children.
> (setf (getenv "LC_CTYPE") nil)

I dcn't think we can get that far. Java doesn't seem to support
environment modifications
that way, see http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#getenv%28%29
and in particular "Returns an unmodifiable string map view of the
current system environment."
Note the "unmodifiable".

We could allow setting the environment for run-program. Here's what I'd do:

1) fix the documentation of run-program to mention the environment merging
2) add a new function that can completely replace the default
environment for the program
to run, use an alist or a hash. Also add a function that can return
the full environment, for cases where you
don't want to rebuild everything.

Comments? Opinions?
(Continue reading)

Permalink | Reply |
headers
Ville Voutilainen | 29 Mar 2012 07:01
Picon

Re: run-program :environment nil

On 27 March 2012 19:41, Ville Voutilainen
<ville.voutilainen@...> wrote:
> On 27 March 2012 16:42, Pascal J. Bourguignon
<pjb@...> wrote:
>> I like the following API, which is implemented in clisp.
>> (getenv)        --> the current environment as an a-list.
>>                    (("LC_CTYPE" . "C") ("TERM" . "/bin/bash") …)
>> (getenv "TERM") --> the string value, or NIL if the variable is not
>>                    present in the environment.
>>                    "/bin/bash"
>> (setf (getenv "LC_CTYPE") "en_US.UTF-8")
>>                    changes the environment for the current process and
>>                    its future children.
>> (setf (getenv "LC_CTYPE") nil)
>
> I dcn't think we can get that far. Java doesn't seem to support
> environment modifications
> that way, see http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#getenv%28%29
> and in particular "Returns an unmodifiable string map view of the
> current system environment."
> Note the "unmodifiable".
>
> We could allow setting the environment for run-program. Here's what I'd do:
>
> 1) fix the documentation of run-program to mention the environment merging
> 2) add a new function that can completely replace the default
> environment for the program
> to run, use an alist or a hash. Also add a function that can return
> the full environment, for cases where you
> don't want to rebuild everything.
(Continue reading)

Permalink | Reply |
headers
Ville Voutilainen | 29 Mar 2012 07:01
Picon

Re: [armedbear-devel] run-program :environment nil

On 27 March 2012 19:41, Ville Voutilainen <ville.voutilainen <at> gmail.com> wrote:
> On 27 March 2012 16:42, Pascal J. Bourguignon <pjb <at> informatimago.com> wrote:
>> I like the following API, which is implemented in clisp.
>> (getenv)        --> the current environment as an a-list.
>>                    (("LC_CTYPE" . "C") ("TERM" . "/bin/bash") …)
>> (getenv "TERM") --> the string value, or NIL if the variable is not
>>                    present in the environment.
>>                    "/bin/bash"
>> (setf (getenv "LC_CTYPE") "en_US.UTF-8")
>>                    changes the environment for the current process and
>>                    its future children.
>> (setf (getenv "LC_CTYPE") nil)
>
> I dcn't think we can get that far. Java doesn't seem to support
> environment modifications
> that way, see http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#getenv%28%29
> and in particular "Returns an unmodifiable string map view of the
> current system environment."
> Note the "unmodifiable".
>
> We could allow setting the environment for run-program. Here's what I'd do:
>
> 1) fix the documentation of run-program to mention the environment merging
> 2) add a new function that can completely replace the default
> environment for the program
> to run, use an alist or a hash. Also add a function that can return
> the full environment, for cases where you
> don't want to rebuild everything.
>
> Comments? Opinions?
(Continue reading)

Permalink | Reply |
headers
Ville Voutilainen | 27 Mar 2012 18:41
Picon

Re: [armedbear-devel] run-program :environment nil

On 27 March 2012 16:42, Pascal J. Bourguignon <pjb <at> informatimago.com> wrote:
> I like the following API, which is implemented in clisp.
> (getenv)        --> the current environment as an a-list.
>                    (("LC_CTYPE" . "C") ("TERM" . "/bin/bash") …)
> (getenv "TERM") --> the string value, or NIL if the variable is not
>                    present in the environment.
>                    "/bin/bash"
> (setf (getenv "LC_CTYPE") "en_US.UTF-8")
>                    changes the environment for the current process and
>                    its future children.
> (setf (getenv "LC_CTYPE") nil)

I dcn't think we can get that far. Java doesn't seem to support
environment modifications
that way, see http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#getenv%28%29
and in particular "Returns an unmodifiable string map view of the
current system environment."
Note the "unmodifiable".

We could allow setting the environment for run-program. Here's what I'd do:

1) fix the documentation of run-program to mention the environment merging
2) add a new function that can completely replace the default
environment for the program
to run, use an alist or a hash. Also add a function that can return
the full environment, for cases where you
don't want to rebuild everything.

Comments? Opinions?
(Continue reading)

Permalink | Reply |
headers
Pascal J. Bourguignon | 27 Mar 2012 15:42
X-Face
Face
Favicon

Re: [armedbear-devel] run-program :environment nil

Mark Evenson <evenson <at> panix.com> writes:

> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
>
>> 
>> (lisp-implementation-version) --> "1.0.1"
>> 
>> 
>> The documentation of extensions:run-program is misleading:
>> 
>>    :environment 
>>        An alist of STRINGs (name . value) describing the new
>>        environment. The default is to copy the environment of the current
>>        process.
>> 
>> The alist doesn't describe the NEW environment, it is only MERGED into
>> the current environment.
>
> […]
>
> Which behavior would you prefer?

I agree that for usual programs, merging is useful.
On the other hand, if you mess with the environment it's often for
security considerations, and there it's better to start with a blank
slate.

I certainly expected that :environment '() provide an empty environment,
just like execle/execvpe:
(Continue reading)

Permalink | Reply |
headers
Mark Evenson | 27 Mar 2012 14:26
Picon
Favicon

Re: [armedbear-devel] run-program :environment nil


On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:

> 
> (lisp-implementation-version) --> "1.0.1"
> 
> 
> The documentation of extensions:run-program is misleading:
> 
>    :environment 
>        An alist of STRINGs (name . value) describing the new
>        environment. The default is to copy the environment of the current
>        process.
> 
> The alist doesn't describe the NEW environment, it is only MERGED into
> the current environment.

[…]

Which behavior would you prefer?

We certainly have imprecise documentation here.  The merged environment
behavior what is easiest with the underlying JVM API which is based
on the notion of UNIX exec().  In practice, I would venture that
that most people would expect the merged behavior, as it is the
common pattern for such wrappers around UNIX execv() and friends
which have to copy the environment anyways at an operating system
level before it replaces it with the new code.  (Ok, since every
contemporary OS probably has "copy-on-write" semantics here, I'll
stop making OS-dependent statements of doubtful utility).
(Continue reading)

Permalink | Reply |

Gmane