Re: Request for comments: string variable patchset 2

[Juergen W. <wie...@fr...>]

On Monday 25 October 2004 00:38, Ethan Merritt wrote:
> I did figure out how to implement a gnuplot function
>    <string-value> = command(<string-expression>)
> but I have serious reservations about it.
> (1) it leaks memory (probably fixable, but so far I haven't
> figured out how)
> (2) it makes me really uneasy that you could trigger evaluation
> of this function from, say, inside a plot statement:
> 	plot <foo> 1:using (command("something expensive"))
> This could, to say the least, consume system resources.

I didn't thought of that, you're right.  There could be a warning in
the docs to command(), and anybody dumb enough to try it
nevertheless gets what he deserves.  But this probably is indeed not
an ideal solution.

> So instead I offer the following alternative proposal.
> I have updated the patchset on SourceForge to include the
> following variant syntax
> 	@"stringvar"  evaluates to "contents of stringvar"
> That is, it evaluates the stringvar and places the value in
> double-quotes.
>
> For string constants this is a complicated no-op.
> E.g.
> 	a = "string constant blah blah"
> 	b = a
> 	c = @"a"
>
> a, b, and c now contain identically the same string.
> But when back-tics are involved it becomes more interesting.
>
> > I need something like
> >
> >   gawkcall = sprintf("gawk -f getname %i %s", this_index,
> > filename) name = execute(gawkcall)
>
> With the new syntax, you would do this as follows:
> 	gawkcall = sprintf( '` gawk -f getname %i %s `', ...)
> 	show var
> 		gawkcall = ` gawk -f getname ... `
> 	name = @"gawkcall"
>

Which does essentially the same as

  gawkcall = sprintf('"` gawk -f getname %i %s `"', ...)
  name = @gawkcall

right?  I haven't thought of this before seeing your @"var" syntax.

> Note that the sprintf call uses single-quote + back-tic to
> delimit the command string.
>
> name becomes a string variable containing the output from
> executing the shell command in gawkcall.
>
> What do you think?  Is this sufficient, or is there still a need
> for an actual function command("foo")?

It suffices /my/ needs.  Obviously, it was OK before, too, I just
didn't see it.  Thus, should be some examples in the docs.

But I like the syntax of command("foo") much more.  It seems cleaner
to me because there is no detour through the parser.  There are
no problems if the input or output contains quotes. And it's easier 
to
understand.  But once more: It's fine as it is.

Juergen