Re: [MiNT] XaAES: bug(s) in shel

> I don't think this belongs into a user-application.

It belongs. Its the application that creates the ARGV environment, and the NULL: entry is part of it. You can look at mintlibs spawnve() in mintlib/spawn.c, this is actually where i borrowed the code from, though its not a separate function there.

> -E disables SW_ENVIRON

Oops. Anyway, using that flag i get seperate arguments in the callee for arguments that contain spaces.

> Those are identical.

Uh? They shouldn't be.

> Actually callee is a child of toswin

Well, yes. But depending on how it is called its the id of tw-call that is returned to the caller. In any case, neither the actually callee nor the id that is returned is a (MiNT-)-child of the caller (in the case of XaAES looks like tw-call is being called in such a way that it actually IS a child of the caller, but you can't count on that).

> I know it's not nice to have to use waitpid here, but I don't know any
> AES-call for that atm.

I think the only way would be to enter a message loop and wait for the CH_EXIT message in a real application. But for testing purposes, and if only used on XaAES, waitpid() seems to work.

> I'm thinking of an additional flag to tell XaAES to wait for the process
> to enhance the confusion ...

I think this is not neccessary. Any real application could just handle the CH_EXIT message.

Helmut Karlowski <helmut.karlowski@ish.de> schrieb am 14:54 Sonntag, 14.Februar 2016:

Am 14.02.2016, 13:15 Uhr, schrieb Thorsten Otto:

>> Empty arguments don't work. I didn't expect that it's so much to add,
>> and
>
> One reason might also be that i simplified the make_argv() routine for
> testing purposes. Originally, it also handles empty arguments by
> inserting a NULL: entry at the beginning of ARGV.

I don't think this belongs into a user-application.

> When i use -E (pass via SW_ENVIRON) it does not seem to work, but that
> might be toswin's fault.

-E disables SW_ENVIRON

xcaller.prg: test shel_write
usage: xcaller.prg [-0eEcCgGmM] -q quote -p proc number...
-0: add empty arguments
-e: disable non-SW_ENVIRON
-E: disable SW_ENVIRON
-c: disable CL_NORMAL
-C: disable CL_PARSE
-g: disable non-graphic
-G: disable graphic
-m: disable LAUNCH
-M: disable LAUNCHNOW
-p: process set callee (default: calle.tos)
-q quote: set quote-char: 0: ', 1: ", 2: 0

Actually I'm still working on it and have just uploaded new versions ...

> What also looks strange in your test program is
>> pid = shel_write(...)> waitpid(pid, ...)
> shel_write should return the AES-id of the callee, not a MiNT pid.

Those are identical.

> Also, since the spawned process is a child of AES, the caller can't do a

Actually callee is a child of toswin

675|/home/root}pstree 377
toswin2-+-callee
|-ksh-+-ue
| `-xcaller---tw-call
`-ksh---pstree

and waitpid waits for tw-call who's pid is usually 1 less than the one of

the callee.

I know it's not nice to have to use waitpid here, but I don't know any
AES-call for that atm.

I'm thinking of an additional flag to tell XaAES to wait for the process
to enhance the confusion ...

-Helmut

Re: [MiNT] XaAES: bug(s) in shel_write()