Re: help on bash-3.2
bastl73 wrote: > Is it possible that this error relays to bash-3.2.0 ? > > If I configure kdebase-3.5.6, I get this error: Does the error persist after applying the released patches for bash-3.2? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.2 breaks mc (echo -e '\137')
[EMAIL PROTECTED] wrote: > Configuration Information [Automatically generated, do not change]: > Machine: amd64-linux > OS: suse90 > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='amd64-linux' > -DCONF_OSTYPE='suse90' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' > -DCONF_VENDOR='unknown' > -DLOCALEDIR='/scr/os2-suse90/koenig/bash-3.2.1-1/PREINSTALL//usr/local//share/locale' > -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib > -O2 -D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > uname output: Linux atuin 2.6.16.21-0.25-smp #1 SMP Tue Sep 19 07:26:15 UTC > 2006 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 3.2 > Patch Level: 1 > Release Status: release > > Description: > > bash versions before 3.2 all allowed > > echo -e '\137' > > to display an underscore, but now in 3.2 _only_ > > echo -e '\0137' > > seems to be valid. this breaks apps and scripts which (still) > use the old (non-posix) always-three-digit-oactal-number scheme. Here is what I wrote when this issue first came up last October: It's intentional. The xpg_echo and `echo -e' code should be identical, and the xpg_echo code is required by POSIX/XSI to interpret octal constants only with the leading `0'. There are lots of ways to indicate that backslash escapes should be interpreted -- maybe too many -- but when they are, they should behave consistently. echo is crazy enough without more differing interpretations of backslash escapes. Any application wanting to use a standard utility for output should use printf. It was not in my summary of changes between 3.1 and 3.2 (an oversight), but it certainly appears in the changelog (CWRU/changelog): lib/sh/strtrans.c - add code to echo -e and echo with xpg_echo enabled to require a leading 0 to specify octal constants Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: help on bash-3.2
bastl73 wrote: > When I downloaded bash I haven't seen a patch to this version, so I did now > installed GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu). Now all > works fine. The patches are available at: ftp://ftp.cwru.edu/pub/bash/bash-3.2-patches/ ftp://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/ Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: readline: edit (mode:vi) means eol unreachable
Hugh Sasse wrote: >> I'm not sure I understand the question. If the termcap/terminfo entries > > The question is about the vi edit mode for a correctly configured > terminal, with no personalization. Should the cursor keys take me > out of insert mode, or leave me in insert mode (like vim), and > should I be able to move to beyond the last character (after having > moved left) so that I can append more text? It depends on whether or not the termcap/terminfo capabilities are specified. Readline binds some common arrow key sequences by default (xterm and vt100), but if your arrow keys output something else, either they need to be in termcap/terminfo or you need to bind them yourself in .inputrc. If the key sequence isn't bound, it will be treated as a series of keys probably beginning with ESC, which: > All this could be complicated by the cursor keys emitting Escape, > which could interact horribly with vi mode! Readline can work around this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.2, escape sequences
Hi Chet, hi bug-bash readers, I'm not quite getting the changes in bash's handling of escape sequences. [EMAIL PROTECTED](~)> echo '\a' '\a Ouch? This is not related to escape sequence handling: [EMAIL PROTECTED](~)> echo -E '\a' '\a [EMAIL PROTECTED](~)> echo -e '\a' ' And yet, it is: [EMAIL PROTECTED](~)> echo '\\ \ \ \ ' \\ \ \ \ [EMAIL PROTECTED](~)> echo '\\ \a \ \ ' \ \ '\\ \a \ \ [EMAIL PROTECTED](~)> echo 'wow\awow' wow'wow\awow [EMAIL PROTECTED](~)> echo $'\a' ' [EMAIL PROTECTED](~)> echo \\a \a Finally! [EMAIL PROTECTED](~)> echo $BASH_VERSION 3.2.5(1)-release [EMAIL PROTECTED](~)> gcc --version gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Sorry if I'm being terribly ignorant here, but I don't get it. On a related note, the documented escape sequences handled by "echo" differ between help echo and man echo (-e vs. -E). -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash 3.2, escape sequences
Sebastian Kapfer wrote: > I'm not quite getting the changes in bash's handling of escape > sequences. I can't reproduce your results: z4.local(1)$ ./bash --version GNU bash, version 3.2.9(5)-release (i386-apple-darwin8.8.1) Copyright (C) 2005 Free Software Foundation, Inc. z4.local(1)$ ./bash z4.local(2)$ echo '\a' \a z4.local(2)$ echo -E '\a' \a z4.local(2)$ echo -e '\a'| cat -v ^G z4.local(2)$ echo '\\ \ \ \ ' \\ \ \ \ z4.local(2)$ echo '\\ \a \ \ ' \\ \a \ \ z4.local(2)$ echo 'wow\awow' wow\awow z4.local(2)$ echo $'\a' | cat -v ^G z4.local(2)$ echo \\a \a I suspect that you have echo defined as a function or alias, or something in $PROMPT_COMMAND or $PS1 is obscuring the output. > On a related note, the documented escape sequences handled by "echo" > differ between help echo and man echo (-e vs. -E). Well, they document different programs. `help echo' describes the bash builtin, and `man echo' describes /bin/echo. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
