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

Re: semantics and portability

This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.

>>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:

>> >>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:
Marc> No.  All I am saying is that the process started to run the underlying
Marc> interpreter should have the same (shell) environment as the one of
Marc> "scheme-script".
>> After rereading this, I'm still not sure I get it.  "scheme-script"
>> *is* the underlying interpreter, no?

Marc> Well it could be the executable for the interpreter, but it could also
Marc> be a shell script that execs the appropriate underlying interpreter
Marc> (Gambit, Scheme48, etc) after doing some administrative checks (that
Marc> the user has permission to run the interpreter, logging the use of
Marc> a Scheme script, or whatever).  For example, I can perfectly imagine
Marc> Gambit's interpreter to reside in "gsi" and "scheme-script"
Marc> is a shell script like this

Marc>    #! /bin/sh
Marc>    ... parse command line options BUT DON'T CHANGE THE ENVIRONMENT!
Marc>    exec gsi ...

Hmmm, what do we do to help Scheme implementations like PLT whose
front-end script *needs* to set internally used environment variables
like PLTHOME or PLTCOLLECTS?  This is unlikely to interfere with the
script, but it sure breaks the guarantee you're suggesting.

I'm searching for some wording in the
SRFI 22, and haven't come up with anything that fits yet.

Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla