From: John G. <jge...@ny...> - 2001-06-10 20:20:10
|
> John is correct that on Windows, the current directory is > implicitly on PATH > whether you want it or not. > > I have not comment on how best the console plugin should handle this > (personally either way works for me, but I am on Windows most of > the time). > > To be sure we have an informed discussion, I want to point out the current > search mechanism in the console plugin (which has a lot Windows specific > code--thank you). > > Commands are resolved and execute in this order: > > 1) a the console plugin's built-in command (cd or pwd) is just executed > in the calling thread (same JVM). > > 2) a windows built-in command ("md", "rd", "del", "dir", "copy", "move", > "erase", "mkdir", "rmdir", "start", "path", "ver", "vol", > "ren", "type") > spawns a new Windows shell (command.exe or cmd.com) runs the built-in. > > 3) if a file in the current directory matches, then it is executed in a > separate process > > 4) leave it to the JVM to resolve it and execute it (typically uses PATH > on most machines--I guess) in a separate process > > > NOTES: > > Step 2) is only done on Windows platforms. > > Also only on Windows platforms, during steps 3) and 4), the extensions > (".cmd", ".bat", ".com", ".exe") are appended one-by-one to the > command and > tried. This is to follow the Windows/DOS convention of letting the user > ignore extensions. > > One more thing: I would like to enhance console plugin's built-in commands > to include the GNU Utilities written in Java (such as: ls, du, rm). They > would avoid the need to spawn a new process for these basic commands (this > is really needed on Windows). So, I guess we would need a config option to > turn this on/off as Unix folks may not like this. Another reason to consider subclassing DefaultShell (or implementing Shell) for Windows. > > Do we need a list of Unix built-in command (like the Windows ones)? They > would be used to protect the user from Slava's evil user. Also, the GNU > Utilities would also provide the same protection. I would prefer to have the Console emulate the user's OS command line, because most users will be comfortable with their own native environment and because it creates a definite target for programming. If the differences were small, I might prefer a single syntax in the name of platform independence, but Windows users keep tripping over the fact that the current DefaultShell is a basically a Unix emulation with arbitrary Windows features hacked in. Adding utility classes to a Windows shell that emulate Unix utilities should improve performance over calls to Cygwin exectuables, but I would make their inclusion optional so that the user can have a command-line interpreter that is completely transparent. The issues being discussed seem to fall under the Template Method pattern. DefaultShell contains an algorithm that starts with a String and ends (most of the time) with a Process. There are some steps in the algorithm that are invariant, and there are some that are OS-specific. Maybe what is needed is an abstract CommandInterpreter class that plugs into DefaultShell and gets subclassed for Windows, Unix, and anything else. The inclusion of GNU Utilities could be handled neatly by a WinPlusCmdInterp class, or something with hopefully a better sounding name. John |