[Gambas-user] EXEC vs. SHELL

[Benoît Minisini]

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

I added this answer to the wiki, at http://gambasdoc.org/help/doc/shellexec.

Regards,

-- 
Benoît