[[...]] documentation claims tilde expansion and process substitution occur within double quotes

[Lawrence Velázquez]

Both the manual [1] and man page [2] state:

The words between the [[ and ]] do not undergo word splitting
and filename expansion.  The shell performs tilde expansion,
parameter and variable expansion, arithmetic expansion,
command substitution, process substitution, and quote removal
on those words (the expansions that would occur if the words
were enclosed in double quotes).

However, the parenthetical is misleading because tilde expansion
and process substitution don't occur within double quotes.  (I just
helped an IRC user who'd been confused by this text.)

[1] 
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bashref.texi?h=devel=9c430f6bf37984e01977cc17f7066a6498aa4f18#n1153
[2] 
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?h=devel=9c430f6bf37984e01977cc17f7066a6498aa4f18#n762

-- 
vq

Re: bash newgrp(1) -c option? Fwd: /usr/bin/sg in Cygwin?

[Lawrence Velázquez]

On Mon, Apr 22, 2024, at 1:41 AM, Cedric Blancher wrote:
> The Solaris ksh93-integration version of ksh93 has a newgrp -c option
> (David Korn, Glenn Fowler and Roland Mainz did implement it), which
> works like ksh93/bash -c, and executes script under the requested
> group, and upon exiting resumes the old shell with the old group.
>
> Could you please implement this (newgrp -c 'command') in the bash
> newgrp builtin too?

I don't think bash has a "newgrp" builtin.

-- 
vq

Re: Parsing regression with for loop in case statement

[Lawrence Velázquez]

On Wed, Apr 10, 2024, at 11:07 PM, Martin D Kealey wrote:
> But ... oh look, it's mentioned in §2.10.2 (
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_10_02
> ).
>
> I wonder when that was added, and why?

It's been there since at least POSIX.2-1992 [1].  At a glance, it
looks like the Bourne shell accepted LFs before "in" from the very
beginning [2].  (The Solaris 10 shell definitely does accept them.)

[1]: https://archive.org/details/ieeestandardforiinst
[2]: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/cmd.c

-- 
vq

Re: [sr #111047] Value of BASHPID changes when inside a here-document

[Lawrence Velázquez]

Reproducing my comment [1] for the list:


> On Apr 4, 2024, at 5:57 PM, Richard Waite  wrote:
> 
> Does variable expansion for here-documents occur in a subshell?

Sometimes.  When a command requires forking (roughly speaking), its
redirections (not just here-documents) are processed after the fork
as an optimization.  For more details, including workarounds, see:

  - https://mywiki.wooledge.org/BashPitfalls#pf64
  - https://www.vidarholen.net/contents/blog/?p=865
  - https://lists.gnu.org/archive/html/help-bash/2024-02/msg00022.html


> Checking the value of BASH_SUBSHELL seems to indicate no:

This is not a context in which BASH_SUBSHELL is incremented.  As
per Chet [2]:

> From: Chet Ramey 
> Subject: Re: BASH_SUBSHELL is not incrementing when part of a pipeline
> Date: August 8, 2023 at 10:06:48 AM EDT
> To: Kamil Cukrowski Priv , bug-bash@gnu.org
> Cc: chet.ra...@case.edu
> Reply-To: chet.ra...@case.edu
> 
> On 8/7/23 9:56 AM, Kamil Cukrowski Priv wrote:
>> Hi, when BASH_SUBSHELL is part of a pipeline with just a simple command it 
>> does not increment. Consider the following:
> 
> Yes. BASH_SUBSHELL increments for asynchronous commands (&), commands
> explicitly in subshells, compound commands in pipelines, coprocesses,
> process substitution, and command substitution.


[1]: https://savannah.gnu.org/support/?111047#comment1
[2]: https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00017.html

-- 
vq

Re: Manual: clarify what POSIX stands for

[Lawrence Velázquez]

On Sun, Mar 31, 2024, at 8:47 PM, Martin D Kealey wrote:
> Most English speakers find "explanations of names" to be distractions
> rather than helping, so if you REALLY want to add this, can it please NOT
> be right next to the first use of the word "POSIX".

As the OP noted, the info/online manual already lists POSIX in the
"Definitions" section, so that would be the obvious place to add
further exposition, if desired.  (The man page already spells out
"Portable Operating System Interface" in the "SEE ALSO" section.)

-- 
vq

Re: Add option to just print history, with no added timestamps or line numbers

[Lawrence Velázquez]

On Sun, Mar 24, 2024, at 11:01 PM, Dan Jacobson wrote:
> P.S., "\t%s" seems to have an extra space squeezed between them with 
> bash: "\t %s",
> unless perhaps the spec says that %s always starts with a space.

The standard doesn't say that, so in native mode bash's `fc' is
indeed slightly nonconformant, but in POSIX mode it does omit the
extra space.

$ set +o posix
$ fc -ln -1 | od -t c -t x1
000   \t   s   e   t   +   o   p   o   s   i   x  \n
   09  20  73  65  74  20  2b  6f  20  70  6f  73  69  78  0a
017
$ set -o posix
$ fc -ln -1 | od -t c -t x1
000   \t   s   e   t   -   o   p   o   s   i   x  \n
   09  73  65  74  20  2d  6f  20  70  6f  73  69  78  0a
016

-- 
vq

Re: Add option to just print history, with no added timestamps or line numbers

[Lawrence Velázquez]

On Sun, Mar 24, 2024, at 8:54 PM, Dan Jacobson wrote:
> Yes, it omits the line numbers. But leaves the "^I " separators!
>
> $ fc -l 999 1000|cat -vt
> 999^I echo invite Nerbleson for dinner
> 1000^I echo and Snordsworth too
> $ fc -ln 999 1000|cat -vt
> ^I echo invite Nerbleson for dinner
> ^I echo and Snordsworth too

This behavior is standardized by POSIX.

When the -l option is used to list commands, the format of
each command in the list shall be as follows:

"%d\t%s\n", , 

If both the -l and -n options are specified, the format of
each command shall be:

"\t%s\n", 

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html

-- 
vq

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

[Lawrence Velázquez]

On Sun, Mar 24, 2024, at 2:56 PM, Greg Wooledge wrote:
> On Sun, Mar 24, 2024 at 01:04:38PM -0400, Zachary Santer wrote:
>> On Fri, Mar 22, 2024 at 11:23 AM Chet Ramey  wrote:
>> >
>> > This is what you can do with @K.
>> >
>> > https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00119.html
>> >
>> > Word splitting doesn't happen on the rhs of an assignment statement, so you
>> > use eval. The @K quoting is eval-safe.
>> 
>> Yeah, but what can you do with @k?
>
> You can write the keys and values to a stream/file.

I guess you can also more easily iterate over them or move them to
an indexed array (as has already been demonstrated).  I'm not really
sure this merited its own parameter transformation, but then again
that's how I feel about most of the transformations.


>> The difference in expansion behavior between indexed and associative
>> array compound assignment statements doesn't make sense.

The behavior of the latter is for backward compatibility, I think.
Initially expansions could only be used in associative array compound
assignments like this, so word splitting was undesirable:

declare -A x=([$y]=$z)

I suppose the contents of x=(...) could be examined lexically to
determine whether splitting should be allowed, but that would make
the situation even messier.


> It would be pretty reasonable to have a builtin that could take an array
> name plus any number of additional argument pairs, and load those pairs
> as keys/values into said array.  Then you could do something like this:
>
> declare -A hash=(...)
> kvlist=( "${hash[@]@k}" )
>
> declare -A newhash
> addtoarray newhash "${kvlist[@]}"
>
> Some readers may observe that this looks a bit like Tcl's "array set"
> command.  That's not a coincidence.  Whenever I see "a list of alternating
> keys and values", that's where my mind goes.
>
> I'm debating mentally whether this hypothetical new builtin would only
> work with associative arrays, or also double as an "lappend" (append new
> elements to the end of a list/array) if given an indexed array name.

Incidentally, yash has an "array" builtin that works like this on
indexed arrays.  (Yash doesn't have associative arrays.)

https://magicant.github.io/yash/doc/_array.html


-- 
vq

Re: Add option to just print history, with no added timestamps or line numbers

[Lawrence Velázquez]

On Sun, Mar 24, 2024, at 1:40 AM, Dan Jacobson wrote:
> $ help history
> should mention how in the world one is supposed to just print the plain 
> history,
> without any line numbers or time stamps.

fc -ln 1

-- 
vq

Re: History Expansion in Arithmetic Expansion

[Lawrence Velázquez]

On Sat, Mar 23, 2024, at 11:34 AM, A4-Tacks wrote:
> Description:
>  I am unable to use logical inversion operators in line
>  arithmetic extensions, nor can I escape them, which is undoubtedly 
> abnormal
>
> Repeat-By:
>  ```bash
>  $ ((!RANDOM))
>  bash: !RANDOM: event not found
>  ```

Unfortunately this is intentional and documented.  In interactive
shells with default settings, unquoted `!' introduces a history
expansion [1].  You cannot backslash-escape `!' within `((exp))'
because `exp' is treated almost [*] as if it were double-quoted,
and within double quotes `\' escapes `!' but is not removed [3].

[1]: https://www.gnu.org/software/bash/manual/html_node/History-Interaction.html
[2]: 
https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html
[3]: https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html

[*]: One exception is that double quotes themselves are removed,
so another (arguably worse) workaround is `(("!"RANDOM))'.

-- 
vq

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

[Lawrence Velázquez]

On Fri, Mar 22, 2024, at 12:54 PM, Greg Wooledge wrote:
> Also, I don't see the lower-case k transformation in the man page.

It's at the end of the list:

https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=f3b6bd1#n3525

-- 
vq

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

[Lawrence Velázquez]

On Wed, Mar 20, 2024, at 7:11 AM, Zachary Santer wrote:
> On Wed, Mar 20, 2024 at 12:29 AM Lawrence Velázquez  wrote:
>>
>> This isn't specific to ${var[@]@k}.
>>
>> $ kv1='a 1 b 2 c 3'
>> $ kv2=(a 1 b 2 c 3)
>> $ declare -A aa1=($kv1) aa2=(${kv2[@]}) aa3=("${kv2[@]}")
>> $ declare -p aa1 aa2 aa3
>> declare -A aa1=(["a 1 b 2 c 3"]="" )
>> declare -A aa2=(["a 1 b 2 c 3"]="" )
>> declare -A aa3=(["a 1 b 2 c 3"]="" )
>>
>> A couple of previous discussions:
>>   - https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00066.html
>>   - https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00128.html
>
> There I go, reporting a bug that isn't a bug again.
>
> One would think that enabling this behavior would be the entire
> purpose of the alternate ( key value ) syntax. If it doesn't do that,
> what benefit does it give over the standard ( [key]=value ) syntax?
> Maybe it;s easier to use eval with?

https://lists.gnu.org/archive/html/bug-bash/2019-07/msg00056.html

-- 
vq

Re: "${assoc[@]@k}" doesn't get expanded to separate words within compound assignment syntax

[Lawrence Velázquez]

On Tue, Mar 19, 2024, at 11:18 PM, Zachary Santer wrote:
> As such, I would expect that
> $ declare -A assoc_2=( "${assoc_1[@]@k}" )
> would create assoc_2 as a duplicate of assoc_1. However, we see that
> the entire expansion becomes the key for a single array element, with
> its value being the empty string.

This isn't specific to ${var[@]@k}.

$ kv1='a 1 b 2 c 3'
$ kv2=(a 1 b 2 c 3)
$ declare -A aa1=($kv1) aa2=(${kv2[@]}) aa3=("${kv2[@]}")
$ declare -p aa1 aa2 aa3
declare -A aa1=(["a 1 b 2 c 3"]="" )
declare -A aa2=(["a 1 b 2 c 3"]="" )
declare -A aa3=(["a 1 b 2 c 3"]="" )

A couple of previous discussions:
  - https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00066.html
  - https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00128.html

-- 
vq

Re: Bash 5.2: Missing ‘shopt’ option ‘syslog_history’ in doc/bashref.texi

[Lawrence Velázquez]

On Mon, Mar 18, 2024, at 12:49 AM, Kerin Millar wrote:
> On Mon, 18 Mar 2024 06:30:49 +0200
> Oğuz  wrote:
>
>> On Sunday, March 17, 2024, tpeplt  wrote:
>> >
>> >The texinfo version of the bash manual is missing a description of
>> > the ‘shopt’ option ‘syslog_history’.
>> >
>> 
>>  That must be a vendor extension, bash doesn't have such an option.
>
> It has such an option in the case that SYSLOG_HISTORY and SYSLOG_SHOPT 
> are defined.

I doubt those cause the build to modify the documentation, though.
The packager must have edited the man page.

-- 
vq

Re: "local -g" declaration references local var in enclosing scope

[Lawrence Velázquez]

On Sun, Mar 10, 2024, at 5:36 PM, Greg Wooledge wrote:
> Here it is in action.  "local -g" (or "declare -g") without an assignment
> in the same command definitely does things.
>
> hobbit:~$ f() { declare -g var; var=in_f; }
> hobbit:~$ unset -v var; f; declare -p var
> declare -- var="in_f"

This example appears to work the same without "declare -g":

$ f() { var=in_f; }
$ unset -v var; f; declare -p var
declare -- var="in_f"

But you're right that it does have an effect.  I overlooked attributes:

$ printvar() { printf '%s: <%s> <%s>\n' "$1" "$var" "${var@a}"; }
$ x() { local var; y; printvar outer; }
$ y() { local var; z; printvar inner; }
$ z() { local -gu var; var=hello; printvar innermost; }
$ x; printvar outermost
innermost:  <>
inner:  <>
outer: <> <>
outermost: <> 

-- 
vq

Re: "local -g" declaration references local var in enclosing scope

[Lawrence Velázquez]

On Sun, Mar 10, 2024, at 1:51 PM, Kerin Millar wrote:
> Dynamic scoping can be tremendously confusing. The following examples 
> should help to clarify the present state of affairs.
>
> $ x() { local a; y; echo "outer: $a"; }
> $ y() { local a; a=123; echo "inner: $a"; }
> $ x; echo "outermost: $a"
> inner: 123
> outer:
> outermost:
>
> This is likely as you would expect.
>
> $ y() { local -g a; a=123; echo "inner: $a"; }
> $ x; echo "outermost: $a"
> inner: 123
> outer: 123
> outermost:
>
> This may not be. There, the effect of the -g option effectively ends at 
> the outermost scope in which the variable, a, was declared. Namely, 
> that of the x function.

This doesn't seem to be accurate; the assignment is performed at
the *innermost* declared scope (other than the "local -g" one):

$ x() { local a; y; echo "outer: $a"; }
$ y() { local a; z; echo "inner: $a"; }
$ z() { local -g a; a=123; echo "innermost: $a"; }
$ x; echo "outermost: $a"
innermost: 123
inner: 123
outer:
outermost:

Basically, without an assignment, "local -g" does nothing.


> The manual states that the "-g option forces variables to be created or 
> modified at the global scope, even when declare is executed in a shell 
> function" and that "it is ignored in all other cases". I would consider 
> this wording insufficient for a user to be able to effectively reason 
> with the difference between the second case and the other two cases 
> presented.

Later it does say

When used in a function, `declare` makes each _name_ local,
as with the `local` command, unless the `-g` option is used.

but that doesn't really make the consequences of -g clear either.


-- 
vq

Re: [PATCH] tests/array.tests: using grep -E instead of egrep

[Lawrence Velázquez]

On Mon, Feb 19, 2024, at 4:08 AM, Xiangyu Chen wrote:
> From: Xiangyu Chen 
>
> The console ouput lots of egrep warning message, those message causes 
> test case fail in diff stage.

On what system does this happen?  The proposed changes might break the test 
suite on some older systems.

-- 
vq

Re: Inconsistent treatment of left-hand side of conditional expression where IFS is not its default value

[Lawrence Velázquez]

On Sun, Feb 18, 2024, at 5:03 PM, Kerin Millar wrote:
> Hi,
>
> This report stems from the discussion at 
> https://lists.gnu.org/archive/html/help-bash/2024-02/msg00085.html.
>
> Consider the following two cases.
>
> $ ( set a -- b; f=+ IFS=$f; [[ $f$*$f == *"$f--$f"* ]]; echo $? )
> 0
>
> $ ( set a -- b; f=$'\1' IFS=$f; [[ $f$*$f == *"$f--$f"* ]]; echo $? )
> 1
>
> It does not make sense that that the exit status value differs between 
> these cases, especially since SOH is not a whitespace character (in the 
> sense of field splitting). I think that the second case should also 
> yield 0. Regardless of what the intended behaviour is, I would also 
> expect for the manual to describe it.
>
> Note that quoting the left-hand side fixes it for SOH. In the absence 
> of quotes, xtrace output suggests that all of the SOH characters are 
> stripped from the expansion of $f$*$f.
>
> $ ( set a -- b; f=$'\1' IFS=$f; [[ "$f$*$f" == *"$f--$f"* ]]; echo $? )
> 0

Case commands exhibit similar behavior:

$ set a -- b
$ (f=+ IFS=$f; case $* in *"$f"*) echo 0;; *) echo 1;; esac)
0
$ (f=$'\1' IFS=$f; case $* in *"$f"*) echo 0;; *) echo 1;; esac)
1
$ (f=$'\1' IFS=$f; case "$*" in *"$f"*) echo 0;; *) echo 1;; esac)
0


-- 
vq

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

[Lawrence Velázquez]

On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote:
> Recently, I discovered a potential bug in the 'bash --posix' terminal 
> and I believe I have a fix that could resolve this issue. Before 
> proceeding, I wanted to confirm if this is an open-source project where 
> external contributions via pull requests are welcomed.

Yes, contributions are welcome, although this project does not use
pull requests.

https://git.savannah.gnu.org/cgit/bash.git/tree/README?h=bash-5.2#n51

-- 
vq

Re: $((expr)) allows the hexadecimal constant "0x"

[Lawrence Velázquez]

On Tue, Jan 16, 2024, at 4:43 PM, Chet Ramey wrote:
> On 1/9/24 11:23 PM, Martin D Kealey wrote:
>> The words “Integer constants follow the C language 
>> definition, without suffixes or character constants” were not added to the 
>> manual until June 2019 in the Devel branch (as commit 
>> 48492ffae22d692594757e53fb4580ebb1f506cf), and did not land in the Master 
>> branch until December 2020 (as commit 
>> 8868edaf2250e09c4e9a1c75ffe3274f28f38581).
>
> [...]
>
>> Ubuntu LTS users would then have 
>> first had a chance to read them in April 2022.
>
> That seems like an Ubuntu problem. I understand they have to lag -- the
> aforementioned RHEL 7 issue is just the worst example of vendors shipping
> old releases -- but 16 months seems like a pretty big gap. I don't use
> Ubuntu, but I figure they make releases more often than that.

LTS releases drop every two years, with interim releases every six
months in between.

https://ubuntu.com/about/release-cycle

-- 
vq

Re: document that read built-in can't return zero-length string in the middle of input

[Lawrence Velázquez]

On Fri, Jan 12, 2024, at 2:06 PM, Robert Elz wrote:
> ps: the use of process substitution there is just silly, it would work
> just as well, and be easier to understand if written:
>
>   printf '\\\nabc' | { read -N1; read -r b c; }; declare -p REPLY b c

Presumably Greg was just preventing the implicit pipeline subshell
from swallowing the variables.

bash-5.2$ printf '\\\nabc' | { read -N1; read -r b c; }; declare -p 
REPLY b c
bash: declare: REPLY: not found
bash: declare: b: not found
bash: declare: c: not found

For these self-contained experiments, printing the values from
within the subshell is probably fine.

bash-5.2$ printf '\\\nabc' | { read -N1; read -r b c; declare -p REPLY 
b c; }
declare -- REPLY="a"
declare -- b="bc"
declare -- c=""

-- 
vq

Re: bash should consult .config/bash/...

[Lawrence Velázquez]

On Sat, Dec 9, 2023, at 10:28 PM, Koichi Murase wrote:
> 2023年12月10日(日) 12:10 jidanni :
>> Maybe on the list of config files bash looks at,
>> there should be also .config/bash/... as that is
>
> There was a discussion:
>
> https://lists.gnu.org/archive/html/bug-bash/2021-05/threads.html#00024
> https://lists.gnu.org/archive/html/bug-bash/2021-11/threads.html#00036

See also:

  - "Suggestion/question"
https://lists.gnu.org/archive/html/bug-bash/2021-06/threads.html#3

  - "[Suggestion] Relocate user startup files to their own subdirectory"
https://lists.gnu.org/archive/html/help-bash/2022-07/threads.html#1

PS: Wow, I didn't know the message links on the archive index pages
were all anchored.  That's nifty, and good to know.

-- 
vq

Re: Missing documentation "-bash_input"

[Lawrence Velázquez]

On Tue, Nov 28, 2023, at 5:33 PM, Klaus Frank wrote:
> sorry, but this is not true

It is true.


> I can clearly see that it exists. It may be 
> an distro addition though. Is it specific to ArchLinux? Because I can 
> see it being used and when I try to use it on my system it also clearly 
> works.

You see it being used without causing errors, but that doesn't mean
it's doing what you think it's doing.  Observe that

% bash -c 'printf %s\\n "$@"' -bash 1 2 3

and

% bash -c 'printf %s\\n "$@"' --no_such_option 1 2 3

appear to behave identically.


> But against it just being a distro specific thing is that I also 
> can see it within the bash source code mirror on GitHub. Where does it 
> come from if it is not supposed to exist? Sorry, but something is really 
> confusing here.
>
>
> Example usage: 
> https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/src/makechrootpkg.in?ref_type=heads#L152
>
> arch-nspawn "$copydir" "${bindmounts_ro[@]}" "${bindmounts_rw[@]}" \
>      bash -c 'yes y | pacman -U -- "$@"' -bash "${pkgnames[@]/#//root/}"

You're misinterpreting that command line.  As Andreas already
explained, when you run something like

bash -c 'command string here' a b c d

the first argument after the command string (in my case "a", and
in your case "-bash") is used as $0 while executing that command
string, and the remaining arguments are used as the positional
parameters.  This happens even if an argument looks like an option,
so options are not recognized as such if they follow -c [*]:

% bash -x -c 'printf %s\\n "$0"'
+ printf '%s\n' bash
bash
% bash -c 'printf %s\\n "$0"' -x
-x

In your example, bash executes the command string 'yes ... "$@"'
with "-bash" as $0 and the (possibly multiword) expansion of
"${pkgnames[@]/#//root/}" as the positional parameter(s).  I don't
know why they are setting $0 to "-bash".  Doing so makes the shell
look like a login shell at a quick glance, but that doesn't make
it one:

% bash -c 'printf %s\\n "$0"; shopt login_shell' -bash
-bash
login_shell off

---

[*]: Hypothetical "-bash" and "-bash_input" options would have to
come before -c to take effect.  However, bash does not use Tcl-style
options, so "bash -bash" would be equivalent to "bash -b -a -s -h",
and "bash -bash_input" to "bash -b -a -s -h -_ -i -n -p -u -t".
These options all exist already except for "-_", which is why Greg's
demonstration yielded the error "-_: invalid option".

-- 
vq

Re: Regex: A case where the longest match isn't being found

[Lawrence Velázquez]

On Fri, Oct 27, 2023, at 12:25 AM, Grisha Levit wrote:
> On Thu, Oct 26, 2023, 20:30 Dale R. Worley  wrote:
>
>> I suspect the difference between the versions is how the regexp is
>> unquoted while it is being read, with version 3 interpreting [^\'] as
>> "character class excluding newline, backslash, and quote" and version 5
>> interpreting it as "character class excluding newline and quote".
>>
>
> That seems right

How?  If it were right, wouldn't these produce different results?

% cat foo.bash
printf %s\\n "$BASH_VERSION"
if [[ \\ =~ [^\'] ]]
then
printf %s\\n "${BASH_REMATCH[0]}"
fi
% /bin/bash ./foo.bash
3.2.57(1)-release
\
% /opt/local/bin/bash ./foo.bash
5.2.15(1)-release
\

-- 
vq

Re: Regex: A case where the longest match isn't being found

[Lawrence Velázquez]

On Thu, Oct 26, 2023, at 7:01 PM, Greg Wooledge wrote:
> On Thu, Oct 26, 2023 at 10:50:13AM -0700, Dan Bornstein wrote:
>> I found a case where the regex evaluator doesn't seem to be finding the 
>> longest possible match for a given expression. The expression works as 
>> expected on an older version of Bash (3.2.57(1)-release 
>> (arm64-apple-darwin22)).
>
> Bash uses the system's (libc) version of regex(3), so the difference
> you're seeing is presumably caused by the apple-darwin22 part, rather
> than the bash 3.2 part.  (Or conversely, caused by the linux-gnu part
> rather than the bash 5.2 part.)

Indeed, on my macOS system *both* 3.2.57 and 5.2.15 output

$'foo\' x'

and on shbot (the Linux IRC bot used in #bash) *both* 3.2.48 and
5.2.9 output

$'foo\'

-- 
vq

Re: wrong variable name in error message about unbound variable?

[Lawrence Velázquez]

On Tue, Oct 17, 2023, at 10:48 AM, Christoph Anton Mitterer wrote:
> As Lawrence pointed out:
> $ set -u 
> $ declare -A a
> $ echo ${a[k]}
> bash: a[k]: unbound variable
>
> Here it actually looks first at a (which turns out to be an associative
> array) and thus doesn't even bother to evaluate k, which makes sense of
> course, in order to avoid any side effects.

No.  As I said earlier, the reason "k" is not expanded here is that,
for associate-array accesses, subscripts are NOT arithmetic contexts.
It is not some sort of optimization.  Even if all relevant variables
are defined, "k" is not expanded:

$ set -u
$ k='1+2'
$ declare -A arr=([k]=foo [1+2]=bar [3]=baz)
$ echo "${arr[k]}"
foo

-- 
vq

Re: wrong variable name in error message about unbound variable?

[Lawrence Velázquez]

On Mon, Oct 16, 2023, at 9:06 PM, Christoph Anton Mitterer wrote:
> $ set -u
> $ [ -n "${array[key]+is_set}" ] && echo is set || echo not set
> bash: key: unbound variable
> $ [[ -v array[key] ]] && echo is set || echo not set
> bash: key: unbound variable

Since "array" has not been declared at this point, "${array[key]}"
attempts to access an indexed array named "array".  The shell
evaluates the subscript as an arithmetic expression and tries to
expand a variable named "key", which is unset.  Hence the error.


> $ declare -A array
> $ [ -n "${array[key]+is_set}" ] && echo is set || echo not set
> not set
> $ [[ -v array[key] ]] && echo is set || echo not set
> not set

Once you declare "array" as an associative array, the subscript is
no longer evaluated as an arithmetic expression -- "key" is just
the string k-e-y.

There are no further errors because these examples do not actually
attempt to expand an unset variable.  Observe the same behavior
with a scalar variable:

bash-5.2$ set -u
bash-5.2$ unset var
bash-5.2$ [ -n "${var+set}" ]
bash-5.2$ [[ -v var ]]

Conversely, if you actually do try to expand "${array[key]}", you
will observe an error.

bash-5.2$ set -u
bash-5.2$ unset array
bash-5.2$ declare -A array
bash-5.2$ : "${array[key]}"
bash: array[key]: unbound variable

set -u is about *expanding* unset variables, not merely accessing
them.


> Once array is declared (not even anything of it set yet) it gives
> already no unbound error.

This is a misdiagnosis.  Observe that declaring "array" as an indexed
array still leads to errors about "key".

bash-5.2$ set -u
bash-5.2$ unset array
bash-5.2$ declare -a array
bash-5.2$ [ -n "${array[key]+set}" ]
bash: key: unbound variable
bash-5.2$ [[ -v array[key] ]]
bash: key: unbound variable

The lack of errors is not caused by declaring "array" in general,
but specifically by declaring it as an *associative array*, and
then using it in contexts that never throw set -u errors.


> So shouldn't the error message refer to "array" as the unbound
> variable? Or perhaps both "array[key]"?

Under no circumstances should your examples complain about "array"
because they do not attempt to expand it.  As I demonstrated, your
examples do not even complain about unset scalar variables.


> Because the problem isn't that no key named "key" exists.

Yes, that is the problem.


> And beyond that:
> POSIX says:
>> -u
>>When the shell tries to expand an unset parameter other than the
>>'@' and '*' special parameters, it shall write a message to
>>standard error and the expansion shall fail with the consequences
>>specified in Consequences of Shell Errors.
>
> But just declaring the var, doesn't make it set... so shouldn't it
> still give an error message (which it does when using a non-array
> variable that is declared but not set)?

As I demonstrated, attempting to expand "array" using an nonexistent
key does produce an error message.


-- 
vq

Re: set -x vs. n=($@)

[Lawrence Velázquez]

On Sun, Sep 3, 2023, at 6:08 AM, Dan Jacobson wrote:
> please either say
> + m=$@
> + n=($@)
> or better:
> + m='a b c'
> + n=('a' 'b' 'c')
> or metion on 
> https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html 
> the special exception.

This behavior is not specific to $@.

bash-5.2$ a=foo
bash-5.2$ set -x
bash-5.2$ b=("$a")
+ b=("$a")

However...

bash-5.2$ declare -a c=("$a")
+ c=('foo')
+ declare -a c

-- 
vq

Re: Some incorrect behaviour for BASH arrays

[Lawrence Velázquez]

On Wed, Aug 30, 2023, at 2:12 PM, Victor Pasko wrote:
> Attached please find bug.bash to reproduce incorrect BASH behaviour for
> BASH arrays
> and look at ways to run it

Your tests are flawed.  The lines you use to inspect RESULT...

> badsed() { # just array indexes are used for RESULT
>   ...
>   echo -n "   result=$RESULT size=${#RESULT}"
>   echo " ${RESULT:0:$k}"
> }
>
> ...
>
> badrev() {
> ...
> if [ $i -ge $QSTRING ] ; then
> echo "XXX-break i=$i result=$RESULT size=${#RESULT}"
> break # XXX
> fi
>   done
>   echo "  result=$RESULT size=${#RESULT}"
> }

...are actually only inspecting element 0 of RESULT.  As per the
manual, "[r]eferencing an array variable without a subscript is
equivalent to referencing with a subscript of 0" [*].

Try using ''declare -p RESULT'' instead.

[*] https://www.gnu.org/software/bash/manual/html_node/Arrays.html

-- 
vq

Re: String replacement drops leading '-e' if replacing char is a space

[Lawrence Velázquez]

On Mon, Aug 14, 2023, at 1:27 AM, Eduardo Bustamante wrote:
> The echo command is consuming the '-e', as it is a flag.  Instead, try
> using:
>
>   printf '%s\n' "${x/,/ }"

Also note that echo wouldn't have consumed the "-e" had the expansions
been quoted properly (as Eduardo did in his printf example):

bash-5.2$ x='-e,b,c'
bash-5.2$ echo "${x//,/ }"
-e b c
bash-5.2$ echo "${x/,/ }"
-e b,c


-- 
vq

Re: ! history expansion occurs within arithmetic substitutions

[Lawrence Velázquez]

On Thu, Aug 10, 2023, at 2:21 PM, Dale R. Worley wrote:
> My understanding is that "interactive" directly affects only two things,
> the startup file(s) read and the initial values of various shell
> options.

There are more differences than that.

https://www.gnu.org/software/bash/manual/html_node/Interactive-Shell-Behavior.html

-- 
vq

Re: errexit is not respected on nested functions when parent function preceeds ||

[Lawrence Velázquez]

On Tue, Aug 8, 2023, at 12:04 PM, cirrus.mazurka-0t--- via Bug reports for the 
GNU Bourne Again SHell wrote:
> The following code:
>
> ``` bash
> #!/usr/bin/env bash
>
> set -Eeuo pipefail
> shopt -s huponexit
> shopt -s inherit_errexit
>
> function child_function {
>   return 1
> }
> function parent_function {
>   child_function
>   echo "parent noticed child exit code as $?"
> }
> function grandparent_function {
>   local ec
>   ec=0 && parent_function || ec="$?"

Commands in AND-OR lists are not subject to set -e, with the exception
of the final command.  So within this particular parent_function
call the failing child_function command does not cause an early
exit.  Instead, echo is run, and its exit status (0) becomes that
of parent_function.


>   echo "grandparent noticed parent exit code as $ec"
> }
>
> grandparent_function
> ```
>
> Will surprisingly output:
>
> ```
> parent noticed child exit code as 1
> grandparent noticed parent exit code as 0

This behavior may surprise you, but it is documented [1].  It also
conforms to POSIX [2] and is quite common:

[1]: https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
[2]: 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set

% cat foo.sh
set -e

child_function() {
return 1
}

parent_function() {
child_function
echo "parent noticed child exit code as $?"
}

grandparent_function() {
ec=0 && parent_function || ec="$?"
echo "grandparent noticed parent exit code as $ec"
}

grandparent_function

% bash foo.sh
parent noticed child exit code as 1
grandparent noticed parent exit code as 0
% ksh foo.sh 
parent noticed child exit code as 1
grandparent noticed parent exit code as 0
% mksh foo.sh
parent noticed child exit code as 1
grandparent noticed parent exit code as 0
% zsh foo.sh 
parent noticed child exit code as 1
grandparent noticed parent exit code as 0
% dash foo.sh
parent noticed child exit code as 1
grandparent noticed parent exit code as 0
% yash foo.sh
parent noticed child exit code as 1
grandparent noticed parent exit code as 0

(These are bash 5.2.15, ksh93u+ 2012-08-01, mksh R59 2020/10/31,
zsh 5.9, dash 0.5.11.5, and yash 2.54.)


> Changing the code to:
>
> ``` bash
> #!/usr/bin/env bash
>
> set -Eeuo pipefail
> shopt -s huponexit
> shopt -s inherit_errexit
>
> function child_function {
>   return 1
> }
> function parent_function {
>   child_function || return "$?"
>   echo "parent noticed child exit code as $?"
> }
> function grandparent_function {
>   local ec
>   ec=0 && parent_function || ec="$?"
>   echo "grandparent noticed parent exit code as $ec"
> }
>
> grandparent_function
> ```
>
> Returns the expected result of:
>
> ```
> grandparent noticed parent exit code as 1

This version of parent_function returns early, but not because of
set -e.  In fact, now *every* parent_function invocation exempts
child_function from set -e.

What exactly is the behavior you expect?


> Is there an additional setting that I need to set to fix this? Or is 
> this a bug in bash?

It is not a bug, and as far as I know there is no setting.

Here is some additional reading on set -e wrinkles:
https://mywiki.wooledge.org/BashFAQ/105
https://mywiki.wooledge.org/BashPitfalls#errexit


-- 
vq

Re: built-in printf returns success when integer is out of range

[Lawrence Velázquez]

> On Jul 26, 2023, at 5:14 PM, tho...@habets.se wrote:
> 
> On Wed, 26 Jul 2023 21:52:32 +0100, Dennis Williamson
>  said:
>> You didn't include all the output. It's treated as a warning rather than an
>> error. That's why an error status isn't set.
> 
> Ah indeed, the stderr message with bash builtin has the word
> "warning", whereas the Linux coreutils one does not[1].
> 
> Regardless, I do not believe this should be a warning, and instead
> that coreutils is doing the right thing, and bash is not.

POSIX.1-2017 seems to agree [1].  The printf specification states:

If an _argument_ operand cannot be completely converted
into an internal value appropriate to the corresponding
conversion specification, a diagnostic message shall be
written to standard error and the utility shall not exit
with a zero exit status, but shall continue processing any
remaining operands and shall write the value accumulated
at the time the error was detected to standard output.

The nonnormative "Application Usage" section elaborates:

If an argument cannot be parsed correctly for the corresponding
conversion specification, the _printf_ utility is required
to report an error.  Thus, overflow and extraneous characters
at the end of an argument being used for a numeric conversion
shall be reported as errors.

A recent austin-group-l discussion seems to concur as well [2].
(Full message forwarded below, if you don't want to follow the URL.)

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
[2] https://www.mail-archive.com/austin-group-l@opengroup.org/msg11409.html

-- 
vq



Begin forwarded message:

> From: "Geoff Clare via austin-group-l at The Open Group" 
> 
> Subject: Re: out-of-bounds numbers in shell utility arguments
> Date: June 26, 2023 at 4:49:45 AM EDT
> To: austin-grou...@opengroup.org
> Resent-From: austin-grou...@opengroup.org
> Resent-To: austin-grou...@opengroup.org
> Reply-To: Geoff Clare 
> 
> Thorsten Glaser wrote, on 24 Jun 2023:
>> 
>> what’s the POSIX mode behaviour expected when scripts attempt to
>> use overlong numbers in arguments e.g. to utilities (but possibly
>> anywhere in XSH)?
>> 
>> Say a script has on a 64-bit system:
>> 
>> test 2 -lt 
>> 
>> I found “1.1.2 Concepts Derived from the ISO C Standard” in XSH
>> Introduction, but that just says it should be signed long.
> 
> XCU 1.1.2 relates to utilities that "perform complex data manipulation
> using their own procedure and arithmetic languages".  So it applies to
> shell arithmetic expansion, but isn't really relevant to simple
> argument parsing by a utility.  For that, the relevant text is in XBD
> 12.1 Utility Argument Syntax, item 6.  This specifies ranges that must
> be "syntactically recognized as numeric values" and then says "Ranges
> greater than those listed here are allowed."
> 
> So the allowed behaviours are that either the utility syntactically
> recognises the argument as a numeric value or it doesn't.
> 
> If it doesn't, then it must report this as a syntax error.
> If it does, then its behaviour must be as described by the standard
> for the value that was recognised.
> 
>> So, is it:
>> 
>> • application error (the script writer is at fault, and the shell
>>  can do what it wants but should be consistent)
>> 
>> • unspecified behaviour (the shell can do as it wants but should
>>  be consistent); I really hope not C-level UB
>> 
>> • the utility or shell must detect this, while parsing the argument
>>  as number, erroring out
>> 
>> I’d hope for one of the first two because having wraparound semantics
>> is one of the guarantees for script writers I have in mksh for shell
>> arithmetics (not yet explicitly in the test(1) builtin).
> 
> It's somewhere between the second and third. It's unspecified whether
> the utility will report an error, but if it doesn't then it has to
> handle the value correctly, i.e. test 2 -lt  must
> exit with status 0 or status >1; it must not exit with status 1.
> 
> -- 
> Geoff Clare 
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
> 

Re: [PATCH] Add missing docs for 'set +o', 'set -o'

[Lawrence Velázquez]

On Wed, Jul 19, 2023, at 9:31 AM, Beer, Mathis wrote:
> On Tue, Jul 18, 2023, at 20:58:50 CEST, Lawrence Velázquez wrote:
>> Presumably the synopses in all locations should also use this:
>> 
>> -o [option-name]
>> +o [option-name]
>> 
>> --
>> vq
>
> Far as I can tell, they all already have it. It's just at the very bottom of 
> the 'set' option list, whereas the '+o'/'-o' docs are below the '-o' part.

I don't know what you're referring to.  The set(1) synopses all have

-o option-name
+o option-name

with "option-name" shown as a required option-argument.

-- 
vq

Re: [PATCH] Add missing docs for 'set +o', 'set -o'

[Lawrence Velázquez]

On Tue, Jul 18, 2023, at 9:29 AM, Beer, Mathis wrote:
> Add documentation for 'set -o', 'set +o' syntax to 'help set', 'info'.
> 'set -o'/'set +o' matches the POSIX behavior, but Bash's own documentation 
> should also mention it.
> Phrasing is copied from the manpage, which already mentions it.

Presumably the synopses in all locations should also use this:

-o [option-name]
+o [option-name]

-- 
vq

Re: '${#@}' expands to an integer

[Lawrence Velázquez]

On Wed, Jul 5, 2023, at 9:01 PM, Wiley Young wrote:
> Here's some code as observed "in the wild:"
>
>   `[[ ${#@} -ne 0 ]] && ...`
>
> Perhaps the parser is reading this as an incomplete parameter
> transformation? It seems from context that the original intent was simply...
>
>   `[[ $# -ne 0 ]] && ...`
>
> As it happens, the effect appears to be the same either way, but unless I'm
> missing something, as syntax ${#@} appears to be undefined.

That syntax is defined and documented.

${#parameter}

The length in characters of the expanded value of
parameter is substituted.  If parameter is '*' or
'@', the value substituted is the number of positional
parameters.

https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html

-- 
vq

Re: Document m=1 m=2; echo $m result

[Lawrence Velázquez]

On Sun, Jul 2, 2023, at 8:30 PM, Dan Jacobson wrote:
> man page says:
>
>A variable may be assigned to by a statement of the form
>
>   name=[value]
>
>If value is not given, the variable is assigned the null  string.   All
>values  undergo tilde expansion, parameter and variable
>expansion...
>
> OK, but do please mention somewhere that "if the variable is set more
> than once within the same statement, the final value is used."
>
> $ m=1 m=2;  echo $m
> #(Yes, acts the same as:)
> $ m=1; m=2; echo $m

This is stated under "Simple Command Expansion".

When a simple command is executed, the shell performs the
following expansions, assignments, and redirections, from
left to right, in the following order.

[...]

4.  The text after the = in each variable assignment undergoes
tilde expansion, parameter expansion, command substitution,
arithmetic expansion, and quote removal before being
assigned to the variable.

https://www.gnu.org/software/bash/manual/html_node/Simple-Command-Expansion.html

-- 
vq

Re: [BUG] Associative array initial reference name is made available in another context

[Lawrence Velázquez]

On Sat, Jul 1, 2023, at 3:55 PM, Top Dawn wrote:
> I believe there is a bug with associative arrays, when once referenced in
> another function through the -n option, both the new reference name and the
> old one are made available.
>
> ```bash
>
> #!/bin/bash
> function my_function(){
> declare -A my_array
> my_array=(["one"]="one")
> other_function "my_array"
> }
>
> function other_function(){
> declare -n other_array="${1-}"
> echo "${other_array["one"]}"
> echo "${my_array["one"]}"
> }
>
> my_function
>
> ```
>
> will output :
>
> ```bash
>
> one
> one
>
> ```
>
> I believe this to be a bug.

What makes you think so?  Variables are always visible in invoked
functions, unless you shadow them using local/declare/typeset.

% cat /tmp/foo.bash; echo
function my_function(){
declare -A my_array
my_array=(["one"]="one")
other_function
}

function other_function(){
echo "${my_array["one"]}"
}

my_function

% bash /tmp/foo.bash
one

-- 
vq

Re: Fwd: Command execution by creating file.

[Lawrence Velázquez]

On Tue, Jun 20, 2023, at 11:55 PM, LitHack wrote:
> Sorry instead of alias we have to use the function.

There is still no bug.  You simply do not understand how the shell
language works.

(There's nothing wrong with that, of course, and questions are
welcome at .  But your "bug reports" have all
been baseless.)

> Corrected command: mkdir dir;cd dir;<>file;file()bash;*

You didn't run these commands either.

bash-5.2$ mkdir dir
bash-5.2$ cd dir
bash-5.2$ <>file
bash-5.2$ file()bash
bash: syntax error near unexpected token `bash'

Please don't send broken code, forcing readers to waste their time
figuring out what you actually meant.  (This particular code is
easy to fix, but that's besides the point.)

-- 
vq

Re: Fwd: Command execution by creating file.

[Lawrence Velázquez]

On Tue, Jun 20, 2023, at 10:52 PM, LitHack wrote:
> -- Forwarded message -
> From: LitHack 
> Date: Wed, Jun 21, 2023, 7:31 AM
> Subject: Command execution by creating file.
> To: 
>
>
> Special character '*' can be used to execute the command.
> We have to just create a directory and make a file of any character or word
> and then make alias of the command which we want to execute assigned with
> created file. Now just type the * in terminal and you will that the command
> be executed.

This is not true.  Alias expansion occurs before filename expansion.

> But why this happens, * (special character) is used for auto completion and
> if used as alone it should just print the name of file why it's execute the
> file name as command.

This is not true either.  What makes you think that it should "just
print the name of file"?

> Command:mkdir dir;cd dir:<>file;alias file=ls -l;*

Did you actually run these commands?  They don't agree with you.

bash-5.2$ mkdir dir
bash-5.2$ cd dir
bash-5.2$ <> file
bash-5.2$ alias file='ls -l'
bash-5.2$ *
Usage: file [bcCdEhikLlNnprsvzZ0] [-e test] [-f namefile] [-F 
separator] [-m magicfiles] [-M magicfiles] file...
   file -C -m magicfiles
Try `file --help' for more information.

-- 
vq

Re: Crashing the Linux System

[Lawrence Velázquez]

> On Jun 16, 2023, at 11:39 PM, LitHack  wrote:
> 
> -- Forwarded message -
> From: LitHack 
> Date: Sat, 17 Jun 2023 at 08:52
> Subject: Crashing the Linux System
> To: 
> 
> 
> Running the yes command in command substitution will crash the linux shell.
> According to me inside command the substitution it is creating multiple
> process(fork).  Command: `yes` or $(yes)
> 
> Here is the bug report:
> Bug report 


You already posted this exact "bug report" to zsh-work...@zsh.org,
and the answer you got there applies here too: This is user error
and not a bug.


Begin forwarded message:

> From: Bart Schaefer 
> Subject: Re: Crashing the Linux System
> Date: June 17, 2023 at 12:43:02 AM EDT
> To: LitHack 
> Cc: zsh-work...@zsh.org
> 
> On Fri, Jun 16, 2023 at 8:38 PM LitHack  wrote:
>> 
>> Running the yes command in command substitution will crash the linux shell. 
>> According to me inside command the substitution it is creating multiple 
>> process(fork).  Command: `yes` or $(yes)
> 
> The "yes" command is defined to produce an unending stream of output.
> The $(...) substitution is defined to capture all the output from a
> command and substitute it as a string.  "All the output" of "yes" is
> impossible to capture in finite memory.  The error I get from zsh is
> the expected one:
> zsh: fatal error: out of heap memory
> There definitely are not multiple forks happening.
> 
> This is not a bug except in the sense that it was user error to use
> $(yes) in the first place.  It's no different than deliberately
> writing an infinite loop such as $(while true; do echo y; done).



-- 
vq

Re: `verb=(--) declare -ax verb` causes an ENOTSOCK segfault

[Lawrence Velázquez]

On Fri, Jun 16, 2023, at 1:02 AM, Wiley Young wrote:
> Description:
>`verb=(--) declare -ax verb` causes bash to crash and closes the active
> terminal tab.

The value "(--)" does not seem to be necessary:

% /bin/bash -c 'foo= declare -ax foo'
zsh: segmentation fault  /bin/bash -c 'foo= declare -ax foo'

I am seeing this behavior with bash 3.2.57, so it appears to be
longstanding.

-- 
vq

Re: The date command for time is incorrect

[Lawrence Velázquez]

On Sat, Jun 3, 2023, at 12:40 AM, Budi wrote:
> Why the date command for time is incorrect and different from the
> correct one on panel bar
>
> $ date +%H
> 04
>
> $ date +%I
> 04
>
> while the correct is on panel bar which is 11 (real in 0..24 form, i.e. AM)

Given this...

> Date: Sat, 3 Jun 2023 04:40:58 +

...it looks like something is forcing date(1) to use UTC.  Perhaps
you have the TZ environment variable set?

In any case this isn't really about bash.

-- 
vq

Re: IFS field splitting doesn't conform with POSIX

[Lawrence Velázquez]

On Sat, Apr 1, 2023, at 9:27 PM, Kerin Millar wrote:
> On Sat, 1 Apr 2023 19:44:10 -0400
> Saint Michael  wrote:
>
>> There is an additional problem with IFS and the command read
>> 
>> Suppose I have variable  $line with a string "a,b,c,d"
>> IFS=',' read -r x1 <<< $line
>> Bash will assign the whole line to x1
>>  echo $x1
>> line="a,b,c,d";IFS=',' read -r x1 <<< $line;echo $x1;
>> a,b,c,d
>> but if I use two variables
>> line="a,b,c,d";IFS=',' read -r x1 x2 <<< $line;echo "$x1 ---> $x2";
>> a ---> b,c,d
>> this is incorrect. If IFS=",", then a read -r statement must assign the
>
> No it isn't.
>
>> first value to the single variable, and disregard the rest.
>
> No it musn't. Read 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html 
> and pay particular attention to the definition of what must happen 
> where there are fewer vars (names) than fields encountered.

Also, observe the behavior of other shells:

% cat foo.sh
echo a,b,c,d | {
IFS=, read x1
printf '%s\n' "$x1"
}

echo a,b,c,d | {
IFS=, read x1 x2
printf '%s ---> %s\n' "$x1" "$x2"
}

% bash foo.sh
a,b,c,d
a ---> b,c,d
% dash foo.sh
a,b,c,d
a ---> b,c,d
% ksh foo.sh
a,b,c,d
a ---> b,c,d
% mksh foo.sh
a,b,c,d
a ---> b,c,d
% yash foo.sh
a,b,c,d
a ---> b,c,d
% zsh foo.sh
a,b,c,d
a ---> b,c,d

And the Heirloom Bourne shell:

b# echo a,b,c,d | { IFS=, read x1; printf '%s\n' "$x1"; 
}; echo a,b,c,d | { IFS=, read x1 x2; printf '%s ---> %s\n' "$x1" "$x2"; }
 a,b,c,d
 a ---> b,c,d

-- 
vq

Re: IFS field splitting doesn't conform with POSIX

[Lawrence Velázquez]

> On Apr 1, 2023, at 8:49 PM, Felipe Contreras  
> wrote:
> 
> On Sat, Apr 1, 2023 at 6:35 PM Lawrence Velázquez  wrote:
>> 
>> On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
>>> In that example they are discussing whether or not to make that
>>> behavior a *requirement*. That is prescriptive.
>> 
>> You're so busy pretending this is debate club that you're completely
>> missing everyone's point, which is that the Austin Group by and
>> large aims to standardize existing behavior.
> 
> I did not miss your point, you are missing mine


Begin forwarded message:

> From: Emanuele Torre 
> Subject: Re: IFS field splitting doesn't conform with POSIX
> Date: March 30, 2023 at 1:48:54 PM EDT
> To: Felipe Contreras 
> Cc: bug-bash@gnu.org
> 
> On Thu, Mar 30, 2023 at 11:35:08AM -0600, Felipe Contreras wrote:
>>> How can you say that the current implementation that bash, dash, etc.
>>> use is not compliant to the POSIX specification?
>> 
>> I have never said that.
> 
> The title of this thread is "IFS field splitting doesn't conform with
> POSIX".


-- 
vq

Re: IFS field splitting doesn't conform with POSIX

[Lawrence Velázquez]

On Sat, Apr 1, 2023, at 8:02 PM, Felipe Contreras wrote:
> In that example they are discussing whether or not to make that
> behavior a *requirement*. That is prescriptive.

You're so busy pretending this is debate club that you're completely
missing everyone's point, which is that the Austin Group by and
large aims to standardize existing behavior.  If a situation arises
where many implementations are not conformant, then the standard
is flawed, and it is wrongheaded to blame the implementations.

-- 
vq

Re: IFS field splitting doesn't conform with POSIX

[Lawrence Velázquez]

On Fri, Mar 31, 2023, at 2:10 PM, Chet Ramey wrote:
> kre filed an interpretation request to get the language cleaned up.

For those who might be interested:

https://austingroupbugs.net/view.php?id=1649

-- 
vq

Re: IFS field splitting doesn't conform with POSIX

[Lawrence Velázquez]

On Thu, Mar 30, 2023, at 2:25 PM, Felipe Contreras wrote:
> On Thu, Mar 30, 2023 at 11:48 AM Oğuz İsmail Uysal
>  wrote:
>>
>> On 3/30/23 7:51 PM, Felipe Contreras wrote:
>> > So? This is argumentum ad populum. The fact that most shells do X
>> > doesn't imply that POSIX says X.
>
>> POSIX documents existing practice.
>
> Your definition of what a standard is and mine are very different then.

The Austin Group itself largely disagrees with your position.


> In my view if POSIX was merely descriptive, then the Austin Group
> would have no need to discuss much, as it's fairly easy to describe
> what current shells do.

Composing technical specifications that describe implementations'
shared behaviors while allowing for their idiosyncrasies is more
involved than you seem to think.


> The challenge is in deciding what they *should* do, which is not
> descriptive, but prescriptive.

The Austin Group does not see its role as prescriptive, although
during discussions implementers are often open to modifying their
implementations to achieve consensus.  If many implementers agree
to make a change, the result may appear prescriptive.  (A recent
example is .)


>> If what it says differs from what the majority of shells do, then it's
>> POSIX that is wrong.
>
> Then there is no point in looking at the standard, since we know what
> it should say

The standard is a reference that describes a set of broadly common
behaviors.  Not everyone is interested in researching and testing
an assortment of implementations whenever they want to determine
whether a behavior is portable.

(Also: bash, dash, ksh, and zsh are not the only shells that exist.)


> and there's no point in discussing about what it does actually say.

You miss every shot you don't take.

https://www.opengroup.org/austin/lists.html


-- 
vq

Re: Bash not portable to C23

[Lawrence Velázquez]

On Thu, Mar 23, 2023, at 9:16 PM, Paul Eggert wrote:
> I see that Bash won't compile with a C23 compiler, since it still uses 
> old-style function definitions which C23 no longer supports. Is there 
> any effort and/or interest in fixing this portability problem in Bash?

I believe this was done a few months ago on the devel branch.

https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=a61ffa78ede6df4d1127fddd2e8a1a77a7186ea1

-- 
vq

Re: Vulnerability Report(No SPF Record)

[Lawrence Velázquez]

On Sun, Mar 5, 2023, at 1:33 AM, Syed Maaz wrote:
> Would you be so kind as to provide an update regarding my reported bug?

As previously mentioned, this mailing list is not responsible for
bash-hackers.org.  Consider availing yourself of the contact form
on the website:

https://wiki.bash-hackers.org/#contact

> Kindly inform me if my reported issue has been validated and bug bounty 
> reward is given to me for my responsible disclosure.

A bit presumptuous to request a bug bounty when no bug bounty has
been offered, don't you think?

-- 
vq

Re: 'exec -a' and $0 substitution

[Lawrence Velázquez]

On Wed, Jan 25, 2023, at 6:37 PM, Sergei Trofimovich wrote:
> I fear it's a side-effect of the way 'bash' gets executed via shebang by
> kernel. But maybe not? Somehow direct script execution still manages to
> preserve script's name. Is it an intended behaviour that could not be
> easily changed? Or it's a bug?

It's not a bug.

https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html#index-0

0
($0)  Expands to the name of the shell or shell
script.  This is set at shell initialization.  If
Bash is invoked with a file of commands (see Shell
Scripts), $0 is set to the name of that file.  If
Bash is started with the -c option (see Invoking
Bash), then $0 is set to the first argument after
the string to be executed, if one is present.
Otherwise, it is set to the filename used to invoke
Bash, as given by argument zero.

Whenever bash is executed with a script file, it sets $0 to the
name of that file.  It only uses caller-provided values for $0 when
a script file is not provided.

$ (exec -a foo bash <<<'echo "$0"')
foo
$ (exec -a foo bash -s bar baz quux <<<'echo "$0"')
foo
$ (exec -a foo bash -c 'echo "$0"')
foo
$ (exec -a foo bash -c 'echo "$0"' bar baz quux)
bar

This behavior is standardized in POSIX [*] and is not unique to
bash (I omitted ksh93, which actually does produce "foo" here).

$ (exec -a foo zsh <(echo 'echo "$0"'))
/dev/fd/63
$ (exec -a foo dash <(echo 'echo "$0"'))
/dev/fd/63
$ (exec -a foo yash <(echo 'echo "$0"'))
/dev/fd/63
$ (exec -a foo mksh <(echo 'echo "$0"'))
/dev/fd/63

[*]: 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_05

-- 
vq

Re: curiosity: 'typeset -xr' vs. 'export -r'

[Lawrence Velázquez]

On Tue, Dec 13, 2022, at 6:38 AM, Emanuele Torre wrote:
> On Tue, Dec 13, 2022 at 03:07:16AM -0500, Lawrence Velázquez wrote:
>> Of course not.  I only meant to demonstrate that "export" always
>> creates global variables, so a function that utilizes "declare -gx"
>> actually behaves more like "export" then your alias does.
>
> This is a little inaccurate.
>
> `export' doesn't always act on the *global* variable, but "declare -g"
> does.
>
> The differences are that:
>  * `declare' (without -g), always acts on variables in the current
>dynamic scope, and will create a new variable in the current dynamic
>scope if no variable with the name it was looking for exists.
>
>  * `export' and `readonly' act on the variable they can see, and set
>their "x"/"r" attribute; they will only create a new variable (in the
>global scope) if no variable with the name they were looking for
>exists in any dynamic scope. Just like simple "a=b" assignments.

You're right, thanks for clarifying.  I was thinking exclusively
about the behavior when creating variables.

-- 
vq

Re: curiosity: 'typeset -xr' vs. 'export -r'

[Lawrence Velázquez]

On Mon, Dec 12, 2022, at 4:43 AM, L A Walsh wrote:
> On 2022/12/11 20:47, Lawrence Velázquez wrote:
>> This happens because "declare"/"typeset" creates local variables
>> within functions.  Using -g works around this...
>>
>>  $ Export() { declare -gx "$@"; }
>>  $ Export -r foo=1
>>  $ declare -p foo
>>  declare -rx foo="1"
>>
>> ...but now "Export" always creates global variables, rather than
>> scoping as "declare" and your alias-based version does.  On the
>> other hand, "export" also creates global variables, so in a sense
>> the workaround version is more consistent.
>>
>>  $ f() { export "$@"; }
>>  $ f var=1
>>  $ declare -p var
>>  declare -x var="1"
>>   
> 
> I see, but you still can't use "-r" w/export

Of course not.  I only meant to demonstrate that "export" always
creates global variables, so a function that utilizes "declare -gx"
actually behaves more like "export" then your alias does.


> though I think the -r flag would get dropped in any exported shell

The environment does not propagate the readonly attribute, no.


> though
> in that case, one might expect an error if one uses "typeset -xr"
> along the lines of "-r flag won't be exported".

The readonly attribute is still applied to the original shell
variable, so there's no reason to produce an error.


> Side curious: If one uses -g, does it cause the var to be defined
> in all intervening functions as well as the top(global)
> and current scope?

It defines a global variable, which is then visible to all functions.


-- 
vq

Re: curiosity: 'typeset -xr' vs. 'export -r'

[Lawrence Velázquez]

On Sun, Dec 11, 2022, at 9:37 PM, L A Walsh wrote:
> I suppose one could create an alias (despite advice that
> functions are "better" -- in this case a function doesn't work).
> I'm using ':;' for PS1, so cut/paste works:
>
>   PS1=':; '
>
> :; Export () {
> :;   typeset -x "$@"
> :; }
> :; Export -r foo_xr=1
>
> :; typeset -p foo_xr
> -bash: typeset: foo_xr: not found

This happens because "declare"/"typeset" creates local variables
within functions.  Using -g works around this...

$ Export() { declare -gx "$@"; }
$ Export -r foo=1
$ declare -p foo
declare -rx foo="1"

...but now "Export" always creates global variables, rather than
scoping as "declare" and your alias-based version does.  On the
other hand, "export" also creates global variables, so in a sense
the workaround version is more consistent.

$ f() { export "$@"; }
$ f var=1
$ declare -p var
declare -x var="1"

-- 
vq

Re: [EXT] Re: declare XXX=$(false);echo $?

[Lawrence Velázquez]

On Mon, Dec 5, 2022, at 2:47 AM, Ulrich Windl wrote:
> So basically the behavior is as documented (not a bug), but the design
> decision was poor:
>
>   declare a
>   a=b
>
> has a different semantic as
>   declare a=b
>
> which I consider to be bad.

You're free to think so, but this behavior is ubiquitous among
Bourne-adjacent shells and is not about to change.

% cat foo.sh
export foo=$(false)
echo "$?"

% bash foo.sh
0
% ksh foo.sh 
0
% zsh foo.sh
0
% dash foo.sh
0
% yash foo.sh
0

-- 
vq

Re: [EXT] Re: manual page missing ${parameter-replacement}

[Lawrence Velázquez]

On Tue, Nov 22, 2022, at 2:20 AM, Ulrich Windl wrote:
> AFAIK, bold means "literal" and non-bold or specifically italics means
> "placeholder".
> From man-pages(7):
>
> "(...) boldface is used for as-is text and italics are used to indicate
> replaceable arguments.   Brackets ([]) surround optional arguments,
> vertical bars (|) separate choices, and ellipses (...) can  be  repeated.
> (...)"

Again, you have omitted relevant context.  That excerpt is from
a section of man-pages(7) that discusses synopses.  We are not
talking about a man page synopsis.

The "Parameter Expansion" section of bash(1) simply does not use
boldface for "${" / "}".  I don't know if that is intentional, but
I would guess that only the unique portions of each expansion form
are emphasized with boldface.  Setting every "${" / "}" in boldface
too would dilute that emphasis significantly.

-- 
vq

Re: [EXT] Re: manual page missing ${parameter-replacement}

[Lawrence Velázquez]

On Mon, Nov 21, 2022, at 4:38 AM, Ulrich Windl wrote:
> But from the syntax "${parameter:-word}" it's not really obvious that the
> colon may be omitted.

You're not wrong.

> Should it be "${parameter[:]-word}" (with non-bold square brackets) instead
> (as for "name=[value]")?

No, that would be extremely confusing.  But I think something like
this has been suggested before (I don't remember by whom):

${parameter-word}
${parameter:-word}
Use Default Values.  [...]
${parameter=word}
${parameter:=word}
Assign Default Values.  [...]
${parameter?word}
${parameter:?word}
Display Error if Null or Unset.  [...]
${parameter+word}
${parameter:+word}
Use Alternate Value.  [...]

> Despite of that only ":-" is typeset in bold; shouldn't "${" and "}" be
> typeset in bold, too?

I don't know.  It seems like boldface is used to highlight the parts
that are unique to each form.

-- 
vq

Re: manual page missing ${parameter-replacement}

[Lawrence Velázquez]

On Mon, Nov 21, 2022, at 2:20 AM, Ulrich Windl wrote:
> I think the bash manual page lacks some important detail of parameter 
> substitution, namely:
> "Bash tests for a parameter that is unset or null. Omitting the colon 
> results in a test only for a parameter that is unset."
>
> (found in 
> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)

You omitted all of the relevant context.  The full paragraph is:

When not performing substring expansion, using the form [sic]
described below (e.g., ':-'), Bash tests for a parameter
that is unset or null.  Omitting the colon results in a
test only for a parameter that is unset.  Put another way,
if the colon is included, the operator tests for both
_parameter_'s existence and that its value is not null; if
the colon is omitted, the operator tests only for existence.

The manual then goes on to describe the ${parameter:-word},
${parameter:=word}, ${parameter:?word}, and ${parameter:+word}
forms.  These are what your excerpt is talking about.

So what do you think is missing, exactly?

-- 
vq

Re: feature request: new builtin `defer`, scope delayed eval

[Lawrence Velázquez]

On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote:
> 2022年10月8日(土) 12:04 Cynthia Coan :
>> [...]
>>
>> Otherwise, I think we can perhaps reword this into two smaller
>> features: "function local trap signals",
>
> The existing RETURN trap is exactly the trap that can be used to clean
> up resources local to functions and is already ``function-local''
> unless the user changes its behavior by setting `declare -ft', `set
> -T', or `shopt -s extdebug'. One thing to note is that the RETURN trap
> should be cleaned up inside the RETURN trap itself by running `trap -
> RETURN', or otherwise the RETURN trap is erroneously considered by
> Bash to be set for the caller function.

The latter behavior is why I didn't describe RETURN as function-local
in my earlier message, but I forgot the workaround of unsetting
the trap from within itself.  Nice.

>> and "options to safely
>> append/prepend to a trap" (for some definition of 'safe', perhaps this
>> just means separating by ';'?
>
> Currently, there is no way to register multiple handlers to a trap in
> a safe way, but if you can accept the approach by `;' or newline, you
> can just do it by getting the current trap string with `trap -p
> RETURN' and then overwrite the trap with the adjusted trap string.

Another strategy is to construct the complete trap string before
setting the trap, using whichever concatenation methods are preferred:

f() {
local trapcmds=cleanup
if something; then
trapcmds+='; more_cleanup'
else
trapcmds+='; so_fresh_and_so_clean'
fi
trap "$trapcmds; trap - RETURN" RETURN

rest_of_function
}

-- 
vq

Re: feature request: new builtin `defer`, scope delayed eval

[Lawrence Velázquez]

On Thu, Oct 6, 2022, at 4:08 PM, Cynthia Coan wrote:
> I'd specifically like to propose a new built-in called `defer` which
> acts like `eval` however is not parsed/expanded/run until it's scope
> is leaving.  Hopefully "scope" is the correct word, I'm imagining it
> running at the same time a local would go out of "scope" and be no
> longer available (just before the locals are cleared, so locals can
> still be used in expansion).

I think it would be more natural to implement function-local RETURN
and EXIT traps than introduce a second command that looks like
'trap' and quacks like 'trap' but is actually not 'trap'.  This
could be done generically by adding the ability to "scope" traps
to functions (possibly via a new option to 'trap' or a shopt à la
zsh's LOCAL_TRAPS) or specifically by creating "local" variants of
RETURN and EXIT.  Usage might look like this:

f() {
# new option
trap -f 'cleaning up' EXIT RETURN
cmd1
cmd2
cmd3
}

or this:

g() {
# new traps
trap 'cleaning up' EXIT_LOCAL RETURN_LOCAL
cmdA
cmdB
cmdC
}

-- 
vq

Re: Light weight support for JSON

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 9:24 AM, Yair Lenga wrote:
> Wanted to get feedback about the following "extensions" to bash that will
> make it easier to work with simple JSON object.

It occurred to me to provide references for previous discussion
along these lines, but it turns out there isn't very much of it.
This is the most concrete example I found:

https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00046.html

-- 
vq

Re: Light weight support for JSON

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 4:05 PM, G. Branden Robinson wrote:
> At 2022-08-28T15:52:55-0400, Lawrence Velázquez wrote:
>> On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
>> > How about next July, when JSON is as exactly old as the Bourne shell
>> > was when JSON was deployed?
>> 
>> I do not find "well *actually* JSON is old too!!!" to be particularly
>> persuasive, either.
>
> It's a perfectly valid rejoinder to a claim that the format is too novel
> to be seriously considered.  That you don't regard it as persuasive is
> consistent with your protest not being a rational one in the first
> place

Agree to disagree.

-- 
vq

Re: Light weight support for JSON

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 2:56 PM, G. Branden Robinson wrote:
> At 2022-08-28T14:11:25-0400, Lawrence Velázquez wrote:
>> I do not think bash needs to sprout functionality to support every
>> data-exchange format of the month.
>
> This sentiment is illustrative of the logarithmic memory scale of
> grognards.  The Bourne shell was first released as part of Version 7
> Unix in January 1979.[1]  22 years and three months later, in April
> 2001, Douglas Crockford and Chip Morningstar sent the first JSON
> message.[2]
>
>> A loadable module might be okay, I guess.
>
> How about next July, when JSON is as exactly old as the Bourne shell was
> when JSON was deployed?

I do not find "well *actually* JSON is old too!!!" to be particularly
persuasive, either.

I should have foreseen that the offhand "of the month" jab would
get undue attention compared to my actual objection, which is against
giving one data format uniquely first-class support.  That's on me.

>> Why are people so allergic to just using specific utilities for
>> specific tasks, as appropriate?  (This question is rhetorical.
>> Please do not respond with an impassioned plea about why JSON is
>> so special that it deserves first-class shell support.  It's not.)
>
> I won't litigate this point, but your concept of novelty is distorted
> beyond any standard reasonable in the computer industry.  If we are only
> as young as we feel, you must feel geriatric in the extreme.

Sick burn, pal.  Excuse me while I take out my dentures or whatever.

-- 
vq

Re: Light weight support for JSON

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 2:29 PM, Yair Lenga wrote:
> I do not think that JSON (and REST) are "data exchange format of the
> month". Those are established formats that are here to stay. Like YAML.
> Those are "cornerstones" of cloud computing/configuration. I do not have to
> argue for them, they can speak for themselves.

You *do* have to argue why a shell should provide first-class support
for them, or for any concrete data format.  Shells exist on a much
longer time scale than anything you've been talking about and are
used in essentially every conceivable computing context.  "I think
JSON is *extra-special* important though" is not a reason why the
shell itself should give it special attention.

> As for using external utilities: two main issues:
> * Performance - Processing data in bash processes can be 100X times faster
> than using external tools. The fork/exec is expensive.

And?  Are you running jq 100,000 times in a tight loop?

> * Readability - Each tool has its own syntax, escapes, etc. The final
> result of mixing JQ and bash is not pretty (just lookup jq/bash questions
> on stack overflow)

Neither is your example.  Bash's "type system" (as it were) cannot
fully represent all JSON objects, so you're going to end up with
some sort of gross approximation regardless.

> Having them as a loadable extension seems like a good practical solution.
> They do not have to be "built-in".

The "csv" loadable provides some precedent for this.  It won't solve
the representation problem, though.

-- 
vq

Re: bug-bash Digest, Vol 237, Issue 30

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 1:17 PM, Yair Lenga wrote:
> Yes, you are correct - (most/all of) of those examples "K".
>
> However, given bash's important role in modern computing - isn't it time to
> take advantage of new language features ?

Why?  What benefit would that actually provide?

> this can make code more readable,
> efficient and reliable.

In practice, there's only person who really interacts with bash
code.  If he doesn't think there's a problem with K style, then
it's not going to change.

> I doubt that
> many users are trying to install a new bash in a system that was
> built/configured 15 years ago.

You might be surprised.

-- 
vq

Re: Light weight support for JSON

[Lawrence Velázquez]

On Sun, Aug 28, 2022, at 9:24 AM, Yair Lenga wrote:
> Wanted to get feedback about the following "extensions" to bash that will
> make it easier to work with simple JSON object. To emphasize, the goal is
> NOT to "compete" with Python/Javascript (and other full scale language) -
> just to make it easier to build bash scripts that cover the very common use
> case of submitting REST requests with curl (checking results, etc), and to
> perform simple processing of JSON files.

I do not think bash needs to sprout functionality to support every
data-exchange format of the month.  A loadable module might be okay,
I guess.

Why are people so allergic to just using specific utilities for
specific tasks, as appropriate?  (This question is rhetorical.
Please do not respond with an impassioned plea about why JSON is
so special that it deserves first-class shell support.  It's not.)

-- 
vq

Re: cut loadable outputs extra newlines

[Lawrence Velázquez]

On Sat, Aug 13, 2022, at 10:06 PM, Martin D Kealey wrote:
> I note that
> https://pubs.opengroup.org/onlinepubs/009696699/utilities/cut.html says:
> *> The elements in list can be repeated, can overlap, and can be specified
> in any order, but the bytes, characters, or fields selected shall be
> written in the order of the input data.*
>
> The intention behind this is so that cut can be implemented as a small
> state machine using just getchar, putchar, and a counter. This avoids
> copying via a line buffer, and that implies there should be no line-length
> limit.

That is explicitly required:

INPUT FILES

The input files shall be text files, except that line lengths
shall be unlimited.

-- 
vq

Re: How come math/arithmetic cannot work by set -x

[Lawrence Velázquez]

On Fri, Aug 12, 2022, at 7:40 PM, Dennis Williamson wrote:
> It works for me. What are you expecting?
>
> It would help if you show what you're doing, the result you're getting and
> what you expect instead.

I'm guessing that instead of, for example

% bash -xc 'a="(x=1)" b="2*3"; ((a+b))'
+ a='(x=1)'
+ b='2*3'
+ (( a+b ))

they want something like

% bash -xc 'a="(x=1)" b="2*3"; ((a+b))'
+ a='(x=1)'
+ b='2*3'
+ (( a+b ))
+ (( (x=1)+2*3 ))
+ (( 1+6 ))
+ (( 7 ))

or whatever.  Who knows.

-- 
vq

Re: local -r issue in conjunction with trap

[Lawrence Velázquez]

On Fri, Jul 15, 2022, at 7:06 PM, Koichi Murase wrote:
> 2022年7月16日(土) 7:28 Lawrence Velázquez :
>> You can't shadow a readonly variable:
>>
>> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00152.html
>> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00153.html
>> https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00201.html
>> https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00204.html
>
> We can shadow local readonly variables. What we cannot are global
> readonly variables.

Hm, you are right.  I thought I'd tested that, but I must have done
it wrong.


> It seems to me a bug. While the following works,
>
> $ bash-dev -ec 'T(){ local -r v=; }; trap T 0; F() { local -r v=; exit; }; F'
>
> the following fails
>
> $ bash-dev -e <<< 'T(){ local -r v=; }; trap T 0; F() { local -r v=; exit; }; 
> F'
> main: line 1: local: v: readonly variable
>
> Tested on the current devel 87a6e89e (+ define(relstatus, release) in
> configure.ac)

Same with 5.1.16.  It also fails when run as a script file:

% cat /tmp/foo.bash
set -e

T() {
local -r v=
}

trap T 0

F() {
local -r v
exit
}

F
% bash /tmp/foo.bash
/tmp/foo.bash: line 4: local: v: readonly variable


-- 
vq

Re: local -r issue in conjunction with trap

[Lawrence Velázquez]

On Fri, Jul 15, 2022, at 6:26 PM, Lawrence Velázquez wrote:
> it's worth noting that the trap command runs in the context
> from which the shell exits

Sorry, this might not be clear.  Here I am referring to the command
that is provided as the argument to the "trap" utility.

> not the context in which the trap is set.

And here I am referring to the invocation of the "trap" utility
itself.

-- 
vq

Re: local -r issue in conjunction with trap

[Lawrence Velázquez]

On Fri, Jul 15, 2022, at 12:13 PM, Robert Stoll wrote:
> Following a script to reproduce the problem: 
>
> =
>
> #!/usr/bin/env bash
> set -e
>
> function trapHook(){
>   echo "$1"
>   local -r readonlyVar=$1
> }
>
> function test1(){
>   local -r readonlyVar=2
>   trap 'trapHook $readonlyVar' EXIT
> }
> function test2(){
>   local -r readonlyVar=2
>   trap 'trapHook $readonlyVar' EXIT
>   exit 0
> }
> test1 # works as exit happens outside of test1
> test2 # fails with ./src/test.sh: line 6: local: readonlyVar: readonly 
> variable

You can't shadow a readonly variable:

https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00152.html
https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00153.html
https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00201.html
https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00204.html

The trap is incidental -- you can observe the same behavior without
it -- but it's worth noting that the trap command runs in the context
from which the shell exits, not the context in which the trap is
set.

What do you think the bug is, exactly?  How do you think this should
behave?

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Tue, Jul 5, 2022, at 8:09 PM, Yair Lenga wrote:
> My opinion is that we should be looking at the expected behavior - for 
> a developer that want to implement ”strong”  error handling: any error 
> will break execution until explicitly handled. In the same spirit as 
> the ‘try … catch’ that from JavaScript, python, groovy, etc.
>
> [...]
>
> I think that all four cases, while each one matches different existing 
> bash command(s) (break, return, and ‘unwind’, and return+break) are 
> consistent with the accepted / expected pattern for try … catch, and 
> most developers will understand how to use it.

My opinion is that this notion of error handling is fundamentally
unsuitable for *nix shell programming and that it mostly just
cultivates a broken understanding of how to write shell scripts.
If it were up to me I would dismiss this proposal as flawed in its
very conception, but I'm just some rando who has too much time to
write emails and whose opinion should, by rights, hold less weight
than average.


> Hope it make sense. In any case, I would like to ask for some time 
> until additional community input/comments are sorted out. While the 
> final result may be different from where we started, I hope it will be 
> better.

You have plenty of time.  Things move deliberately here.

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Tue, Jul 5, 2022, at 6:34 PM, Yair Lenga wrote:
> I probably did not described the intended behavior clearly. I believe 
> both cases should behave identical under errfail. The loop will ‘break’ 
> on the first iteration (false when word = a). Same for the all looping 
> commands. I believe this is consistent with if-then-else-if, when an 
> error in the then or else block will result in terminating (‘breaking’) 
> the if. 

It's only consistent if your notion of consistency is "terminate
all compound commands immediately".  This kind of works for "if"
but changes "for" and "while" in a very fundamental way.  Your
initial description of "treat a; b; c like a && b && c" implies
that

if condition; then a; b; c; fi

should behave like

if condition; then a && b && c; fi

and

for word in words; do a; b; c; done

should behave like

for word in words; do a && b && c; done

but it turns out what you apparently want is

for word in words; do a && b && c || ! break; done

which is a larger change than you let on.

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Tue, Jul 5, 2022, at 5:18 PM, Yair Lenga wrote:
> I’m not in front of my desktop, so I can not verify behavior, but here 
> is my expectation - let me know if it make sense, in the context of the 
> project goal - every unhandled failed statement should unwind execution 
> up, until explicitly handled.

But you've said that this won't apply to the topmost level, so
you've already introduced a distinction between that level and every
other level, which will have to be explained.


>> if false ; echo Foo ; [[ notempty ]] ; then echo Full ; else echo Empty ; fi 
>> || echo Fail
>> 
> Output: Empty
> If false … should fail on the first false, going to the else part, 
> printing Empty. Since the ‘echo empty’ succeeded, Fail will not be 
> printed.
>
>> or
>> 
>> if { false ; echo Foo ; [[ notempty ]] ; } ; then echo Full ; else echo 
>> Empty ; fi || echo Fail
>> 
> Output: Empty
> Same as above. Grouping does not change behavior.
>> or
>> 
>> if ( false ; echo Foo ; [[ notempty ]] ) ; then echo Full ; else echo Empty 
>> ; fi || echo Fail
>> 
> Output: empty
> Same as above. Running in a subshell does not change behavior.
>> or 
>> 
>> for x in a b ; do if false ; echo Foo ; [[ notempty ]] ; then echo Bar ; 
>> else echo Empty ; fi ; done
> Output: Empty (for a), Empty (for b)
> Since the if statement succeed, the code will flow to from the first 
> iteration to the second iteration. 

In a nutshell, you are proposing that this:

set -o errfail
if false; true; then cmd1; else cmd2; fi

...should behave like this:

if false; then cmd1; else; cmd2; fi

Okay, but...


> The last case has interesting variant: the case when the loop body fail 
> (for x in a b ; do echo $x ; false ; done.
> Output: a
> In this case, the code failed body will result in effective ‘break’ to 
> the loop, where the whole for statement will fail. I believe this case 
> is not currently covered in the implementation (2 or 3 lines to cover 
> each of the loop constructs: for (list, arithmetic), until and while.

...now you are applying different logic to "for" commands.  You
want this to stop iterating:

set -o errfail
for word in a b c; do false; true; done

...which is NOT what this does:

for word in a b c; do false; done

Yet another inconsistency that will have to be explained.

Contrary to your pitch, this option is shaping up to be about as
incoherent as errexit.  You should heed the suggestion to iron out
the semantics.


-- 
vq

Re: Alias appends space character to end of non-latin string

[Lawrence Velázquez]

On Fri, Jul 1, 2022, at 4:07 AM, Vangelis Natsios wrote:
> When creating an alias containing a path ending with a non-latin (e.g.
> greek) directory name, a space character is appended to the end of the
> path, causing the alias to fail.

Not quite: Neither "paths" nor "non-Latin" characters are necessary,
and the space seems to be added at expansion, not definition.

bash-5.1$ echo "$BASH_VERSION"
5.1.16(1)-release
bash-5.1$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
bash-5.1$ alias a1='printf "<%s>\\n" áa'
bash-5.1$ a1
<áa>
bash-5.1$ alias a2='printf "<%s>\\n" aá'
bash-5.1$ a2

bash-5.1$ alias a1 a2
alias a1='printf "<%s>\\n" áa'
alias a2='printf "<%s>\\n" aá'

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Tue, Jul 5, 2022, at 7:01 AM, Yair Lenga wrote:
> Below is the patch for the new 'errfail' option.

This doesn't apply cleanly to "devel".  I assume you made it against
"master", which isn't the development branch -- "devel" is.  Sorry
I forgot to mention that earlier.


-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Mon, Jul 4, 2022, at 3:55 PM, Yair Lenga wrote:
> I'm sorry - I misunderstood your original comments. I'll prepare the
> patched version (at least, I would like to add comments before
> publishing...) , and share it.
> Where/how can I post it ?

Send it to this list as an attachment [1] with a .txt suffix [2].

[1] Gmail will mangle the patch if you send it inline.
[2] Alleviates issues with clients on the receiving end.

> I did not see anyone else dropping source
> code/patches into the group ?

Code contributions are not as common as you might think, given
bash's prominence.

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Mon, Jul 4, 2022, at 2:33 PM, Yair Lenga wrote:
> Thanks for taking the time to review my post. I do not want to start a
> thread about the problems with ERREXIT.

Neither do I.

> Instead, I'm trying to advocate for
> a minimal solution.
>
> [...]
>
> Please take a look at the specific short example that I listed (below).
> I believe fair summary is the the behavior defined by the POSIX spec is
> less than ideal.
>
> #! /bin/bash
> set -e
> function foo { echo BEFORE ; false ; echo AFTER ; }
> foo || echo FAIL
>
> Where the expected output is "BEFORE ... FAILED, but actual output is
> "BEFORE ... AFTER". The root cause is the way "errexit" (-e) is handled in
> functions, statements-lists, ... when combined with control statements (if,
> while, &&, ...).

So what does your proposed option actually *do*?  You're continuing
to provide examples of changed behavior, instead of explicitly
*describing the changes*.

If you don't understand what I'm asking for, just send a patch.

> As for my question about code being accepted - I'm trying to figure out if
> the bash development team is open to outside contributions. Some projects
> are not open to contribution. If bash is open to contribution, I'll prepare
> the code for submission/review (style, comments, test cases, ...) as
> needed.

The "development team" is one person.  (That person isn't me, to
be clear.)  He's not averse to outside contributions, but there's
no guarantee that he'll agree with your goal in the first place.

Again, you might as well send what you have without worrying too
much about polishing it.  You can always submit refinements later.

-- 
vq

Re: Revisiting Error handling (errexit)

[Lawrence Velázquez]

On Mon, Jul 4, 2022, at 8:20 AM, Yair Lenga wrote:
> I was able to change Bash source and build a version that supports the new
> option 'errfail' (following the 'pipefail' naming), which will do the
> "right" thing in many cases - including the above - 'foo' will return 1,
> and will NOT proceed to action2. The implementation changes the processing
> of command-list ( '{ action1 ; action2 ; ... }') to break of the list, if
> any command returns a non-zero code, that is
>
> set -oerrfail
> { echo BEFORE ; false ; echo AFTER ; }
>
> Will print 'BEFORE', and return 1 (false), when executed under 'errfail'

This is already how errexit behaves in most contexts.

% bash -ec '{ echo BEFORE; false; echo AFTER; }'; echo "$?"
BEFORE
1

So what did you actually change?  Presumably you tweaked the special
treatment given to the conditional portion of "if" commands, but
we shouldn't have to guess.

> I'm looking for feedback on this implementation. Will be happy to share the
> code if there is a chance that this will be accepted into the bash core
> code

I don't think there's a chance unless you share the code first.
Your description is wholly inadequate for understanding the true
nature of your proposal.

-- 
vq

Re: [PATCH] fix COMP_WORDS when completing an empty word

[Lawrence Velázquez]

On Mon, Jun 20, 2022, at 6:28 AM, n+b...@monade.li wrote:
> From: Naïm Favier 
>
> Currently, typing `cmd flag1  flag2` (note the two spaces), navigating
> between the two spaces and hitting Tab produces
> `COMP_WORDS=(cmd flag1 flag2)` without inserting an empty word between
> flag1 and flag2.
>
> I believe this comes from considering the cursor ("sentinel") as a block
> rather than a line, which does not make sense in a completion context,
> but might possibly make sense in other contexts?

Looks like this dates to this change, although I'm not completely sure.

https://git.savannah.gnu.org/cgit/bash.git/tree/CWRU/old-changelogs/CWRU.chlog.v12?h=devel#n7702

-- 
vq

Re: Heredoc leading tab/space behaviour

[Lawrence Velázquez]

On Fri, Jun 24, 2022, at 9:57 AM, Kerin Millar wrote:
> On Fri, 24 Jun 2022 13:53:07 +0200 (CEST)
> "Ing. Gerold Broser" via Bug reports for the GNU Bourne Again SHell 
>  wrote:
>
>> heredoc-error.sh:
>> 
>> #!/bin/bash
>> sed -f - heredoc-error.sh <<-SCRIPT
>> ␣␣s/something/else/
>> ⭲   s/more/else/
>> ␣␣SCRIPT
>> 
>> $ . heredoc.sh
>> bash: warning: here-document at line 2 delimited by end-of-file (wanted 
>> `SCRIPT')
>> sed: file - line 3: unknown command: `S'
>> 
>> 
>> $ . heredoc-ok.sh
>> #!/bin/bash
>> sed -f - heredoc-ok.sh <<-SCRIPT
>> ␣␣s/else/else/
>> ⭲   s/else/else/
>> ⭲   SCRIPT

It has already been explained that you're mistaken, but I don't
understand how these examples are supposed to demonstrate that
leading spaces have been removed from the input.  sed(1) ignores
blank characters before commands.

>> Fix:
>> 
>> I think it'd be convenient if Heredoc supports indentation with spaces at 
>> the delimiter line, too.
>
> One issue with this proposal is that it would violate the rules of the 
> Shell Command Language, per 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04.

Coincidentally, a request to allow <<- to behave this way was
recently submitted.  It was rejected within two days, which feels
like it should be some sort of record.

https://austingroupbugs.net/view.php?id=1588

-- 
vq

Re: Inconsistency between fc and C-x C-e

[Lawrence Velázquez]

On Fri, Jun 10, 2022, at 10:19 AM, Chet Ramey wrote:
> I didn't look at more than mailx, but the description there makes it clear
> that $EDITOR needs to expand to a command name. `more' has similar wording
> ("The name of the editor shall be taken from the environment variable
> EDITOR.") and talks about what to do if the last pathname component in
> $EDITOR is `vi' or `ex'.

That's certainly the common-sense interpretation -- and no doubt
the intended one, given the historical behavior you mentioned.
I was reading phrases like "Determine the name of a utility" and
"The name of the editor shall be taken from the environment variable"
as allowing some wiggle room for the variable contents, but I was
probably overthinking it.

-- 
vq

Re: Inconsistency between fc and C-x C-e

[Lawrence Velázquez]

On Thu, Jun 9, 2022, at 8:37 PM, Luciano wrote:
> By the way, git seems to interpret the EDITOR variable in a way
> consistent with C-x C-e, while the pass program as I said seems to just
> execute $EDITOR, like fc. I wonder if POSIX leaves room for 
> interpretation here. 

It does, insofar as it barely concerns itself with EDITOR at all.
It only specifies that the "crontab", "fc", "mailx", and "more"
utilities use EDITOR and advises other applications to avoid using
it in a conflicting manner.  (The descriptions of the aforementioned
utilities are not all that detailed vis-à-vis EDITOR and could
reasonably be interpreted as allowing either method, but it doesn't
really matter as far as other utilities are concerned.)

-- 
vq

Re: >&"$var" broken in declare -f and exported functions

[Lawrence Velázquez]

On Sun, Jun 5, 2022, at 9:31 PM, Namikaze Minato wrote:
> @everyone, please let me know if I need to do something else to
> actually report the bug or if this thread is enough.

This thread is enough.

-- 
vq

Re: [gnu.org #1838744] Bash Manual, 3.6.2 Redirecting Inputs, SUGGESTION

[Lawrence Velázquez]

On Fri, May 20, 2022, at 7:01 PM, Lawrence Velázquez wrote:
> On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
>> I'm going to tell him there is no guarantee that this can be changed.
>> For one thing, it would be difficult to find a letter that doesn't
>> take an unwanted meaning when associated with "word".
>
> Perhaps something like "num" or "fd" could be used

Or even "fdnum", to stretch the comparison with "varname" to its
breaking point.

-- 
vq

Re: [gnu.org #1838744] Bash Manual, 3.6.2 Redirecting Inputs, SUGGESTION

[Lawrence Velázquez]

On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
> I'm going to tell him there is no guarantee that this can be changed.
> For one thing, it would be difficult to find a letter that doesn't
> take an unwanted meaning when associated with "word".

Perhaps something like "num" or "fd" could be used -- much like
"varname" earlier in the same section.  These would also have the
benefit of being marginally more self-explanatory.

-- 
vq

Re: Possible bug in bash

[Lawrence Velázquez]

On Thu, May 12, 2022, at 11:34 PM, flyingrhino wrote:
> Should the "else" condition after the:  ||  run if the last command in 
> the:  &&  section exits non zero?

Yes.  This behavior is not a bug; ''A && B || C'' is simply not
equivalent to ''if A then B; else C; fi''.

https://mywiki.wooledge.org/BashPitfalls#pf22

> Script:
>
>
> #!/bin/bash
>
> [[ "a" == "a" ]] && \
>  {
>  echo "equal"
>  ls x
>  } || {
>  echo "* SHOULD NOT DISPLAY 4"
>  }
>
>
> Result:
>
> ./moo.sh
> equal
> ls: cannot access 'x': No such file or directory
> * SHOULD NOT DISPLAY 4

This behavior is expected and correct.  There is no bug here.

> BTW, I've checked other conditions as follows and they look ok:
>
> [...]
>
> [[ "a" == "a" ]] && \
>  {
>  echo "equal"
>  } || {
>  echo "* SHOULD NOT DISPLAY 1"
>  }

This would display "* SHOULD NOT DISPLAY 1" if ''echo "equal"''
failed for some reason.  (Unlikely but possible.)

-- 
vq

Re: bash 5.1 heredoc pipes problematic, shopt needed

[Lawrence Velázquez]

> On Apr 24, 2022, at 3:41 PM, Oğuz  wrote:
> 
> 24 Nisan 2022 Pazar tarihinde Ángel  yazdı:
>> 
>> I think a shopt makes more sense. Forcing heredocs to be files although
>> something legit to request, is more a caller workaround to bugs in
>> called programs.
>> 
> 
> https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00084.html


Oh yeah, I remember this.  Here is Chet's position at the time:

https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00085.html


Begin forwarded message:

> From: Chet Ramey 
> Subject: Re: Is there a way to force here-documents/strings to use temporary 
> files?
> Date: December 20, 2020 at 3:53:32 PM EST
> To: Oğuz , bug-bash 
> Cc: chet.ra...@case.edu
> Reply-To: chet.ra...@case.edu
> 
> On 12/20/20 2:25 AM, Oğuz wrote:
> 
>> So, is there any way to force here-documents to use temporary files no
>> matter how long the expanded document is? If not, it would be nice if
>> compat50 had this effect.
> 
> There is not. I'm not sure that a compat setting would be appropriate for
> something that is purely an implementation issue.
> 
> There was a fairly extensive discussion that preceded this change, starting
> with
> 
> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00073.html
> 
> and continuing the next month (!) with
> 
> https://lists.gnu.org/archive/html/bug-bash/2019-04/msg7.html
> 
> One can argue that the concerns on either side (seeking on stdin vs.
> assuming that here-strings will never hit the file system) are assumptions
> that should not be made, for instance
> 
> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00075.html
> or
> https://lists.gnu.org/archive/html/bug-bash/2019-03/msg00082.html
> 
> I decided ultimately to make the change for the most common cases, where
> the amount of data passed in a here string or here document is small. But
> that is simply an implementation detail; the documented semantics of here-
> documents and here-strings aren't changed.
> 
> -- 
> ``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/


-- 
vq

Re: bash 5.1 heredoc pipes problematic, shopt needed

[Lawrence Velázquez]

On Fri, Apr 22, 2022, at 9:51 AM, Sam Liddicott wrote:
> Fix:
> Please could we at least have a shopt to maintain the old behaviour?

Perhaps BASH_COMPAT=5.0 could be extended to handle this.

-- 
vq

Re: Login to a remote machine.

[Lawrence Velázquez]

On Sat, Apr 9, 2022, at 8:14 PM, Ayoub Misherghi wrote:
>  Below I show two ways I ssh logged into a machine.
> In the first method I referred to the remote machine
> as 192.168.0.212 while in the second method I referred to the
> remote machine as [1]testuser5@192.168.0.212 specifying the user.
> In the first method it logged me in as user ayoub when the
> .ssh directory of ayoub does not have the file for the key
> specified with the -i parameter option. With the second method
>it logged me in as the testuser5 user; as expected.
>Some information about the bash version and the Linux version
>is right at the bottom.

What makes you think bash has anything to do with any of this?  Your
shell is not involved with authentication.

-- 
vq

Re: Bug in Bash on syntax error in functions?

[Lawrence Velázquez]

On Fri, Apr 8, 2022, at 3:23 PM, Chet Ramey wrote:
> So the difference is between a command not found
>
>> $ ./testfail1
>> a
>> ./testfail1: line 3: fail_command: command not found
>> b
>> $ ./testfail2
>> a
>> ./testfail2: line 3: 1 + : syntax error: operand expected (error token is
>> "+ ")
>> b
>
> and a word expansion error. Command-not-found errors don't really have any
> effect on execution unless you have the `-e' option set. Word expansion
> errors cause the shell to abort the currently-executing command (in this
> case, a simple command) and return to the top level read-execute loop.

Notably, these don't execute "echo b" either, demonstrating that
this isn't actually about functions at all.

{
echo a
echo "$[ 1 + ]"
echo b
}

echo a; echo "$[ 1 + ]"; echo b

> (And before someone pipes up here, POSIX requires a non-interactive shell
> to exit immediately on a word expansion error, which bash does in posix
> mode.)

*pipes* :)

Consequently, a modernized testfail2 using $((...)) notation doesn't
execute "echo b" when run with ksh, dash, yash, or POSIX-mode bash
(or even native-mode zsh).

-- 
vq

Re: forwarded weirdness report

[Lawrence Velázquez]

> On Mar 30, 2022, at 1:37 AM, Alex fxmbsw7 Ratchev  wrote:
> 
> your default of not allowing is weird
> 
> seems 'allowing alias foreworders to speak' not good to you ?

You're misrepresenting what I said and what Chris said.  Read
messages more closely before you pop off.

-- 
vq

Re: forwarded weirdness report

[Lawrence Velázquez]

> On Mar 29, 2022, at 8:26 AM, Chris Elvidge  wrote:
> 
> On 28/03/2022 22:00, Greg Wooledge wrote:
>> Or -- and I know this answer will be rejected, because it's too simple
>> and sensible -- stop using aliases in scripts.
> 
> +1
> 
> Or could just stop answering questions about aliases in scripts

Unfortunately this might simply allow the alias zealots to form an
unstoppable positive feedback loop.

-- 
vq

Re: forwarded weirdness report

[Lawrence Velázquez]

On Mon, Mar 28, 2022, at 3:06 PM, Martin Schulte wrote:
> on Mon, 28 Mar 2022 20:34:40 +0200 Alex fxmbsw7 Ratchev 
>  wrote:
>> https://pastebin.com/raw/T7ZnFapt
>
> Here's a somewhat stripped down version:
>
> $ bash --noprofile --norc -i -c "echo \$BASH_VERSION; shopt -s 
> expand_aliases ; source <(echo \"alias x='echo hallo'\"); alias; x"
> 5.1.4(1)-release
> alias x='echo hallo'
> bash: x: command not found

https://www.gnu.org/software/bash/manual/html_node/Aliases.html

Bash always reads at least one complete line of input, and all
lines that make up a compound command, before executing any of
the commands on that line or the compound command.  Aliases are
expanded when a command is read, not when it is executed.
Therefore, an alias definition appearing on the same line as
another command does not take effect until the next line of
input is read.  The commands following the alias definition on
that line are not affected by the new alias.

This also applies if the command defines the alias indirectly (e.g.,
by sourcing a second file that contains the `alias` commands).

-- 
vq

Re: for loop over parameter expansion of array can miss resulted empty list

[Lawrence Velázquez]

On Tue, Mar 22, 2022, at 11:05 PM, L A Walsh wrote:
> On 2022/03/22 14:04, Lawrence Velázquez wrote:
>> On Tue, Mar 22, 2022, at 4:53 PM, L A Walsh wrote:
>>   
>>> On 2022/03/21 03:40, Alex fxmbsw7 Ratchev wrote:
>>> 
>>>> i solve this by shopt -s nullglob
>>>>   
>>>>   
>>>>> Repeat-By:
>>>>>Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>>>>>Result: none
>>>>>Expected result: i is ''
>>>>> 
>>>>> 
>>> if you have nullglob set, then that is not the correct result.
>>> 
>>
>> The original bug report said nothing about nullglob.
>>   
> 
> Sorry, I got sidetracked.  In this case it wouldn't matter,
> if you have no directories where you are running this,
> then nothing will match, and it
> will be a null (empty) expression.

The contents of the current working directory don't come into play,
as the original test case does not perform any filename generation.
Note that nearly everything there is quoted.

> Sorry for my getting sidetracked (it happens alot.

No worries.

-- 
vq

Re: for loop over parameter expansion of array can miss resulted empty list

[Lawrence Velázquez]

On Tue, Mar 22, 2022, at 4:53 PM, L A Walsh wrote:
> On 2022/03/21 03:40, Alex fxmbsw7 Ratchev wrote:
>> i solve this by shopt -s nullglob
>>   
>>>
>>> Repeat-By:
>>>Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>>>Result: none
>>>Expected result: i is ''
>>> 
> if you have nullglob set, then that is not the correct result.

The original bug report said nothing about nullglob.

-- 
vq

Re: for loop over parameter expansion of array can miss resulted empty list

[Lawrence Velázquez]

On Mon, Mar 21, 2022, at 8:50 AM, Alexey via Bug reports for the GNU Bourne 
Again SHell wrote:
> I can add one more example, which change array size while it's not 
> expected behavior:
> x=("/"); y=("${x[@]%/}"); echo "x size: ${#x[@]}, y size: ${#y[@]}"

This discrepancy seems to have been introduced some ways back.

 3# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x ${#x[@]}, y 
${#y[@]}"
 3.2.48(1)-release
 x 1, y 1
 42# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x ${#x[@]}, 
y ${#y[@]}"
 4.2.45(1)-release
 x 1, y 0

-- 
vq

Re: Long variable value get corrupted sometimes

[Lawrence Velázquez]

On Wed, Feb 16, 2022, at 8:27 PM, Daniel Qian wrote:
> I'm not familiar with Bash version/release policy, I only found 5.1.8,
> 5.1.12, 5.1.16 at
> download page https://ftp.gnu.org/gnu/bash/
>
> Is this fix included in 5.1.16 version?

Yes, bash 5.1.16 is bash 5.1 with patch 16 and all previous official
patches.

-- 
vq

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

[Lawrence Velázquez]

On Mon, Feb 7, 2022, at 1:26 AM, Alex fxmbsw7 Ratchev wrote:
> well i saw now, printf a char of "\0" results in 0 bytes out to wc -c

% /usr/bin/printf '\0' | wc -c
   1


> however my solution still stays
> you just use memory locations instead of c strings
> and those entries in memory are of course of known length, before setting
> and all is fine

"Your" solution is decades old.  Everyone knows how Pascal-style
strings work.  This is not cutting-edge computer science.


> of course this means to not use these fauly 'c strings', but a self
> coded solution

As Greg already mentioned, such a system requires converting back
to C strings for system calls and other external APIs.  It's not
insurmountable, but it's more involved than just swapping all your
char * to my_string or whatever.

I repeat:

>> It's so simple that you should have no problem converting the entire
>> bash codebase to Pascal-style strings yourself.  We'll wait.


-- 
vq

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

[Lawrence Velázquez]

On Sun, Feb 6, 2022, at 11:53 PM, Alex fxmbsw7 Ratchev wrote:
> On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge  wrote:
>> There are other programming languages besides bash.  Some of them can
>> store NUL bytes internally, either by encoding and decoding them on the
>> fly, or by not using C-style strings internally (which means any system
>> calls require encoding/decoding the internal strings to C-style strings).
>
> i am not sure, but, tell me
> 'c strings' is a problem due to internal function handling with static \0 eof
> while 'c strings' can store null bytes no ? ( tell me if this is true
> or not plz )

It is not true.  C strings are terminated by NUL.


> then if, its up to the coding buddies to self code

How generous of you to volunteer other people's time and effort.


> its so simple:
> you have always static length strings simply, u conunt and know the
> length of every msg used, and so u can separate right
> isnt it so simple ?

It's so simple that you should have no problem converting the entire
bash codebase to Pascal-style strings yourself.  We'll wait.


>> I urge you to learn one of these other languages, and use it.
>
> i cant read others docs it seems buddy, it budds mee, its like the web
> docs about shell scripting, as you i and i wrote on our pages, its
> very invalid
> and so i cant learn a new language sorry

Tragic.


-- 
vq