How to handle clear screens on redirected STDOUT?

[SunnyD]

I'm in the process of writing a GUI app wrapper around a console app. I have the basic redirection of stdout and stdin working properly, except for one thing. The console app on occasion clears the console screen. I haven't yet figured out how, or even if there is a way to "trap" a clear screen on a redirected stdout. Anyone have any insight on this?

(Wrapper is currently being written in C#.Net)

 

[Cogman]

What was the console app written in and for (for as in what operating system)?

Here is the problem, AFAIK, there is no standard "clear screen" method for consoles. Each operating system does it different (yay!) It could be anything from essentially just pushing enter x amounts of time to issuing a command to the OS to clear the console screen buffer.

http://en.wikipedia.org/wiki/Clear_(Unix)

 

[Markbnj]

That's a tough one. According to the docs the Console.Clear command is the equivalent of the DOS cls command, which physically clears the screen buffer. Nothing would be written to stdout that you could watch for, and in C# you can't, as far as I know, get a pointer to the screen buffer and watch that, as you might in native C++. There's no event, or any other signal that I can find that will help.

I'm curious as how you'd want it to work. I assume you're dumping stdout to a text box, and would like to emulate the cls by erasing the content? Maybe it's solvable if you look at it one level up. Why does it clear the screen? Is it displaying different menu options or some other text that you could watch for in stdout?

 

[SunnyD]

Cogman: C#.net/Windows.

Mark: That's what I was thinking after a day of researching it. You pretty much hit it right on the head as to what I'm trying to do. I was trying to avoid any context sensitive "programmatic" screen clears, as I'm not 100% familiar with the command flow of the, we'll call it "client" app. I was hoping to avoid parsing the output that comes out, as I wouldn't be 100% sure on any given command whether it would initiate a clear screen. But now that you mention it, I think that may actually work. I haven't seen very many instances where it does clear the screen yet, but there does seem to be a sort of header that gets displayed in the process. Perhaps I will just try to key off that. Thanks for the suggestion.

Please note, I'm not tied to C# for my wrapper GUI. I just figured I'd give it a try. My language of choice is native C++.

 

[Apathetic]

I don't know if anything even bothers to support this anymore but a LONG time ago there was an ANSI "escape sequence" for clearing a screen. It was 4 bytes, ESC [ 2 J (escape key, left bracket, "2", upper case "J"). It would clear the screen and move the cursor to the "home" position. This is REALLY old and obscure crap, but it's all I can come up with.

Dave

 

[Markbnj]

I don't know if anything even bothers to support this anymore but a LONG time ago there was an ANSI "escape sequence" for clearing a screen. It was 4 bytes, ESC [ 2 J (escape key, left bracket, "2", upper case "J"). It would clear the screen and move the cursor to the "home" position. This is REALLY old and obscure crap, but it's all I can come up with.

Dave

Yeah, you could write that to... stdin I think, and clear the screen. I wouldn't be surprised if support for ansi escape sequences was still built into the console. But what Sunny is doing is wrapping an existing console app by capturing stdin and stdout. The app is issuing a cls (effectively) causing the screen to clear, and he'd like to know when that happens.

 

[Markbnj]

Please note, I'm not tied to C# for my wrapper GUI. I just figured I'd give it a try. My language of choice is native C++.

I had to write a simple... I mean _really_ simple... dialog app in MFC recently as part of a Wix installer. Going from doing GUIs in C# to writing one in MFC again after ten years was like nodding off in the driver's seat of a Nissan Sentra, and waking up in the cockpit of an A380.

 

[tatteredpotato]

I wouldn't be surprised if support for ansi escape sequences was still built into the console.

ANSI escape sequences is still how this stuff is done on linux (or at least how I do this stuff) for the most part, so I wounldn't be surprised if they're still supported on Windows as well either.

 

[Markbnj]

ANSI escape sequences is still how this stuff is done on linux (or at least how I do this stuff) for the most part, so I wounldn't be surprised if they're still supported on Windows as well either.

Maybe they actually aren't. I'm trying to use adb's shell to do some work on an android phone this evening, and whenever I try to run nano I get the ansi escape sequences for text color dumped to the console. It's a mess, and I haven't been able to figure out how to suppress them for nano.

 

[Colt45]

\e[2J is standard for VT100 and the like, so your term is probably scheisse, or setup wrong somehow.

You should be able to edit the nanorc to disable color though, or maybe there is a flag as well. That's just masking the fail though.

 

[Markbnj]

\e[2J is standard for VT100 and the like, so your term is probably scheisse, or setup wrong somehow.

You should be able to edit the nanorc to disable color though, or maybe there is a flag as well. That's just masking the fail though.

Thanks, that's worth a shot. I did try the --ignorercfiles option, but that didn't seem to make a difference. I ended up using adb pull to bring the file over to the host and edit it there.

 

[Kirby]

I had to write a simple... I mean _really_ simple... dialog app in MFC recently as part of a Wix installer. Going from doing GUIs in C# to writing one in MFC again after ten years was like nodding off in the driver's seat of a Nissan Sentra, and waking up in the cockpit of an A380.

lmfao. i don't even think they include mfc in the the express editions of visual studio.

 

[SunnyD]

lmfao. i don't even think they include mfc in the the express editions of visual studio.

You can't, and there's no way to integrate it. But you can download the Windows SDK and compile for MFC via the command line if you're bored enough.