[Gambas-user] SHELL not working (GB_DIR)

[Doriano Blengino]

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.
>>>>>           
>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>               
>>> 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."