From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6980 invoked by alias); 24 Sep 2007 15:05:04 -0000 Received: (qmail 6971 invoked by uid 22791); 24 Sep 2007 15:05:03 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog12.obsmtp.com (HELO s200aog12.obsmtp.com) (207.126.144.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Sep 2007 15:05:01 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Mon, 24 Sep 2007 15:04:55 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E5F63DAC0; Mon, 24 Sep 2007 15:04:50 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 6CBD04C20F; Mon, 24 Sep 2007 15:04:50 +0000 (GMT) Received: from crx595.cro.st.com (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.7.5a-GA) with ESMTP id CLR19443 (AUTH "denis pilat"); Mon, 24 Sep 2007 17:04:48 +0200 (CEST) Message-ID: <46F7D210.3060704@st.com> Date: Mon, 24 Sep 2007 15:05:00 -0000 From: Denis PILAT User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Eli Zaretskii , denis.pilat@st.com, gdb-patches@sourceware.org Subject: Re: [RFC] usage of environment variable from the command line References: <46F13F2A.8010507@st.com> <20070921225527.GA28500@caradoc.them.org> <20070922135839.GA6285@caradoc.them.org> In-Reply-To: <20070922135839.GA6285@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00342.txt.bz2 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. > >