CODEWITHSUNDEEP
stringevalcsh
JDS
JDS

Reputation: 16998

Csh eval statement?

I'm trying to understand how the eval statement works. Here's a snippet of code I'm looking at that I don't understand:

    eval `$SOME_DIR/util/dbget.pl \
          VARIABLE1 \
          VARIABLE2 \
          VARIABLE3 \
          VARIABLE4 `

Anyways my initial idea after some research is that eval just literally types in those strings in the command line, meaning it runs the .pl script, then... I'm not sure what it's doing with those variables. The comment above this code said "get a few parameters" but I'm not sure what that means.

Does eval 'VARIABLE' initialize the variable? This seems to be the case because after the eval the code goes on to use these variables as if they're now initialized (does if statement checks, etc).

I'm clearly new to this kind of scripting and just jumping into a large repository. Thanks for any help.

Upvotes: 0

Views: 19282

Answers (2)

Keith Thompson
Keith Thompson

Reputation: 263537

Both eval and the backtick syntax are explained in the csh man page.

If you're on a Linux system, it's likely that csh is really tcsh, an enhanced version of the original csh C-shell. These particular features are the same in both csh and tcsh. The backtick syntax invokes what's called "command substitution".

Quoting the tcsh man page on my system (with some minor tweaks to avoid markdown's special treatment of the backtick character):

Command subsitution

Command substitution is shown by a command enclosed in [backticks]. The output from such a command is normally broken into separate words at blanks, tabs, and newlines, with null words being discarded; this text then replaces the original string. Within double quotes ("), only newlines force new words; blanks and tabs are preserved.

In any case, the single final newline does not force a new word. Note that it is thus possible for a command substitution to yield only part of a word, even if the command outputs a complete line.

And:

eval arg ...

(As in sh(1).) The arguments are read as input to the shell and the resulting command(s) executed in the context of the current shell. This is usually used to execute commands generated as the result of command or variable substi‐ tution, since parsing occurs before these substitutions. See tset(1) for an example of using eval.

Upvotes: 0

Mark Reed
Mark Reed

Reputation: 95325

Ok, the backticks are replaced with the output of the command between them.

The eval takes that output and executes it as if typed.

In this case I assume the perl is printing out some variable assignments, like set VARIABLE1=value1 or setenv VARIABLE1 value1. In which case, after the above eval, you should have $VARIABLE1 available to later csh code.

Just running the .pl script (which I assume is Perl) without the eval would not affect the environment of the csh process. By using eval, you're giving the Perl code permission to modify that environment.

This means the Perl has to know that its output is intended for csh, btw. In sh/bash the syntax of variable assignment is different.

ETA More attempted clarification:

If you do this:

$SOME_DIR/util/dbget.pl

You get a bunch of variable assignment statements printed to your screen. This is not useful, and has no effect whatsoever on the actual variables in your shell.

If you do this:

echo `$SOME_DIR/util/dbget.pl`

You get the same result in a more roundabout fashion: instead of the perl code printing directly to your screen, it's printing into an expression that gets passed to the csh echo command, and then the echo is what does the actual printing to the screen. That distinction is subtle, but important: the backticks take control away from the perl and put it back in the hands of the shell. Once the shell has captured the output, it can store it in a variable, write it into a file, or do lots of other things with it that the Perl code doesn't have to be rewritten to deal with. The Perl is still just printing.

If you do this:

eval `$SOME_DIR/util/dbget.pl`

Then what the shell does is execute the output of the Perl as if it were typed at the prompt. This is very powerful. It's also dangerous, because the surrounding program winds up executing code that the person who wrote that program has never seen. So you have to trust the source of that code (in this case the perl script) not to produce anything damaging (intentinonally or otherwise).

Upvotes: 3

Related Questions