Re: Bash readline remap ESC insert/command mode key
On Mon, Jan 23, 2012 at 07:38:52PM EST, Chet Ramey wrote: > On 1/23/12 8:52 AM, Roger wrote: > > > A little more indepth examination, and I can see VIM's wait is > > approximately double of what the readline patch's wait time is. > > However, I think the shorter wait time is more functional as when > > typing a double char, it in no way takes as long as VIM's wait time > > unless you type the same char with your finger and then use a toe to > > type the second char. > > > > Matter of fact, I'm starting to find VIM's long wait time length > > a little annoying. ;-) > > > > Great job at guessing the wait time! > > Thanks. Half a second seemed right. In Vim, I have set the timeout to 200 milliseconds rather than the default 1000 (one whole second). This amounts to a typing speed of c. 5 characters per second or 60 wpm, a reasonable goal for the average typist. CJ
Re: Bash readline remap ESC insert/command mode key
On Mon, Jan 23, 2012 at 08:52:17AM EST, Roger wrote: [..] > Matter of fact, I'm starting to find VIM's long wait time length > a little annoying. ;-) :h tm :h ttm CJ
Re: '>;' redirection operator
On Sat, Dec 24, 2011 at 10:08:31AM EST, Bill Gradwohl wrote: [..] > The man page is written the way Robbie the Robot used to speak in the old > black and white TV days¹. Short, cryptic and in many cases unintelligible IN > THE DETAILS. Alternatively, one might snicker that some lawyer wrote it to > purposely make it difficult to understand. As with most of the > documentation I've seen in the Linux community, it's awful. [..] I find it rather ironical that your rant should amount to a clumsy rewording of section 6.1, GNU Manuals, from the GNU Coding Standards: http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals In particular: ‘Don’t use Unix man pages as a model for how to write GNU documentation; most of them are terse, badly structured, and give inadequate explanation of the underlying concepts.’ CJ ¹ Actually, regarding form rather than content, man pages go back considerably farther than Robbie the Robot and black and white TV... some 2,000 years or so... See wiki articles, re: ‘scrolls’ and ‘codex’ for the details.
Re: Is the description of set -- missing in man bash or at least difficult to find?
On Thu, Dec 22, 2011 at 01:09:38PM EST, Peng Yu wrote: > Hi, > As I mentioned previously, there are shortcomings in man bash. Here, > I just point another example. And I hope my suggestion will be > addressed. [..] Here's my suggestion, and nothing needs to be ‘addressed’. There are shortcomings in _the man documentation format_ and one of them is that it doesn't work (at least for me...) when the documentation is longer than one screen or thereabouts. I've pretty much come to the conclusion that any man page that is over a couple of hundred lines is a waste of my time and should probably not even exist in the first place. What I did: $ info bash Then I selected the last entry: ‘Indexes’, then the ‘Variable Index’ and then... I searched for ‘@’... and found exactly what I was looking for! Took about three seconds! In order to find more about ‘set’, I did the same, choosing the ‘Builtin index’ instead of the ‘Variable Index’... and found everything I'll ever need to know about ‘set’ before anyone has time to say Bob's your uncle. Not to mention that I didn't waste anyone's time and bandwidth opening a ‘bug report’... :-) Be aware that in the event info's rather peculiar user interface is too much of a hassle, you may find that the ‘pinfo’ derivative might better suit your needs. CJ
Re: Strange bug in arithmetic function
On Mon, Feb 21, 2011 at 04:13:54AM EST, Marcel de Reuver wrote: > In a bash script I use: $[`date --date='this week' +'%V'`%2] to see if > the week number is even. > Only in week 08 the error is: bash: 08: value too great for base > (error token is "08") the same in week 09, all others are ok... Due to the prepended zero, bash thinks you are using octal (base 8) numbers. Compare: $ a=$((7+8)) $ echo $a 15 $ a=$((7+08)) $ bash: 08: value too great for base (error token is "08") cj
Re: cd with multiple arguments?
On Fri, Dec 10, 2010 at 05:24:34AM EST, Marc Herbert wrote: > > It's trivial to write a shell function to do that, and many other > > things. > > Things like "good default settings" and "batteries included" Not sure the reference to python (?) is relevant here, since the language by itself does not do much and the included ‘batteries’ are almost entirely provided via modules, all in all an approch not very different from Chet's suggesting writing a function. True, bash does not come with a vast library of ready-to-use functions. > ... typically make users switch from one tool to another. And what some see as features, others call.. bloat. Personally, what made me abandon bash early on and switch to python for most of my scripting needs was that by the time I reached the end of the manual, I had already forgotten the beginning. :-) cj
Re: Any guide about writing my own bash built-in commands?
On Thu, Jan 28, 2010 at 08:42:25PM EST, Clark J. Wang wrote: > Hi all, > I want to write my own built-in bash commands but I cannot find any > info about that in bash manual. Anyone has any idea? Never done that myself but I found this excellent introductory article: http://cfajohnson.com/shell/articles/dynamically-loadable/ Should provide an entry-point for further research. CJ
[OT] regarding 'time' builtin
On Fri, Jul 17, 2009 at 04:54:51PM EDT, Dave B wrote: > On Friday 17 July 2009, Linda Walsh wrote: > > > where does the output from the 'time' command "go" > > > > I.e. if I wanted to pipe the output to a prog or file, how would I > > go about doing it? > > Please see > > http://mywiki.wooledge.org/BashFAQ/032 Sometimes I wonder if Greg is a "real" person.. not a smart program that can generate the correct answers to all the questions you had about bash utilization - and may have been too shy to ask. :-) CJ
Re: Colored prompt length is not correctly computed - UTF-8
On Sat, Jul 04, 2009 at 11:20:56PM EDT, Bob Proulx wrote: > Chris Jones wrote: > > Is there a 4.0 .deb available..? > A bash 4.0 .deb is available in Debian's experimental distribution. I > don't know if the dependencies it was compiled with are available in > Lenny or Squeeze or not as it would have matched Unstable at one time > and so you would need to check. Even if it isn't available (yet) due > to the dependencies you could use it as the basis of a backport to > Lenny. Thanks. But I feel that bash is too central a piece of the system for s/o like me to experiment with, so I'll live with it for now. A minor change in my habits appears to provide a workaround: hitting CTRL+L prior to hitting CTRL+A/E. CJ
Re: Colored prompt length is not correctly computed - UTF-8
On Sat, Jul 04, 2009 at 02:56:20PM EDT, Chet Ramey wrote: [..] > Thanks for the report. I can reproduce this on bash-3.2.49, and it's > fixed in bash-4.0. Thanks for confirming I was not hearing voices or something :-) Is there a 4.0 .deb available..? I just compiled: http://ftp.gnu.org/gnu/bash/bash-4.0.tar.gz This let me verify that the problem is indeed fixed in 4.0 but I'd rather not go the way my of my debian "etch" system, where just about every app I used on a regular basis was from the tarball version. Also, out of curiosity, do you maintain a bug tracking system that can be accessed by the general population? Thanks, CJ
Colored prompt length is not correctly computed - Correction.
On Sat, Jul 04, 2009 at 12:18:51PM EDT, Chris Jones wrote: > 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 turki 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 > i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release > > Description: > > When retrieving a command from bash's history, emacs keybindings CTRL-E & > CTRL-A > do not move the cursor to the end and beginning of the retrieved command. > > CTRL+E moves the cursor to a point that is short of the end of command > CTRL+A moves the cursor to a point that is within the bash prompt > > When the cursor is moved to a location within the prompt, an ensuing CTL+K > erases not only the retrieved command, but also the part of the prompt that is > to the right of the cursor. > > This was first noticed on a debian "lenny" system running the default 3.2.39 > version of bash running in a color xterm, but was later reproduced on ubuntu > 9.04 with bash 3.2.48 in gnome terminal. > > This was also verified to happen on the linux console - kernel 2.6.26. > > Repeat-By: > > $ export PS1="\[\033[0;41m\][$(date +%T)]...@\h:\w]\$\[\033[0m\] " > > [11:47:48][c...@turki:~]$ echo try as you may > > CTRL+R > may > (reverse-i-search)`may': echo try as you may > ^ (cursor position) > CTRL+E > [11:47:48][c...@turki:~]$ echo try as you may > ^ (new cursor position) > CTRL+A > [11:47:48][c...@turki:~]$ echo try as you may >^(cursor now in prompt) > CTRL+K > [11:47:48][cjns > (erases part of prompt) > > Note, that this does not occur when doing the (reverse-i-search) on "echo", > "try", or "as" - it only occurs when searching for "you" or "may". > > Fix: > > Not fixes, but either of the following corrects the problem: > > 1. Removing the escape sequence¹ from the prompt. > > 2. Switching the locale from UTF-8 (en_US.UTF-8) to ISO-8859-1 > (en_US.iso88591). ¹ To be exact: "removing the color-related escape sequences from the prompt.
Colored prompt length is not correctly computed - UTF-8
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 turki 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: When retrieving a command from bash's history, emacs keybindings CTRL-E & CTRL-A do not move the cursor to the end and beginning of the retrieved command. CTRL+E moves the cursor to a point that is short of the end of command CTRL+A moves the cursor to a point that is within the bash prompt When the cursor is moved to a location within the prompt, an ensuing CTL+K erases not only the retrieved command, but also the part of the prompt that is to the right of the cursor. This was first noticed on a debian "lenny" system running the default 3.2.39 version of bash running in a color xterm, but was later reproduced on ubuntu 9.04 with bash 3.2.48 in gnome terminal. This was also verified to happen on the linux console - kernel 2.6.26. Repeat-By: $ export PS1="\[\033[0;41m\][$(date +%T)]...@\h:\w]\$\[\033[0m\] " [11:47:48][c...@turki:~]$ echo try as you may CTRL+R may (reverse-i-search)`may': echo try as you may ^ (cursor position) CTRL+E [11:47:48][c...@turki:~]$ echo try as you may ^ (new cursor position) CTRL+A [11:47:48][c...@turki:~]$ echo try as you may ^(cursor now in prompt) CTRL+K [11:47:48][cjns (erases part of prompt) Note, that this does not occur when doing the (reverse-i-search) on "echo", "try", or "as" - it only occurs when searching for "you" or "may". Fix: Not fixes, but either of the following corrects the problem: 1. Removing the escape sequences from the prompt. 2. Switching the locale from UTF-8 (en_US.UTF-8) to ISO-8859-1 (en_US.iso88591).
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 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.
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
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
Color prompt issues - debian lenny - UTF-8
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? I removed the color escape sequences from my user's bash prompt via a: $ PS1="[\$(date +%T)]...@\h:\w]\\$ " .. and everything was 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 of fixed, so please let me know if this an option. Thanks, CJ
Re: Feature Idea: Enhanced Tab Completion
On Sat, Mar 21, 2009 at 04:59:36PM EDT, Bob Proulx wrote: > Chris Jones wrote: > > I had posted the following obfuscated explanation a couple of hours > > ago but since I was subscribed under a different address, it never > > made it to the list. > > > > :-( > > Actually it seems to have made it to the okay. No need for an unhappy > face. You do not need to be subscribed to post to a bug reporting > mailing list. But addresses that are not subscribed are held for > human review before approval. If it is an address that posts multiple > times then we usually add it to the list just like subscribed > addresses so there won't be a delay subsequently. Thanks for filling me in.. Wasn't aware of this. I used the gnu lists' "change address" option in the meantime but I was not expecting to see my earlier post "converted" and eventually show up.. ever. > Looking at the timestamps it appears you posted the message at > 14:08:08 -0400 on your machine and it was received by monty-python 39 > seconds before that at 21 Mar 2009 14:07:29 -0400. You might want to > adjust your clock. :-) [17:45:09][r...@turki:~]# date; ntpdate-debian Sat Mar 21 17:45:23 EDT 2009 21 Mar 17:45:31 ntpdate[32504]: step time server 128.10.19.24 offset -42.229268 sec Seems to have only been off by 8 seconds? > Then because the address was unknown it sat waiting for a human > moderator to approve the message for 1h15m20s when it was approved at > 21 Mar 2009 15:22:49 -0400 and sent through to the mailing list. I > personally think that is a pretty good turnaround time for an unknown > address to get through the anti-spam human moderation process > considering the total volume of mail going through lists.gnu.org but > since I am one of the mailing list moderators I am biased. :-) I think 1 hour+ is simply amazing. Don't you people have .. er, like weekends and stuff..?? :-) > This beat out this next posting 15m19s later which went through > without delay at 21 Mar 2009 13:38:08 -0600 because it was a known > address. Yes .. I screwed up.. yet again.. My original post was pretty lame .. seeing it twice is an embarrassment especially on a decent list such as this one. :-\ CJ
Re: Feature Idea: Enhanced Tab Completion
On Sat, Mar 21, 2009 at 01:16:12PM EDT, Ken Irving wrote: > This sounds a lot like what you get with the reverse-search-history > command, bound to control-r (C-r), a great feature indeed. Priceless. I had posted the following obfuscated explanation a couple of hours ago but since I was subscribed under a different address, it never made it to the list. :-( Maybe it's because I'm used to it.. but seems to do pretty much what you're after and with less effort: Say, you ran the following command: $ xset dpms force suspend To retrieve this command later in the day: + "sus" # or other such as "ce s" etc. Displays: (reverse-i-search)`sus': xset dpms force suspend # or etc. $ xset dpms force suspend Naturally, if typing "sus" (or other) retrieves a different command, you would have to either type an extra character such as "p" (the search back in the history is incremental) or issue a second but with a bit of practice, you pretty soon get used to finding short strings that will hit on the exact command that you are looking for. Where it works "better" for me than what you suggest is that you don't have to visually scan an excerpt of the history to locate the command that you were looking for: either you find what you're looking for the first time around or successive actions bring back successive hits one at a time, which I personally think is more efficient. Another useful aspect of "reverse-search-history" is that you are not limited to searching on the command name, which makes it easier for me at least to select a search argument that will bring back the precise entry that I am looking for especially for commands that I typically issue dozens of times in any bash session. i.e. it's probably more effective to look for, say "less /var/log/messages" via a " sag" or " less". Sorry for the lenghty explanation, stuff like that can be demo'ed in a couple of keystrokes but takes forever to describe in plain English. CJ
Re: Feature Idea: Enhanced Tab Completion
On Sat, Mar 21, 2009 at 01:01:51PM EDT, Cam Cope wrote: > I'm sorry if the feature has already been implemented, I haven't heard > of any way to implement it. This is what I was thinking of: Right now, > if you run history, it will list out all the recently used commands, > and then you could run !360 to run that history result. Often I'm > looking for a specific command that I don't want to retype the options > for. Instead of having to do history | grep commandname and then > !###, just start typing !commandname and hit tab to see history > entries that start with it. Maybe it's because I'm used to it.. but seems to do pretty much what you're after and with less effort: Say, you ran the following command: $ xset dpms force suspend To retrieve this command later in the day: + "sus" # or other such as "ce s" etc. Displays: (reverse-i-search)`sus': xset dpms force suspend # or etc. $ xset dpms force suspend Naturally, if typing "sus" or other retrieves a different command, you would have to either type an extra character such as "p" (the search back in the history is incremental) or issue a second but with a bit of practice, you pretty soon get used to finding short strings that will hit on the exact command that you are looking for. Where it works "better" for me than what you suggest is that you don't have to visually scan an excerpt of the history to locate the command that you were looking for: Either you find what you're looking for the first time around or successive actions bring back successive hits one at a time, which I personally think is more efficient. Sorry for the lenghty explanation, stuff like that can be demo'ed in a couple of keystrokes but takes for ever to describe in plain English. CJ
