The real problem is that chaos has been burned in to the Windows environment in that there is no standard output device which you must use to make your program work. This is much different from the Unix operating system in which the only way to insure that your program works across different platforms is to use the standard output device. When you do, everything from a raspberry PI to a main frame knows what to do when the program prints something to the screen. The chaos of no standard output device infects programs that started out in Windows and have been ported over to unix-like systems. A good example is a popular video player called Kodi. It's useful when converting one video format into another so that it will play on more different devices. It is the recommended player for use with a line of server devices that are meant to play cable or off-the-air TV signals on one's home network. I can tell you for a fact that these devices are very accessible when one is using a Mac or Linux device to control the devices such as ask them to scan your cable or antenna feed for signals. The output is a somewhat cryptic listing of the various channels, their signal strength and quality and a short ID containing the service name such as CNN or the call letters of a TV station in the aria. When you try, however, to watch one of the channels live, it's a no go right now. If you call up Kodi, the only button on the GUI screen that works is the "Close" button which is quite ironic. Another line which says, "Kodi Entertainment Center" shows on the screen but one can not get anything else to happen as there are no more buttons at all. One has to be able to tell Kody various control options and there is simply nothing else to select. I am not yet sure what is wrong but it's a poster child for the mark that Windows chaos has left on the software world. I can tell you that if Kodi gets fixed, cable TV and modern digital reception will all become accessible from a command and control standpoint because pieces of the puzzle already fit together nicely. As for getting a back door in to Windows functionality by using bash or any other shell/terminal, the lack of a predictable output method for a Windows application is the same old issue that has become the "standard" of Windows applications. One positive thing I can say is that these cross-platform issues may bring us full circle in computing in which all operating systems will be forced to have and even require that there be a standards-based mechanism for getting data in to and out of applications. Several years ago, very smart but not very far-sighted people said that the GUI was everything one ever needed and it does simplify mundane tasks for many people but I remember a quote from a television series on human language in which someone said, "Draw me a picture that says that it is not raining." In unix, we know it is possible to have the best of both worlds. Most of the wizardry of such programs as JAWS and Window-Eyes is invested in trying to tease output redirection out of a system that seems to do it's best to confound this process. Martin Janina Sajka <janina@xxxxxxxxxxx> writes: > One might hope for this, but I suspect there's a builtin problem with > Windows screen readers. Are any of them any good with text output in the > terminal? I haven't tried recently myself, but I don't see as there's > been any reason for them to get any better this way. > > Decades ago we had pretty powerful screen readers for DOS, and we > certainly have a very powerful screen reader on Linux consoles in > Speakup. But, without something similarly capable, I don't see how cli > based apps are going to attract blind users on Windows. Sad, actually. > > Janina _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list