[Gambas-user] EXEC vs. SHELL

[Benoît Minisini]

> >>>> 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 invoke /bin/sh and pass it a single command line. /bin/sh
> parse this command line the same way it does on a regular shell,
> thus
>
> >>>>     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:
>
> will do the same as if you typed: "ls -l *.o >/tmp/list" in a
> terminal emulator.  This is very useful because the
>
> SHELL command is powerful. This simple line do:
> >>>>     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)
>
> 1. split command line in several parts: executable,
>    parameters, other stuffs...
> 2. search for "ls" executable in environment PATH,
> 3. substitute "*.o" with all ".o" files in current directory,
> 4. prepare a redirection (the normal /bin/ls output (stdouput) is
> redirected to /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.
>
> 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 is done with parsing & computing work, it invokes
> an exec() system call which load and run a program, passing
> it 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:
>
> Gambas EXEC instruction call the exec() system call, bypassing the
> shell (/bin/sh). This is faster and less memory hungry because you
> run an external command without invoking /bin/sh, but you loose the whole
> shell's power.  As a matter of fact, if you want to list all the ".o" files
> from the current directory and put the result in /tmp/list without using
>
> 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
>
> 1. search files by yourself,
> 2. create a files names' array out of these files,
> 3. invoke /bin/ls and pass it an array which contains "-l" and
>     the files names' array
> 4. redirect its standard output to 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:
>
> In conclusion, if you run Gambas' EXEC you just supply it the
>
> program's name to run and its parameters. 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'll invoke /bin/ls passing it the aforementioned parameters. /bin/ls
> will recognize "-l" as one of its switches; but "*.o" and ">/tmp/list"
> will be recognized as files to look after (no file named "*.o" can exist,
> as "*" is a wilcard character meaning "all".)
> ">/tmp/list" is a shell syntax, not especially a /bin/ls one;
> /bin/ls will make a redirection (the ">" character) toward /tmp/list file,
> creating it if it doesn't exist, squashing it if already there.
>
> >>>> 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:
>
> For information you can type: man sh at shell prompt.  This will show you
> the shell's whole information and syntax but none of them are available
> from the EXEC command.  The most important three things available from
> shell and
>
> not available from 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
>
> 1. Pattern substitution.  *.o and others are shell patterns,
> 2. Redirections and pipes. ">/...", "</...", "2>&1 | some_command"
>     etc,
> 3. Environment variables, such as $HOME, $PATH, etc.
>
> >>>> 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.
>
> But EXEC have benefits against SHELL. If you have to invoke an
> external command which have (or may have) unusual characters in the
> command line, like 'firefox
> http://someserver.com/doit.cgi?name=foo&reply=bar', SHELL (understand
> /bin/sh or any other shell interpreter you use, such as zsh or csh) will
> interpret characters as "?" and "&" while 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.
>
> A rule of thumb is: if you need shell capabilities, use SHELL;
> otherwise use EXEC.  Using SHELL save typing, on the other hand,
> if you're sure no strange characters ("?", "&", "$", spaces, etc)
> will happend in the command line you're making, use EXEC.

Please work directly on the wiki. Things on the mailing-list won't go there 
automagically...

Regards,

-- 
Benoît