Re: Readline bug?
On 1/21/19 10:01 PM, Greg Bell wrote:
>
> Hi Chet et al,
>
> On bash 4.3.48 (Ubuntu 16.04), \C-e doesn't work to move me to the end of
> line when in vi command mode.
Thanks for the report. This has been there forever. The default readline
vi command-mode keymap has ^E bound to switch to emacs editing mode. Since
bash uses `set -o emacs' for that, the bash readline initialization code
unbinds the key sequence. It needs to make sure that the function it's
bound to is still rl_emacs_editing_mode.
Here's a patch that fixes it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-5.0-patched/bashline.c 2019-01-16 16:13:21.0 -0500
--- bashline.c 2019-01-22 08:48:05.0 -0500
***
*** 498,502
rl_unbind_key_in_map (CTRL('M'), emacs_meta_keymap);
#if defined (VI_MODE)
! rl_unbind_key_in_map (CTRL('E'), vi_movement_keymap);
#endif
--- 498,505
rl_unbind_key_in_map (CTRL('M'), emacs_meta_keymap);
#if defined (VI_MODE)
! kseq[0] = CTRL('E');
! func = rl_function_of_keyseq (kseq, vi_movement_keymap, (int *)NULL);
! if (func == rl_emacs_editing_mode)
! rl_unbind_key_in_map (CTRL('E'), vi_movement_keymap);
#endif
Re: Where is GLOBAL_COMMAND?
> grep global_command *.? GLOBAL_COMMAND is uppercase. But the actual variable name global_command is in lowercase. I think that GLOBAL_COMMAND should be changed to global_command in the comment. -- Regards, Peng
Re: Installing bash with rpath
On 1/20/19 7:47 PM, Mohammad Akhlaghi wrote: > On 1/21/19 12:25 AM, Chet Ramey wrote: >> Isn't there a linker option you can supply, possibly as part of LDFLAGS, >> to embed that into the bash binary? > > I pass `-Wl,-rpath-link=$instdir/lib' to LDFLAGS. It sets RPATH properly on > all the programs I install (including libreadline, and many other basic > programs), except for Bash and AWK. > > In my built programs, Bash and AWK are the only programs that depend on > libreadline, but RPATH does get written into libreadline, so I don't know > if the linking with libreadline has any affect on this problem or not. > > Is there any step in the build or install of Bash that somehow disables > using this method of setting RPATH? The bash link step doesn't do anything with rpath. The readline Makefiles set rpath to the installed location of the library at build time (using $libdir), so if you install it somewhere else that's going to be wrong. It should probably use $(DESTDIR)$(libdir) if that's what you use to install your copy of readline. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.0 Official Patch 2
BASH PATCH REPORT
=
Bash-Release: 5.0
Patch-ID: bash50-002
Bug-Reported-by:Ante Peric
Bug-Reference-ID:
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00095.html
Bug-Description:
When an alias value ends with an unquoted literal tab (not part of a quoted
string or comment), alias expansion cannot correctly detect the end of the
alias value after expanding it.
Patch (apply with `patch -p0'):
*** ../bash-5.0/parser.h2018-12-28 19:11:18.0 -0500
--- parser.h2019-01-11 15:13:03.0 -0500
***
*** 48,51
--- 48,52
#define PST_REDIRLIST 0x08/* parsing a list of redirections
preceding a simple command name */
#define PST_COMMENT 0x10/* parsing a shell comment; used by
aliases */
+ #define PST_ENDALIAS 0x20/* just finished expanding and
consuming an alias */
/* Definition of the delimiter stack. Needed by parse.y and bashhist.c. */
*** ../bash-5.0/parse.y 2019-01-02 13:57:34.0 -0500
--- parse.y 2019-01-14 08:23:31.0 -0500
***
*** 2558,2567
pushed_string_list->flags != PSH_DPAREN &&
(parser_state & PST_COMMENT) == 0 &&
shell_input_line_index > 0 &&
! shell_input_line[shell_input_line_index-1] != ' ' &&
shell_input_line[shell_input_line_index-1] != '\n' &&
shellmeta (shell_input_line[shell_input_line_index-1]) == 0 &&
(current_delimiter (dstack) != '\'' && current_delimiter (dstack) !=
'"'))
{
return ' '; /* END_ALIAS */
}
--- 2558,2569
pushed_string_list->flags != PSH_DPAREN &&
(parser_state & PST_COMMENT) == 0 &&
+ (parser_state & PST_ENDALIAS) == 0 && /* only once */
shell_input_line_index > 0 &&
! shellblank (shell_input_line[shell_input_line_index-1]) == 0 &&
shell_input_line[shell_input_line_index-1] != '\n' &&
shellmeta (shell_input_line[shell_input_line_index-1]) == 0 &&
(current_delimiter (dstack) != '\'' && current_delimiter (dstack) !=
'"'))
{
+ parser_state |= PST_ENDALIAS;
return ' '; /* END_ALIAS */
}
***
*** 2572,2575
--- 2574,2578
if (uc == 0 && pushed_string_list && pushed_string_list->flags !=
PSH_SOURCE)
{
+ parser_state &= ~PST_ENDALIAS;
pop_string ();
uc = shell_input_line[shell_input_line_index];
*** ../bash-5.0/y.tab.c 2019-01-02 13:57:43.0 -0500
--- y.tab.c 2019-01-14 08:39:23.0 -0500
***
*** 4874,4883
pushed_string_list->flags != PSH_DPAREN &&
(parser_state & PST_COMMENT) == 0 &&
shell_input_line_index > 0 &&
! shell_input_line[shell_input_line_index-1] != ' ' &&
shell_input_line[shell_input_line_index-1] != '\n' &&
shellmeta (shell_input_line[shell_input_line_index-1]) == 0 &&
(current_delimiter (dstack) != '\'' && current_delimiter (dstack) !=
'"'))
{
return ' '; /* END_ALIAS */
}
--- 4874,4885
pushed_string_list->flags != PSH_DPAREN &&
(parser_state & PST_COMMENT) == 0 &&
+ (parser_state & PST_ENDALIAS) == 0 && /* only once */
shell_input_line_index > 0 &&
! shellblank (shell_input_line[shell_input_line_index-1]) == 0 &&
shell_input_line[shell_input_line_index-1] != '\n' &&
shellmeta (shell_input_line[shell_input_line_index-1]) == 0 &&
(current_delimiter (dstack) != '\'' && current_delimiter (dstack) !=
'"'))
{
+ parser_state |= PST_ENDALIAS;
return ' '; /* END_ALIAS */
}
***
*** 4888,4891
--- 4890,4894
if (uc == 0 && pushed_string_list && pushed_string_list->flags !=
PSH_SOURCE)
{
+ parser_state &= ~PST_ENDALIAS;
pop_string ();
uc = shell_input_line[shell_input_line_index];
*** ../bash-5.0/patchlevel.h2016-06-22 14:51:03.0 -0400
--- patchlevel.h2016-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 1
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 2
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.0 Official Patch 1
BASH PATCH REPORT
=
Bash-Release: 5.0
Patch-ID: bash50-001
Bug-Reported-by:a...@freakout.de
Bug-Reference-ID: <201901082050.x08koshs006...@bongo.freakout.de>
Bug-Reference-URL:
http://lists.gnu.org/archive/html/bug-bash/2019-01/msg00079.html
Bug-Description:
Under certain circumstances, the glob expansion code did not remove
backslashes escaping characters in directory names (or portions of a
pattern preceding a slash).
Patch (apply with `patch -p0'):
*** ../bash-5.0/bashline.c 2018-11-27 13:20:16.0 -0500
--- bashline.c 2019-01-16 16:06:03.0 -0500
***
*** 232,235
--- 232,236
static int bash_possible_command_completions __P((int, int));
+ static int completion_glob_pattern __P((char *));
static char *glob_complete_word __P((const char *, int));
static int bash_glob_completion_internal __P((int));
***
*** 1742,1746
/* This could be a globbing pattern, so try to expand it using pathname
expansion. */
! if (!matches && glob_pattern_p (text))
{
matches = rl_completion_matches (text, glob_complete_word);
--- 1743,1747
/* This could be a globbing pattern, so try to expand it using pathname
expansion. */
! if (!matches && completion_glob_pattern ((char *)text))
{
matches = rl_completion_matches (text, glob_complete_word);
***
*** 1851,1855
}
! globpat = glob_pattern_p (hint_text);
/* If this is an absolute program name, do not check it against
--- 1852,1856
}
! globpat = completion_glob_pattern ((char *)hint_text);
/* If this is an absolute program name, do not check it against
***
*** 3714,3717
--- 3715,3773
}
+ static int
+ completion_glob_pattern (string)
+ char *string;
+ {
+ register int c;
+ char *send;
+ int open;
+
+ DECLARE_MBSTATE;
+
+ open = 0;
+ send = string + strlen (string);
+
+ while (c = *string++)
+ {
+ switch (c)
+ {
+ case '?':
+ case '*':
+ return (1);
+
+ case '[':
+ open++;
+ continue;
+
+ case ']':
+ if (open)
+ return (1);
+ continue;
+
+ case '+':
+ case '@':
+ case '!':
+ if (*string == '(') /*)*/
+ return (1);
+ continue;
+
+ case '\\':
+ if (*string == 0)
+ return (0);
+ }
+
+ /* Advance one fewer byte than an entire multibyte character to
+account for the auto-increment in the loop above. */
+ #ifdef HANDLE_MULTIBYTE
+ string--;
+ ADVANCE_CHAR_P (string, send - string);
+ string++;
+ #else
+ ADVANCE_CHAR_P (string, send - string);
+ #endif
+ }
+ return (0);
+ }
+
static char *globtext;
static char *globorig;
***
*** 3878,3882
}
! if (t && glob_pattern_p (t) == 0)
rl_explicit_arg = 1; /* XXX - force glob_complete_word to append `*'
*/
FREE (t);
--- 3934,3938
}
! if (t && completion_glob_pattern (t) == 0)
rl_explicit_arg = 1; /* XXX - force glob_complete_word to append `*'
*/
FREE (t);
*** ../bash-5.0/lib/glob/glob_loop.c2018-12-31 13:35:15.0 -0500
--- lib/glob/glob_loop.c2019-01-09 09:44:36.0 -0500
***
*** 55,59
case L('\\'):
- #if 0
/* Don't let the pattern end in a backslash (GMATCH returns no match
if the pattern ends in a backslash anyway), but otherwise return 1,
--- 55,58
***
*** 61,69
and it can be removed. */
return (*p != L('\0'));
- #else
- /* The pattern may not end with a backslash. */
- if (*p++ == L('\0'))
- return 0;
- #endif
}
--- 60,63
*** ../bash-5.0/patchlevel.h2016-06-22 14:51:03.0 -0400
--- patchlevel.h2016-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 0
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 1
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Where is GLOBAL_COMMAND?
On 1/22/19 7:47 AM, Peng Yu wrote: >> grep global_command *.? > > GLOBAL_COMMAND is uppercase. But the actual variable name > global_command is in lowercase. That's a documentation convention - the all-caps in the docstring calls your attention to the need to search case-insensitively for the actual variable, while spelling it case-sensitively would make it blend into the sentence and make it harder to realize that the sentence is indeed pointing you to an external variable. > > I think that GLOBAL_COMMAND should be changed to global_command in the > comment. If you think the existing convention is confusing, then submit a patch to change it instead of asking someone else to take on the grunt work. Otherwise, learn to live with the existing convention (which doesn't bother me, so I won't be submitting a patch). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Where is GLOBAL_COMMAND?
On 1/22/19 12:32 AM, Peng Yu wrote: > Hi, > > GLOBAL_COMMAND is mentioned as a global variable. But I don't find it. > Is it renamed to something else? grep global_command *.? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Readline bug?
On Tue, 22 Jan 2019, Greg Bell wrote: On bash 4.3.48 (Ubuntu 16.04), \C-e doesn't work to move me to the end of line when in vi command mode. This is specific to bash, and has been the case for as long as I can remember. I thought I'd reported it, but maybe not... As a workaround, in .bashrc: bind -m vi-command '"\C-e": end-of-line' All other readline consumers work fine with the default binding, and I add the usual emacs-style line editing bindings to vi-insert mode via .inputrc as well. -Rob
Re: Where is GLOBAL_COMMAND?
> That's a documentation convention - the all-caps in the docstring calls > your attention to the need to search case-insensitively for the actual > variable, while spelling it case-sensitively would make it blend into > the sentence and make it harder to realize that the sentence is indeed > pointing you to an external variable. Why not just use ` to quote it literally? Given that markdown is very common nowadays. Quoting it with ` should be a better choice rather than making it capitalized. I guess this probably because the original codebase predates markdown and its variants? > If you think the existing convention is confusing, then submit a patch > to change it instead of asking someone else to take on the grunt work. > Otherwise, learn to live with the existing convention (which doesn't > bother me, so I won't be submitting a patch). If it was hosted on github, then I would. But I am not used to savannah. Personally, I don't think it is as convenient. -- Regards, Peng
Re: Where is GLOBAL_COMMAND?
On 1/22/19 2:37 PM, Peng Yu wrote: >> That's a documentation convention - the all-caps in the docstring calls >> your attention to the need to search case-insensitively for the actual >> variable, while spelling it case-sensitively would make it blend into >> the sentence and make it harder to realize that the sentence is indeed >> pointing you to an external variable. > > Why not just use ` to quote it literally? Given that markdown is very > common nowadays. Quoting it with ` should be a better choice rather > than making it capitalized. I guess this probably because the original > codebase predates markdown and its variants? By MANY years ;) > >> If you think the existing convention is confusing, then submit a patch >> to change it instead of asking someone else to take on the grunt work. >> Otherwise, learn to live with the existing convention (which doesn't >> bother me, so I won't be submitting a patch). > > If it was hosted on github, then I would. But I am not used to > savannah. Personally, I don't think it is as convenient. You fail to understand the power of distributed version control. Nothing is preventing you from creating a github clone of the savannah upstream git repository, and making your patches in whatever way you prefer using github's processes; the only real leap is realizing that you submit your patches as emails to this list rather than as pull requests to github. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: loadable cat bug?
On 2019-01-21 at 20:03 -0600, Peng Yu wrote:
> When I use the loadable cat, I may get the following error. The input
> is a fifo in this specific case.
>
> cat: cannot open /tmp/tmp.VXkbqFlPtH: Interrupted system call
>
> So far, I can not make a minimal script to demonstrate the problem.
> But if I replace it with coreutils cat in my code, the problem is
> gone.
>
> Does anybody know what could cause this error?
Hello
The loadable cat is getting interrupted during an open() call (due to a
signal, usually), which is quite odd. Generally open(2) is immediate,
but in the case of a fifo, open(, O_RDONLY) doesn't return until the
pipe is opened for writing. So, if a signal is received at that point,
cat will fail with this error. This is easy to reproduce on bash 4.x by
simply resizing the window. On bash-5.0 SIGWINCH was changed to use
SA_RESTART so it's not an issue.
Can you figure out if it may be getting interrupted by a different
reason?
It would be simple to avoid the symptom with eg. the following trivial
patch. However, that would also not allow ending the cat by a Ctrl-C.
If that was just a matter of the window getting resized, bash 5 already
fixed it.
Best regards
diff --git a/examples/loadables/cat.c b/examples/loadables/cat.c
index be99c4c..dc8246d 100644
--- a/examples/loadables/cat.c
+++ b/examples/loadables/cat.c
@@ -71,7 +71,10 @@ char **argv;
if (argv[i][0] == '-' && argv[i][1] == '\0')
fd = 0;
else {
- fd = open(argv[i], O_RDONLY, 0666);
+ do {
+ fd = open(argv[i], O_RDONLY, 0666);
+ } while (fd == -1 && errno == EINTR);
+
if (fd < 0) {
s = strerror(errno);
write(2, "cat: cannot open ", 17);
UUID as Array Keys strangely not possible
Howdy,
The following cannot work because, for some reason, the array subscript
parser insists on doing math on array indices even when the array is
associative instead of numeric
typeset -A UUID_TABLE
...
UUID_TABLE+=( [${SOME_UUID}]=${SOME_VALUE} )
...
some_command ${UUID_TABLE[${SOME_UUID}]}
The parser and evaluator insist on doing math on ${SOME_UUID} no matter
how its quoted or whatever. This seems extremely wrong.
At a minimum putting the index in double quotes should suppress the
arithmetic evaluation. In the ideal the decision to math-or-not decision
should happen after the array type is known, thought that's probably too
hard.
Alternately some sort of builtin hash function to map complex strings
into usable associative array indexes would be nice.
UUIDs are simply too useful and common in current systems to sustain
their current second-class status.
(DISCLAIMER: I'm not a subscriber to this list.)
Re: UUID as Array Keys strangely not possible
On 1/22/19 3:32 PM, Robert White wrote:
> Howdy,
>
> The following cannot work because, for some reason, the array subscript
> parser insists on doing math on array indices even when the array is
> associative instead of numeric
>
> typeset -A UUID_TABLE
> ...
> UUID_TABLE+=( [${SOME_UUID}]=${SOME_VALUE} )
> ...
> some_command ${UUID_TABLE[${SOME_UUID}]}
>
> The parser and evaluator insist on doing math on ${SOME_UUID} no matter how
> its quoted or whatever. This seems extremely wrong.
Do you have some sample UUID data to test this with?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: ${p+\"$p\"}
OK so bash is right and dash is wrong? So I should file a dash bug?
Re: ${p+\"$p\"}
On 1/22/19 6:36 PM, 積丹尼 Dan Jacobson wrote:
> OK so bash is right and dash is wrong? So I should file a dash bug?
Rather, POSIX says the behavior is undefined, so both shells are right,
and you cannot portably use " inside ${p+...} when in a double-quoted
context (such as a heredoc).
For more details:
http://austingroupbugs.net/view.php?id=221
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: ${p+\"$p\"}
Date:Tue, 22 Jan 2019 20:23:50 -0600 From:Eric Blake Message-ID: <77d63ba1-64ba-c0a8-7d32-9d8cc3289...@redhat.com> | Rather, POSIX says the behavior is undefined, That's what it is going to say, when Issue 8 is published, some years into the future (how many, anyone's guess.) For now it is just all a big mess. kre
