MDelany@hbapn1.prime.com (Mark Delany) (01/03/90)
From: Mark Delany <mdelany@hbapn1.prime.com>
To: Brian Fox <bfox@ai.mit.edu>
Cc: Bug Reports <bug-bash@wheaties.ai.mit.edu>
Subject: Bash: port to XENIX Sys V; 2 bugs; 1 suggestion
Date: 3 Jan 1990 (12:40)
Hello Brian:
I thought I'd send this direct to you as well as bug-bash@... because it
is mostly about things aport from bash bugs.
First, a big thank-you for bash. I moved over to UNIX (the Xenix Sys V
variant) about a year ago. Prior to that I'd been spoilt on other OS's
that had a decent command-line interface. So, it took me months to
recover from the shock of /bin/sh and /bin/csh... Should I call this
shell-shock? :-)
Anyway, I'm sure you have some idea of the relief I felt the first time I
could pull back a command line and fix it with a key-stroke or two, rather
than have to re-enter the whole thing. Path completion (TAB) is the other
feature I had come to know and love, so this too I had sorely missed
before bash.
BTW, we'll be scrounging together some $$ here to ship to FSF as a more
tangible sign of encouragement. Mind you, converting our Aussie dollars
to US ones seems to make them substantially less valuable, sigh.
----------------------------------------
Port to XENIX
-------------
I've ported bash-1.02 to SCO XENIX System V (I understand that it is
important to differentiate between this and earlier versions of XENIX.
The version I have prints the version number 2.3.1 - kid 5.34).
You are more than welcome to the port code if you're interested.
[I say "interested" as the archive-server (sun.soe.clarkson.edu)
indicates the existence of a 1.04 version of bash in it's index,
but I cannot seem to get the directory). So, if there is a 1.04
you may have already ported it, or the port code I have may be
hopelessly out of date.]
I'll assume that you are interested in some form, so I've appended the
output of diff of every file that had to changed. In case the version
I've got is no longer relevant, I've included a brief discussion on the
essence of the changes.
0. The OS #define
XENIX Sys V is now very close to true SYSV, so I didn't want to
introduce another OS type and have to change every #ifdef SYSV to
#if defined(SYSV) || (XENIX), etc. As it would have meant hundreds
of changes.
What I did instead is to introduce a SUBOS #define, which is set in
conjunction with OS, not instead of it. I'm not suggesting that's
what you do, it just seemed that a lot less code changes are needed
this way. So, my Makefile has:
OS = SYSV
SUBOS = XENIX
It's important that you know this as the appended changes only make
sense in this context.
1. sys/ndir.h
What a pain this is for all ports! On XENIX the correct include
file is sys/ndir.h
2. *getpwuid (), *getpwent ();
On XENIX the structure returned by these routines is named "passwd"
not "pwd".
3. Signals.
The signal list is slightly different (of course!) for SYS V.
Not too bad really, is it!?
Before moving onto the next topic. One last point about porting to XENIX.
If my port is out-of-date but you are interested in a XENIX port, then
send me the latest version and I'll re-port it for you. Actually, if
there is a later version I wouldn't mind it anyway...
----------------------------------------
2 Possible bugs.
----------------
During the port process I noticed what appear to be two bugs. Again,
these may be irrelevant if a 1.04 exists.
1. ifndef JOB_CONTROL
This is trivial. In shell.c you have an #ifndef JOB_CONTROL (line
304) it seems that this should be #ifndef NOJOBS as the code that
follows indicates job-control stuff. I'm not certain the fix is
correct, only that it built and worked for me, It may work due to
serendipity. Perhaps it's meant to be #ifdef, not #ifndef?
2. Core dump when Ctrl-D
This or more serious. The symptom is, when you enter Ctrl-D (that
is read by readline()) bash core dumps. This is especially
noticeable if SHLVL is > 1. I ended up with little core droppings
all over the place when testing the port :-)
The problem seems to be in parse.y when readline() returns an EOF
(because it has read EOF from the terminal). The code in parse.y
never seems to consider that the variable current_readline_line
will contain an invalid pointer, eg EOF.
As far as I can tell, the EOF return from readline() is what it's
meant to return (the test code at the end of readline indicates
this also), so a minor change in parse.y to test for EOF fixed the
problem.
The code to fix both of these bugs has been included as part of the
attached diff report.
----------------------------------------
Suggestion.
-----------
Of course, the inevitable suggestion. It relates to path completion (TAB
and ESC ?) and the idea is stolen directly from the path completion
processing of the PRIMOS command line editor.
I did have a look at the completion code and tried a one line hack to
effect the change, but it didn't work. Nonetheless, it seems *fairly*
easy to do for someone who knows the code - doesn't everybody say that
when they don't have to do the work!
In short, the suggestion is: in the situation when a path completion
cannot advance the path because of duplicates, why not print out the
ambiguity list automatically, instead of ringing the bell?
For example; if your directory contains the two entries:
abc1 abc2
and you typed in ab (TAB), path completion would (as it does now) add the
c, but stop as further completion is ambiguous - fine.
If you TAB again, all you currently get is a bell. You don't know whether
this is because of duplicates or no match, or complete; so you have to go
to a second key-stroke to find out, specifically ESC ?.
However, if the test for duplicates was changes to jump into the code that
lists the choices, the user would be able to differentiate between typos
and ambiguities with less key-strokes, plus they have the list to pick
from!
The rules might be: If TAB can advance, do so. If it cannot advance due
to ambiguity, list the possible candiates. If it cannot advance due to
typo, or completed path, bell.
The advantages I see are:
o Less key-strokes to differentiate ambiguities
o Shouldn't cost more CP/IO as the selection list has already
been built prior to the test.
o Potentially free up the ESC ? binding.
From my brief examination of the code it seems that the path list has
already been constructed, so very little extra code should be required to
implement this - but then again I haven't done it, so it could be
monstrously difficult!
Anyway, like all suggestions, throw it out if you don't like it.
Regards,
Mark D.
======================================================================
Diff report of changes to make bash work on SCO XENIX SYS V
-----------------------------------------------------------
Note that the #define of XENIX assumes #define SYSV
******************** glob.c ********************
35a36,39
> #ifdef XENIX
> #include <sys/ndir.h>
> #include <string.h>
> #else
39a44
> #endif
******************** parse.y ********************
432a433,438
> #ifdef XENIX
> if ((long) current_readline_line == (long)EOF) {
> current_readline_line = NULL;
> return EOF;
> }
> #endif
******************** shell.c ********************
304c304
< #ifndef JOB_CONTROL
---
> #ifndef NOJOBS
******************** trap.c ********************
44c44
< #ifdef SYSV
---
> #if defined(SYSV) && !defined(XENIX)
58a59
> #ifdef XENIX
61a63,67
> "SIGPWR"
> #else
> "SIGUSR1",
> "SIGUSR2",
> "SIGCLD",
65a72
> #endif /* XENIX */
******************** variables.c ********************
29a30,32
> #ifdef XENIX
> struct passwd *getpwuid (), *getpwent ();
> #else
31c34,35
< #endif
---
> #endif /* XENIX */
> #endif /* SYSV */
******************** lib/readline.c ********************
61a62,64
> #ifdef XENIX
> struct passwd *getpwuid (), *getpwent ();
> #else
72a76,78
> #ifdef XENIX
> #include <sys/ndir.h>
> #else
75a82
> #endif /* XENIX */
77a85
> #endif /* XENIX */
2448d2455
<
======================================================================