From stuckey@mrcnext.cso.uiuc.edu Mon Nov 23 13:55:30 1992
Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629)
	  on Mon, 23 Nov 92 13:55:22 -0600 id AA04525 with SMTP 
Received: from garcon.cso.uiuc.edu by calvin.sfasu.EDU with SMTP (5.59/25-eef)
	id AA29972; Mon, 23 Nov 92 13:44:31 CST
Return-Path: <stuckey@mrcnext.cso.uiuc.edu>
Received: from mrcnext.cso.uiuc.edu by garcon.cso.uiuc.edu with SMTP id AA08166
  (5.67a8+/IDA-1.5 for <hyperc-l@calvin.sfasu.edu>); Mon, 23 Nov 1992 13:41:41 -0600
Received: by mrcnext.cso.uiuc.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA19061; Mon, 23 Nov 92 13:38:50 CST
Date: Mon, 23 Nov 92 13:38:50 CST
From: stuckey@mrcnext.cso.uiuc.edu (Anthony J. Stuckey)
Message-Id: <9211231938.AA19061@mrcnext.cso.uiuc.edu>
To: henigan@quando.quantum.de, hyperc-l@calvin.sfasu.edu
Subject: Re: HyperC evangelizing
Status: R

The way that Unix MAN runs is to read from an environment
variable a set of directories to search for your man pages.
I don't know how hard this would be to inplement in Hyperrc -- I
would think that you could make a /csys/manpath file, which holds
on separate lines the directories to be searched, reads these
in and tries to open the man file under each of them, returning
not found if it can't find it.

Many Unix programs mane use of either the password file for multiple
users or environment variables.  This is a real prorting concern.
Since this is a single user system, it could be set up so that
All of this stuff just gets ripped out, but that may complicate
porting.  (it's probably best though).

Programs like UUDECODE and Unix-UNZIP are going to make use of
file permission bits that are not available under prodos.  This
information can be thrown away by the De-coder, but a corresponding
En-coder is going to have to make up some reasoanable fake entry.

2)
HyperC inclusdes a lot oof Unix functions, but names them mostly
to entirely non-standardly.  Curses is pretty fully represented,
as far as movement and plotting functions go, but there is no
newwin() to get multiple windows, refresh() is  done automatically,
(most versions of games will write thingsto the screen and then rerase
them in testing valid moves, etc -- for real applications this probalhybly
isn't nearly so much of a concern.)

STD.H in and of itself is entirely non-standard.  This includes entries
from <ctype.h>, <files.h>, <stdio.h>, and other such things.  breaking
it apart might make compile times faster.
Strings.h is mostly non-existent, with important functions like
strcpy() and strcat() missing.  index() and rindex() are names that
I've seen in unix environments, but the more common name for rindex()
is strrchr().  strtok() is missing, the entire scanf() family is

getc() family under Unix acts differently.  getchr() is  usually named
getchar(), getc(stdin) will get you a character from the keyboard,
etc.  There are a lot of complexities in the Unix multi-processing
support that aren't mirrored in HyperC under the default distribution.

I have come up with no good way to implement some things like pipes.
The best that I've thought of is to have the original program scan
it's command line for the | symbol, and if it is found use the
exec() command to start up the appropriate second program with
a "tmp.file" output file or something similar.  this would work
really well for more and other simple utilities, but fails pretty
quicklyonce you start getting command line options on the second
program.