On Fri, Aug 04, 2000 at 11:31:13AM -0400, Subba Rao wrote:
> In this case, when my command fails the BASH variable $? value is displayed
> in my prompt. What is happening is that a command return value stays there
> until an new command is issued. A newline for the shell will still return the
> previous $? value. $? value is never reset until a new command is issued.
Well, that's just the way shells work. When you write a shell
script, you never care whether you put a few blank lines between
the command that you're testing.
Now, as you've found, you can override that behaviour by
executing a command that returns true (0) _after_ the $? value
has been displayed, but before the next command is accepted.
You chose whois, but that's a real executable, so you have to
fork an extra time for each prompt. If you use a shell builtin
like $(exit 0), to reset the result value, and keep using \u for
your user name, then (a) your shell might run a bit more
quickly, but (b) you can't actually use $? yourself, on the
command line. Well you can in multi-statement lines, I guess.
Aesthetics aside, better to have learned this lesson, leave the
prompt as you originally had it (not resetting the result), and
reset it manually if you feel strongly about it.
It actually sounds like a bloody good idea. Think I'll try it
myself for a while.
Thanks,
--
Andrew
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
