Re: incorrect handling of invisible characters in prompt string

[Mike Frysinger]

to dig up this thread yet again :)
http://lists.gnu.org/archive/html/bug-bash/2006-03/msg6.html

a user reported this with bash-3.0.17 with a good test case:
http://bugs.gentoo.org/130955

and i'm able to reproduce this here by setting my PS1:
PS1='$(echo "Strange \[\e[0;32m\]Prompt\[\e[0m\] ")'
then holding down say 'f' until my cmdline wraps around, then holding 
backspace to delete the letters until it wraps back up to one line and 
triggers a garbaled prompt:
;32mPrompt f

the proposed hack:
http://lists.gnu.org/archive/html/bug-bash/2006-03/msg5.html

seems to work for this test case ...
-mike


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Fwd: Re: Bash-3.1.17 gets lost looking for end of string in certain contexts

[Richard]

Have just read the archives... ;) Forwarding to the list accordingly!

--  Forwarded Message  --

Subject: Re: Bash-3.1.17 gets lost looking for end of string in certain 
contexts
Date: Wednesday 03 May 2006 22:36
From: Richard <[EMAIL PROTECTED]>
To: Eric Blake <[EMAIL PROTECTED]>

As promised, further to my previous message, hereinafter more data on 
the
subject.

(beware of line wrapping at 72 chars)



[EMAIL PROTECTED] rag]$ ldd '/mnt/STG1/bin/bash'
libdl.so.2 => /mnt/STG1/lib/libdl.so.2 (0x4001a000)
libc.so.6 => /mnt/STG1/lib/libc.so.6 (0x4001e000)
/mnt/STG1/lib/ld-linux.so.2 (0x4000)
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash' --version
GNU bash, version 3.1.17(2)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED] rag]$ strings -a '/mnt/STG1/bin/bash' | grep GCC | head -n 1
GCC: (GNU) 3.4.6
[EMAIL PROTECTED] rag]$ '/mnt/STG1/lib/libc-2.3.6.so'
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6.
Compiled on a Linux 2.6.12 system on 2006-05-01.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
.
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash'
[EMAIL PROTECTED] ~]$ echo $BASH_VERSION
3.1.17(2)-release
[EMAIL PROTECTED] ~]$ status=`echo 'beriberi'| { grep -E -e '().*\1' 
>/dev/null
2>&1 ; echo $?; }` || echo OOPS
[EMAIL PROTECTED] ~]$ echo $status
0
[EMAIL PROTECTED] ~]$ cd /mnt/STG1/opt/sources/grep-2.5.1a/tests
[EMAIL PROTECTED] tests]$ GREP=grep /mnt/STG1/bin/bash spencer1.script
spencer1.script: line 602: unexpected EOF while looking for matching `''
spencer1.script: line 608: syntax error: unexpected end of file
[EMAIL PROTECTED] tests]$



As you can see the bare command does not trigger the error; however the
script for some contextual reason does trigger it.

Just curious: why is it that your version displays 6 within parenthesis,
whereas mine displays 2?

At your disposal for any addtional info you may require.

Richard

---


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

unwanted expansion of variable with nested strings

[Mike Frysinger]

ignoring the fact that i can pass in variables to gawk using the '-v' option, 
i'm wondering if this is a bug in how bash expands variables to pass to 
programs ... i couldnt pick out anything under EXPANSION, but that's probably 
just because i missed it ;)

take for example:
$ foo="a b c"
$ gawk 'BEGIN {foo="'${foo}'"}'
gawk: BEGIN {foo="a
gawk:^ unterminated string

this being because bash executed:
argv[0] = gawk
argv[1] = BEGIN {foo="a
argv[2] = b
argv[3] = c"}

when really i wanted:
argv[0] = gawk
argv[1] = BEGIN {foo="a b c"}

so if i quote ${foo} like so:
$ gawk 'BEGIN {foo="'"${foo}"'"}'
it'll work in this case, but then fail if foo contains newlines:
foo="a
b
c"
-mike


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: incorrect handling of invisible characters in prompt string

[Mike Frysinger]

On Wednesday 03 May 2006 21:42, Mike Frysinger wrote:
> the proposed hack:
> http://lists.gnu.org/archive/html/bug-bash/2006-03/msg5.html
>
> seems to work for this test case ...

but then seems to break another one:
export LC_ALL=C
PS1='\[\e[0;33m\]\u\[\e[0m\] '
printf a > foo.txt
cat foo.txt

then again, this test is broken atm with a unicode locale:
PS1='\[\e[0;33m\]\u\[\e[0m\] '
printf a > foo.txt
export LC_ALL=en_US
cat foo.txt <- works
export LC_ALL=en_US.UTF8
cat foo.txt <- fails
-mike


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: unwanted expansion of variable with nested strings

[Paul Jarc]

Mike Frysinger <[EMAIL PROTECTED]> wrote:
> $ foo="a b c"
> $ gawk 'BEGIN {foo="'${foo}'"}'
> gawk: BEGIN {foo="a
> gawk:^ unterminated string

This is normal.  man bash:

#   Word Splitting
#   The  shell  scans the results of parameter expansion, command substitu-
#   tion, and arithmetic expansion that did not occur within double  quotes
#   for word splitting.

> so if i quote ${foo} like so:
> $ gawk 'BEGIN {foo="'"${foo}"'"}'
> it'll work in this case, but then fail if foo contains newlines:
> foo="a
> b
> c"

What do you mean by "fail"?  What do you want to happen in this case?


paul


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash