[Gambas-user] EXEC vs. SHELL

Jean-Yves F. Barbier 12ukwn at ...626...
Sat Jul 25 01:41:37 CEST 2009


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

-- 
The English have no respect for their language, and will not teach
their children to speak it.
		-- G. B. Shaw




More information about the User mailing list