Re: bash: S>99?4:S>9?3:S>0?2:0: syntax error in expression
Archimerged Ark Submedes wrote: Machine Type: i386-redhat-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: gcc accepts the expression S>99?4:S>9?3:S>0?2:0 bash 3.2(33) does not. I claim this is a bash bug: gcc is perfectly happy with S>99?4:S>9?3:S>0?2:0, but GNU bash, version 3.2.33(1)-release (i386-redhat-linux-gnu) chokes on W=$((S>99?4:S>9?3:S>0?2:0)). The bash man page promises that "The operators and their precedence, associativity, and values are the same as in the C language." Thanks for the report; it was an operator precedence problem. It's fixed for the next version. 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/
Re: Cannot bind ctrl-u to a readline function in bash.
Woody Thrower wrote: It appears that bash cannot bind ctrl-u either by using the "bind" command, or by reading .inputrc at startup. By default, readline binds the tty editing characters (erase, kill, literal-next, word-erase) to their readline equivalents when it's called, if they're bound to readline functions. If they're bound to macros, readline won't overwrite the bindings. It doesn't do anything with the `reprint' character (default ^R); there's never been demand for it. Use the `bind-tty-special-characters' variable to enable or disable this behavior. 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/
Re: Cannot bind ctrl-u to a readline function in bash.
Chet Ramey wrote: > Woody Thrower wrote: > >It appears that bash cannot bind ctrl-u either by using the "bind" command, > >or by reading .inputrc at startup. > > By default, readline binds the tty editing characters (erase, kill, > literal-next, word-erase) to their readline equivalents when it's called, > if they're bound to readline functions. If they're bound to macros, > readline won't overwrite the bindings. It doesn't do anything with the > `reprint' character (default ^R); there's never been demand for it. > > Use the `bind-tty-special-characters' variable to enable or disable this > behavior. As a clarification I wanted to say something a little bit more here. If I am wrong please correct me. I think what you just said was that if the character is already bound to an tty function, such as by system default or by stty setting, then they override bash's readline values because readline reads the tty values and reloads them with every input line. This enables any user changes made with stty to have effect. But this prevents the readline values from persisting because they are overridden by the tty values. The 'set bind-tty-special-chars off' variable controls this behavior in which case the readline values will be used instead of the tty driver values. But then subsequent changes with stty won't have effect. This means that an alternative way to make bash's readline values persistent (having them override the tty driver value) is to unset them in the tty driver first. If they are not set in the tty driver then they won't override readline ~/.inputrc values. It will just be a normal character in that case. stty -a Normally control-u is bound to tty driver kill. Because of there is a tty driver value for ^U that value always overrides any readline binding. But if ^U is remove from the tty driver setting then it won't. There isn't a portable way to unset these values in the tty driver but with GNU stty setting a value to "undef" will undefine it. stty kill undef Having done this configuration to free up C-u it can then be bound normally to whatever function is desired. Here it is bound to the emacs behavior. bind '"\C-u": universal-argument' Bob
Re: Cannot bind ctrl-u to a readline function in bash.
Bob Proulx wrote: Normally control-u is bound to tty driver kill. Because of there is a tty driver value for ^U that value always overrides any readline binding. But if ^U is remove from the tty driver setting then it won't. There isn't a portable way to unset these values in the tty driver but with GNU stty setting a value to "undef" will undefine it. stty kill undef Having done this configuration to free up C-u it can then be bound normally to whatever function is desired. Note that undefining a tty editing character with stty makes it unavailable to all programs you run. Programs that don't use readline to read input will not be able to perform the function the tty editing key is intended to provide. 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/
Re: Cannot bind ctrl-u to a readline function in bash.
Chet Ramey wrote: > Bob Proulx wrote: > >Normally control-u is bound to tty driver kill. Because of there is a > >tty driver value for ^U that value always overrides any readline > >binding. But if ^U is remove from the tty driver setting then it > >won't. > > Note that undefining a tty editing character with stty makes it unavailable > to all programs you run. Programs that don't use readline to read input > will not be able to perform the function the tty editing key is intended > to provide. True. For "werase"/word-erase that probably won't matter very much. But for any of the others and especially for some such as "erase" that would probably not be good. :-) Bob
Q: bash parameter expansion
Hi,
I wonder whether such difference in parameter expansion is valid:
$ env -i sh -c 'fun() { echo "[${*#foo }]"; }; fun foo bar'
[foo bar]
$ env -i sh -c 'fun() { echo "[${*#foo}]"; }; fun foo bar'
[ bar]
$ sh --version
GNU bash, version 3.2.33(1)-release (x86_64-alt-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
Unlike bash, dash demonstrates no such difference:
$ env -i ash -c 'fun() { echo "[${*#foo }]"; }; fun foo bar'
[bar]
$ env -i ash -c 'fun() { echo "[${*#foo}]"; }; fun foo bar'
[ bar]
--
ldv
pgppfwvOoMyFU.pgp
Description: PGP signature
Re: Cannot bind ctrl-u to a readline function in bash.
Chet Ramey wrote: > By default, readline binds the tty editing characters (erase, kill, > [...] Use the `bind-tty-special-characters' variable to enable or disable this > behavior. > Thanks. That does indeed address my issue. I understand and appreciate using the tty editing bindings by default, but would it make sense to honor explicit overrides in the .inputrc without requiring that tty editing inheritance behavior to be disabled? I'm a long-time tcsh user (about 18 years), trying to transition to bash. For what it's worth (probably not very much--I'm not a typical user), I do actually miss the default ^R reprint behavior quite a bit when I find myself in a default bash environment. Thanks again for your help.
