Space or multiple spaces before command causes it to not get logged
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall uname output: Linux gouch.ihate.ms 3.2.0-24-virtual #38-Ubuntu SMP Tue May 1 16:38:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 24 Release Status: release Description: Putting a space or multiple spaces before a command and executing it causes the command to not get logged to bash history file. Repeat-By: user@server:~$ pwd /root user@server:~$ history 1 pwd 2 history user@server:~$ ls -- Note the space before the command user@server:~$ date Fri May 25 02:59:43 UTC 2012 user@server:~$ history 1 pwd 2 history 3 date 4 history
Re: Space or multiple spaces before command causes it to not get logged
On Fri, May 25, 2012 at 6:05 AM, r...@gouch.ihate.ms wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall uname output: Linux gouch.ihate.ms 3.2.0-24-virtual #38-Ubuntu SMP Tue May 1 16:38:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 24 Release Status: release Description: Putting a space or multiple spaces before a command and executing it causes the command to not get logged to bash history file. Repeat-By: user@server:~$ pwd /root user@server:~$ history 1 pwd 2 history user@server:~$ ls -- Note the space before the command user@server:~$ date Fri May 25 02:59:43 UTC 2012 user@server:~$ history 1 pwd 2 history 3 date 4 history Probably a feature, check if the variable HISTCONTROL contains ignorespace and the value of HISTIGNORE (printf %q\\n $HISTIGNORE)
Apply for a Job
Apply for a Job Apply for a Job? Three Steps to apply for a Job: 1. A Resume 2. Cover letter 3. Company research http://www.ways2work.in/apply-for-a-job/
Re: in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches
On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote: It seems that $COMP_WORDBREAKS annoys users when filenames contain one of its characters: [...] Unsetting $COMP_WORDBREAKS is not a solution, as completion would no longer work in contexts where such characters are word separators. indeed, it's not On Thu, May 24, 2012 at 03:16:40PM -0400, Chet Ramey wrote: The whole raison d'etre for having it in the first place is to allow the user to specify these things. It's easy enough to have COMP_WORDBREAKS only contain whitespace and shell metacharacters. of course but COMP_WORDBREAKS is used in the context of different completion which are kind enough to not alter main user environment. That's why COMP_WORDBREAKS would need to apply in a given context ( like the scope of a function being used as a completion :) ) On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote: How about the following behavior when the user types [TAB]? 1. Try to complete the whole word, ignoring $COMP_WORDBREAKS. 2. If there are no matches, take $COMP_WORDBREAKS into account like now. See: https://lists.gnu.org/archive/html/bug-bash/2011-05/msg00148.html [thread follow-up]: https://lists.gnu.org/archive/html/bug-bash/2011-06/msg00032.html The patch in the above thread allowed COMP_WORDBREAKS to be set on a completion basis using a newly created `complete` -B switch. It uses the proper hook for this task but as been considered (probably rightfully) heavyweight. It would needs a strong knowledge of the codebase (and hook definition) in order to add such a feature in an elegant manner. regards
Re: locale specific ordering in EN_US -- why is aAbByYzZ?
On Mon, May 21, 2012 at 12:19:26PM -0700, Linda Walsh wrote: So which is correct? Anyone wanting to reference an upper or lower case range [a-z] or [A-Z], is gonna hurt from this. My OS uses en_US.UTF-8. I don't remember this bug having been cited here: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/120687 About $ export LC_COLLATE=C /etc/skel/.bashrc co
Re: old-menu-complete behavior in bash v4 / readline v6
By the way, if anyone wants a fix for this bug, here it is:
In lib/readline/funmap.c, around line 107, make menu-complete map to
rl_old_menu_complete:
{ menu-complete, rl_old_menu_complete },
In lib/readline/complete.c, around line 2443, comment out the if-loop:
/*if (match_list_size 1 _rl_complete_show_all)
display_matches (matches);*/
Then compile and install. Works great now.
On Tue, Mar 15, 2011 at 11:24 AM, Chet Ramey chet.ra...@case.edu wrote:
On 3/15/11 11:13 AM, Alan wrote:
Thanks for the response!
The problem is, if I turn off 'show-all-if-ambiguous', hitting tab
won't display all the possible completions. I like the old behavior of
'menu-complete' because if I wanted to display the completions, I
could always hit tab before purely cycling through the choices with
'menu-complete.' So it gives more flexibility in my opinion.
Plus, I expected something with the name, 'old-menu-complete,' to
behave like the old 'menu-complete' did, but I digress...
Sure, modulo any bug fixes. It was, as I said, a bug that the menu
completion function didn't behave like other completion functions and
honor the setting of show-all-if-ambiguous. That was changed in the
readline-6.2 development cycle before I changed the behavior more
radically and split the old from the new.
What would be the best way for me to make old-menu-complete behave
like menu-complete did pre-readline-6.0? (In other words, behave like
'show-all-if-ambiguous' is off, while it is really on for other stuff
like tab.) Would it be best to write some sort of bash function? Or
would it be better to just modify the source code?
You'll have to modify the source code.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
