Re: [Gambas-user] EXEC vs. SHELL

[Doriano B. <dor...@fa...>]

Benoît Minisini ha scritto:
>> 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.
>   

I am proud of this; re-reading this text I would suggest the following 
corrections, if you don't mind:

1) Under the title "Exec", at point #3, replace '...array which contains 
the "-l" and all the files.' with 'array which contains the "-l" and all 
the filenames you found.'

2) In the section "But EXEC has a good advantage over SHELL...", the 
sample code box has an extraneous trailing quote: 'firefox 
http://someserver.com...reply=bar"' <-- trailing double quote.

3) May be some good-english-speaking-guy could revise the correctness...

Thanks, and regards,

Doriano Blengino