> >>>> 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.
Please work directly on the wiki. Things on the mailing-list won't go there automagically... Regards, -- Benoît ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
