Re: [Gambas-user] EXEC vs. SHELL
Doriano Blengino a écrit : Jean-Yves F. Barbier ha scritto: Benoît Minisini a écrit : ... Please work directly on the wiki. Things on the mailing-list won't go there automagically... I don't have a wiki account nor know the wiki's syntax. JY Dear Jean-Yves, I am sorry to write this, but your english looks to me worse than mine. I don't speak English, I speak American, which is also called english but is quite different. Please review your corrections: are you really sure that there are less errors than in the original version? As I am not english, I could be wrong, but your name makes me think you are not english either... I am pretty sure that things like this simple line do... is an error. There no, its semantic' similar to: with these, here's what you can do: ... are also other little imprecisions: for example the sentence /bin/ls will make a redirection (the character) is misguiding (it is not /bin/ls which does redirections, but /bin/sh), yeah, I also made a type upon stdout, I made it in less than 5 minutes without reread When I originally wrote that text, it was a reply to this mailing list, and I weighted as much as possible the words and the concepts. But it was an email reply, not a documentation page, and as always I was unsure about my english. If in an email bad english can be accetable, I think it is not in an official documentation. Thanks for your interest, and best regards, JY -- Some optional equipment shown. -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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=fooreply=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
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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. /..., /..., 21 | some_command etc, 3. Environment variables, such as $HOME, $PATH, etc. But exec has a good advantage over SHELL. If you
Re: [Gambas-user] EXEC vs. SHELL
Benoît Minisini a écrit : ... Please work directly on the wiki. Things on the mailing-list won't go there automagically... I don't have a wiki account nor know the wiki's syntax. JY -- -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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=fooreply=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. Regards, -- Benoît -- 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
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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=fooreply=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
Re: [Gambas-user] EXEC vs. SHELL
Ok, thanks, that makes it clearer! Rolf Mike Keehan schrieb: Hi Rolf, EXEC will run a single executable program. SHELL can run a shell script, including pipes and redirection between two or more executables. You could think of EXEC as the fundamental way to run another program, while SHELL is shorthand for EXEC /bin/bash parameters Mike. Rolf-Werner Eilert wrote: 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 :-) Rolf -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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=fooreply=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 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
Rolf-Werner Eilert ha scritto: 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 ... 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? Thanks for your appreciation, it makes me feel good. I think that my writing could be better - it was only a quick reply in a forum -, but the more important thing you said is about cross-linking together several pages of the docs: sections like SEE ALSO and DIFFERENCES BETWEEN... (similar ways to do something). The same problem is found in the normal man(1) pages - related arguments are in fact not related in the documentation. For example, Samba and NFS do (more or less) the same thing, but the documentation treats them as completely separated. I understand this, but this is no good anyway. Regards, Doriano -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
Doriano Blengino schrieb: Rolf-Werner Eilert ha scritto: 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 ... 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? Thanks for your appreciation, it makes me feel good. I think that my writing could be better - it was only a quick reply in a forum -, but the more important thing you said is about cross-linking together several pages of the docs: sections like SEE ALSO and DIFFERENCES BETWEEN... (similar ways to do something). The same problem is found in the normal man(1) pages - related arguments are in fact not related in the documentation. For example, Samba and NFS do (more or less) the same thing, but the documentation treats them as completely separated. I understand this, but this is no good anyway. Regards, Doriano Hmmm - I thought that was possible to do with the Gambas wiki pages. Some time ago I helped translate some of the pages (and I should continue to do so, I know), and there were links to other pages... Well, maybe Benoit would have to initiate that by creating a base page. Benoit, did you hear us? :-) As to your English, we might ask some native speaker on the list to look through it. Regards Rolf -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
Doriano Blengino schrieb:
Rolf-Werner Eilert ha scritto:
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
...
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?
Thanks for your appreciation, it makes me feel good.
I think that my writing could be better - it was only a quick reply in a
forum -, but the more important thing you said is about cross-linking
together several pages of the docs: sections like SEE ALSO and
DIFFERENCES BETWEEN... (similar ways to do something).
The same problem is found in the normal man(1) pages - related arguments
are in fact not related in the documentation. For example, Samba and NFS
do (more or less) the same thing, but the documentation treats them as
completely separated. I understand this, but this is no good anyway.
Regards,
Doriano
Hmmm - I thought that was possible to do with the Gambas wiki pages.
Some time ago I helped translate some of the pages (and I should
continue to do so, I know), and there were links to other pages... Well,
maybe Benoit would have to initiate that by creating a base page.
Benoit, did you hear us? :-)
As to your English, we might ask some native speaker on the list to look
through it.
Regards
Rolf
You can create a page at /doc/shellexec and put your text there, with the
title Differences between SHELL and EXEC.
Then in the SHELL and EXEC pages, you add a link to this page
([/doc/shellexec]) in the {seealso ... } section.
Regards,
--
Benoît
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
What Doriano typed only needs some minor touching up. I'd be happy to assist with any English cleanup for that or anything further...however, being rather pressed for time at the moment, I may not be able to get to it until late tomorrow evening. As to your English, we might ask some native speaker on the list to look through it. Regards Rolf -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
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. /..., /..., 21 |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=fooreply=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, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EXEC vs. SHELL
Hi Rolf, EXEC will run a single executable program. SHELL can run a shell script, including pipes and redirection between two or more executables. You could think of EXEC as the fundamental way to run another program, while SHELL is shorthand for EXEC /bin/bash parameters Mike. Rolf-Werner Eilert wrote: 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 :-) Rolf -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
