echo '-e' doesn't work as expected, or does it?
Hi! Short question this time.. $ echo '-e' does not print -e $ echo '-e ' does print -e . Is this the way as it ought to be? GNU bash, Version 4.1.5(1)-release (Debian stable) Regards
Re: echo '-e' doesn't work as expected, or does it?
Am Sat, 21 Jan 2012 12:24:03 +0100 schrieb Philip : > Hi! Short question this time.. > > $ echo '-e' > does not print -e > > $ echo '-e ' > does print -e . > > Is this the way as it ought to be? GNU bash, Version 4.1.5(1)-release (Debian > stable) > > Regards > Nevermind! Just found an older thread about this.
Cross compile crapout
Trying to compile for an arm target I get this execute_cmd.c: In function 'execute_pipeline': execute_cmd.c:2205: error: 'job_control' undeclared (first use in this function) execute_cmd.c:2205: error: (Each undeclared identifier is reported only once execute_cmd.c:2205: error: for each function it appears in.) execute_cmd.c: In function 'execute_function': execute_cmd.c:4243: warning: passing argument 1 of 'array_rshift' discards qualifiers from pointer target type execute_cmd.c:4245: warning: passing argument 1 of 'array_rshift' discards qualifiers from pointer target type execute_cmd.c:4320: warning: passing argument 1 of 'array_shift' discards qualifiers from pointer target type execute_cmd.c:4321: warning: passing argument 1 of 'array_shift' discards qualifiers from pointer target type make: *** [execute_cmd.o] Error 1 I found the fix here, but it would be nice if it could work its way into the source for the next release. http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00039.html Thanks, Jon
Re: Cross compile crapout
On 1/21/12 11:13 AM, Jonathan Andrews wrote: > I found the fix here, but it would be nice if it could work its way into > the source for the next release. > > http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00039.html This is patch 18 to bash-4.2. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash readline remap ESC insert/command mode key
On 1/19/12 2:25 AM, Roger wrote: >> bind -m vi-command '"ii": vi-insertion-mode' >> bind -m vi-insert '"ii": vi-movement-mode' >> >> >> Or the following should work (untested here) using $HOME/.inputrc: >> >> $if mode=vi >> >>set keymap vi-command >>"ii": vi-insertion-mode >> >>set keymap vi-insert >>"ii": vi-movement-mode >> >> $endif > > > I've just tested the above inputrc by executing a new bash shell instance and > the above inputrc statement works, but there is an undesirable effect when > using it. > > While in insert mode, pressing the 'i' key only once causes readline to > intercept it and not print the 'i' char to screen if only pressed once. In > order to get the 'i' char printed, I need to immediately press any other key > following the 'i' char/key so it is not intercepted by readline as it is not > a > double 'i' key (ie 'ii'). Yes. It's ambiguous at that point. Readline can't tell whether or not you mean 'ii' until you type the second `i'. If you type something else, you must not have meant 'ii' and readline can use the original binding to self-insert. Readline doesn't add characters bound to a multi-character key sequence to the editing buffer and perform redisplay, because it will just have to go back and erase them later in the majority of cases. I could look at putting in some sort of inter-character timeout, but I don't know yet how well the code structure lends itself to that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
