off by one in wrapping long lines in bash-3.1
Configuration Information: 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 -O2 -march=k8 -pipe -D_FORTIFY_SOURCE=1 uname output: Linux vapier 2.6.14.3-grsec #4 PREEMPT Wed Dec 21 16:10:15 EST 2005 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.1 Patch Level: 5 Release Status: release Description: when you first launch bash-3.1, the long-line wrapping ability appears to be broken. very long lines at first will start to wrap one character too soon and overwrite the current line rather than start on the next line. resizing the terminal, executing a program, or similar operations appear to "fix" the issue, it's just the initial run where things are screwed up. observered on both Gentoo and Debian. bash-3.0 works correctly. 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... - hold down a letter until it gets to the edge of the terminal - observe the line wrapping properly now -mike ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional expression problem: both "-a file" and "! -a file" return true
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 1/7/2006 8:17 AM: > > Now, in this case, you have three arguments, and POSIX requires that the > binary operator "-a" have higher precedence than the "!" negation operator > on a 2-argument test. And the one-argument test of "!" and of "testFile" > both return true (since neither is the empty string), so the overall > expression returns 0. Correcting myself, POSIX does not require any precedence between the two forms (it looks like an editorial oversight from the OPERANDS section). But the RATIONALE (XCU line 35443) states that "The ! operator has higher precedence than the -a operator, and the -a operator has higher precedence than the -o operator." Therefore, when -a is defined as a unary operator, an XSI compliant test is required to return failure for "test ! -a file" if file exists. Bash got this wrong, so indeed it is a bug. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxl0S84KuGfSFAYARAj6WAJ44nX0B2O5D+LvuiT3NNJ+c3GljugCdGOA5 UCxNICnejGO98ZJFlKDjZqo= =FNG7 -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Background processes receive SIGINT even though they shouldn't
Ingemar Nilsson wrote: > Machine Type: i386-redhat-linux-gnu > > Bash Version: 3.0 > Patch Level: 16 > Release Status: release > > Description: > In some cases, background processes receive SIGINT from the > terminal where it was started even though the manual states > that such processes are immune to keyboard-generated signals. > This is best explained by trying out the example below. > > There is a reason for the seemingly complex sleep arrangement > in test2. This is really a condensed version of a much larger > script, but it still demonstrates the problem well. I think you're slightly misunderstanding how job control and process groups interact. When you run test1 from an interactive shell with job control enabled, it is placed into a separate process group. The terminal's foreground process group is set to test1's process group, which means that group receives keyboard-generated signals like SIGINT. The shell started to run test1 is not interactive, so job control is disabled. This means that all processes started by test1 and its descendants are placed into the same process group. Since this is the terminal's foreground process group, these processes receive the SIGINT. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional expression problem: both "-a file" and "! -a file" return true
Eric Blake <[EMAIL PROTECTED]> wrote: > But the RATIONALE (XCU line 35443) states that "The ! operator has higher > precedence than the -a operator, and the -a operator has higher precedence > than the -o operator." Therefore, when -a is defined as a unary operator, > an XSI compliant test is required to return failure for "test ! -a file" > if file exists. Bash got this wrong, so indeed it is a bug. No, I think that quote only says that this: ! 1 -a 2 is the same as this: ( ! 1 ) -a 2 and not this: ! ( 1 -a 2 ) It doesn't give us any guidance for deciding whether ! is an operator or operand in any particular case. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: off by one in wrapping long lines in bash-3.1
Mike Frysinger wrote: > Configuration Information: > 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 -O2 -march=k8 -pipe > -D_FORTIFY_SOURCE=1 > uname output: Linux vapier 2.6.14.3-grsec #4 PREEMPT Wed Dec 21 16:10:15 EST > 2005 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 3.1 > Patch Level: 5 > Release Status: release > > Description: > when you first launch bash-3.1, the long-line wrapping ability appears to be > broken. very long lines at first will start to wrap one character too soon > and overwrite the current line rather than start on the next line. resizing > the terminal, executing a program, or similar operations appear to "fix" the > issue, it's just the initial run where things are screwed up. observered on > both Gentoo and Debian. bash-3.0 works correctly. > > 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... > - hold down a letter until it gets to the edge of the terminal > - observe the line wrapping properly now I can't reproduce it on MacOS X or Linux, using Terminal, xterm, or aterm. It sounds like readline is getting an incorrect value for the terminal autowrap capability. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: off by one in wrapping long lines in bash-3.1
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... > > - hold down a letter until it gets to the edge of the terminal > > - observe the line wrapping properly now > > I can't reproduce it on MacOS X or Linux, using Terminal, xterm, or > aterm. It sounds like readline is getting an incorrect value for > the terminal autowrap capability. so there's no confusion, here's a screen shot of Eterm: http://dev.gentoo.org/~vapier/bash-no-wrap.png i have ncurses-5.5 / readline-5.1 installed on both my Gentoo/Debian machines ... i normally use Eterm, but i tried xterm, gnome-terminal, aterm, rxvt, screen, and the linux console and got the same incorrect results ... fired up OS X (10.3.9) with Terminal and when i ssh into either my Gentoo or Debian box it fails to wrap properly ... i talked to a friend who uses Fedora Rawhide and has bash-3.1(patch5), readline-5.5-10, and ncurses-5.0-3.1 and he was able to reproduce the bad behavior (he uses gnome-terminal) ... not quite sure where to take this next as ive never poked around readline or bash before and terminals scare me :) -mike ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
