bash prompt misbehaving - correction.
Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. The main difference between debian etch and debian lenny in this respect appears to be that the default locale is now unicode (en_US.UTF-8). I remember seeing other posts relative to this type of problem, possibly on this list, but searching online, I could not find anything that explained what is happening or provided a workaround/resolution. Debian lenny has the following installed: $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. My guess is that the non-printable characters in my bash prompt that switch colors interfere with bash's notion of the prompt's length? root's bash prompt is defined like so: PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] I removed the color escape sequences from my user's bash prompt via a: $ PS1=[\$(date +%T)]...@\h:\w]\\$ .. and now everything is back to normal. Seems to confirm my above speculations. In any case it's just a minor annoyance that I can live with for now, but all the same, I would be grateful if anyone could provide some useful pointers to documentation or bug reports that would help understand what is happening, and possibly a workaround. If this is really a bug in the version of bash that I am running, I will eventually upgrade to a version of bash where the issue is fixed, so please let me know if this an option. Thanks, CJ
Re: bash prompt misbehaving - correction.
Chris Jones schrieb: ... After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. ... PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] This works correctly with bash 4.0.24. Regards, Bernd -- Bernd Eggink http://sudrala.de
Re: bash 4.x filters out environmental variables containing a dot in the name
2009-06-29, 10:03(-04), Chet Ramey:
and it's a bug that bash-4 is filtering them.
Maybe, maybe not. That's open to interpretation. Here's how I see it.
not allowing them to be used in
the shell is fine (echo ${vmlinux.lds}), but removing them from the
environment and thus not allowing other applications to leverage them is not.
The shell is not like other applications that simply pass the environment
through as uninterpreted strings. It applies semantic interpretation to
the environment variables it inherits.
Many tools that use the environment apply semantic
interpretation to the environment variables they inherit, and
what variable is supported by a shell is shell dependant.
Shells scan the initial environment exactly once: at startup, when creating
variables. The environment passed to child processes is created from the
set of exported shell variables. This implies to me that the environment
passed to child processes consists only of valid shell variables.
For the rc or es shell, anything is valid except the empty string.
Certainly conforming applications should not create environment variables
with invalid names.
What about non-conforming applications? I agree that if they
should to use the shell API, they should conform to it, but
here, we're in case not covered by the API. That application
should be able to expect its environment to be transfered as is
through a shell to another non-conforming application.
POSIX explicitly states that applications shall tolerate the presence of
these
environment variables, and while that is open for interpretation (i.e.
you've
interpreted this to mean automatic removal), i dont see any reason for bash
to
be culling these.
Posix also says that variables are inherited from the environment. That
word has a very specific meaning, as was reiterated during the $@ and set -u
discussion. The same variables language is used when Posix talks about
creating the environment for shell execution environments.
Yes, but that's shell variables, it's not talking about the rest
of the environment.
The question is whether tolerant just means that the shell doesn't display
a warning message about the assignment, as it does when you use an invalid
variable name in an assignment statement, or exit with a variable assignment
error, or dump core with a seg fault, as in many historical versions of sh.
It may or may not also mean that the shell passes inherited invalid variable
names to child processes.
Historical versions of sh and ksh behave like bash-4.0.
ksh93 doesn't but pdksh/mksh still does.
It seems, though, that there might be enough use for me to try and make it
work. While I'm not wild about creating yet another class of variable,
there might be a way to do it simply.
I suppose the most obvious way would be to store away those
environment strings that bash doesn't know how to handle and
append it to each execve.
Now other points to consider could be what to do in cases like:
- there is both a=1 and a=2 in the environment passed to the
shell.
- there is both a=1 and a in the environment passed to the
shell. (and maybe also and =x).
I think it's probably worth asking the Austin group about it.
--
Stéphane
Re: bash prompt misbehaving - correction.
On Tue, Jun 30, 2009 at 05:23:27AM EDT, Bernd Eggink wrote: Chris Jones schrieb: ... After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. ... PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] This works correctly with bash 4.0.24. I guess I need to check the NEWS file of this version to see if there are any fixes that might have addressed this issue since 3.2.29. CJ
Re: bash prompt misbehaving - correction.
Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. The main difference between debian etch and debian lenny in this respect appears to be that the default locale is now unicode (en_US.UTF-8). I remember seeing other posts relative to this type of problem, possibly on this list, but searching online, I could not find anything that explained what is happening or provided a workaround/resolution. Debian lenny has the following installed: $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: $@ vs. nounset
Yang Zhang wrote: (IIRC, in bash, variables set to empty arrays and unset variables are the same). In the shell, a variable is not set until it has been assigned a value. An array variable is not set unless one of its indices has been assigned a value. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash prompt misbehaving - correction.
On Tue, Jun 30, 2009 at 08:30:35AM EDT, Chet Ramey wrote: Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. [..] $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. Is there anything that happened between 3.2.39 3.2.49 that might account for this, or would you suspect a problem with my setup? I just ran the same test again on a plain xterm with TERM=xterm and no additional layers such as gnu/screen and I'm still getting the same result. If this is of interest, what kind of information about my context should I provide. Or should I run a test with a more current version of bash and if I can't recreate, forget about it? Thanks, CJ
Re: bash prompt misbehaving - correction.
Chris Jones wrote: On Tue, Jun 30, 2009 at 08:30:35AM EDT, Chet Ramey wrote: Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. [..] $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. Is there anything that happened between 3.2.39 3.2.49 that might account for this, or would you suspect a problem with my setup? I would assume that one of the patches addresses this problem. Or should I run a test with a more current version of bash and if I can't recreate, forget about it? You should always test against the most current version. In your case, you can test against more recent versions of bash-3.2 or bash-4.0. If the work to fix the problem has already been done and released, why not take advantage of it? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: feature request: more complete set -e
Greg Wooledge:
If you simply handle errors yourself by checking the return
code from commands that actually matter, you won't have to worry about
all these nasty little surprises.
How is this done?
CHK0=test $? == 0
my_important_task; $CHK0 || exit 1
Chet:
To do otherwise would have made expr much less useful. Idioms such as
var=10
while var=`expr $var - 1`
do
echo $var
done
Mmh I'd use the C like for loop for this which is supported by bash as well.
Bob Proulx:
Also I must mention grep too. The exit status of grep isn't just
whether it exits without an error but instead returns an indication of
whether the pattern matched or not. This makes idioms such as this
possible:
if grep -q PATTERN FILE; then
... do something ...
fi
to sum up / clarify:
Touching while and if doesn't make sense. Because the exit status is used to
control the program flow. There is no easy way to catch segmentation faults or
such.
Can you come up with a useful use case where you want to ignore the result in
for i in ?
Sure.
for i in $(grep ...); do .. done
So mmh. I should stop using bash because bash can't destinguish a failure from
a return value.
It can. But you have to remember details all the time.
So the problem here is that grep is an external tool.
In other languages you can do
my_lines = file('foo').read.lines.filter( l : matches l 'some regex')
and you'll get an exception if the file isn't found.
So I have to learn those details or use another language.
Thank you for taking the time discussing this topic here. I learned a
lot.
Marc Weber
Re: feature request: more complete set -e
On Tue, Jun 30, 2009 at 09:58:45PM +0200, Marc Weber wrote:
How is this done?
CHK0=test $? == 0
my_important_task; $CHK0 || exit 1
You'd need single quotes instead of double there. (And == is illegal in
Bourne/POSIX shell test commands; only bash tolerates it.) You could
also use a function instead:
check() { test $? = 0; }
my_task; check || exit 1
Or, you could avoid the extra definition and simply check directly:
my_task || exit 1
my_task || { echo error occurred 12; exit 1; }
Re: feature request: more complete set -e
Marc Weber wrote: Chet: To do otherwise would have made expr much less useful. Idioms such as var=10 while var=`expr $var - 1` do echo $var done Mmh I'd use the C like for loop for this which is supported by bash as well. A relatively recent addition to the language. The while loop idiom has been around since the original Bourne shell. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4.x filters out environmental variables containing a dot in the name
Stephane CHAZELAS wrote: Posix also says that variables are inherited from the environment. That word has a very specific meaning, as was reiterated during the $@ and set -u discussion. The same variables language is used when Posix talks about creating the environment for shell execution environments. Yes, but that's shell variables, it's not talking about the rest of the environment. Yes, well, that's the question, isn't it? Whether there is any rest of the environment. Is the environment passed to subshells made up of only shell variables with the export attribute? Since we agree that invalid shell assignments in the environment don't cause shell variables to be created, they must belong to some special class that is outside the rest of the shell to get them passed to subshells. Historical versions of sh and ksh behave like bash-4.0. ksh93 doesn't but pdksh/mksh still does. This behavior changed in ksh93s. I think it's probably worth asking the Austin group about it. Probably. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash prompt issue - lenny - UTF-8.
On Tue, Jun 30, 2009 at 01:34:21PM EDT, Chet Ramey wrote: Chris Jones wrote: [..] Is there anything that happened between 3.2.39 3.2.49 that might account for this, or would you suspect a problem with my setup? I would assume that one of the patches addresses this problem. It's either my setup that's causing this or the fix came into existence between 3.2.48 and 3.2.49: I have tested on the current up-to-date ubuntu system that runs the former and I recreated the problem. Back with 3.2.39 on the lenny sustem, I ran the same test in the linux console and witnessed the same behavior as in xterm. I proceeded to switch my default locale to en_US.iso88591 and this fixed the problem both on the linux console and xterm. I switched back to en_US.utf8 and was able to recreate the problem. Or should I run a test with a more current version of bash and if I can't recreate, forget about it? You should always test against the most current version. In your case, you can test against more recent versions of bash-3.2 or bash-4.0. If the work to fix the problem has already been done and released, why not take advantage of it? I'll run a test with 3.2.49 just in case, if time allows. Thanks, CJ
Please add these dynamic-complete-history / menu-complete bindings to bash/readline
Hi, Bash ships with lots of useful completion functions, but if you don't bind them to keys, then less people will use them. - In bash's emacs keymap, please bind dynamic-complete-history to M-/, since it's sort of like Emacs's dabbrev-expand -- it looks through the entire buffer (well, actually, the entire history) to complete a word. - In bash's vi insert keymap, please bind dynamic-complete-history to \C-x\C-i -- this would give Bash a C-x C-i keystroke that works sort of like Vim. It's not a perfect match with what Vim does, but it's the best available. - In bash/readline's vi insert keymap, please bind menu-complete to \C-n. This is like Vim's binding. bind -m vi-insert '\C-n: menu-complete' ; - Bash/readline has no menu-complete-backward or menu-complete-reverse function which could go on vi insert C-p like in Vim. The best Neil Moore neil at s-z.org could come up with is: bind -m vi-insert '\C-n: menu-complete' ; bind -m vi-insert '\C-b: universal-argument' ; bind -m vi-insert '\C-p: \C-b-1\C-n' The problem is that, no matter whether you use Bash 3 or Bash 4, C-p only works once. If you press C-p twice, or C-p C-n, it thinks you want to complete the next word. This seems to be because universal-argument exits the menu-complete in a way that digit-argument does not. P.S. Neil, thank you -- most of the above is made up of some of your thoughts, your text, and of your code that you told to me. Only the idea to ship them as bindings with Bash is mine. -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com
