[Gambas-user] EXEC vs. SHELL

[Doriano Blengino]

Rolf-Werner Eilert ha scritto:
> Could someone explain me why there are two different ways of executing 
> shell commands and how they differ in practice? I mean, when do I want 
> EXEC and when will I want SHELL? What's the idea behind them?
>
> Thanks for all hints :-)
>   
SHELL invokes /bin/sh and passes it a single command line. /bin/sh 
parses this command line exactly the same way you do on a normal shell. So,

    SHELL "ls -l *.o >/tmp/list"

will do exactly the same as you typed "ls -l *.o >/tmp/list" in a 
terminal emulator under a shell. This is a lot of things, because the 
shell has a tremendous power. This command does:

    1. split the command line in several parts: executable to run, 
parameters to pass it, other constructs...
    2. search for an executable named ls in the PATH environment.
    3. substitute "*.o" with all the ".o" files in the current directory
    4. prepare a redirection (the normal output of /bin/ls is redirected 
in /tmp/list)

To make it short, the shell can do a lot of things, and the gambas SHELL 
command brings that power to you.
After /bin/sh has done with all this parsing/computing work, it invokes 
an exec() system call, which loads and executes an executable, passing 
it a number of parameters.

The gambas EXEC instruction calls the exec() system call, bypassing the 
shell (/bin/sh). This is faster and less memory hungry, because you 
invoke an external command without invoking /bin/sh, but you loose all 
the power the shell has. In fact, if you want to list all the ".o" files 
in the current directory and put the result in /tmp/list without using 
the powerful shell, you have to:

    1. search by yourself the files
    2. create an array of the names of those files
    3. invoke /bin/ls and pass it an array which contains the "-l" and 
all the files
    4. redirect its standard output in a file

To conclude. If you run an EXEC in gambas, you must simply supply the 
program name to execute and all its parameter. If you issue:

    EXEC ["/bin/ls", "-l", "*.o", ">/tmp/list"]

you will invoke /bin/ls passing it the above parameters. /bin/ls will 
(correctly) recognize the "-l" as a switch; but "*.o" and ">/tmp/list" 
will be recognized as files to look for, and no files named "*.o" will 
exist. The ">/tmp/list" is a shell syntax, not a /bin/ls one, and 
/bin/ls will look again to for file named ">/tmp/list".

You can type "man sh" at the shell prompt; all of what you will read 
there are shell capabilities, and none of them are available in EXEC. 
The three most important things which are available in the shell, and 
not available in EXEC are:

    1. Pattern substitution. *.o and the like are shell construct.
    2. Redirections and pipes. ">/...", "</...", "2>&1 |some_command" 
and so on.
    3. Variables like $HOME, $PATH and so on

But exec has a good advantage over SHELL. If you have to invoke an 
external command which has (or can have) unusual characters in the 
command line, like "firefox 
http://someserver.com/doit.cgi?name=foo&reply=bar", SHELL (or, better, 
/bin/sh) will interpret characters like "?" and "&", whilst EXEC will not.

The reply to your answer is: if you need some shell capability, use 
SHELL; otherwise use EXEC. Using SHELL saves typing, on the other hand, 
if you are sure that no strange characters ("?", "&", "$", spaces, and 
others) can appear in the command you are constructing.

Hope this is a good start - regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."