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
