In article <[log in to unmask]>,
David Groves <[log in to unmask]> wrote:
>2)  Both listf and listfile should allow either '*' or '@' as wild-card
>    characters, at least if being used from inside POSIX.
 
I wouldn't suggest trying to merge the two worlds like this.  Wild-card
expansion works very different in POSIX (where it's done by the shell)
than it does in MPE (where it's done by the utility).
 
>3)  Using output redirection from a compound command can cause bizarre
>    behavior, i.e., lines passed to a subsequent command sometimes have
>    'temporary' file names appended to them (such as '> U12223223.xx.xx').
 
Do mean when you do something like this?
 
        ( echo one; echo two; echo three) | cat
 
>4)  If a soft link exists (/x/b/c.d@ -> .src/c.d), then the wrong error
>    message is provided if an attempt is made to lay another link on top
>    of the existing one; instead of 'a link already exists' or the like,
>    the message "ln: File or directory 'blah/blah' is not found" occurs.
 
What's sounds happening here is that you've supplied a destination that's
that's symbolic link to directory.  In that case the ln utility will
follow that symlink and try to put the symlink in the destination
directory.
 
>6)  cat does not preserve copied line lengths under all conditions.  If
>    a file's line lengths are 'excessive,' cat has been known to truncate
>    lines without warning or notice.
 
Sounds like a bug in the C stdio library, and a problem in just about
every utilitiy.
 
>8)  When make encounters a target that should have an active link to
>    another source location (but that link is missing), it should say
>    something to the effect that 'the file blah/blah.c is missing' instead
>    of saying "make[2]: No rule to make target 'blah/blah.c'." I know this
>    is a ported version, but it should still be correct.
 
I think the error message is correct.  Make can't tell if the file is
missing or a rule is missing needed to make the file.
 
>10) ftp, when run inside the POSIX shell, should (in my opinion) default
>    to HFS-style names, that is, it should not be necessary to use
>    ./src/wm/file.c as opposed to just src/wm/file.c.
 
I don't know if there's a general way for an MPE utility to tell if it's
been started from the shell.
 
>14) The command-line limit for c89 compiler switches is seriously short.
...
>15) When c89 is invoked with the -E switch, the output should appear in
>    a form that allows piping it back to an invoking process...
>16) When c89 is given the -P switch, it should allow HFS-style names.
>17) The c89 compiler should allow very long lines (> 2049 characters) ...
 
These all sound like problems in the underlying CCXL compiler.
 
>20) vi needs to be able to handle very long lines (> 2049 characters).  It
>    currently just shows a series of '@' characters at the left margin (no
>    text) and does not respond to Crl-G or other commands very well while
>    trying to cope with the long line.
 
This is traditional vi behaviour...
 
>23) Someone needs to port Emacs to the 3000.  In my next life, I'll have the
>    time, but not today.  Qedit works wonderfully under POSIX, but it's
>    not free, and not even cheap.
 
Porting GNU Emacs would be a major task.  I shudder at the thought of
trying to get undump working under MPE.
 
                                                Ross Ridge
 
--
 l/  //   Ross Ridge -- The Great HTMU                         +1 519 883 4329
[oo][oo]  [log in to unmask]      http://csclub.uwaterloo.ca/u/rridge/
-()-/()/
 db  //