Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!BU-CS.BU.EDU!composer
From: composer@BU-CS.BU.EDU
Newsgroups: gnu.bash.bug
Subject: A set of bash bugs and suggestions (long)
Message-ID: <8906132121.AA04301@bucse.bu.edu>
Date: 13 Jun 89 21:21:44 GMT
References: <8906131834.AA00966@wheaties.ai.mit.edu>
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 144

|   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