jjd@BBN.COM (James J Dempsey) (06/14/89)
I have collected a set of bugs and suggestions which I will send in
this one message. I'm sending them now in the hope they will be
considered for 1.0.
I am using Bash 0.99 under Ultrix 3.0 on a VAX 8530.
------------------------------
bug:
There seems to be a bad interaction with the use of PROMPT_COMMAND and
"if". Consider the following:
if date
then
echo yes
fi
This works fine if PROMPT_COMMAND is unset, but if PROMPT_COMMAND is
set to (say) "date", then bash core dumps after saying something like:
"OOPS! Bad command type `313548'!"
------------------------------
misfeature:
make_bug_report tries to automatically send bug reports using
/usr/bin/mail. I'm not sure if this is wise. Our host uses MH/MMDF
so /usr/bin/mail won't actually send mail. If you really want this to
work, perhaps you should make a compile time option which is the
command to use for mailing bug reports.
Of course, everyone on bug-bash is probably happy that this failed to
send mail on my system, because I've hit make_bug_report about 50
times in the past week or so during debugging and we don't need all
that traffic on bug-bash.
------------------------------
If you define a function and use the name of the function in the
function definition, bash trys to recurse until it core dumps. I'm
talking about a function like this:
function ps () { ps | more; }
Do you really mean to allow recursive functions? I've tried to get a
working recursive function and have been unsuccessful. Perhaps you
should either not allow recursive functions or make it so that if the
first command called in a function matches the function name, then the
program by that name is called instead of the function. This would
allow people to customize programs with their own arguments without
having to use a different name for the function.
------------------------------
bug:
Local variables don't seem to work. The function describing them in
the manual core dumps when I try it. That function is:
using_bin () {
local PATH=/bin;
eval $*;
}
This also core dumps:
function foo () {
local x=1;
}
------------------------------
Confusion:
I'm confused about which init files run when. I'm going to leave
.inputrc out of this discussion because I understand that it is the
init file for the GNU Readline library and it should only contain
readline commands and is executed upon starting any program using readline.
From reading the code it looks like for a login shell named "bash" the
following init files get executed:
/etc/profile
~/.bash_profile
And for a non-login shell named "bash", the following get executed:
~/.bashrc
This means that for things like aliases and functions, you must either
put them in both your .bash_profile and your .bashrc or you must
explicitly source your .bashrc from from your .bash_profile in order
to make sure that they are always defined.
I'm thinking of the case where bash is your login shell. If I login
from a telnet connection, .bash_profile gets executed. If I start up
an xterm window, only .bashrc gets executed. This doesn't seem right
to me.
Why not make bash do the following: For a login shell have bash source
/etc/profile, .bashrc and .bash_profile. For a non-login shell have
bash source just .bashrc. In this way one can isolate things like
terminal type negotiation for login to .bash_profile and put other
things which always need to be done (like settting PATH) in .bashrc.
No matter what scheme is chosen, I think it would be a good idea to
describe it in the documentation -- even the preliminary documentation.
------------------------------
Question:
Is there any way to tell (from inside your init file) whether or not
the shell it is running in is interactive or not? In csh, you can say
"if ($?prompt)". This is important because there are some things
(like "stty") you don't want to do if you are non-interactive (say in a
script or an rsh command) while others you always want to do.
If there isn't a mechanism for determining whether the current shell
is interactive, there should be.
------------------------------
bug:
This one is going to be hard to explain because I don't know what I'm
talking about.
I use rsh to start up X windows client programs on other hosts. For
example, I want to do something similar to:
rsh other-host -n "DISPLAY=myhost:0.0;export DISPLAY;TERM=xterm;xterm"
however, I don't want the local rsh to hang around for the duration of
the client, so (under tcsh or csh) I can cause it to go away by
exec'ing the client and setting its stdin, stdout and stderr to
/dev/null. Something like this:
rsh otherhost -n "setenv DISPLAY myhost:.0;exec client </dev/null >&/dev/null"
However, when I use bash, even when I set stdin, stdout and stderr to
/dev/null and exec the client, the local rsh stays around for the duration of
the client anyway.
------------------------------
suggestion:
It would be nice if there was a .bash_logout file.
------------------------------
Despite these teething problems, I've been very happy with bash and
currently use it as my login shell. It's great.
--Jim Dempsey--
BBN Communications
jjd@bbn.com (ARPA Internet)
..!{decvax, harvard, wjh12, linus}!bbn!jjdcomposer@BU-CS.BU.EDU (06/14/89)
| Date: Tue, 13 Jun 89 14:33:53 -0400 | From: James J Dempsey <jjd@bbn.com> | | I have collected a set of bugs and suggestions which I will send in | this one message. I'm sending them now in the hope they will be | considered for 1.0. | | I am using Bash 0.99 under Ultrix 3.0 on a VAX 8530. | | ------------------------------ | bug: | | There seems to be a bad interaction with the use of PROMPT_COMMAND and | "if". Consider the following: | | if date | then | echo yes | fi | | This works fine if PROMPT_COMMAND is unset, but if PROMPT_COMMAND is | set to (say) "date", then bash core dumps after saying something like: | "OOPS! Bad command type `313548'!" Well, I don't have an Ultrix system to play with right now. But, I was unable to reproduce the above core dump on a Sun 3 running Sun UNIX 4.2 Release 3.4 nor on an Encore Multimax running UMAX 3.3. Can anyone else out there duplicate this problem? | misfeature: | | make_bug_report tries to automatically send bug reports using | /usr/bin/mail. I'm not sure if this is wise. Our host uses MH/MMDF | so /usr/bin/mail won't actually send mail. If you really want this to | work, perhaps you should make a compile time option which is the | command to use for mailing bug reports. Actually, I will be sending some changes/suggestions to bfox relatively soon with something to similar. I'll include the idea of it being optional at compile time. Just so you know, another possibility is to have the bug report mailed to the MAINTAINER instead (which, if set properly will not be bug-bash.) Also, the program to open the pipe to should be set in a #define, or some method similar. I'll have changes shortly after I finish some other projects I'm working on. | bug: | | Local variables don't seem to work. The function describing them in | the manual core dumps when I try it. That function is: | | using_bin () { | local PATH=/bin; | eval $*; | } | | This also core dumps: | | function foo () { | local x=1; | } Again, I was NOT able to reproduce core dumps on the above. They both worked fine. Of course, I'm not using Ultrix, so I'm not sure if others (in addition to you) are having a problems it. | Confusion: | | I'm confused about which init files run when. ...stuff about ~/.inputrc deleted... | >From reading the code it looks like for a login shell named "bash" the | following init files get executed: | | /etc/profile | ~/.bash_profile | | And for a non-login shell named "bash", the following get executed: | | ~/.bashrc You are correct. If it is a login shell: execute if they exist in the following order: /etc/profile ~/.bash_profile (as long as -noprofile is not specified) if ~/.bash_profile is not found ~/.bash_login and if not found then ~/.profile If you want ~/.bashrc to be executed in a login shell just source it in your ~/.bash_profile. If it is not a login shell: just execute ~/.bashrc | Why not make bash do the following: For a login shell have bash source | /etc/profile, .bashrc and .bash_profile. For a non-login shell have | bash source just .bashrc. In this way one can isolate things like | terminal type negotiation for login to .bash_profile and put other | things which always need to be done (like settting PATH) in .bashrc. Actually, that makes sense. Especially, since that is the way the csh does it upon login, basically. Csh sources ~/.cshrc, then ~/.login when it is a login shell. I'm curious as to why it was decided not to automatically source ~/.bashrc also upon login. Of course, you can always just put a test in your ~/.bash_profile like: if [ -f ~/.bashrc ]; then source ~/.bashrc fi | Question: | | Is there any way to tell (from inside your init file) whether or not | the shell it is running in is interactive or not? In csh, you can say | "if ($?prompt)". This is important because there are some things | (like "stty") you don't want to do if you are non-interactive (say in a | script or an rsh command) while others you always want to do. You could try something like the follow: if [ "$PS1" ]; then .. do stuff that's for interactive shell .. fi I believe that should work. | suggestion: | | It would be nice if there was a .bash_logout file. There is. ~/.bash_logout gets executed upon logout, if the shell is a login shell. | Despite these teething problems, I've been very happy with bash and | currently use it as my login shell. It's great. Good. I hope you continue to enjoy bash! Cheers... | --Jim Dempsey-- -jeff Jeff Kellem INTERNET: composer@bu-cs.bu.edu (or composer%bu-cs.bu.edu@bu-it.bu.edu) UUCP: ...!harvard!bu-cs!composer
andrewt@WATSNEW.WATERLOO.EDU (Andrew Thomas) (06/14/89)
composer@bu-cs.bu.edu writes: > | Date: Tue, 13 Jun 89 14:33:53 -0400 > | From: James J Dempsey <jjd@bbn.com> > | > | I am using Bash 0.99 under Ultrix 3.0 on a VAX 8530. > | > | ------------------------------ > | bug: > | > | There seems to be a bad interaction with the use of PROMPT_COMMAND and > | "if". Consider the following: > | > | if date > | then > | echo yes > | fi > | > | This works fine if PROMPT_COMMAND is unset, but if PROMPT_COMMAND is > | set to (say) "date", then bash core dumps after saying something like: > | "OOPS! Bad command type `313548'!" > > Well, I don't have an Ultrix system to play with right now. But, I was > unable to reproduce the above core dump on a Sun 3 running Sun UNIX 4.2 > Release 3.4 nor on an Encore Multimax running UMAX 3.3. Can anyone else > out there duplicate this problem? I am running Ultrix 2.0 on a uVaxII. I tried to reproduce this on a clean bash session, and could not do it. Andrew Thomas andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo
jjd@BBN.COM (James J Dempsey) (06/15/89)
>> Date: Wed, 14 Jun 89 12:48:10 EDT >> From: Andrew Thomas <andrewt@watsnew.waterloo.edu> >> To: bug-bash@prep.ai.mit.edu >> Subject: A set of bash bugs and suggestions (long) >> >> composer@bu-cs.bu.edu writes: >> > | Date: Tue, 13 Jun 89 14:33:53 -0400 >> > | From: James J Dempsey <jjd@bbn.com> >> > | >> > | I am using Bash 0.99 under Ultrix 3.0 on a VAX 8530. >> > | >> > | There seems to be a bad interaction with the use of PROMPT_COMMAND and >> > | "if". Consider the following: >> > | >> > | if date >> > | then >> > | echo yes >> > | fi >> > | >> > | This works fine if PROMPT_COMMAND is unset, but if PROMPT_COMMAND is >> > | set to (say) "date", then bash core dumps after saying something like: >> > | "OOPS! Bad command type `313548'!" >> > >> > Well, I don't have an Ultrix system to play with right now. But, I was >> > unable to reproduce the above core dump on a Sun 3 running Sun UNIX 4.2 >> > Release 3.4 nor on an Encore Multimax running UMAX 3.3. Can anyone else >> > out there duplicate this problem? >> >> I am running Ultrix 2.0 on a uVaxII. I tried to reproduce this on a >> clean bash session, and could not do it. >> >> Andrew Thomas >> andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo It seems that no one can reproduce this, although I haven't seen a message from anyone running Ultrix 3.0. Here is some more data to aid in debugging. Below is the output of a bash session where I tried to reduce my environment to the absolute minimum. Also included is the output of "set" to show the environment. It is interesting to note that it didn't say "Bad command type" this time. --Jim Dempsey-- BBN Communications jjd@bbn.com (ARPA Internet) ..!{decvax, harvard, wjh12, linus}!bbn!jjd % bash -norc bash$ set EUID=14895 UID=14895 HISTSIZE=500 HISTFILE=/u1/jjd/.bash_history BASH_VERSION=0.99 BASH=/usr/local/gnu/bin/bash SHLVL=1 PWD=/u1/jjd MAILPATH=/usr/spool/mail/jjd MAILCHECK=60 IFS= PS2=bash> PS1=bash$ TERMCAP=emacs:co#80:tc=unknown: PATH=:/u1/jjd/Bin:/usr/local/gnu/bin:/nd/bin:/usr/local/bin:/usr/local/nosupport:/usr/ucb:/usr/bin:/bin:/u1/ezf/bin:/usr/local/bin/X11:/usr/local/bin/X10.4:/usr/local/bin/uw:/u1/jjd USER=jjd TERM=emacs SHELL=/usr/local/gnu/bin/bash HOME=/u1/jjd bash$ if date bash>then bash>echo fine bash>fi Wed Jun 14 13:26:05 EDT 1989 fine bash$ PROMPT_COMMAND=date Wed Jun 14 13:26:15 EDT 1989 bash$ if date Wed Jun 14 13:26:54 EDT 1989 bash>then Wed Jun 14 13:26:55 EDT 1989 bash>echo fine Wed Jun 14 13:26:56 EDT 1989 bash>fi Illegal instruction (core dumped) %
chet@cwns5.INS.CWRU.Edu (Chet Ramey) (06/15/89)
In article <8906141744.AA00311@life.ai.mit.edu> jjd@BBN.COM (James J Dempsey) writes: [ Talks about his prompt_command problem ] >It seems that no one can reproduce this, although I haven't seen a >message from anyone running Ultrix 3.0. Here is some more data to aid >in debugging. I am running bash 0.99 on a VAXstation 2000 with Ultrix 3.0. >bash$ PROMPT_COMMAND=date >Wed Jun 14 13:26:15 EDT 1989 >bash$ if date >Wed Jun 14 13:26:54 EDT 1989 >bash>then >Wed Jun 14 13:26:55 EDT 1989 >bash>echo fine >Wed Jun 14 13:26:56 EDT 1989 >bash>fi >Illegal instruction (core dumped) Here is my output with the same input: pirate$ echo $SHLVL 3 pirate$ PROMPT_COMMAND=date Wed Jun 14 18:01:36 EDT 1989 pirate$ if date Wed Jun 14 18:01:41 EDT 1989 > then Wed Jun 14 18:01:44 EDT 1989 > echo fine Wed Jun 14 18:01:46 EDT 1989 > fi Wed Jun 14 18:01:49 EDT 1989 fine Wed Jun 14 18:01:49 EDT 1989 pirate$ Also, setting line buffering for stderr as advised by another posting makes bash dump core in xrealloc on my machine (VS2000, Ultrix). Chet Ramey Network Services Group, CWRU chet@{cwjcc,pirate}.INS.CWRU.Edu "The flagon with the dragon has the potion with the poison; the vessel with the pestle holds the brew that is true!"