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

[MiNT] AW: mintlib Fforce problem?



>if(!*_argv[0] && isatty (2))                               
> (void) Fforce(2, -1);
>  This
> doesn’t seem to be valid for TOS machines because -1
> (BIOS) handle is only available on MiNT and Magic

That (-1) is still a GEMDOS handle, not a bios device.
On all TOS machines you can do Fwrite(-1, ....) to write to the console,
even with very old TOS versions. Its the same value you get from Fopen("CON:"),
and is one of the reasons why checking for an error from Fopen() is sometimes done wrong by applications.

> Or I’m
> missing something and there’s another way of
> redirecting con to serial?  

You could do an Fforce(2, -2) instead. But that redirects only output written to GEMDOS handle 2.
I'm not sure what you are trying to do, maybe you should have a look at Bconmap() instead.

Thorsten


--------------------------------------------
Mariusz Buras <mariusz.buras@gmail.com> schrieb am So, 4.1.2015:

 Betreff: [MiNT] mintlib Fforce problem?
 An: mint@lists.fishpool.fi
 Datum: Sonntag, 4. Januar, 2015 01:01 Uhr
 
 Hi there,  I’m developing for TOS
 with Vincent’s cross-compilers and automatically this
 uses mintlib.I’ve encountered a
 problem which causes output redirection to break in a
 situation whereparent
 application (using mintlib) Pexec’s a child
 application and child application tries to redirect con to
 aux (Fforce(1,2)).This
 seems to be caused by mintlib/main.c calling Fforce(2,-1)
                  
 /* if stderr is not re-directed to a file, force 2 to
 console               
  * (UNLESS we've been run from a shell we trust, i.e.
 one that supports               
  *  the official ARGV scheme, in which case we leave
 stderr be).               
  */               
 if(!*_argv[0] && isatty (2))                               
 (void) Fforce(2, -1);
  This
 doesn’t seem to be valid for TOS machines because -1
 (BIOS) handle is only available on MiNT and Magic. For some reason this call
 makes further calls to redirect handle=2 ignored? This in
 itself is probably not desired but I’d argue that
  mintlib shouldn’t be doing that in the first
 place under plain TOS.
  Or I’m
 missing something and there’s another way of
 redirecting con to serial?  RegardsMariusz