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 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
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
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: 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: 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" 1>&2; exit 1; }
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: 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: 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: "$@" 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.
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: 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 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.
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
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