[Gambas-user] EXEC vs. SHELL

[Rolf-Werner Eilert]

Doriano Blengino schrieb:
> 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,
> 


Oh yeah, thank you very much for that comprehensive explanation!

In fact, I find your answer so well written that I want to propose to 
take it up into the Gambas wiki, linked between SHELL and EXEC or just 
as part of both texts. What do you think?


Regards

Rolf