Re: why is eval needed?

[Ray Andrews <rayandrews@eastlink.ca>]

On 2022-11-20 07:08, Stephane Chazelas wrote:
> zsh doesn't impose anything. "-L 2" is a string made of 4
> characters in any shell or programming language. There's no
> programming language where "-L 2" means 2 strings -L and 2.

But that's the thing, I'd naively thought the variable could be inserted 
in the command string and be 'just' a string of characters, but zsh 
imposes that 'tree' must see '-L 2' as a single entity, yes?  As shown, 
we need word splitting to solve the problem and show tree what it wants 
to see. Or, as I was speculating, some way of just flattening the string 
back to nothing more than a string of characters -- but then again, 
probably tree wouldn't like that either, perhaps the string is always 
'packaged' into words?  If so, then there's no avoiding that we must 
word-split '-L 2' into two words and there's nothing to wish for.


> That is a very weird feature from a language design point of
> view. Anybody who doesn't know what the shells looked like
> before the Bourne shell would think Stephen Bourne was out of
> his mind.
>
It's what happens when functionality expands by accretion -- simple 
structures no longer suffice but they are tweaked rather than 
rethought.  It's like the difference between the layout of Paris vs. 
London.
> My understanding is that the Bourne shell's bizarre IFS handling
> and the fact that globbing was performed upon parameter
> expansion was an attempt to keep some level of backward
> compatibility with that Thompson shell. You see similar things
> hapenning in csh from the same era.
The dilemma of compatibility!  No easy answers.  I myself tend towards a 
'garage to the dump' mentality but it's not that simple.
> The Korn shell (from the early 80s) kept most of that with the
> exception that it only did IFS-splitting upon expansions, not on
> literal text.
Holy cow!  IFS splitting in text??
> The fact that in sh/ksh/bash:
>
> arg='-L 1'
> tree $arg
>
> Calls tree with "-L" and "1" as arguments is not that bash
> doesn't do some sort of magic "grouping" that zsh would be
> doing, but that ksh/bash contrary to zsh does that extra layer
> of $IFS-splitting from the Bourne shell on top of the syntax
> parsing as the default value of $IFS happens to contain the
> space character.
Ah!  So my little issue is a zsh exclusive?  Not complaining tho, I 
don't like zsh doing things I didn't ask it to do so if in this case I 
need to request a word split that's just fine.  After all it's tree 
that's being difficult so the problem is rare and easily solved.
> That's why in sh/bash/ksh you almost always need to quote
> parameter expansions if you intend to pass the contents of a
> variable as an argument to a command.
>
> See
> https://unix.stackexchange.com/questions/171346/security-implications-of-forgetting-to-quote-a-variable-in-bash-posix-shells
> for the kind of thing that  can happen if you forget.
Heavy.  That's the closest I've come to understanding those vulnerabilities.
>
> If you want to assemble a string, and that string to be
> evaluated as shell code, that's what eval is for. eval evaluate
> code written in the shell language. That's a way  to dynamically
> invoke the language interpreter.
Ok, so I understood that correctly.  At least partially.
> What are you doing there?  I have no 'nm' command here.  No such command in
> Debian repository.
> nm is a standard development command (though not -D which AFAIK
> is a GNU extension). Part of GNU binutils on GNU systems.
Ah, that's why I can't find it.  It's hard to find commands so packaged.
> Note that tree is not part of the GNU project, it's just a
> utility written by some guy and shared to the world. There is
> *some* level of consistency among utilities in the GNU
> toolchest. There is even such a thing as published GNU coding standards.
> See for instance
> https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces
Yeah, tides of organization wash here and there.  No overall commander 
tho, so a bit of chaos is unavoidable.
> I'll agree with you that the lack of consistency in API between the
> different tools that are available out there can be annoying
> (nothing to do with GNU or Linux)
You know, half of it is just cultural adaptation.  When I first started 
with Linux the first thing I did was decide between zsh and bash and I'm 
basically assuming that Linux will be like DOS but slightly more 
powerful and zsh will be like C and that all Linux OS apps will be as 
flawless as WordPerfect 5.1.  CRASH!  Now that I'm used to being in a 
bazaar not a monastery it's easier to get around.  One does get mud on 
one's shoes.
> eval evaluates shell code. I struggle to understand what you
> don't understand. Maybe you're thinking too much or too little
> of what a "command line string" is. A "command line string"
> like:

I think at this level of my education it's enough to say that eval looks 
at it's arguments as if they were typed on the command line.  I haven't 
really 'understood' anything, I use eval ad hoc when it seems to solve 
problems.  Using it with real understanding is a future goal.


> For that string to be passed as code to the shell language
> interpreter for it to interpret.

Right, I get that:


2 /aWorking/Zsh/Source/Wk 0 $ var="echo howdy"

2 /aWorking/Zsh/Source/Wk 0 $ eval $var
howdy

> Again, tree has nothing to do with the GNU project.

I dunno, I get it all from Debian and Debian is a GNU/Linux OS so I 
don't know more than that.


Thanks for a most educational post!  I love these history lessons, they 
inform my entire outlook.  You can't understand where you are unless you 
understand where you've been.