Re: Infinite loop in globbing
On 03/14/2011 07:36 PM, Chet Ramey wrote: Here's a minimal patch. Chet Thanks. It is working. I mean no infinite loop. RR
Re: vzctl enter hangs
On 8 mar, 22:36, Chet Ramey wrote: > On 3/8/11 10:04 AM, gnu.bash.bug wrote: > > > Running "strace -fvzctlenter 152 " shows: > > Sovzctlis running bash in a pty and talking to it that way? > > I'd be interested in seeing what interrupted the select/read/write/ > sigprocmask system calls in both processes. > > 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/ I just filed a bug report form for vzctl You can follow it here: http://bugzilla.openvz.org/show_bug.cgi?id=1812 //Michael
Bash-4.2 Official Patch 8
BASH PATCH REPORT = Bash-Release: 4.2 Patch-ID: bash42-008 Bug-Reported-by:Doug McMahon Bug-Reference-ID: <1299441211.2535.11.camel@doug-XPS-M1330> Bug-Reference-URL: http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00050.html Bug-Description: Bash-4.2 does not attempt to save the shell history on receipt of a terminating signal that is handled synchronously. Unfortunately, the `close' button on most X11 terminal emulators sends SIGHUP, which kills the shell. This is a very small patch to save the history in the case that an interactive shell receives a SIGHUP or SIGTERM while in readline and reading a command. The next version of bash will do this differently. Patch (apply with `patch -p0'): *** ../bash-4.2-patched/sig.c Tue Nov 23 08:21:22 2010 --- sig.c Tue Mar 8 21:28:32 2011 *** *** 47,50 --- 47,51 #if defined (READLINE) # include "bashline.h" + # include #endif *** *** 63,66 --- 64,68 extern int history_lines_this_session; #endif + extern int no_line_editing; extern void initialize_siglist (); *** *** 506,510 #if defined (HISTORY) /* XXX - will inhibit history file being written */ ! history_lines_this_session = 0; #endif terminate_immediately = 0; --- 508,515 #if defined (HISTORY) /* XXX - will inhibit history file being written */ ! # if defined (READLINE) ! if (interactive_shell == 0 || interactive == 0 || (sig != SIGHUP && sig != SIGTERM) || no_line_editing || (RL_ISSTATE (RL_STATE_READCMD) == 0)) ! # endif ! history_lines_this_session = 0; #endif terminate_immediately = 0; *** ../bash-4.2-patched/patchlevel.hSat Jun 12 20:14:48 2010 --- patchlevel.hThu Feb 24 21:41:34 2011 *** *** 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 7 #endif /* _PATCHLEVEL_H_ */ --- 26,30 looks for to find the patch level (for the sccs version string). */ ! #define PATCHLEVEL 8 #endif /* _PATCHLEVEL_H_ */ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Completion of ENV variables seems to be broken - leading slash (or even more) is added
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-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. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc'
-DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=core2 -O2
-pipe
uname output: Linux dlnbp019 2.6.37-gentoo-r2 #1 SMP PREEMPT Sat Mar
12 08:59:11 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 7
Release Status: release
Description:
When enter in console "ls $HOME/" and press TAB for
completion, then bash add slash for special characters like $ { }
When I back to wersion 4.1_p10 then problem is gone. Problem
also exists with 4.2_p6 and 4.2_p1 (these veriosn I have checked).
Repeat-By:
1/ type: ls $HOME
2/ press TAB
3/ Should get: ls \$HOME
4/ Try the same with ${HOME}
5/ Should get \$\{HOME\}
old-menu-complete behavior in bash v4 / readline v6
Hi,
I prefer the pre-readline-6.0 version of menu completion, so I tried
using the "old-menu-complete" option in bash v4 / readline v6.
However, "old-menu-complete" doesn't behave exactly like
"menu-complete" did in bash v3 / readline v5.
For example, in bash v3:
$ mkdir directory
$ touch directory/{a,b,c,d,e}
$ less directory/[invoke "menu-complete" command]
$ less directory/a [invoke "menu-complete" command]
$ less directory/b
In bash v4, using "old-menu-complete":
$ mkdir directory
$ touch directory/{a,b,c,d,e}
$ less directory/[invoke "old-menu-complete" command]
a b c d e
$ less directory/a
In other words, in bash v3, "menu-complete" basically just cycles
through the possible matches, WITHOUT displaying all the possible
matches before the first cycle. However, in bash v4,
"old-menu-complete" displays ALL possible matches before cycling
through the matches on the command line.
Is there a way I can get "old-menu-complete" in bash v4 to match the
behavior of "menu-complete" in bash v3 exactly in this regard?
Thanks for your help,
Alan
Re: vzctl enter hangs
> So vzctl is running bash in a pty and talking to it that way? For the exact details I'll point to the OpenVZ guys :-). It is an OS virtualization patch for the kernel. With it you can run virtual servers which are isolated from each other. The vzctl enter number is used on the physical server to enter one of the running virtual servers. From taht point you ar captured within this virtual server. How it is eactly done, see above :-). Unitil Bash 4.1.9 it just worked. From Bash 4.2.0 and onwards it is broken. Could be a bug in Bash, could be a bug in the OpenVZ. Because we found it after upgrading Bash it seems logical to start the investigation here. I've asked in teh OpenVZ forums if someone has an solution and if needed I wil open a bug report there... > I'd be interested in seeing what interrupted the select/read/write/ > sigprocmask system calls in both processes. What exactly do you want. A full strace report? I'm trying to find the difference between 4.1.9 and 4.2.0 which causes this behavior, but that is not simple because I don't know the order and which differences I must combine. So this process will take a while... -- Henk van de Kamer http://www.vandekamer.com/ P.S. Al mijn e-mail is digitaal ondertekend om mij zo te beschermen tegen identiteitsdiefstal. Mocht uw mailprogramma hier niet goed mee overweg kunnen, lees dan mijn uitleg [1]. Sorry voor de overlast, maar in de toekomst zal u waarschijnlijk ook uw e-mail willen beschermen... [1] http://www.hetlab.tk/artikelen/digitale-handtekening smime.p7s Description: S/MIME Cryptographic Signature
ReadLines and Substraction
Hello Everyone, I have an issue regarding the bash. I have 2 different files and each of them involves some float point numbers for each lines. I want to subtract each line then put all the results into a file. The first line float number will be subtract with the first line of other file and the second with the other second... and etc... When I read both files with: cat ./Temp1.log | while read line; do cat ./Temp2.log | while read line; do #It reads the first line of temp1, I also need to read the first line of temp2. However, Temp2 will be read until the end of file so that I cannot read one by one for each lines of different files. done done If you can help me with this, will be very happy for that. Thanks in advance. Best.
Re: old-menu-complete behavior in bash v4 / readline v6
On 3/14/11 3:20 PM, Alan wrote:
> Hi,
>
> I prefer the pre-readline-6.0 version of menu completion, so I tried
> using the "old-menu-complete" option in bash v4 / readline v6.
>
> However, "old-menu-complete" doesn't behave exactly like
> "menu-complete" did in bash v3 / readline v5.
>
> For example, in bash v3:
>
> $ mkdir directory
> $ touch directory/{a,b,c,d,e}
> $ less directory/[invoke "menu-complete" command]
> $ less directory/a [invoke "menu-complete" command]
> $ less directory/b
>
> In bash v4, using "old-menu-complete":
>
> $ mkdir directory
> $ touch directory/{a,b,c,d,e}
> $ less directory/[invoke "old-menu-complete" command]
> a b c d e
> $ less directory/a
>
> In other words, in bash v3, "menu-complete" basically just cycles
> through the possible matches, WITHOUT displaying all the possible
> matches before the first cycle. However, in bash v4,
> "old-menu-complete" displays ALL possible matches before cycling
> through the matches on the command line.
>
> Is there a way I can get "old-menu-complete" in bash v4 to match the
> behavior of "menu-complete" in bash v3 exactly in this regard?
Turn off `show-all-if-ambiguous'. It was a bug in pre-readline6
versions that menu completion did not honor the setting of that
variable.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Completion of ENV variables seems to be broken - leading slash (or even more) is added
On 3/14/11 7:08 PM, Rafał Lalik wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-pc-linux-gnu-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. -I./include -I./lib
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
> -DSYS_BASHRC='/etc/bash/bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
> -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=core2 -O2
> -pipe
> uname output: Linux dlnbp019 2.6.37-gentoo-r2 #1 SMP PREEMPT Sat Mar
> 12 08:59:11 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
> GenuineIntel GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 7
> Release Status: release
>
> Description:
> When enter in console "ls $HOME/" and press TAB for
> completion, then bash add slash for special characters like $ { }
> When I back to wersion 4.1_p10 then problem is gone. Problem
> also exists with 4.2_p6 and 4.2_p1 (these veriosn I have checked).
Please read the previous discussion of this issue, starting with
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: old-menu-complete behavior in bash v4 / readline v6
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...
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?
Thanks so much for your help,
Alan
On Tue, Mar 15, 2011 at 9:32 AM, Chet Ramey wrote:
> On 3/14/11 3:20 PM, Alan wrote:
>> Hi,
>>
>> I prefer the pre-readline-6.0 version of menu completion, so I tried
>> using the "old-menu-complete" option in bash v4 / readline v6.
>>
>> However, "old-menu-complete" doesn't behave exactly like
>> "menu-complete" did in bash v3 / readline v5.
>>
>> For example, in bash v3:
>>
>> $ mkdir directory
>> $ touch directory/{a,b,c,d,e}
>> $ less directory/ [invoke "menu-complete" command]
>> $ less directory/a [invoke "menu-complete" command]
>> $ less directory/b
>>
>> In bash v4, using "old-menu-complete":
>>
>> $ mkdir directory
>> $ touch directory/{a,b,c,d,e}
>> $ less directory/ [invoke "old-menu-complete" command]
>> a b c d e
>> $ less directory/a
>>
>> In other words, in bash v3, "menu-complete" basically just cycles
>> through the possible matches, WITHOUT displaying all the possible
>> matches before the first cycle. However, in bash v4,
>> "old-menu-complete" displays ALL possible matches before cycling
>> through the matches on the command line.
>>
>> Is there a way I can get "old-menu-complete" in bash v4 to match the
>> behavior of "menu-complete" in bash v3 exactly in this regard?
>
> Turn off `show-all-if-ambiguous'. It was a bug in pre-readline6
> versions that menu completion did not honor the setting of that
> variable.
>
> 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/
>
Re: old-menu-complete behavior in bash v4 / readline v6
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: vzctl enter hangs
> > So vzctl is running bash in a pty and talking to it that way? > > For the exact details I'll point to the OpenVZ guys :-). It is an OS > virtualization patch for the kernel. With it you can run virtual servers > which are isolated from each other. The answer to my question was "yes." > What exactly do you want. A full strace report? That's what I got, and the strace points the finger at vzctl. It looks like a bug in vzctl that was masked by bash-4.1 and previous versions. > I'm trying to find the difference between 4.1.9 and 4.2.0 which causes > this behavior, but that is not simple because I don't know the order and > which differences I must combine. So this process will take a while... The difference looks to be that bash-4.1 closed fds 3-20 at startup, and bash-4.2 sets open fds in that range to close-on-exec. vzctl is careless with its file descriptors, and bash not closing them results in its controlling terminal getting messed up. Michael Kalisz opened a bug report with the openvz group. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Completion of ENV variables seems to be broken - leading slash (or even more) is added
> Bash Version: 4.2
> Patch Level: 7
> Release Status: release
>
> Description:
> When enter in console "ls $HOME/" and press TAB for
> completion, then bash add slash for special characters like $ { }
> When I back to wersion 4.1_p10 then problem is gone. Problem
> also exists with 4.2_p6 and 4.2_p1 (these veriosn I have checked).
The difference is that bash-4.1 expanded $HOME and left the expansion
as part of the replacement text. Bash-4.2 tries to leave what the
user typed alone, but that leads to an inherently ambiguous situation:
when do you quote the `$' in a filename (or, in this case, a directory
name)? It could be a shell variable, and it could be a character in
the filename.
The bash-4.1 solution, though it modified what the user typed, did not
result in any ambiguity. A filename was a filename, and if it contained
characters that needed to be quoted, readline did so.
I might be able to finesse this issue and retain the bash-4.2 behavior
by changing state when rewriting the directory name for opendir(2), but
I have to think about it some more.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
