[comp.binaries.ibm.pc.d] picnix with sh problem

istewart@datlog.co.uk ( Ian Stewartson) (04/12/90)

marty@wuphys.wustl.edu (Marty Olevitch) writes:

>In using the picnix utilities with either the "sh" shell that
>was recently posted or with the MKS Korn shell, I noticed that
>none of the commands produced any output unless they were given
>a dummy argument. They did work correctly under command.com.
>[example removed]
>It doesn't seem to matter what the dummy argument is, as long as
>it is present. The same thing happens for all of the picnix utilities
>that I tried.

As one of the authors of ms_sh, I tried this as a result of this message
and the problem appears as reported.  However, I am at a loss to explain
why.  I don't use the Picnix utilities (PU) myself so I wasn't aware of the
problem until it was mentioned, so this problem does exist in the 1.6
release which when to Bill Davidsen yesterday.

A couple of comments that may help someone identify the problem.

   1.  The PU appear to have been written using TurboC.  I don't have
       TurboC so I don't know how it processes its command line or gets
       its command line.

   2.  MS_SH does not write the command line exactly as COMMAND.COM, it
       leaves out the first space (and the trailing space when redirection
       occurs).  Now this doesn't seems to affect any programs I have written
       or purchased.  However, I modified MS_SH to emulate COMMAND.COM
       more precisely and the problem remains.  As far as I can tell, MS_SH
       generates the PSP exactly as COMMAND.COM with the exception of
       the pointers, return address, original interrupt addresses etc.

   3.  Although the PU work with COMMAND.COM, they don't work if you
       spawn them from a programme:

       #include <stdio.h>
       #include <process.h>
       main ()
       {
	   spawnl (P_WAIT, "ls.exe", "ls", "/l", (char *)NULL);
       }

       generates a short multi-column listing and not the long listing
       expected.

In the light of this problem, and one or two others than have been reported,
I've written to Bill to ask him to discard the release.  If you have a
solution to this problem or can tell me where or how TurboC processes its
command line, PLEASE MAIL me at istewart@datlog.co.uk or
{}!uunet!mcsun!ukc!datlog!istewart.  We have a 4 (FOUR) day expiry on all
non-source groups here and I am on holiday for the next twelve days.

On another subject, unfortunately the shell does mask the 8-bit.  The MINIX
shell from which this is derived uses the 8-bit to mark characters escaped
by a \.  I agree that we should write software supporting international
characters sets (8, 16, 24, 32).

However, changing the shell to support 8 bits is quite a major task and I
felt it was more important for the first release to get it working.  The
second release fixes a number of major problems in the shell other than the
8 bit problem.  It also introduces some new features to make it more usable
in the MSDOS environment.  It is and remains my intention to get release 1.7
8 bit clean (which resolves a related problem with \).

In defense of my decision to release it to CBI, I can only say that 1) I
received a number of requests for the executable after posting it to
comp.sources.misc; and 2) a large number of people using the shell are
more likely to find problems (see above), give useful feed back etc than
one or two.  The documentation does state that the shell does not support
8 bit character sets (Readme, section on Differences, point 5).

And, please, if you do come across a problem with the shell, let me know.
I will acknowledge all mail relating to the shell (assuming I receive it).

Thanks,

Ian Stewartson
Data Logic Ltd, Queens House, Greenhill Way, Harrow, Middlesex, HA1 1YR, UK.
(Phone) +44 1 863 0383 (Telex) 888103 (Fax) +44 1 861 2010
	+44 81 863 0383 after May 6th 1990.
(Network) istewart@datlog.co.uk or ukc!datlog!istewart