From: Mike (My Watch Has Windows) Meyer Organization: The Amiga Online Review Column - ed. Jason L. Tibbitts III Subject: REVIEW: WShell 2.0 Keywords: utility, shell, CLI Path: menudo.uh.edu Distribution: world Newsgroups: comp.sys.amiga.reviews Followup-To: comp.sys.amiga.applications Reply-To: Mike (My Watch Has Windows) Meyer Ultrix: Will drive you to drink. --text follows this line-- With 2.0 now available in ROM, Wishful Thinking Development Corporation has released a version of WShell designed to work with 2.0 in much the same way that earlier versions of WShell worked with earlier versions of AmigaDOS. To quote the manual, "WShell is a command shell designed as a much-enhanced but highly compatible alternative to the Amigas built-in Shell." Alternative? AmigaDOS 2.0 supports the concept of a "user shell", that defaults to the shell provided in ROM. WShell fully supports those features, and can be installed as a user shell. It is possible - even simple - to arrange things so that every shell started is a WShell, and you never have to type at anything but a WShell. It is also possible to use WShell as another application that must be started when you wish to use it, with everything normally going to the ROM shell. In additions, WShell comes with DisplayHandler, a replacement for the AmigaDOS con: handlers. As with WShell proper, you can either arrange that everything that opens a con: device (among others) gets a displayhandler device, or that only programs that specifically request a displayhandler device get one. WShell can be used with or without displayhandler. Compatible? WShell tracks the Commodore ROM shells closely. Even during the test phases of the ROM version, WShell had new features soon after the ROM shell had them. In using WShell for nearly three years, through various versions, I've as yet to encounter a compatibility problem that can be attributed to WShell. There are, of course, obscure things that can be done that would cause WShell to behave differently than the ROM shell. After all, it does add more functionality to the command line. However, even these cases are tailored so that common usage gets the proper action, and there are usually switches to turn them off. For example, the "&" character is used in WShell to start a background task. &'s in quoted arguments aren't recognized. Whether an & in the middle of a command line terminates a command and causes it to be started in the background is a user-configurable option. Such things will be mentioned along with the features in question. In general, if a script works with the ROM shell, it will almost certainly work with WShell. However, it is easy to write WShell scripts that will fail if run with the ROM shell. Enhancements? There are a long list of enhancements that WShell provides the AmigaDOS user. DisplayHandlers adds more, FComp (a file name completer) adds even more, and PathHandler adds still more. I'm just going to list many of them. First, WShell improves how the shell starts. Unlike the AmigaDOS shells, WShell lets you put many of the things one wants to do for every shell - typically aliases and options - in the Config-WShell file that is read when the first WShell starts. To help with controlling aliases, WShell has two different alias namespaces, "local" and "global". Global aliases are global to all WShells. Local aliases are only visible to the WShell they were entered in. All aliases in Config-WShell are global, and aliases other aliases default to local. This allows you to set up all the aliases you always want in Config-WShell, and have project-specific aliases in each WShell. Now, the things that all Unix users tend to ask for - `|' for anonymous pipes and `&' to run a process in the background. WShell provides both of those. Further, the two characters are user-selectable, so you don't have to follow the Unix conventions. As mentioned, & may or may not work if used to separate commands, depending on a user-selectable option. | must be preceded by a space, to discriminate the pipe usage from the pattern-matching usage. Another feature Unix users will like is that the I/O redirection characters may appear anywhere on the command line. Further, they have been enhanced with '<>' to redirect both input and output to a console device (i.e. "sci <>con:11/0/100/100/Sci-window &" to start a CLI utility in it's own window). WShell permits you to define the NOCLOBBER environment variable, which will cause the file redirection operators to not overwrite existing files. !> or !>> override the NOCLOBBER variable. As another boon to Unix uses, the character used for escaping other characters in quoted strings (normally `*') can be changed to whatever you want, including backslash. Further, unlike the standard AmigaDOS shell, that escape character can be used to quote some characters (only <, >, |, &, [, `, ; and *) outside of quoted strings. Since those are nonsense pairs in AmigaDOS, no ROM Shell scripts should fail because of this feature. On the other hand, most Unix users will probably be annoyed by the addition of backticked commands in the 2.0 ROM shell. This is a feature copied form Unix after Unix has decided the chosen syntax was a bad idea, and is dropping it. If a portion of a command line is surrounded by backticks (`), then that portion is sent to the user shell as a command, and the output of that command replaces the backticked string in the command line, after all newlines in the output have been turned into spaces. The 2.0 shell only allows one backticked command per command line; WShell allows many. The 2.0 shell does not allow nesting of backticked command (which is why Unix dropped that syntax). WShell allows nesting by doubling the backticks inside the command. Once again, no scripts meant for the ROM shell should have troubles with this extension to the 2.0 shell. As a boon to Rexx users, WShell supports Rexx scripts directly. The extension is "rexx", and the default host is the WShell that started the script. You can send commands back to the WShell that change it's state, which isn't possible with the 2.0 ROM shell. The execio command can be used WShell Rexx macro to directly import the output of commands into the macro without going through an intermediate file, and do it noticeably faster than reading the file in with Rexx I/O. WShell allows those who dislike the implicit CD to turn it off. WShell uses an environment variable to hold a "global path". This is a list of directories that are locked and searched on each command search, as opposed to the local path or the ROM shell path, where the directories are locked when the path is set up, and that lock is searched on command searches. This means you can use "df1:c" for common commands, and the disk in drive df1: will be searched, not the disk that was in drive c when the path was set. On startup, WShell can "take over" an existing shell. This is intended for startup sequences, but I haven't tried it (I start my initial WShell via an icon in WBstartup). WShell lets you select the number of consecutive EOF (control-\) characters you need to use to log out. If this is set large enough, you get a warning added to the prompt. As with previous versions of WShell, there is a utility that fixes Execute() to use WShell instead of the ROM shell. WShell includes an extensive set of built-in commands, including commands for manipulating a stack of directories that you have visited, and one that runs its standard input as a batch file. Among the most interesting of the builtin commands is the prompt command. Like its AmigaDOS counterpart, it lets you set the prompt. However, you can include any of the current directory, the date, time of day, elapsed time, the current command failure level, the task ID, available memory - either chip, fast or public, task number, stack size, and the return code and error codes from the last command. Further, you can insert commands to be run in either a subshell or the current shell when the prompt is generated, and environment variables can be expanded. You also get to change text colors inside the prompt, should you wish to. Finally, there's potentially much information, and you may not feel you have enough room in your prompt string for everything you want, the env:titlebar variable can be set to put this information in the screen titlebar after commands. You can get the original window titlebar into your prompt if you need that. DisplayHandler. DisplayHandler is a replacement for the console handler supplied with AmigaDOS. It can be used solely with WShell, or with any program that opens a CON: window. It allows menus to be attached to device names, which can be used to insert commands into the window. It supports the 2.0 CON: switches, and a selection of others as well. The most interesting new feature of DisplayHandler is the "session history". This is the text output to the window. If a device has session history enabled, then each window will have a scroll bar for scrolling through the session history. The session history can be logged to a file for later perusal. Session history should not be confused with command history, which is a list of commands entered into the window. DisplayHandler provides this facility as well. It is similar to the command history provided by the AmigaDOS shell, with some enhancements. Most notable are the ability to control search wraparound, the length of the short line that will be added to the history list, and whether unmodified commands will be added to the list. Other option allow specifying a window/screen to use, borderless windows, simple or smart refresh windows, forcing the screen it opens on to the front, opening inactive, controlling propagation of break characters, pen colors, font and size and keymap used by the window. Using menus is straightforward. When a DisplayHandler device is mounted, a menu can be added to all windows that open using that by providing the name of a menu description file to the "MENU" keyword. The menu file allows you to specify menu entries (or submenu entries), including separator bars, and the text that is inserted into the input stream when they are selected. This allows you to put common commands in the menu, complete with Right-Amiga keyboard shortcuts. The line/history editing facilities are compatible with, and more extensive than, the similar AmigaDOS facilities. Deleting forwards/backwards by words, by chars and by path elements (a "name") are all possible. Cutting text from one history line and inserting it in another is possible. FComp. FComp was intended to be a filename completion facility. Users of other operating systems may recognize this, as in its raw form it works as other such facilities - you type a partial file name, and hit the appropriate magic character, and extra text is added to the line to complete the file name, or part of it. If the file name isn't unique, it beeps at you, and you hit the magic character again to cycle through the possible completions. However, FComp carries this much further than other such facilities I've seen. You can control how completion is done - the string displayed when a completion or partial completion happens, and a "search path" to be checked for files. This control can be done based on the completion key used or the command being entered. The shell and FComp cooperate so that completions that will be read by a running command use the rules for that command. For example, I have FComp configured so that doing filename completion for names to be used by a LISP interpreter look in source:lisp as well as the current directory. Since it's already got hooks into the input stream, FComp also provides a keymap facility. This can be used to provide "hotkeys" for various things, or to change the actions of keys to something you prefer. For example, I use FComp to create an Emacs-like editing environment, and to let me use the arrow keys to control scroll through the session history as well as the command history. Finally, FComp registers the windows it is dealing with as AppWindows, so you can drop icons into a WShell window and have various actions taken on them. The WSHAPP tooltype specifies a string to be inserted - with some substitutions - into the input stream for a window when the icon is dropped on the window. The FILETYPE tooltype causes FComp to check for a string for the named filetype, so that you could cause all files of type ILBM to have "view" run on them if they are dropped on a WShell. If neither is specified, the name of the icon is inserted into the input stream. To make sure things don't get to slow, FComp runs asynchronously. If you decide you know the name and don't want to wait for a directory scan, you can type more characters. FComp won't insert text in that case. FComp also caches directory entries so that searches don't have to happen often. The user is given much control over that cache to trade off performance vs. memory use, but I've found the defaults work rather well. PathHandler. PathHandler is a device driver that provides the same functionality as the multiple assigns in 2.0, on (as usual) with more facilities thrown in. A pathhandler path takes the form path:dir1,dir2,dir3 where the dir?s may be arbitrary AmigaDOS directories, including other path: directories. An alias facility exists so that long path lists can be referenced by a short name. The device tao: can be listed to see what paths and aliases are currently defined. The protection attributes on the directories in a pathhandler path can be used as expected. If a directory would disallow the action being attempted, that directory will be skipped during the search. The meaning of the E bit is changed slightly. If it is off, then a list operation on that directory will get back only the directory name, not the files contained in it. These attributes are those of the pathhandler entries, not the directories themselves. This allows for creating different versions of a path with different protections. Summary. I'm a convert. My Amiga would be much less useful, and I would be much less productive, without the features and abilities that WShell brings to the Amiga. Other have said that various features are "worth the purchase price by themselves." I can only concur. The cost of WShell is low enough that I'd be willing to pay that for part of the functionality it provides. That all these pieces come in the package for one low price makes it an incredible bargain. Administrative Details. For the record, WShell 2.0 is hard drive installable, has no copy protection, and works with 1.3, 2.0, accelerated processors, and the Amiga 3000. --- Es brillig war. Die schlichte Toven Mike Meyer Wirrten und wimmelten in Waben; mwm@pa.dec.com Und aller-mumsige Burggoven decwrl!mwm Die mohmem Rath' ausgraben.