[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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