Screen Corruption when browsing Command History with Custom Prompt
From: root To: bug-bash@gnu.org,[EMAIL PROTECTED] Subject: Screen Corruption when browsing Command History with Custom Prompt Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux Ashley-Ubuntu 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: I'm using a custom prompt using ~/.bashrc, given below: PS1="\n\e[0;31m\u: \w\n# \e[m" When I browse the command history using the up/down arrow buttons, some of the first few characters get stuck to the prompt. However, if I move the cursor until it reaches the position just after these characters, I can type-in the command I want and it works - even though someone who sees the screen later will wonder how it did work. For example, this is how my bash screen looks after I've run the ls command: root: /home/ash # gedls Desktop Documents Examples Music My Games Pictures Public Templates Videos root: /home/ash # It looks as if I've run a command 'gedls', whereas the first three characters are left-overs from the 'gedit' command I ran just before it. The output is exactly what I expect, but I can't seem to delete the 'ged' from the prompt. Repeat-By: Set a custom prompt using the PS1 variable as follows: PS1="\n\e[0;31m\u: \w\n# \e[m" Then, browse command history using up/down keys. The issue appears when the newline (\n) characters and the coloring sequences (\e[0;31m, \e[m) are used together in the prompt.
Re: Screen Corruption when browsing Command History with Custom Prompt
Ashley Wilson wrote: Repeat-By: Set a custom prompt using the PS1 variable as follows: PS1="\n\e[0;31m\u: \w\n# \e[m" Then, browse command history using up/down keys. As the documentation states, you need to bracket sequences of non-printing characters in prompt strings with the \[ and \] escape sequences. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Screen Corruption when browsing Command History with Custom Prompt
The escape sequence for adding colors are an exception - If you add backslashes to those brackets, it won't (and doesn't) work as expected. I tried what you said : Set PS1 = "\n\e\[0;31m\u: \w\n# \e\[m" The resulting prompt did, still, exhibit the corruption explained in my bug report, and the prompt appeared as follows: 0;31mroot: /home/ash # * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * It seems I shouldn't have used the \e character.. The default Ubuntu .bashrc has another way of doing it, which I tried to learn from. And it seems it works! Here is my working sequence (and no screen corruption!) PS1="\n\[\033[0;31m\]\u: \w\n# \[\033[00m\]" Note that not all square brackets are preceded with backslashes! Thanks for replying anyway. I was only trying to copy-paste from the web, but overlooked the example that was already in the default .bashrc !! Sorry for the trouble.. -- Regards, Ashley. On Tue, Sep 9, 2008 at 11:49 PM, Chet Ramey <[EMAIL PROTECTED]> wrote: > Ashley Wilson wrote: > >> Repeat-By: >> >>Set a custom prompt using the PS1 variable as follows: >> >>PS1="\n\e[0;31m\u: \w\n# \e[m" >> >>Then, browse command history using up/down keys. > > As the documentation states, you need to bracket sequences of non-printing > characters in prompt strings with the \[ and \] escape sequences. > > Chet > >
Re: Screen Corruption when browsing Command History with Custom Prompt
No, Wait! That's not the issue!! This works just fine: PS1="\n\[\e[0;32m\]\u: \w\n# \[\e[m\]" So, all I had to do was to add '\[' before and '\]' after the coloring sequence to fix everything! -- Regards, Ashley. On Wed, Sep 10, 2008 at 12:51 AM, Ashley Wilson <[EMAIL PROTECTED]> wrote: > The escape sequence for adding colors are an exception - If you add > backslashes to those brackets, it won't (and doesn't) work as > expected. > > I tried what you said : Set > > PS1 = "\n\e\[0;31m\u: \w\n# \e\[m" > > The resulting prompt did, still, exhibit the corruption explained in > my bug report, and the prompt appeared as follows: > >0;31mroot: /home/ash > # > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * * * * * > > It seems I shouldn't have used the \e character.. The default Ubuntu > .bashrc has another way of doing it, which I tried to learn from. And > it seems it works! Here is my working sequence (and no screen > corruption!) > > PS1="\n\[\033[0;31m\]\u: \w\n# \[\033[00m\]" > > Note that not all square brackets are preceded with backslashes! > > Thanks for replying anyway. I was only trying to copy-paste from the > web, but overlooked the example that was already in the default > .bashrc !! > > Sorry for the trouble.. > > -- > Regards, > Ashley. > > > On Tue, Sep 9, 2008 at 11:49 PM, Chet Ramey <[EMAIL PROTECTED]> wrote: >> Ashley Wilson wrote: >> >>> Repeat-By: >>> >>>Set a custom prompt using the PS1 variable as follows: >>> >>>PS1="\n\e[0;31m\u: \w\n# \e[m" >>> >>>Then, browse command history using up/down keys. >> >> As the documentation states, you need to bracket sequences of non-printing >> characters in prompt strings with the \[ and \] escape sequences. >> >> Chet >> >> >
Re: Screen Corruption when browsing Command History with Custom Prompt
Ashley Wilson wrote: No, Wait! That's not the issue!! This works just fine: PS1="\n\[\e[0;32m\]\u: \w\n# \[\e[m\]" So, all I had to do was to add '\[' before and '\]' after the coloring sequence to fix everything! Of course it works; this is exactly what Chet was trying to tell you. -- Matthew ENOCOFFEE: operator suffering from lack of sleep and/or early-morning-itis
Re: Screen Corruption when browsing Command History with Custom Prompt
On Wed, Sep 10, 2008 at 3:02 AM, Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Ashley Wilson wrote: >> >> No, Wait! That's not the issue!! This works just fine: >> >> PS1="\n\[\e[0;32m\]\u: \w\n# \[\e[m\]" >> >> So, all I had to do was to add '\[' before and '\]' after the coloring >> sequence to fix everything! > > Of course it works; this is exactly what Chet was trying to tell you. > > -- > Matthew > ENOCOFFEE: operator suffering from lack of sleep and/or early-morning-itis > Yes, I realize that now. Thanks Mathew, Chet. -- Regards, Ashley.
Differentiating false from fatal
Say you have a shell script, and you need it to be bulletproof.
As you write it, you throw in error checking all over the place.
But say you have a function that needs to return a boolean result in some
way - call the function "bool_foo" for the sake of discussion. Further
assume that bool_foo will sometimes fail to return a result, and it's
defined with:
function bool_foo
(
xyz
)
...and not function bool_foo
{
xyz
}
...so that bool_foo's variables don't mess with those of other functions,
but also making it so it cannot just exit 1 to terminate the program
directly.
How would you go about making bool_foo return a boolean result -and- be
able to return a fatal?
Do you make bool_foo echo "True" or "False" and use the exit status to
reflect success/failure?
Or do you make 0 mean True, 1 mean False, and anything else mean fatal in
$?? And if so, how do you go about differentiating these three things -
do you use nested if's or a case? And what if you have set -e in effect?
I'm sure I can come up with A way of handling this, but what have you
found works well in practice?
I suspect I'm going to end up rewriting my bool_foo functions to echo
True or False, and then use their exit status to indicated success or
failure. So instead of:
if bool_foo
then
: true
else
: false
fi
...it seems I'll end up with this mess scattered all over (with set -eu
in effect, among other things) :
case "$(shell_init; bool_foo)" in
True)
: true
;;
False)
: true
;;
*)
echo "$0: Unrecognized output from bool_foo" 1>&2
exit 1
;;
esac
I guess what I'm saying is "I miss having an exception mechanism" :)
Followups directed to comp.unix.shell.
script vs. terminal vs. same line vs. ^C
Here we see with the same $-, if you put it on the same line, you'll run it despite ^C... $ cat file echo $-; sleep 7; echo BOOM $ bash -i file bhimBC ^C $ echo $-; sleep 7; echo BOOM bhimBC ^C BOOM OK, same $-, and same test -t , so what does one have to do to make bash think it is a script and not go BOOM, unset PS1 or something?
Re: Differentiating false from fatal
On Wed, Sep 10, 2008 at 9:32 AM, Dan Stromberg <[EMAIL PROTECTED]>wrote:
>
> Say you have a shell script, and you need it to be bulletproof.
>
> As you write it, you throw in error checking all over the place.
>
> But say you have a function that needs to return a boolean result in some
> way - call the function "bool_foo" for the sake of discussion. Further
> assume that bool_foo will sometimes fail to return a result, and it's
> defined with:
>
> function bool_foo
> (
> xyz
> )
>
> ...and not function bool_foo
> {
> xyz
> }
>
> ...so that bool_foo's variables don't mess with those of other functions,
> but also making it so it cannot just exit 1 to terminate the program
> directly.
It seems to me that the mechanism already exists - use the curly brace form
of the function definition and a make a habit of using local variable
definitions within the implementation of your bool_foo's. That way bool_foo
can exit if it needs to and return a boolean otherwise.
If bool_foo delegates to other functions whose use of global variables is
unspecified and potentially undesirable, then guard the call to the those
functions with enclosing subshells as required - that's a choice you make in
bool_foo.
I agree a formal exception mechanism would be nice, but I have found that
use of exit and the subshell feature does allow most exception handling
patterns to be emulated reasonably well.
jon seymour.
