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

[Denis PILAT <denis.pilat@st.com>]

Sorry for the "ugly" syntax, my point was more about the possibility to 
use env. variable than the syntax itself which, I admit, is ugly.

My needs are only about text replacement, so $ENV(HOME) syntax is fine.
Do you like a  new patch ? Or shall we discuss more about it ?

-- 
Denis

Daniel Jacobowitz wrote:
> 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.
>
>