[Gambas-user] SHELL not working (GB_DIR)

[Doriano Blengino]

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,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."