On 10/10/14, 5:45 PM, Leandro Lucarella wrote:
> I still don't understand why wouldn't we use environment variables for
> what they've been created for, it's foolish:-)

I, too, think envvars are quite appropriate here. -- Andrei

On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
> I still don't understand why wouldn't we use environment variables for
> what they've been created for, it's foolish :-)

Because using environment variables to tune program X will also affect programs A-Z.

On 10/10/14, 7:54 PM, Walter Bright wrote:
> On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
>> I still don't understand why wouldn't we use environment variables for
>> what they've been created for, it's foolish :-)
>
> Because using environment variables to tune program X will also affect
> programs A-Z.

Nope. Try this at your Unix command prompt:

echo $CRAP
CRAP=hello echo $CRAP
CRAP=world echo $CRAP


Andrei

On 10/10/2014 9:25 PM, Andrei Alexandrescu wrote:
> On 10/10/14, 7:54 PM, Walter Bright wrote:
>> On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
>>> I still don't understand why wouldn't we use environment variables for
>>> what they've been created for, it's foolish :-)
>>
>> Because using environment variables to tune program X will also affect
>> programs A-Z.
>
> Nope. Try this at your Unix command prompt:
>
> echo $CRAP
> CRAP=hello echo $CRAP
> CRAP=world echo $CRAP

Windows doesn't work like that.

Am 11.10.2014 06:25, schrieb Andrei Alexandrescu:
> On 10/10/14, 7:54 PM, Walter Bright wrote:
>> On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
>>> I still don't understand why wouldn't we use environment variables for
>>> what they've been created for, it's foolish :-)
>>
>> Because using environment variables to tune program X will also affect
>> programs A-Z.
>
> Nope. Try this at your Unix command prompt:
>
> echo $CRAP
> CRAP=hello echo $CRAP
> CRAP=world echo $CRAP

in windows there are user-environment-variables (walter talking about) and shell-environment variables (like in your example)
setting user-environement variables will affect every program
thats why java is not using them

Am 11.10.2014 um 06:43 schrieb dennis luehring:
> Am 11.10.2014 06:25, schrieb Andrei Alexandrescu:
>> On 10/10/14, 7:54 PM, Walter Bright wrote:
>>> On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
>>>> I still don't understand why wouldn't we use environment variables for
>>>> what they've been created for, it's foolish :-)
>>>
>>> Because using environment variables to tune program X will also affect
>>> programs A-Z.
>>
>> Nope. Try this at your Unix command prompt:
>>
>> echo $CRAP
>> CRAP=hello echo $CRAP
>> CRAP=world echo $CRAP
>
> in windows there are user-environment-variables (walter talking about)
> and shell-environment variables (like in your example)
> setting user-environement variables will affect every program
> thats why java is not using them
>

And lets not forget about OS/400 or any of the other non-POSIX systems out there, unless D is never expected to target such OSs.

--
Paulo

Paulo Pinto, el 11 de October a las 10:50 me escribiste:
> Am 11.10.2014 um 06:43 schrieb dennis luehring:
> >Am 11.10.2014 06:25, schrieb Andrei Alexandrescu:
> >>On 10/10/14, 7:54 PM, Walter Bright wrote:
> >>>On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
> >>>>I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-)
> >>>
> >>>Because using environment variables to tune program X will also affect programs A-Z.
> >>
> >>Nope. Try this at your Unix command prompt:
> >>
> >>echo $CRAP
> >>CRAP=hello echo $CRAP
> >>CRAP=world echo $CRAP
> >
> >in windows there are user-environment-variables (walter talking about)
> >and shell-environment variables (like in your example)
> >setting user-environement variables will affect every program
> >thats why java is not using them
> 
> And lets not forget about OS/400 or any of the other non-POSIX systems out there, unless D is never expected to target such OSs.

You can use different mechanisms in different OSs. There is no need to force a runtime to be OS-independent. If that were the case, then we should close the concurrent GC pull request now.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Y vos, me dijiste que soy, un abismo de silencio.
Será, porque vos no escuchas, que yo grito por dentro.

On 10/11/2014 3:59 PM, Leandro Lucarella wrote:
> You can use different mechanisms in different OSs. There is no need to
> force a runtime to be OS-independent. If that were the case, then we
> should close the concurrent GC pull request now.

I still don't see why it can't use a special argument to the C main() function.

Andrei Alexandrescu, el 10 de October a las 21:25 me escribiste:
> On 10/10/14, 7:54 PM, Walter Bright wrote:
> >On 10/10/2014 5:45 PM, Leandro Lucarella wrote:
> >>I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-)
> >
> >Because using environment variables to tune program X will also affect programs A-Z.
> 
> Nope. Try this at your Unix command prompt:
> 
> echo $CRAP
> CRAP=hello echo $CRAP
> CRAP=world echo $CRAP

Your example is actually broken, because this is parsed by the shell separately, CRAP=hello is passed as an env variable to the echo command but the $CRAP expansion is evaluated before the command is called, so it will always have the value that had before every echo call (which is empty if you didn't define it before running those 3 commands).

But try this for example: LANG=nonexistent perl /dev/null And see how your perl complaints.

But anyway, yeah, that's the idea, there are many ways to define environment variables, and usually you never do so globally (except for things that you really want to affect the whole system, like the language). That doesn't mean you can't override it for a particular program.

You can also create scripts to run programs, this is how Firefox runs for example:

---
$ file /usr/bin/firefox
/usr/bin/firefox: symbolic link to `../lib/firefox/firefox.sh'
$ file /usr/lib/firefox/firefox.sh
/usr/lib/firefox/firefox.sh: POSIX shell script, ASCII text executable
$ grep -v '^#' /usr/lib/firefox/firefox.sh | head

set -e



MOZ_LIBDIR=/usr/lib/firefox
MOZ_APP_LAUNCHER=`which $0`
MOZ_APP_NAME=firefox
MOZ_DEFAULT_PROFILEDIR=.mozilla/firefox
MOZ_PROFILEDIR=.mozilla/firefox

---

It basically defines a bunch of environment variables and run the binary. This is a super common practice in posix systems. We are not inventing anything here. I don't know how windows or other OSs deal with defining environment variables in a script.

Very basic facilities are always configured this way, for example try man 3 mallopt to see how can you change options in the malloc implementation using environment variables...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Ladrón no es cualquiera, ladrón es quien usurpa el bien ajeno en
beneficio propio, si no, no.
	-- Ricardo Vaporeso

On 10/11/2014 4:23 PM, Leandro Lucarella wrote:
> It basically defines a bunch of environment variables and run the
> binary. This is a super common practice in posix systems. We are not
> inventing anything here. I don't know how windows or other OSs deal with
> defining environment variables in a script.
>
> Very basic facilities are always configured this way, for example try
> man 3 mallopt to see how can you change options in the malloc
> implementation using environment variables...
>

I don't deny it is common practice on Linux, but defining a bunch of environment variables and then running the app, i.e. using the ev's as command line switches, seems pointless. Just use command line switches.

Anyhow, environment variables are a common source of problems on Windows, which is why dmd, for example, uses dmd.conf instead.