Re: Broken parse on `'${'`
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Chet Ramey on 7/9/2005 12:29 PM:
>
>>Repeat-By:
>>zsh$ echo `echo '${'`
>>${
>>zsh$ bash
>>bash$ echo `echo '${'`
>>
>># Hmm - I was just incorrectly presented PS2, asking to try to continue
>>what bash thought was an incomplete ${ variable substitution
>>
>>Fix:
>> unknown
>
>
> Thanks for the report. This has been fixed.
Does this fix backport easily to 3.0, or will I have to wait for 3.1 to be
released? Sometimes it is rather a shame that bash provides no anonymous
read-only access to a version control system, because it means pending
fixes are only made public when you are ready to make a new release.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC0lnQ84KuGfSFAYARAjsgAJ9c2XbNF2nGLo5f82gB1ooDPUE3+ACgyRG8
Y8B8DvIiL0OFLwWYkCoVGK0=
=wRdl
-END PGP SIGNATURE-
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Broken parse on `'${'`
Eric Blake wrote:
> According to Chet Ramey on 7/9/2005 12:29 PM:
>
Repeat-By:
zsh$ echo `echo '${'`
${
zsh$ bash
bash$ echo `echo '${'`
# Hmm - I was just incorrectly presented PS2, asking to try to continue
what bash thought was an incomplete ${ variable substitution
Fix:
unknown
>>>
>>>
>>>Thanks for the report. This has been fixed.
>
>
> Does this fix backport easily to 3.0, or will I have to wait for 3.1 to be
> released? Sometimes it is rather a shame that bash provides no anonymous
> read-only access to a version control system, because it means pending
> fixes are only made public when you are ready to make a new release.
The fix will be in 3.1. I will see what I can do about sending out a
patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
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
(announce) GTK+2 + Bash
For your reading pleasure, this is a copy of what I posted to , and other mandatory cross-posting... I'm very excited to announce shell interface to GTK+2 (2.6.1) for Bash. It read XML syntax describing the widget layout, and returns user selection as shell variable or runs shell command as callback. It's designed for simple GUI dialog or layout, with the emphasis on getting the user data back into shell. For the moment, the shell variable and command are disabled. It just prints to stdout, instead. But, you can change it easily. Ref: http://freshmeat.net/projects/bashdiff/ http://home.eol.ca/~parkw/index.html#gtk Usage: gtk < file.xml gtk file.xml... For example, GTK+2 tutorial has 2 button 'helloworld2.c', http://www.gtk.org/tutorial/sec-anupgradedhelloworld.html http://www.gtk.org/tutorial/images/helloworld2.png You can now build the same thing with Or, gtk << EOF ... EOF Feedbacks are welcome. Enjoy! -- William Park <[EMAIL PROTECTED]>, Toronto, Canada ThinFlash: Linux thin-client on USB key (flash) drive http://home.eol.ca/~parkw/thinflash.html BashDiff: Super Bash shell http://freshmeat.net/projects/bashdiff/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Invisible characters in prompt with multi-byte support enabled
Short version: bash-2.05b/lib/readline/display.c:update_line:1353 calculates _rl_last_c_pos incorrectly if multibyte support is enabled and there are invisible characters in the line that include zero-width characters. Long version: I have in my .bashrc: PS1='[EMAIL PROTECTED]:\w\$\[\e[0m\] ' However, there are two spaces displayed at the end of the prompt. When I type characters and reach the end of the line, the last character that still fits on the line is not printed and does not advance the cursor, so the wrap offset is correct. When I use the history to go back to a multi-line input, the display is correct, i.e. only one space after the prompt and correct wrap-around at end of line. I have found out that, when I remove the space at the end of PS1, i.e. PS1='[EMAIL PROTECTED]:\w\$\[\e[0m\]', then the display is correct. When I put at least five spaces at the end of the prompt, i.e. PS1='[EMAIL PROTECTED]:\w\$\[\e[0m\] ', then the problem does not occur either. When there are between one and four spaces (inclusive), there is one space too many in the display and the wrap-around problem described above is present. You will notice that there are eight invisible characters in my prompt, and that, with five or more spaces at the end, the '\e' (ESC) is no longer among the last eight characters (which it is if there are less than five spaces). The problem appears always on xterm (XFree86 4.3.99.903(184)) and sometimes on wscons (NetBSD 2.0_STABLE). A workaround is to disable multi-byte support. The problem is solved when I use a debugger like gdb to increase _rl_last_c_pos manually by one after line 1353 in lib/readline/display.c, which reads: _rl_last_c_pos += _rl_col_width (nfd+lendiff, 0, temp-lendiff); Why is the width of exactly this string important? Obviously, when there are invisible, zero-width characters like '\e' in this substring, the calculation is incorrect. I would have loved to include a fix, but that part of readline's code is incomprehensible to me (for the moment, at least). Regards Alexander -- PGP key available ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
