Re: bash "extglob" needs to upgrade at least like zsh "kshglob"
2022年11月1日(火) 0:59 Chet Ramey :
> If someone wanted to do this, I would take a look at incorporating the
> results, as long as it didn't add dependencies on, say, pcre or gnulib
> regex.
Instead of translating the pattern to a regular expression and
compiling it by regcomp (), I have experimentally implemented
a new extglob engine based on a naive DFA and was comparing the
behavior and the performance with the current implementations of
devel. [Note: In this report hereafter, ``the current
implementation/engine'' always means the implementation of strmatch
(lib/glob/{strmatch,smatch,sm_loop.c}) in the current devel 31f4d468.]
However, I noticed two strange behaviors of the current engine.
Before adjusting the behavior of the new engine and submitting it for
review, I would like to confirm the (expected) behavior of the current
engine in the current devel.
These two behaviors finally turned out to be both related to the
matching of bracket expression by the function `BRACKMATCH'
(lib/glob/sm_loop.c).
--
1. pattern [[=B=]][c] matches with c
$ bash-devel --norc
$ [[ Bc == [[=B=]][c] ]]; echo $?
0 <-- OK. This is expected.
$ [[ c == [[=B=]][c] ]]; echo $?
0 <-- This is unexpected.
See the attached [r0037.brackmatch1.equivalence-class.patch] for the
fix. The problem is caused because [[=B=]][c] is treated as a
single bracket expression [ « [=B=]][c » ] when the equivalence
class [=B=] does not match. This is because `]' after `[[=B=]' is
treated as if it is the first `]' in the bracket expression (such as
`]' after `[' in the pattern « []aaa] »). In the patch, when the
next character after a failing equivalence class [=B=] is `]', the
bracket expression has been changed to fail just the same as the
case for a failing character class [:alpha:]
(lib/glob/sm_loop.c:530; line number is that in the current devel
31f4d468).
--
2. bracket expression sometimes match or unmatch the slash with
FNM_PATHNAME.
FNM_PATHNAME is only used in two places in the Bash codebase. 1)
One is for the glob matching for the filenames in the directory
(lib/glob/glob.c). However, this actually does not seem to have an
actual effect because FNM_PATHNAME only causes differences in the
matching when the target string contains a slash but the filenames
do not contain any slashes. 2) The other is the filtering of the
pathname-expansion results with GLOBIGNORE (pathexp.c). So the only
way to test the behavior of Bash's strmatch with FNM_PATHNAME
(without writing a C program to directly use the function
`strmatch') is to use GLOBIGNORE.
To demonstrate the behavior of the current implementation, I attach
a script [fnmpath.sh], which utilizes GLOBIGNORE for the Bash
implementation. It compares the result with fnmatch(3). The result
in my environment (x86_64-redhat-linux-gnu [Fedora Linux 36 (Server
Edition)]) is this:
$ bash-devel fnmpath.sh
#1: pat=ab/cd/efgyes/yes
#2: pat=ab[/]cd/efg yes/no
#3: pat=ab[/a]cd/efg yes/no
#4: pat=ab[a/]cd/efg no/no
#5: pat=ab[!a]cd/efg yes/no
#6: pat=ab[.-0]cd/efgyes/no
#7: pat=*/*/efg yes/yes
#8: pat=*[/]*/efgno/no
#9: pat=*[/a]*/efg no/no
#10: pat=*[a/]*/efg no/no
#11: pat=*[!a]*/efg no/no
#12: pat=*[.-0]*/efg no/no
#13: pat=ab@(/)cd/efg yes/yes
#14: pat=*@(/)cd/efg no/no
#15: pat=*/cd/efg yes/yes
This tests whether each pattern matches the string "ab/cd/efg". Two
results by Bash's strmatch and fnmatch(3) are connected with
`/'. "yes" means the pattern matches the string "ab/cd/efg" and "no"
means it does not match. Some observations are
* In fnmatch(3), a bracket expression never matches a / with
FNM_PATHNAME.
* In Bash's strmatch, a bracket expression sometimes matches `/' and
sometimes does not. In the codebase, `/' is excluded only when it
explicitly appears after another character in the bracket
expression (lib/glob/sm_loop.c:574) even though the comment
mentions [/]. This is the reason that only [a/] fails with Bash's
implementation in cases #2..#6 in the above result.
* What is happening with Bash's implementation in cases #7..#12 is
related the assumption of the backtracking trick for `*': The
trick for `*' backtracking explained in the code comment
lib/glob/sm_loop.c:320---"This is a clever idea from
glibc"---relies on the behavior that the bracket expression never
matches a slash that `*' cannot match. [Note: The exact
requirements for this trick is actually slightly weaker: each
bracket expression needs to match a fixed number of `/', 0 or 1,
when FNM_PATHNAME is specified; it should never match a slash if
it can match other characters, and it should never match other
character
Interest in Converting Macros to Inline Functions
Hi,
I noticed that Bash code sometimes uses macros where a static inline function
would appear to work equally as well.
For instance, consider the macro ALL_ELEMENT_SUB defined in array.h:
#define ALL_ELEMENT_SUB(c) ((c) == '@' || (c) == '*')
I imagine this could be turned into a function like so:
static inline int all_element_sub(char c) { return c == '@' || c == '*'; }
The reason why one would want to do this is because functions are often easier
to reason about than macros.
The GNU C Preprocessor manual even has a list of pitfalls one can fall into
when programming with macros.
So it may be worthwhile to turn such macros into functions to prevent
developers from accidentally falling into one of these pitfalls.
How does this idea sound?
bash-5.2.9 lib/readline/input.c fix for Tru64
Hi, In bash-5.2.9 if HAVE_SELECT is set but HAVE_PSELECT is not, we still need the "fd_set readfds;" at line 808 in lib/readline/input.c. Found on Tru64 5.1. Also this platform doesn't have strtoimax but config.h is still setting #define HAVE_DECL_STRTOIMAX 1 #define HAVE_DECL_STRTOLL 1 #define HAVE_DECL_STRTOULL 1 #define HAVE_DECL_STRTOUMAX 1 even though later on it correctly realizes that HAVE_STRTOLL, HAVE_STRTOULL, HAVE_STRTOIMAX, and HAVE_STRTOUMAX should not be set. This is because the Tru64 linker will still produce an executable and return true even if the executable contains unresolved symbols. I'm not immediately sure of a fix for that one. -Henry
"cannot execute binary file" error with Bash 5.2
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux sah1lpt664 6.0.5-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed
Oct 26 15:55:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
I can no longer run xxx-ct-ng.config scripts produced by crosstool-ng.
Those just contain a few lines of script, with appended bzip2
compressed text.
https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/toolchain-config.in
Bash 5.2 changed the check_binary_file function, it seems any NUL in
the first
80 characters will cause the error.
Repeat-By:
Create a test.sh with :
#!/bin/sh
tail -n+4 "${0}" | bzcat
exit 0
$ echo foo | bzip2 >> test.sh
$ bash ./test.sh
./test.sh: ./test.sh: cannot execute binary file
Re: Should the readline *-meta flags reset when $LANG changes?
2022年11月15日(火) 0:22 Chet Ramey : > On 8/11/22 5:56 PM, Koichi Murase wrote: > > Can we also change the behavior of TERM in a similar way with option > > 4? Currently, a temporal change of TERM clears keybindings of some > > keys (home, end, right, left, etc.) even when the temporal change does > > not survive across multiple calls of readline: > > I finally got back to look at this, and I couldn't reproduce it. That was > expected, since the arrow key binding functions are pretty careful not to > overwrite an existing binding. Then I figured out what was going on. Thank you for checking this. > > > > $ bash-dev --norc > > $ echo "$TERM" > > screen.xterm-256color > > $ bind '"\e[1~": bell' > > This unbinds the key sequence, since `bell' is not a valid bindable command > name. Ah, OK. The above ``reduced case'' was not correct, but unbinding is actually what I wanted to do in the original problem. In the original code, I intentionally unbind the keybinding for "\e[1~" and instead try to bind a single byte `\e'. However, after running "TERM=xxx infocmp" in the command line, the keybinding does not work anymore This is what I experienced. Currently. as a workaround, I run the unbinding and rebinding code [1] every time the user command is executed, but I would like to skip the workaround if possible in newer versions of Bash. [1] The related code is found at https://github.com/akinomyoga/ble.sh/blob/0c6291f0c1/src/edit.sh#L6410-L6438 > I think the "TERM=$TERM" idiom to reset the readline terminal settings > without overwriting existing key bindings is useful enough to retain the > current behavior. I think it can be useful, but should that also apply to the tempenv of the form "TERM=$TERM infocmp"? In the sense that the side effects of the temporary environment variables (tempenvs) are intended to be not persistent after the execution of the command (unless it is for special builtin and functions in the POSIX mode), I would like to request that the idiom TERM=$TERM to reset the terminal settings would not be invoked for the tempenvs. -- Koichi
Re: Bash-5.2 official patch 9
On 11/12/22 4:39 AM, Kerin Millar wrote: On Tue, 8 Nov 2022 09:50:51 -0500 Chet Ramey wrote: BASH PATCH REPORT = Bash-Release: 5.2 Patch-ID: bash52-009 Are there any plans to backport the "fixes for extended glob in compat mode" in the near future? What is the "near future?" I have a patch that will probably be part of the next batch (attached if you want to use it). There's only been the one report of a problem, though, which impacts its priority. -- ``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.2-patched/parse.y 2022-08-31 11:47:03.0 -0400 --- parse.y 2022-10-05 11:55:18.0 -0400 *** *** 4230,4234 sh_parser_state_t ps; sh_input_line_state_t ls; ! int orig_ind, nc, sflags, start_lineno; char *ret, *ep, *ostring; --- 4230,4234 sh_parser_state_t ps; sh_input_line_state_t ls; ! int orig_ind, nc, sflags, start_lineno, local_extglob; char *ret, *ep, *ostring; *** *** 4273,4277 expand_aliases = 0; #if defined (EXTENDED_GLOB) ! global_extglob = extended_glob; /* for reset_parser() */ #endif --- 4273,4277 expand_aliases = 0; #if defined (EXTENDED_GLOB) ! local_extglob = global_extglob = extended_glob; /* for reset_parser() */ #endif *** *** 4291,4294 --- 4291,4297 restore_parser_state (&ps); + #if defined (EXTENDED_GLOB) + extended_glob = local_extglob; + #endif token_to_read = 0;
Re: Should the readline *-meta flags reset when $LANG changes?
On 8/11/22 5:56 PM, Koichi Murase wrote: Can we also change the behavior of TERM in a similar way with option 4? Currently, a temporal change of TERM clears keybindings of some keys (home, end, right, left, etc.) even when the temporal change does not survive across multiple calls of readline: I finally got back to look at this, and I couldn't reproduce it. That was expected, since the arrow key binding functions are pretty careful not to overwrite an existing binding. Then I figured out what was going on. $ bash-dev --norc $ echo "$TERM" screen.xterm-256color $ bind '"\e[1~": bell' This unbinds the key sequence, since `bell' is not a valid bindable command name. I happened to be using `previous-history' and testing with "\eOH", which rebinds it instead. $ bind -q beginning-of-line beginning-of-line can be invoked via "\C-a", "\eOH", "\e[H". $ TERM=dumb infocmp >dumb.ti Bash does call rl_reset_terminal here when restoring the original value of TERM, and it attempts to bind the arrow keys and the other specials (Home, etc.). It finds that "\e[1~" is not bound, and binds it. $ bind -q beginning-of-line beginning-of-line can be invoked via "\C-a", "\eOH", "\e[1~", "\e[H". I think the "TERM=$TERM" idiom to reset the readline terminal settings without overwriting existing key bindings is useful enough to retain the current behavior. -- ``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: Should the readline *-meta flags reset when $LANG changes?
On 11/14/22 11:40 AM, Koichi Murase wrote: 2022年11月15日(火) 0:22 Chet Ramey : On 8/11/22 5:56 PM, Koichi Murase wrote: Can we also change the behavior of TERM in a similar way with option 4? Currently, a temporal change of TERM clears keybindings of some keys (home, end, right, left, etc.) even when the temporal change does not survive across multiple calls of readline: I finally got back to look at this, and I couldn't reproduce it. That was expected, since the arrow key binding functions are pretty careful not to overwrite an existing binding. Then I figured out what was going on. Thank you for checking this. $ bash-dev --norc $ echo "$TERM" screen.xterm-256color $ bind '"\e[1~": bell' This unbinds the key sequence, since `bell' is not a valid bindable command name. Ah, OK. The above ``reduced case'' was not correct, but unbinding is actually what I wanted to do in the original problem. In the original code, I intentionally unbind the keybinding for "\e[1~" and instead try to bind a single byte `\e'. What do you try to bind \e to? However, after running "TERM=xxx infocmp" in the command line, the keybinding does not work anymore This is what I experienced. Well, yes, if you unbind it, restoring TERM will restore the original binding. I think the "TERM=$TERM" idiom to reset the readline terminal settings without overwriting existing key bindings is useful enough to retain the current behavior. I think it can be useful, but should that also apply to the tempenv of the form "TERM=$TERM infocmp"? You can't really have one without the other, given the way the special variable handling works (and has worked). In the sense that the side effects of the temporary environment variables (tempenvs) are intended to be not persistent after the execution of the command (unless it is for special builtin and functions in the POSIX mode), I would like to request that the idiom TERM=$TERM to reset the terminal settings would not be invoked for the tempenvs. The variables in the temporary environment are restored to their previous values after the command executes. It's that restoration that triggers the call to rl_reset_terminal(), not the environment assignment, undoing any side effects of the environmnent assignment. Bash treats these uniformly, whether the simple command is a builtin, function, or command from the file system. So from readline's perspective, there is no difference between TERM=xxx and 'TERM=xxx command'. rl_reset_terminal() gets called the same way from the same function in both cases. -- ``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: Should the readline *-meta flags reset when $LANG changes?
w2022年11月15日(火) 5:31 Chet Ramey :
> On 11/14/22 11:40 AM, Koichi Murase wrote:
> > 2022年11月15日(火) 0:22 Chet Ramey :
> >> On 8/11/22 5:56 PM, Koichi Murase wrote:
> >>> Can we also change the behavior of TERM in a similar way with option
> >>> 4? Currently, a temporal change of TERM clears keybindings of some
> >>> keys (home, end, right, left, etc.) even when the temporal change does
> >>> not survive across multiple calls of readline:
> >>
> >> I finally got back to look at this, and I couldn't reproduce it. That was
> >> expected, since the arrow key binding functions are pretty careful not to
> >> overwrite an existing binding. Then I figured out what was going on.
> >
> > Thank you for checking this.
> >
> >>>
> >>> $ bash-dev --norc
> >>> $ echo "$TERM"
> >>> screen.xterm-256color
> >>> $ bind '"\e[1~": bell'
> >>
> >> This unbinds the key sequence, since `bell' is not a valid bindable command
> >> name.
> >
> > Ah, OK. The above ``reduced case'' was not correct, but unbinding is
> > actually what I wanted to do in the original problem. In the original
> > code, I intentionally unbind the keybinding for "\e[1~" and instead
> > try to bind a single byte `\e'.
>
> What do you try to bind \e to?
For my particular case, I would like to decode the escape sequences by
myself within the shell code using « bind -x '"\e": shell-func' » to
provide another configuration interface for the terminal's specific
key sequences and keybindings. I must admit that my use case is
unusual, but I am not sure if we could say for sure that there would
never be any use cases of binding to `\e' other than that.
> >> I think the "TERM=$TERM" idiom to reset the readline terminal settings
> >> without overwriting existing key bindings is useful enough to retain the
> >> current behavior.
> >
> > I think it can be useful, but should that also apply to the tempenv of
> > the form "TERM=$TERM infocmp"?
>
> You can't really have one without the other, given the way the special
> variable handling works (and has worked).
>
> > In the sense that the side effects of
> > the temporary environment variables (tempenvs) are intended to be not
> > persistent after the execution of the command (unless it is for
> > special builtin and functions in the POSIX mode), I would like to
> > request that the idiom TERM=$TERM to reset the terminal settings would
> > not be invoked for the tempenvs.
>
> The variables in the temporary environment are restored to their previous
> values after the command executes. It's that restoration that triggers the
> call to rl_reset_terminal(), not the environment assignment, undoing any
> side effects of the environmnent assignment. Bash treats these uniformly,
> whether the simple command is a builtin, function, or command from the
> file system.
>
> So from readline's perspective, there is no difference between TERM=xxx
> and 'TERM=xxx command'. rl_reset_terminal() gets called the same way from
> the same function in both cases.
I would not think the fix would be an easy "single-line" fix either,
but is it impossible to get the context of setting the variable inside
sv_terminal (variables.c:6046) e.g. by checking the variable contexts
where TERM{,CAP,INFO} are defined or by adding the second parameter to
sh_sv_func_t? Maybe it could be more complicated than I initially
thought: For example, we need to care about the case « TERM= read
-e » where we need to finally set up the terminal settings for
readline. We also need to handle att_propagate (variables.c:134) for
the cases like « TERM= export TERM » where the value of the
tempenv would be propagated to the original scope.
--
Koichi
Re: Interest in Converting Macros to Inline Functions
2022年11月15日(火) 8:46 Brent Pappas : > I noticed that Bash code sometimes uses macros where a static inline function > would appear to work equally as well. > For instance, consider the macro ALL_ELEMENT_SUB defined in array.h: The inline keyword is introduced in C99, but Bash is written in C89, and some parts are in K&R. Then, the discussion would be whether we would discard the support for C89 and entirely switch to C99+. If we would switch to C99, there are actually many more places where we can update in addition to the macros. I think a recent answer to a related discussion is https://lists.gnu.org/archive/html/bug-bash/2022-08/msg00141.html (though the "C89-style function definition" in that discussion actually points to the K&R style, and "C99 style" points to the C89 style). > The reason why one would want to do this is because functions are often easier > to reason about than macros. ``It's easier to reason about'' doesn't seem to be a sufficient reason to make large changes. We want to discuss the practical amount of work to rewrite the codebase vs the maintenance cost in the future. Also, if we rewrite the large codebase, we would need to care about new bugs caused by some oversights and mistakes in the rewriting process. > The GNU C Preprocessor manual even has a list of pitfalls one can fall into > when programming with macros. > So it may be worthwhile to turn such macros into functions to prevent > developers from accidentally falling into one of these pitfalls. If you know about the detailed behavior of the preprocessor, we can avoid the pitfalls of macros. In my opinion, the pitfalls of using macros are easier to avoid than many of the general pitfalls of C, which are related to pointers, etc. At least, the maintainer of Bash will check the incoming patches, so I don't think bugs caused by wrong usages of macros would enter the Bash codebase in the future. Nevertheless, I agree that we should use inline functions instead of macros when we start a new C99 project, but we need to be careful in the case of rewriting the existing codebase because there are more chances of creating bugs in the rewriting process itself than that for bugs that would be caused by macros. -- Koichi
Re: cannot validate read -e entry when bound to TAB
2022年11月11日(金) 8:48 Koichi Murase : > 2022年11月11日(金) 7:58 of1 : > > [...] > > read -set .001 -d '' DISCARD > > before the actual read -e > > Alas, this does not work anymore with 5.2 (-e and -t > > combination triggers shell exit or, when used in a script, prevents > > further use of read -e). > > Thanks for the report. I confirmed this. > > [...] > > I'll later check the details. In case someone might be waiting for the action from me, I actually gave up doing this because there was already a fix from Chet (Thanks). I'm just planning to quickly check the behavior of "the next devel push", which seems to be not yet pushed to savannah. Thank you.
Re: [PATCH] glob: add shopt globmtimesort to sort globs by mtime
On 10/3/22 2:56 PM, Evan Gates wrote: --- There is currently no good way to sort files by mtime in the shell. It's possible to do so with an ls that supports -t, but parsing ls is problematic. Thanks for the patch. There are some good things here, usable stuff, but I think I'll look at a more general approach for the next version. 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/
Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'
2022年10月10日(月) 22:47 Chet Ramey : > > 2022年10月4日(火) 0:56 Chet Ramey : > >>> I expect the same behavior of `f1' and `f2' as far as there are no > >>> background jobs. > >> > >> Why? f2 calls `jobs', and so requests information in a particular format, > >> which may or may not be the same format as the default (compact) format > >> bash uses when it reports job status before printing a prompt. > > > > My point is *not* about the format of the output of `jobs', but > > whether `jobs' should print the entries of foreground dead jobs, to > > begin with. > > Yes. I believe that `jobs' should print the status of jobs that the shell > would otherwise notify the user about. This includes foreground jobs that > are killed by a signal other than SIGINT/SIGPIPE. If you still think it should print the foreground dead jobs after reading the rest of my previous email [1], I'm fine with the current behavior. https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00045.html Then, I have a question: Is there any way to distinguish the entries of foreground dead jobs from the ones for the background ones in the output of the `jobs' command? If not, does it make sense to add a special marker or a status word in pretty_print_job (jobs.c:2040) or in print_pipeline (jobs.c:1939)? -- Koichi
Re: bash-5.2.9 lib/readline/input.c fix for Tru64
2022年11月15日(火) 9:04 Henry Bent :
> In bash-5.2.9 if HAVE_SELECT is set but HAVE_PSELECT is not, we still need
> the "fd_set readfds;" at line 808 in lib/readline/input.c. Found on Tru64
> 5.1.
This seems to be reported repeatedly for different lines in the source code.
https://lists.gnu.org/archive/html/bug-bash/2021-05/msg00088.html
https://lists.gnu.org/archive/html/bug-bash/2021-06/msg00160.html
I think someone needs to finally check the fixed version actually
compiles in a real Tru64 machine. I attach a possible patch
[202211-0044.HAVE_PSELECT-in-True64.patch] but haven't tested it in
Tru64, so I'm not sure if this is all.
> This
> is because the Tru64 linker will still produce an executable and return
> true even if the executable contains unresolved symbols. I'm not
> immediately sure of a fix for that one.
I guess that should be fixed at the side of autoconf. I thought the
configure script in the distributed version of Bash might be old so
checked it, but it is actually generated by the latest version of
autoconf-2.71 (2021-01). This can be a regression of autoconf because
these STRTO* tests seem to have existed for at least twenty years
(according to git blame config.h.in) and bash seems to have worked in
Tru64 for this period. Maybe you could try an older version of
autoconf (e.g. 2.69) to regenerate the configure script.
--
Koichi
From 3c0d445ee514a7068e5b634e8ea531c19f8a3d68 Mon Sep 17 00:00:00 2001
From: Koichi Murase
Date: Tue, 15 Nov 2022 11:32:01 +0900
Subject: [PATCH] fix for HAVE_PSELECT in Tru64
https://lists.gnu.org/archive/html/bug-bash/2022-11/msg00044.html
---
lib/readline/input.c | 2 +-
lib/sh/input_avail.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/readline/input.c b/lib/readline/input.c
index da4da455..1ec31805 100644
--- a/lib/readline/input.c
+++ b/lib/readline/input.c
@@ -250,7 +250,7 @@ rl_gather_tyi (void)
register int tem, result;
int chars_avail, k;
char input;
-#if defined(HAVE_SELECT)
+#if defined (HAVE_PSELECT) || defined(HAVE_SELECT)
fd_set readfds, exceptfds;
struct timeval timeout;
#endif
diff --git a/lib/sh/input_avail.c b/lib/sh/input_avail.c
index 2ac44616..f31798f3 100644
--- a/lib/sh/input_avail.c
+++ b/lib/sh/input_avail.c
@@ -107,10 +107,8 @@ nchars_avail (fd, nchars)
int nchars;
{
int result, chars_avail;
-#if defined(HAVE_SELECT)
- fd_set readfds, exceptfds;
-#endif
#if defined (HAVE_PSELECT) || defined (HAVE_SELECT)
+ fd_set readfds, exceptfds;
sigset_t set, oset;
#endif
--
2.37.2
Re: cannot validate read -e entry when bound to TAB
2022年11月15日(火) 1:47 Koichi Murase : > I'm just planning to quickly check the behavior of "the next devel > push", which seems to be not yet pushed to savannah. Thank you. I checked the latest devel push, where I confirmed that it now works. Thank you.
Re: Bash-5.2 official patch 9
> On 14 Nov 2022, at 20:03, Chet Ramey wrote: > > On 11/12/22 4:39 AM, Kerin Millar wrote: >> On Tue, 8 Nov 2022 09:50:51 -0500 >> Chet Ramey wrote: >>> BASH PATCH REPORT >>> = >>> >>> Bash-Release: 5.2 >>> Patch-ID: bash52-009 >> Are there any plans to backport the "fixes for extended glob in compat mode" >> in the near future? > > What is the "near future?" I have a patch that will probably be part of > the next batch (attached if you want to use it). There's only been the one > report of a problem, though, which impacts its priority. Thanks, I'll backport it in Gentoo now. Being part of the next batch is helpful to know. signature.asc Description: Message signed with OpenPGP
