Amiga MA Magazine 1998 #6/amigamamagazinepolishissue1998.iso/www/cucug/amiga/amiinfo/reviews/wshell2.txt

Internet Message Format | 1997-11-07 | 15KB

From: Mike (My Watch Has Windows) Meyer <[e-mail]>
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 <[e-mail]>
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;                [e-mail]
Und aller-mumsige Burggoven                decwrl!mwm
Die mohmem Rath' ausgraben.