🚀 go-pugleaf

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!jjd