From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14963 invoked by alias); 30 Sep 2007 01:30:01 -0000 Received: (qmail 14955 invoked by uid 22791); 30 Sep 2007 01:30:00 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 30 Sep 2007 01:29:58 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 64A8D9832B; Sun, 30 Sep 2007 01:29:56 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 1EF4B98109; Sun, 30 Sep 2007 01:29:56 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1Ibnd5-0007hO-8T; Sat, 29 Sep 2007 21:29:55 -0400 Date: Sun, 30 Sep 2007 01:30:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Eli Zaretskii , denis.pilat@st.com, gdb-patches@sourceware.org Subject: Re: [RFC] usage of environment variable from the command line Message-ID: <20070930012955.GA29254@caradoc.them.org> Mail-Followup-To: Jim Blandy , Eli Zaretskii , denis.pilat@st.com, gdb-patches@sourceware.org References: <46F13F2A.8010507@st.com> <20070921225527.GA28500@caradoc.them.org> <20070922135839.GA6285@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00429.txt.bz2 On Mon, Sep 24, 2007 at 09:43:54AM -0700, Jim Blandy wrote: > 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? I don't want to use something as generic as ${} for Unix environment variables, because we might want a more general expansion. Why not define ${...}, or something similar, to do textual expansion before the language parsers get to it? Then I also have a patch I can submit to let us define string variables more usefully; we can substitute them in without quotes in this context, and so use them for filenames. If we pick the syntax cleverly we can use it to call scripting language functions too. Although sometimes I'd want those to produce GDB "struct value" rather than a text string, so we'd still need both... Yes, there's lots of quoting issues doing it this way. I'd want a more formal specification of when this expansion happened and what it produced before we did it. It should probably be specific to the CLI interpreter and not happen to MI input (excluding interpreter-exec of course). -- Daniel Jacobowitz CodeSourcery