Re: [RFC] usage of environment variable from the command line

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Sat, Sep 22, 2007 at 09:16:38AM +0200, Eli Zaretskii wrote:
>> > Before we go ahead with this can anyone think of a better one that
>> > won't conflict with source language expressions?
>> 
>> How about env("FOO") ?  Or maybe $env("FOO"), to avoid a possibility
>> that the debuggee has a real function by the name of `env'?
>
> I like $env("FOO") or $ENV("FOO").
>
>> > Another problem is escaping.  Right now, you're supposed to be able to
>> > give either quoted strings or raw text to most commands (it
>> > varies, I posted a summary a while back).  Front ends won't know how
>> > to escape the string if you have e.g. %% in your $PWD or want to
>> > print a string containing %%.
>> 
>> The above suggestion solves this problem as well, I think.
>
> Mostly yes.  The context where environment variables would be most
> useful is in places we don't take expressions, like after the
> "file" command; we've been changing those to take quoted strings
> to handle spaces and backslashes safely, so we could allow
> backslash to escape dollar sign too.
>
> Do we want environment variable support only for things that take text
> (pathnames, filenames, string values), or do we also want it in C
> expression contexts?  If only the former, maybe $ENV(HOME) without
> the inner quotes; quotes are already special.

I think we want it in both places.  In general, the syntax for
substituting such variables into source-language expressions would
need to be language-specific to avoid changing the meaning of any
normal expression.  So that would need to be done on a
language-by-language basis.

For the other cases, this is bikesheddy of me, but why not simply
${HOME}, braces required?