Re: off by one in wrapping long lines in bash-3.1

2006-01-13 Thread Mike Frysinger
On Friday 13 January 2006 22:02, Mike Frysinger wrote: > On Friday 13 January 2006 21:16, Chet Ramey wrote: > > Someone who can reproduce this is going to have to gdb bash, attach to > > the shell producing the bad behavior, and find out what _rl_screenwidth > > and _rl_term_autowrap are set to. >

Re: off by one in wrapping long lines in bash-3.1

2006-01-13 Thread Mike Frysinger
On Friday 13 January 2006 21:16, Chet Ramey wrote: > Someone who can reproduce this is going to have to gdb bash, attach to > the shell producing the bad behavior, and find out what _rl_screenwidth > and _rl_term_autowrap are set to. [EMAIL PROTECTED] 0 ~ $ gdb bash (no debugging symbols found) Us

Re: off by one in wrapping long lines in bash-3.1

2006-01-13 Thread Chet Ramey
Mike Frysinger wrote: > On Thursday 12 January 2006 14:21, Chet Ramey wrote: >>> Repeat-By: >>> - run 'bash' >>> - hold down a letter until it gets to the edge of the terminal >>> - observe the line wrapping too soon and overwriting current line >>> - hit enter/resize terminal/etc... >>> - hol

Re: yank-last-arg after a #

2006-01-13 Thread Dan Jacobson
>> $ xx yy zz # qq >> ESC. still gets the qq. C> I get `zz'. Oops, me too. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

expansion fails upon pipes in big5 chars

2006-01-13 Thread Dan Jacobson
$ echo 05017法規修訂座* 05017法規修訂座談會-1.pdf 05017法規修訂座談會.pdf hitting tab gets caught in the hidden "|" in the last byte: $ echo 05017法規修訂座談愧| Display all 3261 possibilities? (y or n) Therefore bash filename expansion fails upon pipes in big5 chars $ echo 會|qp-encode =B7| It knows it is one char though:

say how to remove functions too

2006-01-13 Thread Dan Jacobson
The FUNCTIONS part of the man page should mention that functions can be destroyed with unset, even if it is mentioned elsewhere. E.g., unalias is mentioned right away in the ALIAS section. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/

Re: Background processes receive SIGINT even though they shouldn't

2006-01-13 Thread Chet Ramey
Chet Ramey wrote: > Ingemar Nilsson wrote: > >> I see, thanks. Then I have another question: Why does test2 below fail >> to trap SIGINT when started by test1? It works when I run test2 directly. > > POSIX says: > > When a command is in an asynchronous list, the shell shall prevent > SIGQUIT and

[patch] fix 'exec -l /bin/bash'

2006-01-13 Thread Tim Waugh
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/s

Re: Background processes receive SIGINT even though they shouldn't

2006-01-13 Thread Chet Ramey
Ingemar Nilsson wrote: > I see, thanks. Then I have another question: Why does test2 below fail > to trap SIGINT when started by test1? It works when I run test2 directly. POSIX says: When a command is in an asynchronous list, the shell shall prevent SIGQUIT and SIGINT signals from the keyboard

Re: Bash Bugs

2006-01-13 Thread Chet Ramey
n3d gonzales wrote: > Hello, > > I used my old script to my new machine and their's a bug on it. I have > attached the very simplified script. It will determine whether the file > has space or not. The result is different. I'm not really sure what the aim of your script is given its logic, but t

Re: Background processes receive SIGINT even though they shouldn't

2006-01-13 Thread Ingemar Nilsson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chet Ramey wrote: > I think you're slightly misunderstanding how job control and process > groups interact. Okay. > When you run test1 from an interactive shell with job control enabled, > it is placed into a separate process group. The terminal's