Re: bash 5.2 regression in optimize_connection_fork

[Chet Ramey]

On 11/24/22 2:12 PM, Frode Nordahl wrote:


Just wanted to mention that the fix in
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=94d25f57f124a9b2268a3af0a0915871032f426e
does indeed solve the issue for me.

Thank you for the proper fix and credits for the bug report.


Credit where credit is due.

--
``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 official patch 11

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   5.2
Patch-ID:   bash52-011

Bug-Reported-by:Fabien Orjollet 
Bug-Reference-ID:   
Bug-Reference-URL:  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023776

Bug-Description:

Patch (apply with `patch -p0'):

Using timeouts and readline editing with the `read' builtin (read -e -t) can
leave the readline timeout enabled, potentially resulting in an erroneous
timeout on the next call.

*** ../bash-5.2-patched/builtins/read.def   2022-06-02 14:23:19.0 
-0400
--- builtins/read.def   2022-11-10 10:27:45.0 -0500
***
*** 168,171 
--- 168,174 
if (read_timeout)
  shtimer_clear (read_timeout);
+ #if defined (READLINE)
+   rl_clear_timeout ();
+ #endif
read_timeout = 0;
  }
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 10
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 11
  
  #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.2 official patch 10

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   5.2
Patch-ID:   bash52-010

Bug-Reported-by:la...@apache.org
Bug-Reference-ID:
Bug-Reference-URL:  https://savannah.gnu.org/support/?110744

Bug-Description:

Bash-5.2 checks the first 128 characters of an executable file that execve()
refuses to execute to see whether it's a binary file before trying to
execute it as a shell script. This defeats some previously-supported use
cases like "self-executing" jar files or "self-uncompressing" scripts.

Patch (apply with `patch -p0'):

*** ../bash-5.2-patched/general.c   2022-11-07 10:31:42.0 -0500
--- general.c   2022-11-18 14:48:45.0 -0500
***
*** 684,687 
--- 684,688 
  {
register int i;
+   int nline;
unsigned char c;
  
***
*** 690,702 
  
/* Generally we check the first line for NULs. If the first line looks like
!  a `#!' interpreter specifier, we just look for NULs anywhere in the
!  buffer. */
!   if (sample[0] == '#' && sample[1] == '!')
! return (memchr (sample, '\0', sample_len) != NULL);
  
for (i = 0; i < sample_len; i++)
  {
c = sample[i];
!   if (c == '\n')
return (0);
if (c == '\0')
--- 691,701 
  
/* Generally we check the first line for NULs. If the first line looks like
!  a `#!' interpreter specifier, we look for NULs in the first two lines. */
!   nline = (sample[0] == '#' && sample[1] == '!') ? 2 : 1;
  
for (i = 0; i < sample_len; i++)
  {
c = sample[i];
!   if (c == '\n' && --nline == 0)
return (0);
if (c == '\0')
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 9
  
  #endif /* _PATCHLEVEL_H_ */
--- 26,30 
 looks for to find the patch level (for the sccs version string). */
  
! #define PATCHLEVEL 10
  
  #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.2 official patch 12

[Chet Ramey]

 BASH PATCH REPORT
 =

Bash-Release:   5.2
Patch-ID:   bash52-012

Bug-Reported-by:Kerin Millar 
Bug-Reference-ID:   <20221002095107.89561bc811e549b55644d...@plushkava.net>
Bug-Reference-URL:  
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg1.html

Bug-Description:

When running in bash compatibility mode, nested command substitutions can
leave the `extglob' option enabled.

Patch (apply with `patch -p0'):

*** /fs1/chet/scratch/bash-5.2.12/builtins/shopt.def2022-11-07 
10:31:42.0 -0500
--- builtins/shopt.def  2022-10-14 09:30:11.0 -0400
***
*** 150,153 
--- 150,158 
  #endif
  
+ #if defined (EXTENDED_GLOB)
+ int extglob_flag = EXTGLOB_DEFAULT;
+ static int shopt_set_extglob PARAMS((char *, int));
+ #endif
+ 
  int expaliases_flag = 0;
  static int shopt_set_expaliases PARAMS((char *, int));
***
*** 207,211 
  #endif
  #if defined (EXTENDED_GLOB)
!   { "extglob", &extended_glob, (shopt_set_func_t *)NULL },
  #endif
{ "extquote", &extended_quote, (shopt_set_func_t *)NULL },
--- 212,216 
  #endif
  #if defined (EXTENDED_GLOB)
!   { "extglob", &extglob_flag, shopt_set_extglob },
  #endif
{ "extquote", &extended_quote, (shopt_set_func_t *)NULL },
***
*** 378,382 
  
  #if defined (EXTENDED_GLOB)
!   extended_glob = EXTGLOB_DEFAULT;
  #endif
  
--- 383,387 
  
  #if defined (EXTENDED_GLOB)
!   extended_glob = extglob_flag = EXTGLOB_DEFAULT;
  #endif
  
***
*** 644,647 
--- 649,663 
  }
  
+ #if defined (EXTENDED_GLOB)
+ static int
+ shopt_set_extglob (option_name, mode)
+  char *option_name;
+  int mode;
+ {
+   extended_glob = extglob_flag;
+   return 0;
+ }
+ #endif
+ 
  #if defined (READLINE)
  static int
*** /fs1/chet/scratch/bash-5.2.12/builtins/common.h 2022-11-07 
10:31:42.0 -0500
--- builtins/common.h   2022-10-14 09:29:25.0 -0400
***
*** 258,261 
--- 258,265 
  #endif
  
+ #if defined (EXTENDED_GLOB)
+ extern int extglob_flag;
+ #endif
+ 
  extern int expaliases_flag;
  
*** /fs1/chet/scratch/bash-5.2.12/execute_cmd.c 2022-11-07 10:31:42.0 
-0500
--- execute_cmd.c   2022-11-02 16:32:12.0 -0400
***
*** 3991,4001 
  #endif /* COND_REGEXP */
{
- int oe;
- oe = extended_glob;
  extended_glob = 1;
  result = binary_test (cond->op->word, arg1, arg2, 
TEST_PATMATCH|TEST_ARITHEXP|TEST_LOCALE)
  ? EXECUTION_SUCCESS
  : EXECUTION_FAILURE;
! extended_glob = oe;
}
if (arg1 != nullstr)
--- 4015,4023 
  #endif /* COND_REGEXP */
{
  extended_glob = 1;
  result = binary_test (cond->op->word, arg1, arg2, 
TEST_PATMATCH|TEST_ARITHEXP|TEST_LOCALE)
  ? EXECUTION_SUCCESS
  : EXECUTION_FAILURE;
! extended_glob = extglob_flag;
}
if (arg1 != nullstr)
*** /fs1/chet/scratch/bash-5.2.9/parse.y2022-11-07 10:31:47.0 
-0500
--- parse.y 2022-11-14 11:27:22.0 -0500
***
*** 126,130 
  
  #if defined (EXTENDED_GLOB)
! extern int extended_glob;
  #endif
  
--- 126,130 
  
  #if defined (EXTENDED_GLOB)
! extern int extended_glob, extglob_flag;
  #endif
  
***
*** 3305,3309 
/* Reset to global value of extended glob */
if (parser_state & (PST_EXTPAT|PST_CMDSUBST))
! extended_glob = global_extglob;
  #endif
if (parser_state & (PST_CMDSUBST|PST_STRING))
--- 3321,3325 
/* Reset to global value of extended glob */
if (parser_state & (PST_EXTPAT|PST_CMDSUBST))
! extended_glob = extglob_flag;
  #endif
if (parser_state & (PST_CMDSUBST|PST_STRING))
***
*** 4125,4132 
  #if defined (EXTENDED_GLOB)
/* If (parser_state & PST_EXTPAT), we're parsing an extended pattern for a
!  conditional command and have already set global_extglob appropriately. */
if (shell_compatibility_level <= 51 && was_extpat == 0)
  {
!   local_extglob = global_extglob = extended_glob;
extended_glob = 1;
  }
--- 4143,4150 
  #if defined (EXTENDED_GLOB)
/* If (parser_state & PST_EXTPAT), we're parsing an extended pattern for a
!  conditional command and have already set extended_glob appropriately. */
if (shell_compatibility_level <= 51 && was_extpat == 0)
  {
!   local_extglob = extended_glob;
extended_glob = 1;
  }
***
*** 4236,4240 
sh_parser_state_t ps;
sh_input_line_state_t ls;
!   int orig_ind, nc, sflags, start_lineno;
char *ret, *ep, *ostring;
  
--- 4256,4260 
sh_parser_state_t ps;
sh_input_line_state_t ls;
!   int orig_ind, nc, sflags, start_lineno, local_extglob;
char *ret, *ep, *ostring;
  
***
*** 4

[bash 4] 'test -v 1' is never true

[Alejandro Colomar]

Hi!

I wrote a script, and am trying it on many systems.  On RHEL8, which has bash 4, 
it didn't work.  I could reduce the problem to the following command, which 
never returns true:


test -v 1;

In Debian Sid, where I develop, and where I have bash 5, that works fine, and is 
true if the function or script in which it is has any arguments.  On zsh(1) it 
also works fine.


Is this a known bug in bash?
The exact version where I can reproduce it is 4.4.20(1)-release 
(x86_64-redhat-linux-gnu).


Cheers,

Alex


--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [bash 4] 'test -v 1' is never true

[G. Branden Robinson]

Hi Alex,

At 2022-11-25T22:02:46+0100, Alejandro Colomar wrote:
> I wrote a script, and am trying it on many systems.  On RHEL8, which
> has bash 4, it didn't work.  I could reduce the problem to the
> following command, which never returns true:
> 
> test -v 1;
> 
> In Debian Sid, where I develop, and where I have bash 5, that works
> fine, and is true if the function or script in which it is has any
> arguments.  On zsh(1) it also works fine.
> 
> Is this a known bug in bash?
> The exact version where I can reproduce it is 4.4.20(1)-release
> (x86_64-redhat-linux-gnu).

I don't think it is a bug.  It is unspecified behavior according to
POSIX.

"-v" is not an operator according to POSIX, and I don't recall seeing it
in any shell.  It is therefore interpreted as a string argument.

  The algorithm for determining the precedence of the operators and the
  return value that shall be generated is based on the number of
  arguments presented to test. (However, when using the "[...]" form,
  the right-bracket final argument shall not be counted in this
  algorithm.)

  In the following list, $1, $2, $3, and $4 represent the arguments
  presented to test:

  0 arguments:
  Exit false (1).
  1 argument:
  Exit true (0) if $1 is not null; otherwise, exit false.
  2 arguments:

  If $1 is '!', exit true if $2 is null, false if $2 is not
  null.

  If $1 is a unary primary, exit true if the unary test is true,
  false if the unary test is false.

  Otherwise, produce unspecified results.

https://pubs.opengroup.org/onlinepubs/009695299/utilities/test.html

Regards,
Branden


signature.asc
Description: PGP signature

Re: [bash 4] 'test -v 1' is never true

[Greg Wooledge]

On Fri, Nov 25, 2022 at 03:40:42PM -0600, G. Branden Robinson wrote:
> I don't think it is a bug.  It is unspecified behavior according to
> POSIX.
> 
> "-v" is not an operator according to POSIX, and I don't recall seeing it
> in any shell.  It is therefore interpreted as a string argument.

[...]

It's a bash extension, not part of POSIX.  From 'help test':

  -v VAR True if the shell variable VAR is set.

Or from the man page:

   -v varname
  True if the shell variable varname is set (has been  assigned  a
  value).

So the question is whether "1" qualifies as a "shell variable".  I would
argue that it doesn't -- it's a special parameter, not a variable (because
you can't assign to it).

So, there's no reason to expect that "test -v 1" would work.  If you want
to test whether there's at least one argument, you should use something
like:

(($# > 0)) # bash extension

or

test "$#" -gt 0

Re: [bash 4] 'test -v 1' is never true

[Alejandro Colomar]

Hi Branden!

On 11/25/22 22:40, G. Branden Robinson wrote:

Hi Alex,

At 2022-11-25T22:02:46+0100, Alejandro Colomar wrote:

I wrote a script, and am trying it on many systems.  On RHEL8, which
has bash 4, it didn't work.  I could reduce the problem to the
following command, which never returns true:

 test -v 1;

In Debian Sid, where I develop, and where I have bash 5, that works
fine, and is true if the function or script in which it is has any
arguments.  On zsh(1) it also works fine.

Is this a known bug in bash?
The exact version where I can reproduce it is 4.4.20(1)-release
(x86_64-redhat-linux-gnu).


I don't think it is a bug.  It is unspecified behavior according to
POSIX.

"-v" is not an operator according to POSIX,


Yeah, I know.  I tried dash(1), which at least gives some warning:

$ cat bug.sh
#!/bin/bash

echo $1;

test -v 1 \
&& echo 'arguments';

$ dash bug.sh

bug.sh: 5: test: -v: unexpected operator



and I don't recall seeing it
in any shell.  It is therefore interpreted as a string argument.


But `-v` is a specified option of bash(1) (and also, at least, zsh(1)):

$ help test | grep '\-v'
  -v VAR True if the shell variable VAR is set.


I find it very useful, since I use `set -Eeufo pipefail` in my scripts, to 
simplify error handling.  When I want to use a variable that might be undefined, 
I first check if it exists.




   The algorithm for determining the precedence of the operators and the
   return value that shall be generated is based on the number of
   arguments presented to test. (However, when using the "[...]" form,
   the right-bracket final argument shall not be counted in this
   algorithm.)

   In the following list, $1, $2, $3, and $4 represent the arguments
   presented to test:

   0 arguments:
   Exit false (1).
   1 argument:
   Exit true (0) if $1 is not null; otherwise, exit false.
   2 arguments:

   If $1 is '!', exit true if $2 is null, false if $2 is not
   null.

   If $1 is a unary primary, exit true if the unary test is true,
   false if the unary test is false.

   Otherwise, produce unspecified results.

https://pubs.opengroup.org/onlinepubs/009695299/utilities/test.html

Regards,
Branden


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Re: [bash 4] 'test -v 1' is never true

[Robert Elz]

Date:Fri, 25 Nov 2022 16:53:11 -0500
From:Greg Wooledge 
Message-ID:  

  | So the question is whether "1" qualifies as a "shell variable".  I would
  | argue that it doesn't -- it's a special parameter, not a variable (because
  | you can't assign to it).

A positional param, rather than a special param, but the same argument
applies.

  | So, there's no reason to expect that "test -v 1" would work.

And even with variables, is non portable, and as alternatives
exist here which are portable and just as easy to use, why not
just use one of thise, such as:

  | you should use something like:
  | test "$#" -gt 0

but only for positional params (the 0 is 1 less than the
positional param to be checked ... for positional params,
if one exists (is set), all those before it are also set.
This can be easier to read if written as 'test "$@" -ge 1'
which means the same.

My preferred method for this, which works for all kinds
of variables and parameters is

test "${X+s}" = s

where X is whatever is to be tested (1 in this case)
and "s" is any string you like, except "" .. must be
the same both occurrences of course.

kre

Re: [bash 4] 'test -v 1' is never true

[Greg Wooledge]

On Sat, Nov 26, 2022 at 10:09:22AM +0700, Robert Elz wrote:
> My preferred method for this, which works for all kinds
> of variables and parameters is
> 
>   test "${X+s}" = s
> 
> where X is whatever is to be tested (1 in this case)
> and "s" is any string you like, except "" .. must be
> the same both occurrences of course.

This is also recommended on 
for the general case.

I don't personally suggest using it to check how many positional
parameters were given, because there are alternatives that are much
easier to read for that case.

Re: [bash 4] 'test -v 1' is never true

[Robert Elz]

Date:Sat, 26 Nov 2022 10:09:22 +0700
From:Robert Elz 
Message-ID:  <28751.1669432...@jacaranda.noi.kre.to>

  | This can be easier to read if written as 'test "$@" -ge 1'
  | which means the same.

And of course, I meant $# there, not $@   (just a typo...)

kre