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 ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
