dan@ai.mit.edu (07/21/89)
I have a couple bug reports and a suggestions for bash.
Environment: hp9000 series 800 running HPUX.
1. When a job changes status, bash uses the status of the first
process to report the status of the job. Use the following sequence of
commands to test this:
bash$ echo hi | sleep 60
(Type a ^Z here to change the status of the job)
[1]+ Done echo hi | sleep 60
bash$ jobs
bash$
Use ps and see that the sleep process is still running.
Synopsis: The echo command exits almost immediately. When the ^Z
causes bash to check on the job it sees that each of the children of
the job have changed status. It then uses the status of the echo
command (DEAD) to determine that the job has exited. The code in
flush_child() and wait_for() in jobs.c needs to be updated to check
the status of all children to determine the status of the job. Code in
other portions of bash already do this.
2. The kill command returns immediately when it encounters an error.
This is easily verified by starting a job and then issuing the
following command
bash$ kill <non-existent pid> <pid of background job>
Bash will report trying to kill the non-existent process and will not
signal the background job. It needs to print an error message, save
the fact that an error occurred and continue processing.
I have a few comments about the portability of bash. I am running a
System V based machine which supports most of the berkeley
enhancements. I assume there are a great many people with similiar
systems (sysv + berkeley). Although there is little work required in
porting bash to this system, there are a couple of things which would
make it easier. The first is to snarf the init_siglist function from
GNU make (jobs.c) and use this to initialize the sys_siglist array.
This eliminates the need for hacking the list on each system bash is
moved to.
It would be nice if stuff was not controlled by being either sysV or
bsd. The ability to specify individual capabilites ala emacs would be
great (e.g. #ifdef HAVE_JOB_CONTROL vs. #ifdef BSD).
Finally, I feel that the use of long option names is a mistake in
commands. Specifically I am referring to the -path and -type options
on the type command. Although these are more mnemonic than the one
character options, they represent a special case which is one more
thing for the user to have to learn. Consistency in the interface is
very important. At some point someone may produce a getopt understands
both long and short options and will use this in all the current UNIX
commands. Until this happens, we should stick with the current
standard.
Brian - Thanks for a great shell!
dan smith
--
Dan Smith (804)436-1507 dan@virgil.UUCP
EDO Coporation
Government Systems Division
814 Greenbrier Circle, Chesapeake Va. 23320