[Gambas-user] SHELL not working (GB_DIR)

[Benoît Minisini]

> 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
> >>
> >>>>> jesus at ...2151...:~$ 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