readme.os2

一个开放源代码的 AT&T 的 Korn Shell 的复制品, 支持大多数 ksh89 的特性。

	OS/2 port of pdksh version 5
	June, 1996

Introduction

This document is intended to define the specific features and
differences in the os/2 port of pdksh.  For general features and
descriptions of pdksh itself please refer to the standard pdksh README
or the man page.  In general the port has tried to maintain as many of
the standard ksh features as possible.  For installation details and
an introduction to ksh please read the README.1st file shipped in the
run time zip package for os2.

A default build of pdksh, called ksh.exe, is included in the os2
run time package.  This version was built using the emx environment and
therefore requires that an emx run time package 0.9b or later be
installed on the system.  This is not normally a problem since you
probably already installed it for 'ls' and other Unix commands from
the file gnufutil.zip. (If you haven't install gnufutil.zip you may
want to consider it.)

Building KSH.EXE

If you would rather build your own, you should obtain the sources from
ftp.cs.mun.ca in the directory pub/pdksh.  You will need a copy of tar
and gunzip to unload the archive and install on an hpfs partition. Change
to the source directory and run the script os2\configure.cmd. (If you
prefer you can copy configure.cmd to the source directory.)  This will
prepare the build environment so that your version of make can be used
to build the executable.  Note that configure.cmd is still under
construction and you may need to make changes to the Makefile and to
config.h to match your specific needs.  Copies of all of these files
will be placed into the source directory. In addition you may want to
make changes to config.h to define your particular preferences.
Configure.cmd for os2 support these optional options and arguments:
 /h | /? | -h   Print a usage message and exit.
 /v | -v        Print verbose output during configure 
 /d | -d        build a debug version with symbols (for gcc)  
 sh             build sh rather than ksh 
Any configuration other that the default requires that sed be in your
search path.  You should always get a copy of the latest pre-built version
of ksh as well since the file os2bugs may contain some last minute fixes
that were too late to include in the formal release, and you may find some
other updates.  In addition the run time version supplies a couple of
sample icons for use with ksh.

At this point you can use your favorite make command to build the
executable. Pdksh is known to work with nmake and dmake, gnu make requires
at least version 3.7.3 and is the only one that will automatically make the
man page. You can manually run mkman after starting your new copy of ksh,
'ksh mkman ksh|sh ksh.man'.  (A prebuilt sh and expanded cat version of
ksh.1 is included in the rt package.)

There is a built in check routine that is part of the makefile.  Type
'make check' to run it.  This routine needs a copy of perl on your
machine in order to support the test harness used to test the build.  I
have built the infrastructure into the port to support this checking but
have not been able to get it all to run correctly yet.  The problem is
because of a bug in the os2 port of ksh.  To check the build without using
perl, run the command: 'ksh Bugs ksh'.  This will use the older checking
facility.  You should run this if you make any changes to the source to
insure that you haven't broken something crucial.  Run make check on an
unmodified version first so that you will know what to expect.  If you
want to get the perl version running please contact me for information.

KSH 5 VERSUS KSH 4.9

The KSH version 5 effort is being spearheaded by Michael Rendell. Michael
took over the effort from Simon J. Gerraty who maintained the version 4
code.  While the version 4 code was a good implementation of ksh
version 5 strives to continue the conformance to the actual posix
definitions and to AT&T ksh.

For my version 5 port to os/2, I originally started with the 4.9 os/2
changes and applied them to the new version.  Subsequently many changes
have been made so that there is little resemblance to that version.
One of my goals for version 5 is to make ksh not only and interactive 
shell, but one that can run some limited Unix(tm) shell scripts as well.

Generally the two shells behave the same.  Version 5 has no logout script
(This can be set up using a trap in your profile.ksh file if desired.)  and
the option 'hashall' has been replaced with 'trackall'.  (To see all of the
options use the command 'set -o'.)  In addition the prompt has been changed
to conform with the at&t ksh shell instead of the csh like implemetation of
version 4.  The '!' sign is used for the history number and $variable
substitutions can be used in the prompt.  The commands generally behave more
consistently.  For example bind now goes to standard out so it can be
redirected or piped.  Arrays are now implemented as are almost all AT&T ksh
features plus a few more.  The os/2 port provides file name completion that
is not case sensitive.  The startup file kshrc.ksh is still supported, but
the way it works is slightly different.

OS2 IMPLEMENTATION VS. UNIX

The original OS/2 port was done by Kai Uwe Rommel.  I have re-implemented
his ideas in this os/2 version.  The os/2 version of ksh has been modified
to accept the standard os/2 conventions.  Drive designations a:, etc., are
accepted and path separators in variables have been changed to ';'.  In
addition either '/' or '\' can be used as a directory separator.  The bind
command in emacs mode has been enhanced to accept function key and alt key
bindings.  (To see what the alt key binding should be, use ^Q followed by
the key you are interested in.  Replace the ^ alpha you see with ^0, typed
as two characters, in the bind command.)  The cursor keys have been
implemented for command history for both emacs mode and vi insert mode.
Standard default stty settings are implemented for both modes as well.
A os2 only print option, -f, can be used to force forward slashes in its
argument.  This can be used to switch a variable containing '\' to
output '/' in a pipe to a unix command that doesn't like '\' as a path
separator, such as sed.

/ vs. \ processing

The remapping of certain keys can lead to some confusion for Unix and OS/2
users.  The '\' key has a different meaning in Unix where it is used
to escape a special meaning for the character following it or in the
case of the echo (typeset) command it provides special meanings to
certain characters. At the end of a line the '\' is used to escape the
line feed permitting a command to extend to multiple lines. In OS/2
this key is generally the directory name separator.  To provide for
both functions in the OS/2 pdksh the '\' is defined to be a directory
separator in any pathname specification and will keep its escape
meaning when it is followed by any non-alphanumeric character.  The
echo command retains its special interpretation of '\' and will, for
example, interpret \t as a tab when printing.  This can be
disconcerting when you echo the variable that you just set to c:\tmp.
If you want to use echo on a variable with pathnames in it you should
either use uppercase names or a '/' as a separator. Another choice is
to alias echo to 'print -r' or perhaps 'echo -E'.  This will disable 
the special interpretaions.  You could even use the new 'print -f' to 
force any '\' to switch to '/', but this is less portable.  If you have 
loaded the printenv command it can be used to look at variables.

Unix uses '/' as a directory separator and the OS/2 implementation
permits and in some cases prefers this use as well.  Generally you
can freely mix '/' and '\' characters in a pathname.  However, 'cd \'
will not complete since '\' will escape the new line command and you
will get the secondary prompt.  Just enter a / and the command will
complete.  For many standard os/2 commands the '/' is used to indicate an
option and may want a '\' as a path separator.  These will still work and
be correctly interpreted with pdksh as long as a '/' is not attached 
directly to the command name.  Just be sure and enter the syntax needed
by the command you are trying to execute.

While backslash processing is usually correct and automatic there are times
when it doesn't do what you might expect.  For example ls \tmp\*.exe might
surprise you.  In this case the '\' will be interpreted as an escape for
the '*' character.  You may need quotes or several backslashes to get what
you want. Beginning with 5.2.4 the output of ksh favors '/' for any
generated pathnames.  This is intended to make script processing for
unix scripts easier.  Unfortunately, this may make interactive use for
os2 users that prefer the '\' key a little less desirable.  Should you
prefer the earlier convention then you can rebuild the executable from
the sources.  Only one change in sh.h, DIRSEP, controls this behavior.

; vs. : processing

Another conflict is the use of ':' and ';'.  Unix uses ':' to separate
entries in variable assignment and ';' to indicate multiple commands
on the same line.  OS/2 uses the ';' to separate entries in a variable.
This could lead to problems when making an assignment to a variable in
pdksh.  You will need to escape the ';' in OS/2 to prevent the shell
from interpreting it as the end of the command.  Either surround the
assignment command with quotes or use '\;'.  Note that since a ';' is
not a valid filename or pathname character the '\' will be correctly
interpreted as an escape character.

Since having to escape the ';' character can be a pain when changing
environmental variables containing a list of paths there are some functions
defined in the sample kshrc.ksh file to ease this task.  There are three
functions; add_path, pre_path, and del_path that can be used to append a
path, prepend a path or delete a path from any environmental variable (PATH
by default).  If you needed to add a path to /emx/bin you might do "add_path
e:\emx\bin" for example, or perhaps "add_path e:\emx\book BOOKSHELF" to add
some books to the bookshelf.  Note that you will need a copy of sed in your
search path to use the del_path function.

In OS/2 the ':' is used to separate the drive letter from the rest of
the pathname.  This usage had been preserved in pdksh.  You can imbed
the drive letter as needed in pathnames.  In addition pdksh preserves
the notion of separate contexts for each drive.  To change drives you
would use the cd command.  "cd A:/" would change to the root on drive
A while "cd C:." would change to whatever was current context on drive
C.  Some aliases are defined in the sample kshrc.ksh to permit the
usual A: to automatically do a change directory to the A drive. 

Wildcard Processing

OS/2 and pdksh have similar notions about wildcard characters '*' and
'?' except that pdksh handles the expansion of these wildcard within
the shell and then passes the answer as a list to the application.  If
the application needs to see the wildcard character then you must
escape it from the shell.  Note that pdksh knows about other wildcard
techniques as well.  Please see the man page.

Background Processing

Do to some limitations in the os2 fork process and other differences
between os2 and unix it is not possible to support back-grounding from
pdksh of commands that begin a new window.  For this reason I have
automatically backgrounded all such tasks when they are started.  This
will permit the os2 ksh to serve as a command line launch mechanism for
dos, full screen, and pm applications. (Note that currently ksh can only
launch an application of the same type (windowed, or fullscreen) that
ksh itself is unless you use the 'start' alias.

There is a 'start' alias defined in the sample kshrc.ksh file that can
be used to start normal command line commands in a new window.  For example
you could say "start ksh" to start a copy of ksh itself in a new window.
Since it is a new window it will automatically return control to the existing
copy of ksh.  Note that the start alias uses the os2 start command so
you could supply it with any standard start option such as /FS to force
a full screen copy.  Please check your os2 command reference manual for
further information on start.

PDKSH, OS/2 and the ENVIRONMENT.

The environment in OS/2 and Unix are quite different.  For one thing
you don't actually login to your machine in OS/2 and your initial
environment is established by your CONFIG.SYS file. The Shell will use
the variables that were set in CONFIG.SYS and you should really
consider assigning TMPDIR and HOME for use by pdksh. It will also use
ENV as a variable that names a startup file that will run each time
the shell is started, even if a script is started.  This start up file
is located in your home directory.  For compatability with 4.9 this
shell will also automatically use a startup shell kshrc.ksh if it
finds one in your home directory, is started interactively, and $ENV
is not set.  

The variable OS2_SHELL should point to cmd.exe or a fully compatible
version and will be used as the shell of choice for any scripts that you
write that do not contain the #! or extproc information in the top line
of the script.  If you prefer you can set the variable EXECSHELL to a
shell to be used instead of OS2_SHELL. The use of OS2_SHELL assumes that
the shell requires the /c option and that the shell needs all pathnames
separated with '\'.  Setting EXECSHELL will disable both of these
assumptions.

A special feature is the support of the -l, login option.  If this option is
entered when starting ksh then the shell will execute a loginfile called
profile.ksh if located in $INIT/etc, c:/usr/etc, or your home. If you are
using this shell as your primary shell you may wish to change the settings
in your os2 command shell notebook to call ksh.exe -l.  I would not
recommend changing the default shell in config.sys.

Should you destroy your PATH variable try 'unset PATH'.  A default
path may get you going again.  In addition pdksh for OS/2 always uses
commands from current context first in the search path even if it is
not explicitly set.  By default c: drive is used when no variables
are set.  Specifically c:/usr/bin and c:/usr/etc can be used as defaults
various places in ksh.  If you build your own version then this can be