Greetings, fellow laborers in MPE/ix-dom:
While many of you were having a marvelous time at the party in Toronto, some
of us were mired in the muck of trying to squeeze water from the stone of
POSIX on MPE/iX 5.0. If I sound less-than-overjoyed, then I have communicated
well. There are so many possibilities in this setup that are simply falling
by the wayside, as it were. Perhaps some of the items listed below have
occurred in your work, or perhaps you would just like to get some discussion
going on the substance/intent of some of them. By the way, nothing in this
list or my comments should be construed as critical of the work that Steve
Elmer and others have done so far. I would surely not still have this job
if it were not for the ports of make and perl. Many thanks!!
I have listed a non-exhaustive collection of items, in no particular order,
items which are a) bugs; b) undocumented features; c) poorly documented
features; or d) other, encountered when traveling through the POSIX shell on
MPE/iX 5.0 (more detail available for any item that is not clear):
1) stream should allow HFS-style file names.
2) Both listf and listfile should allow either '*' or '@' as wild-card
characters, at least if being used from inside POSIX.
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').
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.
5) The command file invocation line "#!file_path" should be implemented.
I can kludge it for, say, perl, by setting up a file by the desired
name (say, my_test) as /bin/my_test with execute permissions; its
contents are a single line:
/bin/perl /bin/my_test.pl $*
where the real perl statements are all in /bin/my_test.pl and
where $* transfers all the command-line values to the perl file.
As you can see, this does require two files every time.
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.
7) The port of GNU make 3.70 does not recognize control-y, so using the -d
feature completely locks the terminal until something interruptible
gets called.
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.
9) find does not recognize control-y, and cannot be interrupted.
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.
11) The ftp command "stream" should be documented somewhere; the only way
to learn of its existence is to enter "remotehelp site" from an ftp
session logged in from another platform, and that tells nothing of
the expected command syntax (which is 'quote site stream mpe.file.name').
12) ftp needs a redo capability.
13) ftp needs to be able to handle very long lines (> 2049 characters) in
bytestream mode.
14) The command-line limit for c89 compiler switches is seriously short.
It should allow several hundred characters (maybe 1023). This has
been noted previously by Steve Elmer, but it's still not fixed.
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, e.g., when
invoked through a fork (or implicit fork in a file open). I kludged
together a mechanism for accomplishing the same purpose (for building
a dependency file using the preprocessor output from c89), but it's
clumsy.
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)
without an intervening carriage-return character; the syntactical
line can be longer than that, but the physical line cannot exceed
about 130 characters, as it is now, before causing trouble.
18) If a long double is used as an argument to va_arg, there is
the potential for stack corruption of the c89 compiler run (it occurs
in the lookup_quad routine in c89, NOT the resulting program's execution!)
unless some long double is both declared and initialized before the
first appearance of va_arg. This has been addressed in KPR #5003276196.
19) When vi opens its screen, it should use terminal commands to 'go to
next page' rather than 'home and clear': the visual effect would be
the same for the user, but previously displayed lines would not be
wiped out. Once it has opened a screen, vi handles the display OK.
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.
21) perl should become a supported (i.e., 'provided') utility, and
sufficient resources should be allocated to keep up with the current
version. For instance, the ported version, provided by Steve Elmer,
is 4.036, but the currently available version is 5.001m.
22) perl needs to recognize control-y.
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.
Feel free to correct my wayward path on any of these items, or to enlighten
me as to what I should/could have done instead. Let me hear from you.
--
David Groves [log in to unmask] |
UniSQL, Inc. [log in to unmask] |
8911 N. Capital of Texas Hwy #2300 |512-343-7297x181 |
Austin, TX 78759 [log in to unmask] |
|
