readline expansion: 'cp $v/TAB' - 'cp \$v/' (no expansion) - why?
my #1 bash gripe is that newer versions do not
expand command lines containing '$' in emacs
readline editing mode. I used to be able to do:
$ export SRC=../somedir
$ less ${SRC}/TAB
(TAB meaning press horizontal tab key )
and emacs mode readline would expand,
displaying the contents of ../somedir .
Now it changes the input string into
'less \$SRC/' and prevents tab expansion
as would be done without use of any variables.
Would anyone know how to restore the old behavior
with bash 4.2.2 + readline 6.2 (linux ubuntu 12.04) ?
Thanks Regards, Jason
Re: readline expansion: 'cp $v/TAB' - 'cp \$v/' (no expansion) - why?
On 07/05/2012 04:58 AM, Jason Vas Dias wrote: Now it changes the input string into 'less \$SRC/' and prevents tab expansion as would be done without use of any variables. Would anyone know how to restore the old behavior with bash 4.2.2 + readline 6.2 (linux ubuntu 12.04) ? Yep - upgrade to bash 4.2.29 (that is, patchlevel 2 is missing the fix in patchlevel 29 that restores the behavior you want). ftp://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-029 This topic comes up frequently on this list. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: readline expansion: 'cp $v/TAB' - 'cp \$v/' (no expansion) - why?
hi Eric - thanks for your response, but bash-4.2.29(2), just built from latest patches from gnu on x86_64 ubuntu, does NOT restore the old behavior , but now refuses to tab-expand at all - 'cat $SRC/TAB' on the command line still produces no output. Is there some option I need to give to enable it? Thanks! On 5 Jul 2012 13:24, Eric Blake ebl...@redhat.com wrote: On 07/05/2012 04:58 AM, Jason Vas Dias wrote: Now it changes the input string into 'less \$SRC/' and prevents tab expansion as would be done without use of any variables. Would anyone know how to restore the old behavior with bash 4.2.2 + readline 6.2 (linux ubuntu 12.04) ? Yep - upgrade to bash 4.2.29 (that is, patchlevel 2 is missing the fix in patchlevel 29 that restores the behavior you want). ftp://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-029 This topic comes up frequently on this list. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org
Re: readline expansion: 'cp $v/TAB' - 'cp \$v/' (no expansion) - why?
On 7/5/12 7:59 AM, Jason Vas Dias wrote: hi Eric - thanks for your response, but bash-4.2.29(2), just built from latest patches from gnu on x86_64 ubuntu, does NOT restore the old behavior , but now refuses to tab-expand at all - 'cat $SRC/TAB' on the command line still produces no output. Is there some option I need to give to enable it? Thanks! Make sure you're not using programmable completion to eliminate that as a possible problem. 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/
Re: Doc of set -e should mention non-locality
On Wednesday, July 04, 2012 05:37:25 PM Rainer Blome wrote:
Original-Nachricht
Datum: Fri, 29 Jun 2012 18:03:13 -0500
Von: Dan Douglas orm...@gmail.com
An: bug-bash@gnu.org
CC: Rainer Blome rainer.bl...@gmx.de
Remember that my main suggestion is to clearly document the intended
behavior (see the subject). This could mean to add a generic
paragraph to the documentation of set that describes the scope
and extent for all options.
I'm all for better documentation. Scope in Bash is a complex subject. Almost
none of it is documented, and there is little standardization around how
function scope is supposed to work anyway. I'd call set -e a low priority
relative to documenting what scope behaviors are actually in place.
On Thursday, June 28, 2012 02:37:17 PM Rainer Blome wrote:
The implementation of set -e does not respect lexical nesting.
This can be very surprising.
None of the set options do, nor does the ERR trap.
That may very well be. Is this documented anywhere?
About the one thing you can count on with regards to scope in Bash, is that it
won't be lexical. But that's true of the majority of shells that have any kind
of scoping features at all beyond positional parameters and environment
variables.
PS: Your suggested workaround is, well, hard to understand.
Reminds me of the way people extend FORTH by massaging the stacks.
You have to know exactly what is parsed, substituted and evaluated
when in order to understand this (if it even works, did not try it).
I would not dare use this in production for fear of
receiving a beating from colleagues over hard to maintain code. ;-)
That's basically what it is (and this is yet another an undocumented scope
thing). Setting this trap within a function sets a hook on the function and
all of its callers which essentially runs eval on the given string upon
returning. To make matters more confusing, also potentially on callees if they
have the trace attribute set.
Other than that there's not much to understand or maintain. It'll set -e when
returning from the first function and set +e when returning from the second,
then unset itself on any further callers.
Here's a workaround (untested).
sete() {
[[ $- == *e* ]] return 1
trap $(/dev/stdin) RETURN
} EOF
if [[ $FUNCNAME != \$FUNCNAME ]]; then
set +e
trap - RETURN
else
set -e
fi
EOF
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: Doc of set -e should mention non-locality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/5/12 11:55 AM, Dan Douglas wrote: Remember that my main suggestion is to clearly document the intended behavior (see the subject). This could mean to add a generic paragraph to the documentation of set that describes the scope and extent for all options. I'm all for better documentation. Scope in Bash is a complex subject. Almost none of it is documented, and there is little standardization around how function scope is supposed to work anyway. I'd call set -e a low priority relative to documenting what scope behaviors are actually in place. There really isn't that much scope. Posix barely acknowledges the existence of scopes, period. It doesn't have local variables, options, or traps. The paragraph in the bash man page describing the behavior of the ERR, DEBUG, and RETURN traps, and the various descriptions of local variables, are about it. Bash's use of dynamic scoping is where the complexity comes in, I think, but the implementation is, I hope, consistent. 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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/1u9AACgkQu1hp8GTqdKs19QCfRvkBQ0rUxgNklTCZYhliQv4j d8MAoIfmHmDq9y3EP3y2wxz0fCshO+bo =EmUI -END PGP SIGNATURE-
