Now it's command|show, no more command|clip / run > notepad / paste!
If you are an NVDA screen reader user who also employs the command line, no doubt you will have run into the infuriating issue where only the very tail portion of a command's output is easily accessible to you. How many times have you had to type "command --help > help.txt" or "command --help | clip" before pasting into notepad, all because NVDA can't scroll up in the CLI output history? You can use control+A then control+c in windows cmd, but you still must sacrifice or back up your clipboard contents for this not to mention opening notepad to review the data. Seriously if you wanted to read more than the last 30ish lines of terminal output, until now it always somehow had to involve opening notepad!
While this little program I've made by no means improves NVDA's scrolling functionality itself, it does attempt to make the entire situation just a little less painful by allowing you to pipe the output of any command into a simple multi-line read only text box for easy review. This means that as an NVDA user, you can now review the long output of a process without needing to sacrifice your clipboard's contents, without having to create some temporary file on disk, without having to launch notepad or generally just without any extra 5 seconds of hastle where sighted people spend 0! It even includes a find dialog (ctrl+f, f3, shift+f3) which means that you don't even need to copy the text to notepad to search for a specific phrase! And if you decide you want to preserve a command's output, just press ctrl+s on the text field and you'll be covered!
It really couldn't be more simple, just drop show.exe somewhere on your path (anywhere from c:\windows to c:\users%username% so long as it's part of the path environment variable), then in the command line, you can test by running "dir c:\windows\system32|show" and see how you can instantly review every bit of that massive directory listing where as before you could only view the last 30 lines of it without extra hastle! Of course you can pipe anything to show.exe that you could pipe to the clip command. Easily reviewing git logs in a seekable manner is another great use for this, for example.
The resulting dialog is very simple, containing a read only edit box with command output, a find button, and a save as button. You can also press ctrl+f or f3 in the text field to open the standard find dialog. As with most applications, f3 and shift+f3 remember the last search term so that you can jump between occurances of text easily. The finding here doesn't wrap around yet, I'll likely get around to that soon. The save as feature can also be accessed by pressing control+s in the text field. The aplication always saves files encoded in UTF8.
You can exit the application by pressing either escape or alt+f4. You can also press ctrl+c in the terminal window you launched the application from by piping another process to it.
It's not any more complicated than that!
The main thing to warn about here is that for the first iteration of this program, the same behavior of the clip command is used (E. the text from a piping process queues up, then the text box displays the text once the piping process exits). This means that this isn't yet suitable for reviewing live output from long running CLI programs (say ssh or python). In the future, I'll make a new version of this thing that reads the piped text on a separate thread and continually updates the text field as the piping process outputs more text. This however requires several other considerations (such as screen reader speech to announce live output), so I've forgone it for the moment in light of at least releasing an initial version of this thing as it's already quite useful as is.
I've done my very best under the circumstances to support UTF16, UTF8, system codepage and windows-1252 files for reading if they are piped in to the program. I do not know if this will be sufficient in all cases, please let me know if you find a plain text file that easily opens in your text editor but can't be successfully piped to the program.
If you wish to build this yourself, you can run _build_msvc8.bat or _build_msvc19.bat if you have those versions of Visual Studio installed. If you have a different version of Visual Studio, you will need to either remove or alter the "call *" line at the top of the batch script to point to your local version of vcvarsXX.bat. I am fully aware that this building situation probably isn't convenient for anyone but me, and I apologize for that. First my c/c++ experience does not yet include build systems, it will at some point. Second, due to a side-goal of making at least the first version of this project as small as possible, I rely on Visual Studio's ability to uncomplainingly run with no c runtime library which seems to be far easier to get working than with other compilers (I spent a couple hours trying with mixed success). As my programming knowledge continues to evolve, you can rest assured these primative building steps for this and any other projects of mine will become much more mature and will conform to accepted standards.
The one other thing to mention regarding building is this program's one quite rediculis conditional define. Basically, I'm using a windows rich edit control to show the piped text. This is good because it means control+a to select all works on new versions of windows without shipping a .manifest with the app, there is some support for finding text built in to this control, just generally it's a much more full featured edit box. The one annoyance however is the error beeps when you attempt to arrow past the beginning or end of the text field (you can see the same in wordpad). In one sense they make the text field slightly more accessible (you can tell instantly if you're at the border of the field), but new versions of windows in particular play a sound that's like 2 seconds long, which is a very minor annoyance (at least for me). This caused me to look up how to disable this feature of rich edit controls, and to my horror I found out that the only way to acomplish this was via a COM call! Being frank, I wasn't ready to learn the nastyness of making COM calls in pure c for something like this, so instead made the minorly painful decision to pollute my c code with a little bit of c++ to make the comm call, then make it a conditional define so that the program can still compile in pure c if wanted. Though I'll probably do it sometime myself at some point, if someone wishes to submit a pull request with a pure C version of the disable_richedit_beeps function, I'd be much abliged! Just remember that if the TXT_NOBEEPS macro is defined, you must then make sure your compiler is set to compile as C++.
Trust me, I'm well aware that I have written this program at a rediculisly low level, it could probably be spun up in 40 lines of python and not much more c# or something. However, I was already interested in seeing how small of an executable Visual Studio could generate without a c runtime library, and my idea was to create a simple program. Indeed, the initial version of this thing was less than 90 lines of code, contained 3 functions, and could have possibly been made even smaller. But then I decided to add a find dialog which added another 50 odd lines, then decided to throw in a save feature as well so there's another 50ish, then I decided right before publishing the project that I wanted to support more text file encodings if someone pipes a file to the program, that was another chunk of more than 50 lines of code. In the end, I ended up learning a lot more than I set out to during this development process, however have happily reached my side goal utterly as compiling with vs2008 produces an executable that's only 6.5kb! The ssl signing on the official release I provide shoots it up to 12k instead. All things considered, in the end I'm not unhappy. It took literally days to develop this, there were some painful moments where I was clearly reminded how much easier this would have been had I done this at a higher level, but certainly the fun and challenge made it well worth it for me. If non-c-programmers have ideas for this thing and want to contribute, I may indeed rewrite it at a higher level. For now though, I hope you all get as much use out of this little program as I will get from the knowledge I've collected while making it!