In message <[EMAIL PROTECTED]>
"Duncan Moore" <[EMAIL PROTECTED]> wrote:
> VRPC RISC OS 4.39
> gcc (GCC) 4.1.1 (GCCSDK GCC 4.1.1 Prerelease 1)
>
> #include <stdlib.h>
> int main() {
> return system("cat");
> }
>
> gcc -o test abc.c
>
> 1) Initially this runs OK, with normal output from 'cat'.
>
> 2) However, put some other executable called 'cat' in the current directory,
> and the output is from this new 'cat' command.
>
> 3) Load SharedUnixLib 1.10, and the output is as in 1) again.
The reason behind this change is that since SUL v1.11 what gets given to
system()/exec() is canonicalised first and in step 2) this results in the
full path to your 'cat' executable while in 1) the result is still 'cat'.
The reason why we're now doing the canonicalisation is that we want a more
reliable match what is given to exec() and the new process named in exec()
registering itself to SUL so that the UnixLib environment from parent to
child can be passed on.
Both approaches in v1.10 and v1.11 have their weak points and what's
missing is that we would like at exec() time know exactly what will be
started when the underlying OS_CLI SWI gets called, i.e. a module command,
an system variable alias, an executable on a FS or perhaps something
sitting on the OS_CLI vector intercepting the call and doing something fancy.
I'm not sure I have a better idea as implementation to fix what I wanted to
fix with v1.11 (being a more reliable environment passing). Any
suggestions ?
John.
--
John Tytgat, in his comfy chair at home BASS
[EMAIL PROTECTED] ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
