If you can't tell after reading the following two ideas, they are somewhat related. ==== Idea 1: Leave out the ability to SHELL with no arguments Why? Because it is supposed to start up a new COMMAND.COM session, and there is a problem with that, much like the notepad issue. Simply put, there isn't really a way to determine whether ANY terminal emulator is installed on a Linux system except to go through a list, organized from most preferable to least preferable, and use it. Not only that, but it would steal the focus away from QB64, and typing 'exit' in the terminal window won't resume executing the program. -- Idea 2: Redirect the output of the command passed to SHELL to a temporary file (tmpnam() might be useful). Open the file, read it and output it to the screen. Then close it and delete it. All of the necessary functions to do this are able to be found in <stdio.h> in C, except for adding the redirection operators to the command line, which probably should work just fine with strcat() in <string.h> The reason I bring this up is because of the fact that opening a new terminal emulator window would steal the focus from QB64, and typing 'exit' in the terminal window doesn't mean that QB64 will regain focus (maybe you were looking something up in your Web browser of choice), not to mention that SHELL is supposed to suspend the running program until the command has completed. This doesn't apply to just Linux either. I personally prefer to use Windows PowerShell instead of cmd.exe these days because it is so much more robust, not to mention that it can gain a gigantic boost from its ability to integrate with the .NET framework. Unicode support is on the way with PowerShell 2.0 too. Right now, it is just a customized version of the normal Windows console. ==== How are these related, you ask? The answer is simple: they both help SHELL to work around the issue of fiddling around clumsily with different terminal emulators in a cross-platform way. Oh, and the other idea I had was ridiculous - create your own command prompt when SHELL is used without arguments. Why is it ridiculous? Consider the idea that some Linux users enjoy having zsh set up vim-style or users of bash, Windows, zsh, etc. enjoy their tab completion feature when browsing through directories. Implementing SHELL this way would be insane. It would a few demos just to complete it - and then you couldn't guarantee that bash users would be happy with zsh-like behavior or ash users would enjoy bash behavior. Plus, it would further separate Windows from Linux unnecessarily because two different versions would NEED to be compiled if this ever happened. Why do things that aren't really necessary? When was the last time anybody ever saw a standalone SHELL statement in a compiled program? That really doesn't make sense to me because the idea of a program is to be automated. The only bit of user interaction is done via things like INPUT and LINE INPUT (except in the case of a program crashing). Everything else is meant to be automated, right? Of course, these are merely my ideas on what _could_ be done to get SHELL working when the time comes and why one thing about it should be QB-incompatible. Things could end up being completely different. I'm just a programmer, not the mastermind (or was it genius?) behind this great project. :) ------------------ Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles. |
