[Freemint-list] Handling of PRGs/APPs which console output

[Jo Even Skarstein]

On fr., 2017-01-06 at 23:16 +1000, Miro Kropáček wrote:
>         Basically I think this approach is wrong. 
> I think this concludes yours, Thorsten's, Helmut's and maybe someone
> else's point of view. You think there's an excuse to virtually destroy
> the user's display (yes, it's a rare case but all it takes is one

This is very easy to avoid. In addition to have an open console window
which is the current solution, I volunteer to make two other
solutions/workarounds that does not require any changes or additions to
XaAES.

1. A tiny program that simply opens /dev/xconout2 and doesn't care about
it's output. This will effectively eat all output to stdout as long as
this program runs. Autostart it from the auto-folder, xaaes.cnf or
desktop.
Then if you need to see debug output you must either start the program
from a shell, or tell Teradesk that it's a TOS/TTP which will run it
from TosWin2 (or whatever is installed as TOSRUN).

2. A tiny program that takes the path/name to an executable as
parameter. This program will redirect stdout to /dev/null, launch the
program specified on it's commandline, restore stdout and exit. This
will eat all output to stdout for this particular program.

>  popular app which, for some reason, has output to stdout enabled and
> its author refuses/not being able to remove it) while I (and perhaps
> other non-programmers) advocate for 100% clean and "indestructible"
> display, even if there's a chance that some interesting information
> slips out.
> 
> 
> My point is mainly Linux and Windows world when any app can flood
> stdout with thousands of debug lines and the user is happy using the
> desktop as usual. And I don't see people jumping out of windows only
> because they didn't see that precious debug output! ;)
> 
> 
> So, what others think? Because as I see it, this can't be solved with
> a compromise, it's more good source for a poll. ;)
> 
> 
> -- 
> MiKRO / Mystic Bytes
> http://mikro.atari.org