Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!sunybcs!ugkamins
From: ugkamins@sunybcs.uucp (John Kaminski)
Newsgroups: comp.sys.amiga
Subject: 1.4 wish list
Message-ID: <5137@cs.Buffalo.EDU>
Date: 10 Apr 89 05:59:32 GMT
Sender: nobody@cs.Buffalo.EDU
Reply-To: ugkamins@sunybcs.UUCP (John Kaminski)
Organization: SUNY/Buffalo Computer Science
Lines: 43

My 1.4 wish list:

Although I know it would be rather incompatible with the previous shell,
it would be SOOOOOOOOO handy for the shell to centralize filename expansion,
i.e., wildcarding, and modify the standard programs (copy, more, rename,
delete, etc.) to accept multiple arguments and act upon each.  Or how about
the Pr1me "shell" (it is called the "command level" on their machines)
solution?  The Prime simply re-invokes the command several times, sub-
stituting the next filename on each invocation.

UNIX ln(1) link(2) and unlink(2) (For the non-UNIX types here, the ( # )
notation is the standard manual section) would be appreciated and seemingly
rather easy to implement.  As I put in a recent posting (indirectly), it
would be convenient to store the shell script program under both "co" and
"execute."  ln(1) is the shell-level command which calls link(2).  link(2)
will create another directory entry which points to the same data as another
directory entry.  unlink(2) undoes link(2), and the modification needed is
to store the current number of references to the file so that unlink()
will release the disk storage if the directory entry being unlink()ed has
a reference/link count of 1.

Have a reflexive directory entry such as UNIX's "."  (heck, you have ".." --
that is the same as "/").  It would help typing in Copy commands among other
things.

Copy shouldn't complain about something like copy df0: all to nil:

Have all the defined file bits work.  I don't understand it, but I could
swear I protected a file against reading, but cat --- um hee hee! ahem...
excuse my UNIXness -- Type still gave me the file.

Real pipes.  PIPE: is a good start, but there's nothing quite like:

   $  who | grep '^anyuser' | tail   # last 10 listings of anyuser logged in

RunBack standard.

Execute() should *N*O*T* have to access C:Run (why does it in the first place?)
What's wrong with just loading and running as a child process, like
system(3) on UNIX?  Or just permanently put it in the OS, it's only all of
2324 bytes long as an executable file.

I'm sure there's others, but I'm too tired to remember them.