Re: [Gambas-user] SHELL not working (GB_DIR)
Doriano Blengino ha scritto: Jesus Guardon ha scritto: Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. Not at all. No error message is displayed, simply SHELL command seems to be ignored by the interpreter. As for launch my program I'm using a shell script (you can see it in the previous posts), I'm not able to run gdb against myprogram.gambas, or myprogram (without .sh extension). In a previous mail you wrote: I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH to add your personal path the the standard ones. Or, if you are a security paranoid, you could use: export PATH=/opt/dfhlog/gambas2/bin:/usr/bin:/bin This way you don't trust the existing path. This second form excludes /sbin and /usr/sbin; you should add them if you need system administration commands like route, fdisk, reboot, addgroup and many others. Regards, Just after hitting the send button, I realized that this idea is correct only in part. May be it solves, it is a quick try. The right part is that the PATH variable is used by the shell itself, so even if your gambas program finds the shell and asks it to execute something, the shell will fail to do it. Probably this is not considered an error by gambas, so the instruction SHELL pidof xxx fails silently. The ambigous part is in whether gambas uses PATH to search for the shell. If it is so, then your gambas program will not find the shell, and gambas should report this, because an internal instruction of gambas is failing. In this case, however, one can ask himself if makes it sense to use PATH to search for the shell, which traditionally is /bin/sh, and many scripts included system ones address the shell in this way. Assuming that SHELL is a substitute for EXEC [sh, -c, ], and that EXEC searches executables in PATH, this would explain all. Perhaps would be better to bind SHELL to EXEC [/bin/sh, -c, ...]. I am not sure if, natively, exec() searches executables in PATH. May be that there is the system call exec() which does one thing, and the C library wrapped exec() which does differently. In any case, if it is so, this would explain my sensation that SHELLs in gambas are slow. In my system (a normal Debian), the PATH variable looks like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 . Every time a gambas program invokes a SHELL, the system searches sh in 4 directories, and then sh searches for the executable in 4 directories again; the first four directories could be skipped. Regards, That's exactly the point: I send sh to the system, asking him to search it inside the PATH, by using the execvp() glibc function. I don't remember why I decided to do that. Maybe it is not useful, maybe I can use directly /bin/sh, and let the user use the EXEC instruction if he needs something else? -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Benoît Minisini ha scritto: Doriano Blengino ha scritto: Jesus Guardon ha scritto: SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH The right part is that the PATH variable is used by the shell itself, so even if your gambas program finds the shell and asks it to execute something, the shell will fail to do it. Probably this is not considered an error by gambas, so the instruction SHELL pidof xxx fails silently. The ambigous part is in whether gambas uses PATH to search for the shell. If it is so, then your gambas program will not find the shell, and gambas should report this, because an internal instruction of gambas is failing. In this case, however, one can ask himself if makes it sense to use PATH to search for the shell, which traditionally is /bin/sh, and many scripts included system ones address the shell in this way. Assuming that SHELL is a substitute for EXEC [sh, -c, ], and that EXEC searches executables in PATH, this would explain all. Perhaps would be better to bind SHELL to EXEC [/bin/sh, -c, ...]. I am not sure if, natively, exec() searches executables in PATH. May be that there is the system call exec() which does one thing, and the C library wrapped exec() which does differently. In any case, if it is so, this would explain my sensation that SHELLs in gambas are slow. In my system (a normal Debian), the PATH variable looks like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 . Every time a gambas program invokes a SHELL, the system searches sh in 4 directories, and then sh searches for the executable in 4 directories again; the first four directories could be skipped. Regards, That's exactly the point: I send sh to the system, asking him to search it inside the PATH, by using the execvp() glibc function. I don't remember why I decided to do that. Maybe it is not useful, maybe I can use directly /bin/sh, and let the user use the EXEC instruction if he needs something else? I think there are a few pros in using /bin/sh directly, and perhaps a single con. The pros are: slightly faster; more traditional in the sense that SHELL should invoke the normal system shell (/bin/sh) and not an arbitrary shell due to a mangled PATH; in a case like this one by Jesus, where we find a little error in setting PATH, the SHELL statement would work anyway. The single con, perhaps, is that in a non standard system, with strange PATH set up, the SHELL could fail. But this could be overcome by using EXEC instead of SHELL: a user special enough to use a special setup, can well use EXEC instead of SHELL. Perhaps a little search in some sources analogue in concept to gambas (python, awk...) could be explanatory; I would propend for /bin/sh. Regards and happy Christmas, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Doriano Blengino ha scritto: Jesus Guardon ha scritto: Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. Not at all. No error message is displayed, simply SHELL command seems to be ignored by the interpreter. As for launch my program I'm using a shell script (you can see it in the previous posts), I'm not able to run gdb against myprogram.gambas, or myprogram (without .sh extension). In a previous mail you wrote: I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH to add your personal path the the standard ones. Or, if you are a security paranoid, you could use: export PATH=/opt/dfhlog/gambas2/bin:/usr/bin:/bin This way you don't trust the existing path. This second form excludes /sbin and /usr/sbin; you should add them if you need system administration commands like route, fdisk, reboot, addgroup and many others. Regards, Just after hitting the send button, I realized that this idea is correct only in part. May be it solves, it is a quick try. The right part is that the PATH variable is used by the shell itself, so even if your gambas program finds the shell and asks it to execute something, the shell will fail to do it. Probably this is not considered an error by gambas, so the instruction SHELL pidof xxx fails silently. The ambigous part is in whether gambas uses PATH to search for the shell. If it is so, then your gambas program will not find the shell, and gambas should report this, because an internal instruction of gambas is failing. In this case, however, one can ask himself if makes it sense to use PATH to search for the shell, which traditionally is /bin/sh, and many scripts included system ones address the shell in this way. Assuming that SHELL is a substitute for EXEC [sh, -c, ], and that EXEC searches executables in PATH, this would explain all. Perhaps would be better to bind SHELL to EXEC [/bin/sh, -c, ...]. I am not sure if, natively, exec() searches executables in PATH. May be that there is the system call exec() which does one thing, and the C library wrapped exec() which does differently. In any case, if it is so, this would explain my sensation that SHELLs in gambas are slow. In my system (a normal Debian), the PATH variable looks like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11. Every time a gambas program invokes a SHELL, the system searches sh in 4 directories, and then sh searches for the executable in 4 directories again; the first four directories could be skipped. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)[solved]
Doriano Blengino escribió: Jesus Guardon ha scritto: Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? Not at all. No error message is displayed, simply SHELL command seems to be ignored by the interpreter. As for launch my program I'm using a shell script (you can see it in the previous posts), I'm not able to run gdb against myprogram.gambas, or myprogram (without .sh extension). In a previous mail you wrote: I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH to add your personal path the the standard ones. Or, if you are a security paranoid, you could use: export PATH=/opt/dfhlog/gambas2/bin:/usr/bin:/bin This way you don't trust the existing path. This second form excludes /sbin and /usr/sbin; you should add them if you need system administration commands like route, fdisk, reboot, addgroup and many others. Regards, Ye! This solved the issue. I might figured it out, I didn't know of exclusion on exports. Many thanks, Doriano (and Benoît, for such a great feature!) Regards, Jesús -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Jesus Guardon escribió: Benoît Minisini escribió: Hi all I am experimenting with the GB_DIR environment variable, and I've made a deb package with my program to install it in /opt. The current dir structure is as follows: je...@jesus:~$ tree /opt /opt `-- dfhlog |-- dfhlog.gambas `-- gambas2 |-- bin | | |-- gbr2 - gbx2 | | `-- gbx2 `-- lib `-- gambas2 |-- gb.component |-- gb.corba.component |-- ... etc ...etc... I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). snip Thanks Benoît Surprisingly, after a recompile, it works as expected! May be I was using an old executable file (dfhlog.gambas). Sorry for my mistake 8-( Regards Jesús Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? Thanks in advance. Jesús -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Jesus Guardon escribió: Benoît Minisini escribió: Hi all I am experimenting with the GB_DIR environment variable, and I've made a deb package with my program to install it in /opt. The current dir structure is as follows: je...@jesus:~$ tree /opt /opt `-- dfhlog |-- dfhlog.gambas `-- gambas2 |-- bin | | |-- gbr2 - gbx2 | | `-- gbx2 `-- lib `-- gambas2 |-- gb.component |-- gb.corba.component |-- ... etc ...etc... I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). snip Thanks Benoît Surprisingly, after a recompile, it works as expected! May be I was using an old executable file (dfhlog.gambas). Sorry for my mistake 8-( Regards Jesús Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? Thanks in advance. Jesús SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. Do you have any error message from gambas? I need as many details as possible! Regards, -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
