> 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 >
Fixed. -- Benoît ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
