[RFC] usage of environment variable from the command line

[RFC] usage of environment variable from the command line

[Denis PILAT]

Hi,

I have a patch that allows to use environment variable when typing commands.
Environment variable must be surrounded by "%%" string.
(Ex: "file %%REPOSITORY%%/obj/a.out" would be supported.)


Is there any chance that such a patch could be accepted ?
I've read from the gdb mailing list that I'm not the only one who wants 
to handle environment variable from the command line.

Thanks for your feedback,
--
Denis

Index: top.c
===================================================================
--- top.c       (revision 598)
+++ top.c       (working copy)
@@ -370,6 +370,46 @@ do_chdir_cleanup (void *old_dir)
 }
 #endif

+#define ENV_DELIMITOR  "%%"
+static char*
+evaluate_environment_from_string(char* input)
+{
+  char *p1, *p2, *output, *env_var, *env_var_value;
+  int   env_var_len;
+
+
+  p1 = (char *) strstr (input, ENV_DELIMITOR);
+  if (p1 == NULL)
+    return input;
+
+  p2 = (char *) strstr (p1+1, ENV_DELIMITOR);
+  if (p2 == NULL)
+    return input;
+
+  /* get the env var.  */
+  env_var_len = p2 - p1 - strlen(ENV_DELIMITOR);
+  env_var = xmalloc (env_var_len + 1);
+  strncpy (env_var, p1 + strlen(ENV_DELIMITOR), env_var_len);
+  env_var[env_var_len] = 0;
+
+  /* get its value.  */
+  env_var_value = getenv (env_var);
+  if (env_var_value == NULL) {
+    xfree (env_var);
+    return input;
+  }
+
+  /* replace this value into the original string.  */
+  output = xmalloc (strlen (input) + strlen (env_var_value) - env_var_len - 2*strlen(ENV_DELIMITOR) + 1);
+  strncpy (output, input, p1-input);
+  strcpy  (output+(p1-input), env_var_value);
+  strcat  (output+(p1-input), p2 + strlen(ENV_DELIMITOR));
+
+  xfree (env_var);
+  return evaluate_environment_from_string(output);
+}
+
+
 /* Execute the line P as a command.
    Pass FROM_TTY as second argument to the defining function.  */

   /* Force cleanup of any alloca areas if using C alloca instead of
@@ -391,6 +431,8 @@ execute_command (char *p, int from_tty)
   if (p == NULL)
     return;

+  p = evaluate_environment_from_string (p);
+
   serial_log_command (p);

   while (*p == ' ' || *p == '\t')

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

[Daniel Jacobowitz]

On Wed, Sep 19, 2007 at 05:24:26PM +0200, Denis PILAT wrote:
> Hi,
> 
> I have a patch that allows to use environment variable when typing commands.
> Environment variable must be surrounded by "%%" string.
> (Ex: "file %%REPOSITORY%%/obj/a.out" would be supported.)
> 
> 
> Is there any chance that such a patch could be accepted ?
> I've read from the gdb mailing list that I'm not the only one who wants to 
> handle environment variable from the command line.

I think it would probably be useful to allow if we can find a way that
won't break something else.

I think that syntax is really ugly :-( Before we go ahead with this
can anyone think of a better one that won't conflict with source
language expressions?

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 %%.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Fri, 21 Sep 2007 18:55:27 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org
> 
> I think that syntax is really ugly :-(

Yes, because it comes from the DOS/Windows shell syntax.  I don't
think we should use it, as it makes trouble even in the Windows shell.

> 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'?

> 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.

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

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Denis PILAT]

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.
>
>   

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

[Jim Blandy]

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?

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

[Eli Zaretskii]

> Cc: denis.pilat@st.com,  gdb-patches@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 24 Sep 2007 09:43:54 -0700
> 
> For the other cases, this is bikesheddy of me, but why not simply
> ${HOME}, braces required?

Because it requires a change to the expression parser (at least in C)?

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

[Jim Blandy]

Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: denis.pilat@st.com,  gdb-patches@sourceware.org
>> From: Jim Blandy <jimb@codesourcery.com>
>> Date: Mon, 24 Sep 2007 09:43:54 -0700
>> 
>> For the other cases, this is bikesheddy of me, but why not simply
>> ${HOME}, braces required?
>
> Because it requires a change to the expression parser (at least in C)?

When I said, "For the other cases", I meant the cases other than
source-language expressions: filenames for commands like 'file' and
'cd', breakpoint locations like 'foo.c:12', and so on.

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

[Eli Zaretskii]

> Cc: denis.pilat@st.com,  gdb-patches@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 25 Sep 2007 10:11:44 -0700
> 
> 
> When I said, "For the other cases", I meant the cases other than
> source-language expressions

Sorry for my misunderstanding.

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

[Daniel Jacobowitz]

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

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

[Eli Zaretskii]

> Date: Sat, 29 Sep 2007 21:29:55 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, denis.pilat@st.com,
> 	gdb-patches@sourceware.org
> 
> Why not define ${...}, or something similar, to do textual expansion
> before the language parsers get to it?

Fine with me.

> 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.

Right.  Can you suggest such a specification?

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

[Daniel Jacobowitz]

On Sun, Sep 30, 2007 at 09:16:57AM +0200, Eli Zaretskii wrote:
> > 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.
> 
> Right.  Can you suggest such a specification?

Since I haven't yet, I'm afraid I can't - I have too many projects
already.  It should not be too hard to write one, though.

-- 
Daniel Jacobowitz
CodeSourcery

[RFC] usage of environment variable from the command line

[Denis PILAT]

Hi everyone,

I'going back to the patch proposed a few months ago.

I'm now having a patch that use the suggested syntax "${...}" and 
transform commands at the beginning of top.c/execute_command() only if 
the  ${...} match an environment variable.
It works as well for scripts that can contains env. variables.
Anything from the command line is transformed, there is no limit to the 
kind of commands that can use env. variables.

Attached is the patch, I know that you won't accept it but it's just to 
discuss. I guess it's not generic enough and may be does not cover some 
language ..., but what's sure is that it does not involved any 
regression in the full testsuite.

The old discussion was here: 
http://sources.redhat.com/ml/gdb-patches/2007-09/msg00430.html
My point is:
- What do you mean by a specification ?
- You also told about quoting issues, could you please be more precise ? 
I don't see any issue in my patch (like in every patches I've done ... ;-) )

Thanks,
Denis

Index: top.c
===================================================================
--- top.c       (revision 624)
+++ top.c       (working copy)
@@ -364,6 +364,49 @@ do_chdir_cleanup (void *old_dir)
 }
 #endif

+
+#define ENV_DELIMITOR_BEGIN  "${"
+#define ENV_DELIMITOR_END  "}"
+static char*
+evaluate_environment_from_string(char* input)
+{
+  char *p1, *p2, *output, *env_var, *env_var_value;
+  int env_var_len, delimitor_begin_len, delimitor_end_len;
+
+  p1 = (char *) strstr (input, ENV_DELIMITOR_BEGIN);
+  if (p1 == NULL)
+    return input;
+
+  p2 = (char *) strstr (p1+1, ENV_DELIMITOR_END);
+  if (p2 == NULL)
+    return input;
+
+  delimitor_begin_len = strlen(ENV_DELIMITOR_BEGIN);
+  delimitor_end_len = strlen(ENV_DELIMITOR_END);
+  /* get the env var.  */
+  env_var_len = p2 - p1 - delimitor_begin_len;
+  env_var = xmalloc (env_var_len + 1);
+  strncpy (env_var, p1 + delimitor_begin_len, env_var_len);
+  env_var[env_var_len] = 0;
+
+  /* get its value.  */
+  env_var_value = getenv (env_var);
+  if (env_var_value == NULL) {
+    xfree (env_var);
+    return input;
+  }
+
+  /* replace this value into the original string.  */
+  output = xmalloc (strlen (input) + strlen (env_var_value) - env_var_len - delimitor_begin_len - delimitor_end_len + 1);
+  strncpy (output, input, p1-input);
+  strcpy  (output+(p1-input), env_var_value);
+  strcat  (output+(p1-input), p2 + delimitor_end_len);
+
+  xfree (env_var);
+  return evaluate_environment_from_string(output);
+}
+
+
 /* Execute the line P as a command.
    Pass FROM_TTY as second argument to the defining function.  */

@@ -385,6 +428,8 @@ execute_command (char *p, int from_tty)
   if (p == NULL)
     return;

+  p = evaluate_environment_from_string (p);
+
   serial_log_command (p);

   while (*p == ' ' || *p == '\t')

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

[Eli Zaretskii]

> Date: Fri, 21 Dec 2007 15:31:12 +0100
> From: Denis PILAT <denis.pilat@st.com>
> Cc: gdb-patches@sourceware.org
> 
> The old discussion was here: 
> http://sources.redhat.com/ml/gdb-patches/2007-09/msg00430.html
> My point is:
> - What do you mean by a specification ?

That question was directed at Daniel, not you.

> - You also told about quoting issues, could you please be more precise ? 

That was Daniel, so he should respond.  I guess he meant literal "${"
strings, which could legitimately be part of input.

> +#define ENV_DELIMITOR_BEGIN  "${"
> +#define ENV_DELIMITOR_END  "}"

Please use DELIMITER, not DELIMITOR.

> +  int env_var_len, delimitor_begin_len, delimitor_end_len;
                      ^^^^^^^^^            ^^^^^^^^^
Same here.

> +  delimitor_begin_len = strlen(ENV_DELIMITOR_BEGIN);
> +  delimitor_end_len = strlen(ENV_DELIMITOR_END);

Coding style: a space between function's name and the left
parenthesis.

> +  /* replace this value into the original string.  */
> +  output = xmalloc (strlen (input) + strlen (env_var_value) - env_var_len - delimitor_begin_len - delimitor_end_len + 1);

This line is too long, please break into two.

> +  p = evaluate_environment_from_string (p);

Are we perhaps leaking memory pointed to by `p' before the above line
executes?