readme.os2

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

changed.

Generally all of the environmental variables described in the man page will 
work in OS2 so long as the tools in use understand them in the same way
as Unix would.

Using KSH

The shell itself can be called any name you wish.  Good names include
pdksh.exe, ksh.exe, sh.exe.  You can build two completely different
shells using the options file.  A full blown Korn shell can be built
or a complete subset that behaves very much like a Bourne shell.  The
smaller version is excellent for script support.  In the run time
release I have provided the full shell under the name ksh.exe and the
smaller version under the name sh.exe.  Be careful with names like
rksh.exe or you could end up with a restricted shell that can't do
everything.

In Unix an executable can be tagged with an attribute to
make it known to the system as an executable.  In OS/2 this is done
with an extension.  This shell knows all of the standard OS/2
extensions plus .ksh and .sh.  (Yes it can run dos commands and OS/2 command
files as well.)  The .ksh or .sh extension tells the shell that this is an
executable shell script.  The current version will also treat a file
without an extension as an executable in the style of Unix.  Scripts need not 
necessarily be a ksh shell scripts however.  The standard Unix #! line at 
the top of the file determines the actual shell that will be used to run 
the script.  A feature in this release is that any Unix absolute
pathnames will be tried and, if they fail a second try will be made by
stripping the path from the #! line since Unix style paths are unlikely
to match os2 usage.  Your standard PATH search path will be used.
Should the same filename with a different extension exist in the same
directory pdksh will use the extension typed in by the user or if
no extension is entered then the search order is, .ksh, .exe, no extension,
.sh, .cmd, .com, .bat.  This search order permits ksh scripts to be used to 
modify binary executable behavior while allowing the -Zexe option for emx 
gcc. .  Note that if you explicitly type the extension yourself then any 
extension can be used so long as the #! processing line is at the top of 
the file to let pdksh know what to do.

The sample kshrc.ksh file that comes with the distribution can be used as
an example that shows you how to create aliases that will simulate the
standard OS/2 commands.  This means you can still use copy, dir, and del if
you want to.  Keyboard bindings supplied will still provide the command
stack and suddenly you also have command line completion and alias
capability.  To get the most from the shell you will probably want the set
of Unix commands developed by the Gnu team and ported to os2.  You will
most certainly need them or a similar set if you want to run any Unix
scripts.  A few functions are also provided in the sample kshrc.ksh file to
demonstrate the power of functions and to ease common tasks.

Unix file systems are case sensitive and ksh generally expects this also.  
This means that internal commands as well as aliases are case sensitive.  
You can use this to your advantage.  For example you might want to run a dos 
shell only to find out that 'command' is captured as an internal command by
ksh.  Try 'COMMAND' or even 'Command' and you will get what you wanted.
The file name completion and wild card expansion has been modified for os2
to permit it to ignore case.

Working with Editing Modes

As delivered ksh for os2 supports three different editing modes to use
with the command line.  By default the editing mode is the same as that
used in cmd.exe in that F1, F2, and F3 can be used to edit the previous
command.  Left and right cursor keys can also be used to edit the command.
Support for this comes directly from the emx layer.  The history mechanism
is supported in this mode but you will not be able to scroll trhough
history from the command line.  Pdksh commands exist to display and edit
history and the EDITOR environmental variable can be set to specify the
editor you want.  Two other mutually exclusive editing modes exist as well.

The sample kshrc.ksh file turns on emacs editing mode.  In this mode
pdksh emulates the commands and keyboard binding present in emacs.  The
keyboard binding is fully customizable by the user using the bind command.
For os2 the default build includes support of the cursor keys to edit
both current and previous commands.  The sample kshrc.ksh file includes
some further mapping as examples of keyboard binding.  The bind -m
command can be used to define special macro commands.  Note that in emacs
the ESC key following by a letter key is usually synonymous with holding
down the ALT key and pressing a letter key.  In the current os2 implementation
these keys are not tied together so they could be programmed independantly
although this could be confusing for the user.  This may change in the
future.

Issuing the command 'set -o vi' turns on vi mode. This mode emulates the
keyboard binding from the vi editor.  In addition using the tab key for
command line completion is separately programmable using the set command.
For os2 the cursor keys are also set up to work from within insert mode to
allow editing of both the current and previous commands without ever
leaving insert mode.  The Esc Shft-A sequence can be used to jump to the end
of the line allowing you to append new information to the line.  CTRL-X,
CTRL-E and CTRL-F permit command line completion within insert mode.  Thus
you can use vi mode without ever having to learn traditional vi commands.

SHELL SCRIPT PROGRAMMING

One of my goals in porting this shell was to be able to do shell level
script programming and to run Unix shell scripts with minimal modification.
The first goal is easy and fully functional in this release.  You can write
shell scripts for this or other shells. The name of the shell you want to
run the script is entered in the first line of the script itself after a
'#!' sequence.  If you only enter the name of the command then pdksh will
use your search path to find the shell.  This is the recommended approach,
however absolute paths of the form /bin/ etc. will be stripped
automatically if needed to permit running Unix scripts unmodified. To write
portable scripts use the 'uname' command from Gnu to set a variable that
can be checked for specialized approaches.  As a special case absoulte
paths using '\' will not be stripped and an error will be generated if
the command is not found at the exact path specified.

It is even possible to use ksh as a scripting language when your main
shell is a standard OS/2 shell.  To do this you would write your ksh
script as usual except that the first line in the script should read
'extproc ksh'.  The script should be named with a '.cmd' extension so
that the OS/2 shell can find it.  When the cmd.exe finds this line in
the file it will call ksh to process the script for you.  A script
that is written this way can also be called directly from ksh.  As a
matter of fact you could use this technique entirely for script
creation and name all your scripts with the .cmd extension.  Pdksh
will honor 'extproc' exactly like the standard Unix '#!' processing.

Unlike Unix #! processing the OS2 cmd processing of an extproc header line
only passes the file name to the spawned process instead of the full
pathname.  This is a bug in os2 IMHO since if you explicitely want a
certain path for the command you cannot guarantee it.  The workaround was to
put the path in the extproc line and then shift the extra filename off the
argument list.  For example my whatis.cmd file used to start like this.

     extproc ksh c:/usr/bin/whatis.cmd
     shift

You can still do this, but ksh will also search the path to find a copy
of the command, so this is no longer required.  Of course, the copy that ksh
finds might not be the one you wanted but at least you can copy your cmd
files around without having to modify them.  A side effect of this change
is that typing: "ksh whatis" will now search your path as well which does
change the standard behavior of ksh which some might construe as a feature!

The second goal of running Unix scripts with little or no modification is
much more difficult to achieve.  Unix makes many assumptions about how the
system is set up which makes fully portable scripts difficult to accomplish
without the knowledge of the script internals.  Many script assume the
presense of /dev/null and /tmp.  (The emx layer provides an automatic map
for shell references to /dev/null and /dev/tty as of the 0.9a version and
pdksh also maps /dev/null to nul for the cases where emx doesn't see it
unless a /dev/null is present.)  Some scripts assume /bin and certain
commands within /bin (usually cp and sh). Until I can figure out how to 
make this more transparent you can simply make these directories on the 
drive that you intend to run the script on.  (Of course, you could also 
modify the script.) Some scripts reset the PATH variable near the beginning
of the script.  While you could copy a whole set of commands it is probably
easier to modify the script or use tvfs (more about tvfs later.)  Another
standard "trick" in Bourne shell script programming is to modify IFS to
include a colon and then use the set command to parse a variable by setting
$1, $2, etc.  In OS/2 this would need to be a ';'.  For now you will have to
hand modify the script.

The latest release of ksh for os2 now supports multiple open files
using standard pdksh syntax.  Note that error checking may not be
as complete as standard pdksh for some of this usage.

Of course Unix scripts expect the presence of Unix commands.  You will
need to install a set of Unix utilities, Unix text processing
commands, and probably sed and a version of awk.  I have created a
c:/usr directory on my system for Unix stuff.  I have /usr/bin,
/usr/man, /usr/etc, /usr/home, and /usr/local.  You could establish
even more, or perhaps less, Unix conformance.  You will also need a ps
command.  I use procs.exe which I renamed to ps.exe.  Kill is a ksh
builtin.

RUNNING UNIX GNU CONFIGURE SCRIPTS.

A lot of people would like to use pdksh to permit them to run the
gnu automatic configure scripts.  I am pleased to report that this
is possible using pdksh.  However, I can't guarantee that the results
will match the true configuration for os2 since this is dependant on
the way the individual configure scripts are written.

To set up to run configure scripts you will need to have a copy of pdksh
called sh.exe somewhere in your path and, of course, you should be
running within a pdksh shell.  One of the very early things done
by most configure scripts is to figure out the compiler.  This will fail
since it depends on setting the IFS (see the above discussion).  To
workaround this problem simply set CC to the compiler you want to use
prior to running the script.  For example to use gcc: 'export CC=gcc'.
Most configure scripts couldn't figure out the names of os2 compilers
anyway.  Now you should be able to simply type 'configure' and watch it
work.  At some point the configure script will build a config.status
script to perform the final step.  If this is not run using 'sh -c
config.status' or some such it will fail since .status is not an os2
legal executable suffix.  You can run it manually however by typing 
'ksh config.status'.  If you have problems you should inspect the
config.status script and fix it as required.  Using ksh -x config.status
will echo the lines as they are executed which should aid in debug.

Many configure scripts actually build and execute programs to test
for certain features.  In OS2 using emx, the final link step must have
the .exe extension tied to the executable name or the linker will not
link correctly.  You will need to modify the configure script to
insure the correct executable name.  Once this is built it can be
renamed to a name without an extension if ksh is being used to run it.
A line similar to the following may work for you if you are using 2.0:

ac_link='${CC-cc} -o conftest.exe $CFLAGS $CPPFLAGS $LDFLAGS \
conftest.$ac_ext $LIBS && mv conftest.exe conftest'

This trick takes advantage of ksh's ability to run a command without an
extension.  Even with these changes you may still find that configure does
not correctly identify some os2 features.  I would recommend that the
config.cache file be edited as required or the resulting config.h file.

Another trick is to use the -Zexe option to gcc.  This builds a zero length
file without an extension and the real executable with the extension .exe.
Makefiles and some configure scripts may be fooled by this behavior.

TVFS

An IBM employee written program called tvfs, toronto virtual file system,
can be downloaded from most os2 ftp sites and from IBM ftp sites.  This
program permits you to simulate a Unix like file system that can span
physical drives and even network drives.  Using tvfs you cd once into the
drive letter designated as the tvfs drive and from then on you can
reference all of your drives and directories by only using Unix style
pathnames if you wish.  Even a limited form of symbolic links can be set 
up on this drive.  This can be a great aid in running Unix scripts and
makefiles as well as configure scripts.

WORK IN PROGRESS

There is still much to do and this project will probably never be complete.
The configure.cmd file needs work as does the Makefile.  Please let me know
if you get this to compile using a C compiler other than gcc.  The standard
defaults work in the Makefile but many other things are not implemented.
And of course there are bugs to fix and enhancements to be made.  Check the
file os2bugs in the run time release for the latest information on bugs.

Please let me know if you like this port, have found a porting bug,
have fixed a bug, or have coded a spiffy enhancement.  Michael Rendell
should be consulted for general pdksh items and is now actually
maintaining and enhancing all of the code.  Please check the standard
README for more information and also the file os2bugs for current known
problems and limitations.  I can be reached at [e-mail].

Note that this is a home brew project and is in no way related to my
employment.

	Dale DePriest