[comp.os.os9] Some Statements from Top

Top@mutec.UUCP (The OS9 Project) (09/24/88)

Dear Readers!

Some days ago a mail from Avygdor Moise arrived.  We want to thank him
for his constructive bug reports, hints and his statements about sources. 
We believe that THIS is the way we should discuss about that problem!

>  From unido!uunet!mnetor!yunexus!yugas!avy Wed Sep  7 02:10:23 1988

> General comments, wish list and bug report from avy@yugas
> ---------------------------------------------------------
> 
> Thanks for the software bundle. It arrived alright. It is really impressive
> and it fill my heart to see some such good work being done on os-9.

THANKS!!!

> I used the tools provided and installed them on two computers for testing
> purposes. The first computer is an Atari-1040 ST and the second is a QT
> Plus II from F.H. Laboratory. Both systems installed alright and most of
> the software runs on them.
> 
> What follows are some remarks about functionality, irritations, praise
> and bug report.

> -------------------------------------------------------------------------
> 1. The disk format
> 
>     We had some trouble initially reading your 3 1/2 DD DS floppy disks.
>     The problem was with the sector offset being set to 1 and not to 0.
>     On the Atari-ST OS-9, the sector offset is set to 0 and not to 1.
>     This is a real problem, since the average OS-9 personal user may not
>     have the required software necessary to change the device descriptor
>     appropriately. As a result they may conclude that the disks are
>     damaged.

SORRY, but we have missed to tell everybody HOW to patch the device
descriptor, so now her a short description.

1) Start the debugger:                    debug
2) Link to the floppy device descriptor:  l d0  (or d1 or ...)
3) Set the relocation register:           @7
4) Change the sector offset:              c 5B
                                          01
                                          .
5) Quit debugger:                         q

That's all.

> 2. uucp
>     We have added the appropriate entry in the SYS/sysinfo data base and
>     uucico no longer complains about a missing lock file. Instead it
>     CRASHES the computer.
> 
>     To be more clear about that. On the Atari 1040 ST, whenever uucico
>     gets started, it dials the required number and then the system crashes.

Thats probably because of a KERNEL(2.1) bug. When the first signal send
to a process is lower 32 (and greater 1, of course) and a intercept
routine is installed (as in uucico), the KERNEL runs into a bus error.
Perhaps Microware should tell us a patch.


Now, some remarks from Ulli on his CSh:

~ 3.  csh
~ 
~     It requires documentation. It works quite well but requires more
~     work.
~     BUGS:
~         a. Does not use the SYS/sysinfo data base to locate the mail
~            directory. It always checks /h0/spool/mail, which
~            unfortunately is not where we have put the mail spool
~            directory.

Now fixed.

~         b. If we move the spool directory into /h0, then CSH reports the
~            arrival of new mail on login, but it does not test the mail
~            directory periodically thereafter to check for new mail. I
~            suggest the use of the environment variable MAIL. This

Csh looks after the time period given in the Shell variable `mail` (NOT
enviroment!) if the modify time of the mail file has changed.  If it has
changed, the message `new mail` is printed.  Problem: if you edit the
mail (via OXM) and write it back csh assumes you have new mail.  The
numeric value of `mail` is in seconds. 

~            variable should contain the path to the user mail box. Also
~            the variable NEWMAIL can be set to a numeric value (in
~            minute) representing the mail checking duty cycle for csh.
~            The MAIL variable should be used by oxm as well.
~ 
~         c. The "last command" substitution directive '^' fails given the
~            following  examples
~ 
~             $ ^bad^good^    ...fails
~             $ ^bad^good^    ...works

I'm sorry but I can't see any problem.  When I tested it, it seemed to
work.  My example:

  $ echo bad thing
  bad thing
  $ ^bad^good^
  echo good^ thing
  good^ thing
  $ ^bad^good^
  csh: Event not found
  $

~         d. Setting the prompt with the '-p' command is compatible with
~            OS-9 SHELL, but is does not allow a child process to inherit
~            the parent's prompt. I think that an environment variable
~            PROMPT should also be set whenever the '-p=xxxx' option is
~            given. When CSH is invoked and the '-p' option is not
~            present, then it should set the prompt to the value stored in
~            $PROMPT (if set) or else to the default prompt (I like your
~            choice).

Looks like a good idea, but I think this is not very critical,
so this could be done later ...

~         e. The prompt does not handle the '@' character representing the
~            nest level of the csh.

Never used this feature in the OS9 shell, so I don't miss it. Perhaps
I'll add it in one of the next releases.

~ 
~         f. The command interpreter does not recognize things like \07
~            (bell) or \r (cr) etc.

Yes, there are a lot of problems with escaping and quoting.  This part
should be redesigned completely.  The ^<prio> to set the priority of a
process and the #<stck> for an incremented stacksize doesn't yet work,
too. 

~         In addition I think that the following functions/features should
~         be implemented by the csh.
~ 
~         a.  Support of conditional expressions
~             if (expr) then expr [else expr] endif
~             switch(expr)
~             while(expr)
~             until(expr)
~             foreach(var (list))

NO! (see my statement on the bottom)

~         b.  Ability to manipulate the environment variables and extract
~             path name components like $VAR:h, $VAR:t etc.
~             Also if VAR=(A B C ... ) then $VAR[1] returns B.
~             @VAR=$VAR+7

For what is this REALLY useful? 

~ 
~         c.  Ability to use process output on the command line
~             e.g.
~                 setenv LOGINTIME `date`
~                 pr `list file_of_names` >/p

This will be added after having cleaned up the source (escaping, quoting..).

~ 1.  I have compiled my version of the PD version of the Unix program
~     "compress" and have moved it into my /dd/usr/bin directory. Then I
~     made 2 more copies as follows:
~ 
~     avy:/dd/usr/bin> copy compress zcat
~     avy:/dd/usr/bin> copy compress uncompress
~ 
~     Then using the OS-9 SHELL I typed the following commands
~     (/dd/cmds/compress and /dd/cmds/expand have been purged on my OS-9...):
~ 
~ 
~     $ compress myfile
~     $ zcat myfile
~     
~         It worked (listed myfile.Z to the screen), since SHELL passed in
~         argv[0] the name "zcat", and compress looks at it to select its
~         runtime options.
~ 
~     However when using CSH:
~ 
~     avy:/dd/usr/bin> del myfile.Z
~     avy:/dd/usr/bin> compress myfile
~     avy:/dd/usr/bin> zcat myfile    .... failed... could not exec 'zcat'

Does the OS9 shell open the file zcat, looks on his module name and
starts then the modulename with argv[0] from the argument list? The csh
ony tries to start the program directly.  If I fix it in the way I guess
it have to be, every fork would take longer as necassary. 

~ 2.  I/O redirection does not seem to work as expected in compound statements
~     
~     avy:/dd/usr/bin> triptex <Unix_tripin1 ! tee tripin.tof
~ 
~     The segment "<Unix_tripin1" was given as an argument to triptex.

Right, a SERIOUS bug and fixed now, sorry!

~ 
~ 3.  Bad choice of 'pipe' or 'history' character. I know that OS-9 uses
~     the '!' for connecting processes using pipes. But this may conflict
~     with the history character '!'. I suggest to use the '|' character
~     for pipes and maintain Unix-CSH compatibility and not SHELL
~     compatibility.

I wanted to keep OS9 shell compatibility and so used the '!'.  When the
'!' is followed by a SPACE then it is the pipe symbol, otherwise the
history is accessed.

~ 
~ 4.  CSH should allow users to CHD to directories which are write
~     protected but not read or execute protected.

I think, this is a problem of the chdir() call.  The OS9 shell doesn't
allow this (still compatible :-), too. 

~ 
~ 5.  CSH should allow the addition of "." in the PATH list to facilitate
~     execution of programs from current working directory (not shell
~     scripts).

In the current version csh scans through the execution directory, the
PATH enviroment and then looks in the data directory.  If a file exist
with the name of the desired program, csh tries to read the first two
bytes if these are the mdoule header sync bytes.  If this is true the
program will be started, otherwise it is handled as a shell script.  If
the first charakter in the script is an '*' then it is given to the OS9
shell. 

Just a few lines:

I have written the csh because the OS9 shell doesn't offer any comfort,
like aliasing and history (these are the both most missed feature).  I'm
also missing my favorite prompt.  So I decided to write my own shell
with these useful functions.  And I wanted to keep the shell as OS9 like
as possible.  So, the '!' stays for piping and isn't replaced by the
'|'.  And as I designed the shell I didn't want to implement ANY kind of
shell scripts.

[End of Ullis comments]

> 4. Missing files
>     mdie, sh

"Mdie <port>" is identically to the command "getinfo -u <port>" and
removes the mmon from a tty line.

"sh" is a kind of restricted shell and not necessary for any of the
other programs. It will be removed in the next release. Instead of the
"csh" the MINIX-Shell will be added to the distribution, if the author
grants us the permission.
 
> 5. Documentation
> 
>    Some of the documentation is in German (sorry I cannot understand
>    German). The part which is in English needs to be tailored to OS-9 and
>    not just copied from Unix. This can be quite confusing to people who
>    do not have access to unix and cannot mentally map file name
>    conventions like /usr/local/lib into the appropriate domain under
>    OS-9. Also things line "see foo (1)" do not make sense under OS-9.

We agree completely. But don't be too stern. We do what we can, but please
consider, that it's a lot of stuff and English is not our native language.
The documentation for the OS9LIB is completed now and ready to post.

>    I think that the documentation should fully describe you clever
>    implementation of the SYSINFO database, and explain how to use it
>    reliably for disk space management, record protection/lockout and
>    terminal locking.

The SYSINFO documentation is included.

>    Some of the tools (or documentation) seems to originate from the Gnu
>    project. If this is the case I think it should be told in BIG
>    LETTERS.

Yep? SORRY.  We will check this out and remove everything from GNU (or
add the sources to the distribution).  Sorry FSF, but we will correct
this!

> More problems:
> --------------
> V7MAKE:
>     When defining the macro RDIR as
>         RDIR=RELS
>     and using implicit compilation rules the command generated is
>         cc .... -rRELS ....
>     and not
>         cc .... -r=RELS ...
> 
>     I understand that V7MAKE is a Unix make, but I think that it should be
>     able to totally replace the OS-9 make utility without any side effects.

When Reimer wrote the implicit rules for the v7make, his first intention
was to get a UN*X-like make .  So the OSK compatible rules were a
semi-quick hack.  But, '-rRELS' is working like '-r=RELS', at least with
my compiler-version (3.0). 

This feature will be fixed (for the sake of different compiler versions).

quite another annoying features of V7make:

  - It is slower than the OSK-Make.
  - The name of the shell is hardcoded to "shell". V7make doesn't
    inquire the environment variable SHELL.

>     When using the ".SUFFIXES" macro, v7make fails to build a proper dependency
>     list. We tried to use V7Make on ..../tex82/texware/makefile (P.S. we ported
>     TeX V2.9 to OS-9 - work done by FutureDOS)
> 
>     .SUFFIXES .r .c .p .ch
>     .p.c:
>         convert $*.p $*.c
>     .ch.p
>         tangle $*.web $*.ch
>     .c.r:
>         $(CC) $(CFLAGS) -r=$(RDIR) $*.c .... Does not work as expected

This is really a serious Bug! Reimer will try to get that fixed, too.

> cpp:
>     Can it be integrated invisibly with the microware CC & C68 programs ?
>     i.e. does it understand the Microware CC directives and does it generate
>     directives and error diagnostics suitable for the use of C68 ?

Yes and no.

It will work completly with the c68 unless you want to pass comments
to the c68 (eg: with cc ..-A -C..).  That's because the Microware
cpp passes comments with a special '#'directive to the c68.  Eg:

' ; statement; /* test-comment */ '

becomes

'#6
; statement; /* test-comment */
; statement;'

The OSK-compiler itself can't handle '/*' and '*/'!

The OSK-mode of the cpp can be switched off with the option '-A'.  In
that case cpp behaves like a normal UN*X cpp ('#line'-directives
etc..) and will generate a LOT more warnings (ANSI-C <sigh>).

Known bugs/features of cpp:

  - the cpp fails to handle strings continued over some lines.
eg:
" test \
string \
one"

  - cpp get confused on following input: '/* comment `foo' */'
                                                     ^^  ^^

  - the line-numbers given to the c68 differs about ONE (1) to the
    correct ones.  This has been fixed already.

  - cpp can't handle '#include file /* Comment */'. You have
    to move the comment to a new line.

  - with the -V or -I option the cpp searches first for ""-files
    then for <>-files.

  - it does not support a -G option (anyway I don't know what
    this option is doing with the original cpp. Apparently nothing?).

  - its slower on output: because cpp splits a line at about
    400 chars (don't worry, only after output of a complete token), it has
    to count the chars on a line.  This was included because every cpp
    expands a macro to a complete line and the input linelength of the c68
    is limited to 512(?) bytes.  With the decus-cpp you can handle almost
    arbitrary long macros (the limit of a non-expanded macro-body is 8Kb). 
    This feature and the -I option were the reasons for porting decus-cpp!


> 6. Finally - WE WANT SOURCES

We too :-)

We start to post sources. Keep attention to comp.os.os9.

> With many many thanks
> 
> Avy

Thanks for your comments,

Wolfgang Ocker, Reimer Mellin, Frank Kaefer, Ulli Dessauer
(TOP Munich)

-- 
    |  Top Munich - The OS-9 Project  ---  ..!uunet!unido!mutec!Top  |
    |          (R. Mellin, W. Ocker, F. Kaefer, U. Dessauer)         |
    | -------------------------------------------------------------- |
    | "We make the stuff you never expected in your wildest dreams." |