Re: Bash readline remap ESC insert/command mode key
On 1/23/12 8:22 PM, Roger wrote: >> Patch seems to work great and I can now type 'exit' without command mode >> being spawned when typing the 'i'. >> >> It's behaviour is almost identical to VIM's. > > Found a bug. That's not really related to the timing issue, since the `i' is dropped completely, though the fix may involve using the same code. I'll take a look. Thanks for the report. 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: echo '-e' doesn't work as expected, or does it?
On 1/23/12 5:42 AM, Andreas Schwab wrote: >> you might want to report a bug to suse, here i get: > > It's a bug in --enable-separate-helpfiles: the generated file contains > only one help string for echo, which happens to be the one for !V9_ECHO. It seems like the only way to solve this reliably is to rework how the separate helpfiles are generated. I'll have to look at that for a future version. The separate helpfiles feature doesn't appear heavily used. 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: set -e in (subshells) does not work independently of outer context
[re-adding the list - also, please don't top-post on technical lists]
On 01/24/2012 06:53 PM, Jim Avera wrote:
> Thanks for the quick reply. I read the referenced article and don't
> think it says that at all.
> (http://austingroupbugs.net/view.php?id=52). In fact it seems to imply
> that -e *should* work inside subshell commands even if -e is otherwise
> being ignored (presumably because it is in a conditional context, etc.):
>
>
> 3) If the exit status of a compound command **other than a subshell**
> command was the result of a failure while -e was being ignored, then -e
> shall not apply to this command. [emphasis added]
>
> So what is the implication of this statement if the compound -is- a
> subshell command? Why was the exception "other than a subshell command"
> specified?
> Presumably -e should apply regardless of whether it was being ignored
> outside in such cases.
>
> I checked, and bash's current behavior matches ksh. So it is compatible.
>
> But as I read the specification, bash (and ksh) do something different.
Consider:
$ ksh -c 'set -e; { false && :; }; echo $?'
1
$ bash -c 'set -e; { false && :; }; echo $?'
1
This echoes 1. Why? Inside the compound command, we have an AND-OR
list; which means that the left half of the list is in a context where
-e is ignored (the 'false'); but based on the semantics of &&, the right
half is not executed. That means the overall compound command (the '{
false && :; }') executed with a failure - but the _reason_ it failed was
due to a failure of the AND-OR command, which was in turn due to the
failure of the simple command 'false' in a context where -e is ignored.
Therefore, the compound command has a non-zero status, but does not
trigger an exit for -e, even though -e is in effect for the overall
compound command.
Now, repeat the test with a subshell:
$ ksh -c 'set -e; ( false && : ); echo $?'
$ bash -c 'set -e; ( false && : ); echo $?'
Notice - no exit status. Why? Because sub-shells are the only compound
command where a non-zero status, caused for any reason (including
reasons where set -e was ignored), is fatal to the parent script.
That's what point 3 is trying to tell you.
Point 3 is _not_ requiring subshells to override the contexts where set
-e is ignored. That is, once you are in a context where -e is ignored,
there is NOTHING you can do to get -e obeyed again, not even a subshell.
$ bash -c 'set -e; if (set -e; false; echo hi); then :; fi; echo $?'
hi
0
Even though we called set -e twice (both in the parent and in the
subshell), the fact that the subshell exists in a context where -e is
ignored (the condition of an if statement), there is nothing we can do
in the subshell to re-enable -e.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Bash readline remap ESC insert/command mode key
On Mon, Jan 23, 2012 at 07:38:52PM EST, Chet Ramey wrote: > On 1/23/12 8:52 AM, Roger wrote: > > > A little more indepth examination, and I can see VIM's wait is > > approximately double of what the readline patch's wait time is. > > However, I think the shorter wait time is more functional as when > > typing a double char, it in no way takes as long as VIM's wait time > > unless you type the same char with your finger and then use a toe to > > type the second char. > > > > Matter of fact, I'm starting to find VIM's long wait time length > > a little annoying. ;-) > > > > Great job at guessing the wait time! > > Thanks. Half a second seemed right. In Vim, I have set the timeout to 200 milliseconds rather than the default 1000 (one whole second). This amounts to a typing speed of c. 5 characters per second or 60 wpm, a reasonable goal for the average typist. CJ
Re: [bug] Bash translates >&$var into &>$var for exported functions.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/23/12 2:50 AM, Dan Douglas wrote:
> Hello, In the case of exported functions, Bash interprets a copy descriptor
> followed by an expansion as the >& synonym for &>, resulting in the output
> going to a file named as the value of the FD it's given. This only applies
> to
> ">&$var" and not "<&$var". I've tested various quoting, Is there some way
> around this?
Nope, it's a bug. The command printing code is a little aggressive about
translating >& to &>. I've attached a patch that should be enough to
get you by.
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/
iEYEARECAAYFAk8gbdQACgkQu1hp8GTqdKuy+wCgkdDB7H/C6gUj1X1q8u/UWang
AnYAn2SoWursp9ew88MBhY5dalLn1gSZ
=lgmc
-END PGP SIGNATURE-
*** ../bash-4.2-patched/print_cmd.c 2011-04-21 16:53:01.0 -0400
--- print_cmd.c 2012-01-25 15:55:49.0 -0500
***
*** 114,117
--- 114,120
#define CHECK_XTRACE_FP xtrace_fp = (xtrace_fp ? xtrace_fp : stderr)
+ /* shell expansion characters: used in print_redirection_list */
+ #define EXPCHAR(c) ((c) == '{' || (c) == '~' || (c) == '$' || (c) == '`')
+
#define PRINT_DEFERRED_HEREDOCS(x) \
do { \
***
*** 984,987
--- 1000,1004
{
REDIRECT *heredocs, *hdtail, *newredir;
+ char *rw;
heredocs = (REDIRECT *)NULL;
***
*** 1005,1012
hdtail = heredocs = newredir;
}
! else if (redirects->instruction == r_duplicating_output_word && redirects->redirector.dest == 1)
{
/* Temporarily translate it as the execution code does. */
! redirects->instruction = r_err_and_out;
print_redirection (redirects);
redirects->instruction = r_duplicating_output_word;
--- 1022,1031
hdtail = heredocs = newredir;
}
! else if (redirects->instruction == r_duplicating_output_word && (redirects->flags & REDIR_VARASSIGN) == 0 && redirects->redirector.dest == 1)
{
/* Temporarily translate it as the execution code does. */
! rw = redirects->redirectee.filename->word;
! if (rw && *rw != '-' && DIGIT (*rw) == 0 && EXPCHAR (*rw) == 0)
! redirects->instruction = r_err_and_out;
print_redirection (redirects);
redirects->instruction = r_duplicating_output_word;
Re: Bash readline remap ESC insert/command mode key
>In Vim, I have set the timeout to 200 milliseconds rather than the >default 1000 (one whole second). > >This amounts to a typing speed of c. 5 characters per second or 60 wpm, >a reasonable goal for the average typist. ditto. about half the default is much better. -- Roger http://rogerx.freeshell.org/
