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

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



> it's too much for now to add to toswin.

It's not really that much, and for a program like toswin it would be important to correctly pass the arguments.

> Why not?

Because if you do a Pfork(), you will have two different MiNT-processes with the same GEM application id. Similarly, if you ever going to implement shel_write(SWM_THRCREATE,...), you will have a single MiNT process using different GEM ids.

> Do you use the toswin2.7 from me?

Yes, but it looks like it wasn't using your new xaaes.km. When i try, i get "Wrong kentry version (kernel version too old)". Could you provide a snapshot of your source tree instead?

> I think XaAES should  remove them.

No, not when tw-call is not involved. In that case, the commandline should be passed as is. OTOH, if tw-call is involved, the commandline (and maybe ARGV from the passed-in environment) has to be reconstructed anyway.
Helmut Karlowski <helmut.karlowski@ish.de> schrieb am 20:35 Sonntag, 14.Februar 2016:




Am 14.02.2016, 16:33 Uhr, schrieb Thorsten Otto:

> 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

That's where I looked and found it's too much for now to add to toswin.

>> -E disables SW_ENVIRON
> Oops. Anyway, using that flag i get seperate arguments in the callee for 
> arguments that contain spaces.

Please download the test-program again and tell me the 
xcaller-command-line that you think produces wrong results.
Do you use the toswin2.7 from me?

>> Those are identical.
> Uh? They shouldn't be.

Why not?

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

Which obviously waits for callee to finish, and thus waiting for tw-call 
works in the caller.

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

The code in launch() is executed by the caller (like most if not all 
AES-calls), and that's why the caller is the parent of tw-call. Pretty 
sure waitpid only works in XaAES, that's true.

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

If that would work I think there is nothing more to add on that topic.

The one thing I think is to do is that when tw-call is not involved the 
quote-characters appear at the callee. In this case I think XaAES should 
remove them.


-Helmut