1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Platform-Specific Configuration and Operation Notes
===================================================
1. configure --without-gnu-malloc on:
alpha running OSF/1
alpha running Linux
next running NeXT/OS
all machines running SunOS YP code: SunOS4, SunOS5, HP/UX
linux (optional, but don't do it if you're using Doug Lea's malloc)
QNX 4.2
other OSF/1 machines (KSR/1, HP, IBM AIX/ESA)
AIX
sparc SVR4, SVR4.2 (ICL reference port)
DG/UX
Cray
NetBSD/sparc (malloc needs 8-byte alignment; GNU malloc has 4-byte)
BSD/OS 2.1 if you want to use loadable builtins
If you are using GNU libc, especially on a linux system
(Configuring --without-gnu-malloc will still result in lib/malloc/libmalloc.a
being built and linked against, but there is only a stub file in the archive.)
2. configure using shlicc on BSD/OS 2.1 to use loadable builtins
3. Bash cannot be built in a directory separate from the source directory
using configure --srcdir=... unless the version of `make' you're using
does $VPATH handling right. The script support/mkclone can be used to
create a `build tree' using symlinks to get around this.
4. I've had reports that username completion (as well as tilde expansion
and \u prompt expansion) does not work on IRIX 5.3 when linking with
-lnsl. This is only a problem when you're running NIS, since
apparently -lnsl supports only /etc/passwd and not the NIS functions
for retrieving usernames and passwords. Editing the Makefile after
configure runs and removing the `-lnsl' from the assignment to `LIBS'
fixes the problem.
5. There is a problem with Red Hat Linux's `makewhatis' script.
Running `makewhatis' with bash-2.0 results in error messages
like this:
/usr/sbin/makewhatis: cd: manpath: No such file or directory
/usr/sbin/makewhatis: manpath/whatis: No such file or directory
chmod: manpath/whatis: No such file or directory
/usr/sbin/makewhatis: cd: catpath: No such file or directory
/usr/sbin/makewhatis: catpath/whatis: No such file or directory
chmod: catpath/whatis: No such file or directory
The problem is with `makewhatis'. Red Hat (and possibly other
Linux distributors) uses a construct like this in the code:
eval path=$"$pages"path
to do indirect variable expansion. This `happened to work' in
bash-1.14 and previous versions, but that was more an accident
of implementation than anything else -- it was never supported
and certainly is not portable.
Bash-2.0 has a new feature that gives a new meaning to $"...".
This is explained more completely in item 1 in the COMPAT file.
The three lines in the `makewhatis' script that need to be changed
look like this:
eval $topath=$"$topath":$name
[...]
eval path=$"$pages"path
[...]
eval path=$"$pages"path
The portable way to write this code is
eval $topath="\$$topath":$name
eval path="\$$pages"path
eval path="\$$pages"path
You could also experiment with another new bash feature: ${!var}.
This does indirect variable expansion, making the use of eval
unnecessary.
6. There is a problem with syslogd on many Linux distributions (Red Hat
and Slackware are two that I have received reports about). syslogd
sends a SIGINT to its parent process, which is waiting for the daemon
to finish its initialization. The parent process then dies due to
the SIGINT, and bash reports it, causing unexpected console output
while the system is booting that looks something like
starting daemons: syslogd/etc/rc.d/rc.M: line 29: 38 Interrupt ${NET}/syslogd
Bash-2.0 reports events such as processes dying in scripts due to
signals when the standard output is a tty. Bash-1.14.x and previous
versions did not report such events.
This should probably be reported as a bug to whatever Linux distributor
people see the problem on. In my opinion, syslogd should be changed to
use some other method of communication, or the wrapper function (which
appeared to be `daemon' when I looked at it some time ago) or script
(which appeared to be `syslog') should catch SIGINT, since it's an
expected event, and exit cleanly.
7. Several people have reported that `dip' (a program for SLIP/PPP
on Linux) does not work with bash-2.0 installed as /bin/sh.
I don't run any Linux boxes myself, and do not have the dip
code handy to look at, but the `problem' with bash-2.0, as
it has been related to me, is that bash requires the `-p'
option to be supplied at invocation if it is to run setuid
or setgid.
This means, among other things, that setuid or setgid programs
which call system(3) (a horrendously bad practice in any case)
relinquish their setuid/setgid status in the child that's forked
to execute /bin/sh.
The following is an *unofficial* patch to bash-2.0 that causes it
to not require `-p' to run setuid or setgid if invoked as `sh'.
It has been reported to work on Linux. It will make your system
vulnerable to bogus system(3) calls in setuid executables.
--- ../bash-2.0.orig/shell.c Wed Dec 18 14:16:30 1996
+++ shell.c Fri Mar 7 13:12:03 1997
@@ -347,7 +347,7 @@
if (posixly_correct)
posix_initialize (posixly_correct);
- if (running_setuid && privileged_mode == 0)
+ if (running_setuid && privileged_mode == 0 && act_like_sh == 0)
disable_priv_mode ();
/* Need to get the argument to a -c option processed in the
|
