Re: syntax error while parsing a case command within `$(...)'

[Lawrence Velázquez]

> On Feb 15, 2021, at 10:01 AM, Chet Ramey  wrote:
> 
> The bash command substitution parser handles the majority of these
> cases (heh)

lol I chuckled, well done

vq

Re: syntax error while parsing a case command within `$(...)'

[Lawrence Velázquez]

> On Feb 16, 2021, at 10:42 PM, Dale R. Worley  wrote:
> 
>> Oğuz  writes:
>> 
>> `;;' is optional for the last case item.
> 
> The manual page (for my version) says it's required. If, in some
> certain circumstances, it works without, that's nice.


It's also required by POSIX.

> But there's no commitment that it will work now, or in future
> releases.

The commitment is bash's claim to POSIX compliance. Outside of
command substitutions, the referenced construct currently works,
as POSIX requires. I expect this is by design. If it ceases to be
recognized in the future, then bash will have intentionally become
less compliant with POSIX, for no good reason.

>> `case x in esac' (without the linebreak) works fine outside the
>> command substitution.
> 
> The manual page (for my version) says that "esac" will be recognized
> in positions where a simple command may appear.

The 5.1 man page doesn't say that, or I can't find it, but it doesn't
matter because a simple command can't go immediately after that "in".

> If, in some other circumstances, it works, that's nice.


Recognition of "case x in esac" is also required by POSIX.

> But there's no commitment that it will work now, or in future
> releases.

See above.

> Now, if you want to advocate that it *should* always work, go ahead.
> But that's a feature request, not a bug report.

TO: Chet
SUBJECT: Feature request

Please do not make bash less POSIX-compliant for no good reason!

thx
vq

Re: syntax error while parsing a case command within `$(...)'

[Lawrence Velázquez]

> On Feb 17, 2021, at 10:27 PM, Dale R. Worley  wrote:
> 
> Lawrence Velázquez  writes:
>>>> `;;' is optional for the last case item.
>>> 
>>> The manual page (for my version) says it's required. If, in some
>>> certain circumstances, it works without, that's nice.
>> 
>> It's also required by POSIX.
> 
> Ah, now that's different.  Has the current man page been updated to
> match?

No.

https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html#index-case

Bash has permitted omitting the final ;; since the beginning (more
or less). I assume the documentation omits that detail for a reason
-- perhaps to discourage its use.

vq

Re: Changing the way bash expands associative array subscripts

[Lawrence Velázquez]

> On Mar 15, 2021, at 9:03 PM, Léa Gris  wrote:
> 
> Please excuse my profanity of mentioning zsh in this list, but I really think 
> features and behavior convergence can benefit end users in multiple ways, 
> especially when expanding beyond the POSIX sh scope.
> 
> What direction has taken zsh with expanding associative array indexes?

Broadly speaking, zsh treats subscript expressions as if they are 
double-quoted, but it does not perform arithmetic expansion on associative 
array indices (although subscript expressions must still adhere to related 
parsing rules).

% zsh --version; echo
zsh 5.8 (x86_64-apple-darwin18.7.0)

% cat /tmp/demo1
# Chet's example modified to highlight certain behaviors
foo() {
echo uname >&2
echo +1
}

declare -A assoc
key='x$(foo)]=1,b[1$(foo)'

assoc[$key]=0
declare -p assoc b

% zsh -f /tmp/demo1
/tmp/demo1:declare:10: no such variable: b
typeset -A assoc=( ['x$(foo)]=1,b[1$(foo)']=0 )

However, it does perform multiple expansions in arithmetic contexts.

% cat /tmp/demo2
# Chet's example modified to highlight certain behaviors
foo() {
echo uname >&2
echo +1
}

declare -A assoc
key='x$(foo)]=1,b[1$(foo)'

(( assoc[$key]++ ))
declare -p assoc b

% zsh -f /tmp/demo2
uname
uname
typeset -A assoc=( [x+1]=1 )
typeset -a b=( '' 1 )

Furthermore, "as if they are double-quoted" is rather literal. (Special 
handling allows the use of a["foo"] instead of a[\"foo\"].)

% cat /tmp/demo3
declare -A a
key='$(echo foo)'
a[$key]=1
a['$key']=2
a["foo"]=3

declare -p a

% zsh -f /tmp/demo3
typeset -A a=( ['"foo"']=3 ['$(echo foo)']=1 [\''$(echo foo)'\']=2 )

If we tweak the preamble to create the intended array (and disable NOMATCH to 
treat failed filename generation as bash does), the unset commands work the 
same as in Chet's proposal.

% cat /tmp/demo4
declare -A a
key='$(echo foo)'
a[$key]=1
a[\$key]=2
a[foo]=3

# Avoid Chet's intentional error because it's difficult to get zsh to
# imitate it faithfully.
#unset -v a[$key]
declare -p a

# unsets element with key $key
unset -v a['$key']
declare -p a

# unsets element with key $(echo foo)
unset -v a["$key"]
declare -p a

# unsets element with key foo
eval unset -v a\["$key"\]
declare -p a

% zsh -f +o NOMATCH /tmp/demo4
typeset -A a=( ['$(echo foo)']=1 ['$key']=2 [foo]=3 )
typeset -A a=( ['$(echo foo)']=1 [foo]=3 )
typeset -A a=( [foo]=3 )
typeset -A a=( )

vq

Re: Likely Bash bug

[Lawrence Velázquez]

> On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne Again 
> SHell  wrote:
> 
>   Hello,
> 
>   I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
>   systems more than once either through their instability with libraries
>   or just excess stress.
> 
>   I don't consider current case to be either of the above; see attached.
> 
>   The system is modern Intel computer, 2018 to 2019 configured in BIOS
>   mode. Operating system is BionicPup64 8.0.
> 
>   Best Regards.
> 

Reproduced below for anyone who doesn't feel like reading a bug
report out of an RTF document.

vq



From: root
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: [ash--bash interference (for reference)]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT 2019 
x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 19
Release Status: release

Description:
[Original ash executable/script reduced to 4 bytes after download of 
"Clonezilla" 
through Puppy Package Manager. Reboot of system hung at 'switching-layers'.]

Repeat-By:
[Believed occurred after an ash co-dependency download as part of 
install.]

Fix:
[Noted xwin errors relating to ash on shutdown; had backup savefile. 
Compared /bin and saw the difference. Replaced ash from backup file to working 
folder.]

Re: Likely Bash bug

[Lawrence Velázquez]

> On Mar 16, 2021, at 11:08 PM, Dennis Williamson  
> wrote:
> 
> I've been playing with your optimized code changing the read to grab data
> in chunks like some of the other optimized code does - thus extending your
> move from by-word to by-line reading to reading a specified larger number
> of characters.
> 
> IFS= read -r -N 4096 var
> 
> And appending the result of a regular read to end at a newline. This seemed
> to cut about 20% off the time. But I get different counts than your code.
> I've tried using read without specifying a variable and using the resulting
> $REPLY to preserve whitespace but the counts still didn't match.
> 
> In any case this points to larger chunks being more efficient.

Wrong thread?

vq

Re: Wanted: quoted param expansion that expands to nothing if no params

[Lawrence Velázquez]

> On Mar 23, 2021, at 11:43 PM, Eli Schwartz  wrote:
> 
> On 3/23/21 11:24 PM, L A Walsh wrote:
>> Too often I end up having to write something like
>> if (($#)); then  "$@"
>> else   # = function or executable call
>> fi
>> 
>> It would be nice to have a expansion that preserves arg boundaries
>> but that expands to nothing when there are 0 parameters
>> (because whatever gets called still sees "" as a parameter)
>> 
>> So, example, something like:
>> 
>> $~ == "$@" #for 1 or more params
>> $~ ==  no param when 0 param, # so for the above if/else/endif
>> one could just use 1 line:
> 
> It's not clear to me, how you expect this to differ from the existing
> behavior of "$@" or "${arr[@]}" which already expands to 
> rather than an actual "" parameter.

The original message does recall the behavior of the earliest Bourne
shells [1][2], but that is surely not relevant here, given the use
of ((...)). Right? RIGHT???

  [1]: https://www.in-ulm.de/~mascheck/various/bourne_args/
  [2]: 
https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Shell-Substitutions.html#index-_0022_0024_0040_0022

vq

Re: how does ssh cause this loop to preterminate?

[Lawrence Velázquez]

> On Mar 24, 2021, at 5:21 PM, gregrwm  wrote:
> 
> Oddly, somehow, invoking ssh in a loop causes the loop to preterminate.
> Why?

https://mywiki.wooledge.org/BashFAQ/089

vq

Re: Defaults -- any

[Lawrence Velázquez]

On Tue, Mar 30, 2021, at 12:54 PM, L A Walsh wrote:
> On 2021/03/29 20:04, Greg Wooledge wrote:
> > On Mon, Mar 29, 2021 at 07:25:53PM -0700, L A Walsh wrote:
> >   
> >>
> >>I have both /etc/profile and /etc/bashrc call my configuration
> >> scripts.  Are there common paths that don't call one of those?
> >> 
> >
> > A vanilla bash compiled from GNU sources with no modifications will
> > not source /etc/bash.bashrc or /etc/bashrc or any other such file.
> >   
> 
> 
> So this manpage text is wrong (focusing on paths in /etc):
> 
> When  bash is invoked as an interactive login shell, or as a non-inter-
> active shell with the --login option, it first reads and executes  com-
> mands  from  the file /etc/profile.  Please note that the file
> /etc/profile includes an autodetection shell  code  w(h)ether  it  
> has  to
> source /etc/bash.bashrc.
> 
> When  bash is invoked as an interactive login shell, or as a non-inter-
> active shell with the --login option, it first reads and executes  com-
> mands  from  the file /etc/profile, if that file exists.
> Please note that the file /etc/profile includes an autodetection
> shell  code w(h)ether  it  has  to source /etc/bash.bashrc.

Your man page has been modified from the upstream one.

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

vq

Re: incorrect character handling

[Lawrence Velázquez]

On Tue, Mar 30, 2021, at 4:50 PM, Greg Wooledge wrote:
> On Wed, Mar 31, 2021 at 02:31:46AM +0700, by.sm--- via Bug reports for 
> the GNU Bourne Again SHell wrote:
> > poc=whoami
> > $poc
> > python3 -c "print('!!')"
> > 
> > That return 'whoami' command. 
> 
> You're running into the csh-style history expansion.  A lot of us simply
> disable it, because it's not worth the effort it takes to work around it.
> 
> set +o histexpand
> 
> 
> If you insist on keeping it, and working around it, the key is to
> understand that single quotes will protect you, but double quotes may
> not.
> 
> echo 'hi!'
> 
> echo "hi!"

Further reading:
https://mywiki.wooledge.org/BashPitfalls#echo_.22Hello_World.21.22

vq

Re: When "set -u", "which" outputs environment: line 1: _declare: unbound

[Lawrence Velázquez]

On Fri, Apr 9, 2021, at 4:51 PM, Eli Schwartz wrote:
> Are you ready to have your day truly spoiled? Fedora's package for the
> external program GNU which, provides this /etc/profile.d/ script
> (automatically injected into the environment of any interactive shell
> sessions once you install GNU which -- how charming):
> 
> https://src.fedoraproject.org/rpms/which/blob/rawhide/f/which2.sh
> 
> Corresponding to the terrible advice from the GNU which manpage:
> 
> https://man.archlinux.org/man/which.1#EXAMPLE

At least Fedora quotes $@. Small mercies.

vq

Re: enhancement merge request

[Lawrence Velázquez]

Hi,

> On Apr 18, 2021, at 12:03 AM, Ananth Chellappa  wrote:
> 
> Hello Brian and Chet,
> Please consider merging the enhancement made by Naseeba described
> here :
> 
> https://github.com/ananthchellappa/bash-5.1/blob/main/README.md

In your future emails, you may want to consider

- writing a subject that provides a useful summary of the purpose
  or contents of the email,
- writing a body that contains your message or a useful summary of
  it, and
- not requiring readers to visit an external website to learn
  literally the first thing about what you wish to discuss.

Here's the relevant description from that README:

This version of bash contains the below described update
done by **Naseeba Kilayil** through Upwork :

Currently, when you do set +o history, then commands are
no longer logged to ~/.bash_history. The problem is that
while you get the privacy, you also lose command recall
with !number and arrow-keys. So we want to **enhance**
`set +o history` to suspend logging to ~/.bash_history,
but (while in private mode - i.e., till you do `set -o
history`) you do get command recall with !number and
arrow keys. These private mode commands will, of course,
be forgotten once user exits private mode.

The history feature encompasses a lot more than just saving to the
history file.  The idea of `set +o history` leaving history expansion
and command recall enabled makes no sense to me; those *are* history
features.

Is the desired outcome just to retain all history features except
persistence to ~/.bash_history (or any other file)?  If so, this
can be accomplished by unsetting HISTFILE.

P.S. I've attached the patches from the aforelinked Git repository,
for the curious.

-- 
vq

From 4cddd70586f64530e41ccb3c4293c5e805ef840a Mon Sep 17 00:00:00 2001
From: Ananth 
Date: Sat, 17 Apr 2021 20:42:11 -0700
Subject: [PATCH 1/8] Always keep history

---
 bashhist.c   |  2 ++
 bashhist.h   |  2 ++
 builtins/set.def | 16 
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/bashhist.c b/bashhist.c
index 2a05a53..eb6471a 100644
--- a/bashhist.c
+++ b/bashhist.c
@@ -91,6 +91,8 @@ static struct ignorevar histignore =
 int remember_on_history = 0;
 int enable_history_list = -1;  /* value for `set -o history' */
 
+int private_history_mode = 0;
+
 /* The number of lines that Bash has added to this history session.  The
difference between the number of the top element in the history list
(offset from history_base) and the number of lines in the history file.
diff --git a/bashhist.h b/bashhist.h
index 615f5d2..8061bac 100644
--- a/bashhist.h
+++ b/bashhist.h
@@ -39,6 +39,8 @@
 #  endif /* !HISTEXPAND_DEFAULT */
 #endif
 
+extern int private_history_mode;
+
 extern int remember_on_history;
 extern int enable_history_list;/* value for `set -o history' */
 extern int literal_history;/* controlled by `shopt lithist' */
diff --git a/builtins/set.def b/builtins/set.def
index 8ee0165..150e153 100644
--- a/builtins/set.def
+++ b/builtins/set.def
@@ -395,7 +395,7 @@ set_ignoreeof (on_or_off, option_name)
   ignoreeof = on_or_off == FLAG_ON;
   unbind_variable_noref ("ignoreeof");
   if (ignoreeof)
-bind_variable ("IGNOREEOF", "10", 0); 
+bind_variable ("IGNOREEOF", "10", 0);
   else
 unbind_variable_noref ("IGNOREEOF");
   sv_ignoreeof ("IGNOREEOF");
@@ -468,16 +468,16 @@ bash_set_history (on_or_off, option_name)
 {
   if (on_or_off == FLAG_ON)
 {
-  enable_history_list = 1;
-  bash_history_enable ();
-  if (history_lines_this_session == 0)
-   load_history ();
+  private_history_mode = 0;
 }
   else
 {
-  enable_history_list = 0;
-  bash_history_disable ();
+  private_history_mode = 1;
 }
+enable_history_list = 1;
+bash_history_enable ();
+if (history_lines_this_session == 0)
+  load_history ();
   return (1 - enable_history_list);
 }
 #endif
@@ -706,7 +706,7 @@ set_builtin (list)
break;
}
 }
-
+
   /* Do the set command.  While the list consists of words starting with
  '-' or '+' treat them as flags, otherwise, start assigning them to
  $1 ... $n. */
-- 
2.31.1

From aeea5a2e2d36e6e6c57063835a1fb1a17f5c60fc Mon Sep 17 00:00:00 2001
From: Ananth 
Date: Sat, 17 Apr 2021 20:46:47 -0700
Subject: [PATCH 2/8] tag history entry as private

---
 bashhist.c   | 15 +++
 lib/readline/doc/hstech.texi | 15 ---
 lib/readline/history.c   | 28 ++--
 lib/readline/history.h   |  4 +++-
 4 files changed, 48 insertions(+), 14 deletions(-)

diff --git a/bashhist.c b/bashhist.c
index eb6471a..6190018 100644
--- a/bashhist.c
+++ b/bashhist.c
@@ -599,7 +599,7 @@ pre_process_line (line, print_changes, addit)
{
 #if defined (READLINE)
  if (expanded == 2 && rl_dispatching == 0 && *

Re: enhancement merge request

[Lawrence Velázquez]

> On Apr 18, 2021, at 7:12 PM, Ananth Chellappa  wrote:
> 
> Even this guy https://paulh.consulting/
> thought it was easy before deciding it was worth $500 of his time to try
> adding it :)

I don't know who "this guy" is.  There are a lot of very skilled
developers who aren't specifically versed in the paradigms or
particulars of shells.  There's nothing wrong with that, but it's
also not really a compelling argument in favor of changing the
fundamental behavior of a shell option.

> analog@DESKTOP-O264A5N ~ $ set HISTFILE=/home/analog/.bash_history

This does not set the HISTFILE shell variable or affect the history
mechanism in any way.  It clears all positional parameters except
the first, which is set to 'HISTFILE=/home/analog/.bash_history'.

> 2150  echo a private command   < Yikes, this was in private mode! I
> shouldn't see this after "exiting"
> 2151  echo an evil command < private mode. LV suggested that using
> HISTFILE unset/set would be be

HISTFILE doesn't affect the internal history list, only the external
history file.  It wasn't clear to me that you cared about the former.

-- 
vq

Re: enhancement merge request

[Lawrence Velázquez]

> On Apr 19, 2021, at 7:18 AM, Greg Wooledge  wrote:
> 
> On Mon, Apr 19, 2021 at 01:16:48AM -0400, Grisha Levit wrote:
>> I think you can do something similar to the patch directly in the shell by
>> temporarily unsetting HISTFILE and then deleting history entries in a
>> certain range and restoring HISTFILE when you are ready
> 
> I still think my solution fits the criteria exactly.  There was *no*
> stated requirement that the "private mode" could not be a separate
> shell process.

This wasn't explicitly stated either, but it seems like Ananth wants
"private mode" to have access to preceding history.  Perhaps something
resembling this (with `history -a` instead, if preferred)?

private_mode() {
history -w
bash --rcfile <(
echo source ~/.bashrc
echo history -r
echo unset HISTFILE
)
}

-- 
vq

Re: Latest devel branch push

[Lawrence Velázquez]

On Sat, May 15, 2021, at 4:29 PM, Alex fxmbsw7 Ratchev wrote:
> but is that the devel tree

Switch to the "devel" branch.

-- 
vq

Re: Prefer non-gender specific pronouns

[Lawrence Velázquez]

> On Jun 5, 2021, at 12:47 PM, John Passaro  wrote:
> 
> I can see a couple reasons why it would be a good thing, and in the con
> column only "I personally don't have time to go through the manual and make
> these changes".

There don't seem to be many instances in the Texinfo source.

#1, already pointed out by OP:

% ripgrep -w -g '*.texi' 'he|his|him'
doc/bashref.texi
7848:in a non-writable directory other than his home directory after 
login,

Not relevant, as these refer to specific individuals:

doc/oldbash.texi
178:manual.  Brian and Diane would like to thank Chet Ramey for his
9138:# The alternative explanation is that his frequent use of the

#2, from readline:

lib/readline/doc/rltech.texi
1654:exceptional events, like a user pressing the interrupt key on his 
terminal,

#3, from readline, already pointed out by OP:

lib/readline/doc/rluser.texi
342:commands in an @dfn{inputrc} file, conventionally in his home 
directory.

From GNU termcap (I think), so out of scope:

lib/termcap/grot/termcap.texi
1477:specify what type he really has.  One example of a generic type

That's three.  Pretty tractable for anyone so inclined.  (Didn't
look at source code comments or anything.)


-- 
vq

Re: [PATCH] Prefer non-gender specific pronouns

[Lawrence Velázquez]

On Sun, Jun 6, 2021, at 12:35 AM, G. Branden Robinson wrote:
> At 2021-06-05T23:29:58-0400, Lawrence Velázquez wrote:
> > doc/oldbash.texi
> > 178:manual.  Brian and Diane would like to thank Chet Ramey for his
> > 9138:# The alternative explanation is that his frequent use of the
> 
> My "git grep" didn't turn this file up anyway.  Maybe I'm on the wrong
> branch?

I'm on the "devel" branch.

> > That's three.  Pretty tractable for anyone so inclined.  (Didn't
> > look at source code comments or anything.)
> 
> Thanks, Lawrence!

Sorry, you might want to redo your patch.  It just occurred to me
that I made a predictable oversight.

% git grep --perl-regexp '\b(she|her|hers)\b' -- '*.texi'
doc/oldbash.texi:# If the user has her own init file, then use that 
one, else use
doc/oldbash.texi:and the second draft.  Without her help, this manual 
would probably
lib/readline/doc/rltech.texi:possible-completions call.  After that, 
readline asks the user if she is sure
lib/readline/doc/rltech.texi:she wants to see them all.  The default 
value is 100.  A negative value 

(I believe doc/oldbash.texi is a legacy document that needn't be
bothered with.)

-- 
vq

Re: 'wait' in command group in pipeline fails to recognize child process

[Lawrence Velázquez]

On Tue, Jun 22, 2021, at 6:32 PM, Martin Jambon wrote:
> I would also mention pipelines here, since these are more commonly
> used than () subshells.  I don't know if there are other ways of
> creating subshells.  If that's all, I think it would be valuable
> to mention those two cases rather than just one.

There are also command substitutions and any commands run asynchronously.

If the description applies to all subshells, not just ones inside
(...), then perhaps the documentation should just omit "()" instead
of spelling out every possible way a subshell can be created.

> Well, I suppose "root shell" could be misunderstood as a shell run by 
> the 'root' user but this doesn't make much sense in this context.

Yes, but then the reader is left to reverse-engineer the meaning
of this term you just made up.  If the documentation is to be
changed, it should be more clear than before.  "Root shell" makes
it less clear and should not be used.  There wouldn't be anything
wrong with adding a more verbose but more precise explanation.

> I also changed "invoking shell" to "root shell" because the invoking 
> shell or parent shell is not necessarily the same as the root shell e.g.
> 
> $ echo $$; (echo $$; (echo $$))
> 688918
> 688918
> 688918

Maybe something like this would get the point across:

($$) Expands to the process ID of the shell.  In a subshell,
 it expands to the value that $$ has in the invoking shell.

-- 
vq

Re: 'wait' in command group in pipeline fails to recognize child process

[Lawrence Velázquez]

On Tue, Jun 22, 2021, at 8:52 PM, Martin Jambon wrote:
> It's better. However, the reader is still left wondering what "the 
> shell" is referring to in first sentence.

Subshells aside, I have a hard time believing that "the process ID
of the shell" confuses anybody in practice.  Even POSIX doesn't
overcomplicate this:

$
Expands to the decimal process ID of the invoked shell.  In
a subshell (see Shell Execution Environment), '$' shall
expand to the same value as that of the current shell.

(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02)

-- 
vq

Re: bash on Tru64

[Lawrence Velázquez]

On Tue, Jun 29, 2021, at 4:38 PM, Jay K wrote:
> diff -u input_avail.c.orig input_avail.c
> --- input_avail.c.orig  2019-12-26 13:59:17.0 -0800
> +++ input_avail.c       2021-06-29 12:48:19.407119600 -0700
> @@ -110,7 +110,7 @@
>  #if defined(HAVE_SELECT)
>    fd_set readfds, exceptfds;
>  #endif
> -#if defined (HAVE_PSELECT)
> +#if defined (HAVE_PSELECT) || defined (HAVE_SELECT)
>    sigset_t set, oset;
>  #endif

This change is already on the devel branch.

https://git.savannah.gnu.org/cgit/bash.git/commit/lib/sh/input_avail.c?h=devel&id=2047e28

-- 
vq

Re: parameter expansion with `:` does not work

[Lawrence Velázquez]

On Wed, Jul 7, 2021, at 6:37 PM, lisa-as...@perso.be wrote:
> So you used `:` at the beginning and it worked?

Chet and Greg already spelled out your mistake.  It has nothing to
do with the ':' command.

-- 
vq

Re: parameter expansion with `:` does not work

[Lawrence Velázquez]

> On Jul 7, 2021, at 10:38 PM, lisa-as...@perso.be wrote:
> 
> Correct.  How do others customarily use `${fdir:=$PWD}` ?

The common idiom is

: "${fdir:=$PWD}"

The ':' utility is used because it does nothing, but its arguments
are expanded as usual.

> I'd rather understand what's going on, rather than simply never use it.

Think about what is happening here:

fdir=${fdir:=$PWD}

This is conceptually equivalent to

if [[ -z "$fdir" ]]; then
fdir="$PWD"
fi
fdir="$fdir"

I hope you can see why this is a pointless thing to do.

-- 
vq

Re: Command substitution fails in here-document delimiter.

[Lawrence Velázquez]

> On Jul 13, 2021, at 4:37 PM, Paul Gilmartin  wrote:
> 
> Description:
>   When "word" in here-document contains command substitution,
>   bash reports an error:
> here: line 4: warning: here-document at line 2 delimited by end-of-file 
> (wanted `foo$( true )bar')
>   Man bash shows:
>Here Strings
>A variant of here documents, the format is:
> 
>   [n]<< 
>The word undergoes tilde expansion, parameter and variable expansion, 
> command substitu‐
>tion,  arithmetic  expansion, and quote removal.


Here-strings are not here-documents, so you've been reading the
wrong section of the man page.  The section on here-documents makes
it clear that the behavior you've observed is not a bug.

Here Documents

[...]

The format of here-documents is:

[n]<<[-]word
here-document
delimiter

No parameter and variable expansion, command substitution,
arithmetic expansion, or pathname expansion is performed
on 'word'.


-- 
vq

Re: gettext feature request

[Lawrence Velázquez]

On Sat, Jul 31, 2021, at 4:17 PM, Jean-Jacques Brucker wrote:
> The advantage of adding such variable is that we could use more easily 
> different mo files in a same bash execution :
> 
> (at least) one "legacy" (for /$"..."/) and (at least) one 'C-strings' 
> (for /$'...'/), which could then be shared with a C program (For example 
> lazy people could then reuse coreutils mo files, as they contain lot of 
> frequently-used-everywhere strings, while using their own mo file for 
> "legacy" strings).

I'm a little confused.  My impression was that this hypothetical
option would *disable expansion* in $"...", not *enable translation*
in $'...'.  I wasn't under the impression that reappropriating
$'...' for translation was on the table?

-- 
vq

Re: An alias named `done` breaks for loops

[Lawrence Velázquez]

On Sat, Aug 14, 2021, at 6:59 PM, George Nachman wrote:
> Description:
> Defining an alias named `done` breaks parsing a for loop that does not have
> an `in word` clause.
> 
> 
> Repeat-By:
> 
> Run the following script. It fails with this error:
> 
> myscript.bash: line 7: syntax error near unexpected token `done'
> myscript.bash: line 7: `  done'
> 
> 
> #!/bin/bash
> 
> alias done=""
> 
> f() {
>   for var; do
>   done
> }

The 'alias' command is irrelevant because aliases are not expanded
in noninteractive shells by default.  The absence of 'in X' is also
irrelevant.  The problem is that there cannot be *nothing* between
'do' and 'done'.  (I'll let someone more patient relate this to the
formal grammar, if they're so inclined.)

% bash --version | head -n 1
GNU bash, version 5.1.8(1)-release (x86_64-apple-darwin18.7.0)
% cat /tmp/myscript1.bash
f() {
for var in a b c; do
done
}
% bash /tmp/myscript1.bash
/tmp/myscript1.bash: line 3: syntax error near unexpected token `done'
/tmp/myscript1.bash: line 3: `done'

You *can* force alias expansion by setting expand_aliases, in which
case you get a different error.

% cat /tmp/myscript2.bash
alias done=''

f() {
for var in a b c; do
done
}
% bash -O expand_aliases /tmp/myscript2.bash
/tmp/myscript2.bash: line 6: syntax error near unexpected token `}'
/tmp/myscript2.bash: line 6: `}'

This is the same error you'd get if you simply omitted 'done'
entirely, which should make sense.

> Fix:
> `done` should not be considered a simple command in the context where it
> would terminate a for loop.

POSIX mode does disable alias expansion in that situation (see
,
item 7).  Perhaps the default behavior is for backward compatibility?

% bash --posix /tmp/myscript2.bash
/tmp/myscript2.bash: line 5: syntax error near unexpected token `done'
/tmp/myscript2.bash: line 5: `done'

-- 
vq

Re: "printf -v foo bar" sets $? to 1

[Lawrence Velázquez]

On Sat, Aug 14, 2021, at 7:56 PM, Keith Thompson wrote:
> Bash Version: 5.1
> Patch Level: 4
> Release Status: maint
> 
> Description:
> The builtin "printf" command with the "-v" option works
> correctly, but it reports failure by setting $? to 1.
> 
> The problem was introduced by this commit; I've confirmed
> that it doesn't occur with its immediate predecessor.
> 
> commit a30f513fc4cd507e74de6f0d0006b289a017a0d0
> Author: Chet Ramey 
> Date:   2021-05-13 14:49:18 -0400
> 
> more changes to handle @ and * as associative array keys
> 
> 
> Repeat-By:
> if printf -v foo bar ; then echo OK ; else echo FAILED ; fi

Have you tried a newer build?

% bash --version | head -n 1
GNU bash, version 5.1.8(1)-release (x86_64-apple-darwin18.7.0)
% bash -c 'printf -v foo bar; echo $?'
0

-- 
vq

Re: @K transformation

[Lawrence Velázquez]

On Fri, Aug 20, 2021, at 6:11 PM, Léa Gris wrote:
> Le 21/08/2021 à 00:06, Chet Ramey écrivait :
> > The best way to clone an associative array is:
> > 
> > declare -A options
> > eval options=\( "${assoc[@]@K}" \)
> > 
> > The quoting @K performs is eval-safe.
> > 
> 
> Although I was not attempting to clone the Associative array but turn it 
> into a flat array with interleaved key and value each as own element.

declare -a options
eval options=\( "${assoc[@]@K}" \)

-- 
vq

Re: Exclamation mark when using character classes

[Lawrence Velázquez]

> On Fri, Aug 20, 2021 at 10:30 PM hancooper via Bug reports for the GNU
> Bourne Again SHell bug-bash@gnu.org wrote:
> 
> I am using EPOCHREALTIME and then computing the corresponding human
> readable form, that can handle
> changes in locale
> now=$EPOCHREALTIME
> printf -v second '%(%S)T.%s' "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> printf -v minute '%(%M)T' "${now%[^[:digit:]]}"
> printf -v hour '%(%H)T' "${now%[^[:digit:]]}"Incidentally, [![:digit:]] does 
> not work there, you need to use the
> POSIX-specified caret (^) instead of an
> exclamation mark when using character classes. I'm not sure if this is
> intentional or a bug in bash; man
> page doesn't seem to mention it.


https://lists.gnu.org/archive/html/help-bash/2021-08/msg00120.html

> On Aug 21, 2021, at 10:55 AM, hancooper  wrote:
> 
> I got it backwards.  POSIX specifies ! for use in globs, and bash
> permits ^ as an extension, for people who are used to ^ from regular
> expressions.
> 
> Had "tested" this using grep or [[ =~ ]] or something else that uses
> regular expressions, not globs.

https://lists.gnu.org/archive/html/help-bash/2021-08/msg00125.html

Why are you reposting other people's messages from a different
mailing list, without attribution?

-- 
vq

Re: Issue declaring an array via a variable name

[Lawrence Velázquez]

On Sat, Aug 21, 2021, at 6:02 PM, Hunter Wittenborn wrote:
> In my head, something like this (where 'value' is equal to 'y'):
> 
> `declare "${value}"="x"`
> 
> becomes this (which it appears to do so):
> 
> `declare "y"="x"`

Almost.  The argument parses without issue ('=' has no special
meaning here), so it undergoes the usual parameter expansion and
quote removal, and you end up with

declare y=x

which is fine.

> Logically (for me anyway), this:
> 
> `declare "${value}"=("x" "z")`
> 
> should then become this:
> 
> `declare "y"=("x" "z")`

The shell performs parameter expansion and quote removal on a command
*after* parsing it.  As I see it, your mental model for `declare`
requires the shell to:

   1. Pause parsing upon seeing '('.
   2. Go back and, out of the usual order, perform parameter expansion
  and quote removal on the portion of the word preceding '=' to
  see whether it expands to a valid identifier.
  3a. If it does, resume parsing the word as an assignment, so '('
  begins an array.
  3b. If not, resume parsing as regular word, so '(' is a syntax error.

These would be rules that don't apply anywhere else.  You may find
this logical and worthwhile, but others sure don't.

"${value}"=("x" "z")  # invalid
echo "${value}"=("x" "z") # invalid
declare "${value}"=("x" "z")  # invalid but you want it to be valid

As has already been pointed out, this all goes away if you just
quote the parentheses -- even if you're silly about it:

declare -a "${value}"=\(x\ z\)

-- 
vq

Re: Issue declaring an array via a variable name

[Lawrence Velázquez]

On Sun, Aug 22, 2021, at 4:38 PM, Alex fxmbsw7 Ratchev wrote:
> last time again

You promise?

> one pair quotes, not more

Except you're wrong.

$ val=foo
$ declare "$val"='x'
$ declare -p "$val"
declare -- foo="x"

$ val=bar
$ declare -a "$val"='(baz quux)'
$ declare -p "$val"
declare -a bar=([0]="baz" [1]="quux")


-- 
vq

bug-bash@gnu.org

[Lawrence Velázquez]

> On Aug 22, 2021, at 10:22 PM, Koichi Murase  wrote:
> 
> 2021年8月23日(月) 6:13 Emanuele Torre :
>> It would be nice to have a parameter transformation (e.g. "${par@p}")
>> that expands $par to a string that will not be expanded by PS1, PS2, &c.
> 
> It seems to me that you can just put '$par' (not "$par") in PS1.
> Then, the suggested "${par@p}" can be simply '$par', which isn't worth
> implementing as a new transform.  You can write
> 
>  PS1='blabla $tmp_var blabla'
> 
> Or
> 
>  PS1="blabla \$tmp_var blabla"

An example in the original post asserted that tmp_var "will not
exist when PS1 is expanded", so it must be inserted when PS1 is
defined.  This requirement seems pretty contrived to me (why can't
tmp_var be kept around, exactly?), but that's what was postulated.

-- 
vq


Begin forwarded message:

> From: Emanuele Torre 
> Subject: [feature request] parameter transformation to safely add strings to 
> PS1, &c.
> Date: August 22, 2021 at 5:11:53 PM EDT
> To: bug-bash@gnu.org
> 
> It would be nice to have a parameter transformation (e.g. "${par@p}")
> that expands $par to a string that will not be expanded by PS1, PS2, &c.
> 
> example:
> 
>  tmp_var=$(blabla) # this variable will not exist when PS1 is expanded
>  PS1="blabla ${tmp_var@p} blabla"

Re: Defect in manual section "Conditional Constructs" / case

[Lawrence Velázquez]

On Tue, Aug 24, 2021, at 4:44 PM, Dietmar P. Schindler wrote:
> Doesn't the example I gave above show that quotes are removed? If they
> weren't, how could word aa with pattern a""a constitute a match?

The quotes are handled by the matching process itself, *not* as
part of the usual shell expansions.  Otherwise these patterns would
be equivalent, but they're not.

% cat /tmp/foo.sh
case $1 in
'a?a') echo one ;;
a?a) echo two ;;
esac
% bash /tmp/foo.sh 'a?a'
one
% bash /tmp/foo.sh aaa
two


-- 
vq

Re: Defect in manual section "Conditional Constructs" / case

[Lawrence Velázquez]

On Wed, Aug 25, 2021, at 5:18 AM, Dietmar Schindler wrote:
> > sent: 25. August 2021 02:14
> > from: "Lawrence Velázquez"
> > Cc: bug-bash@gnu.org
> > On Tue, Aug 24, 2021, at 4:44 PM, Dietmar P. Schindler wrote:
> > > Doesn't the example I gave above show that quotes are removed? If they
> > > weren't, how could word aa with pattern a""a constitute a match?
> > 
> > The quotes are handled by the matching process itself, *not* as
> > part of the usual shell expansions. …
> 
> I didn't say that quotes were handled "as part of the usual shell 
> expansions" (on the contrary, in my original message I wrote "this 
> expansion series ["Shell Expansions" performed on the command line] is 
> not performed on the case command's _word_ and patterns"), so I'm sorry 
> I don't get why you are emphasizing this.

The nub (which I unwisely left implicit) was that the quotes are
handled differently from usual, making it misleading at best to
say, unqualified, that quote removal occurs before the matching
happens.  At a minimum you'd need to elaborate on the special sauce
that Chet described.

-- 
vq

Re: Handling options with optional arguments with getopts

[Lawrence Velázquez]

On Fri, Aug 27, 2021, at 1:20 PM, nigelberlinguer wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, August 27, 2021 4:02 PM, Robert Elz  wrote:
> > XBD 12.2 guideline 7 is:
> >
> > Guideline 7: Option-arguments should not be optional.
> >
> > That is, if you want to be able to give an option arg, or not give one,
> > those should be implemented as 2 separate options.
> 
> It should be noted though, that the POSIX requirement by "Guideline 7"
> is not guided by actual portability in the technical sense but by a
> rule written in the POSIX standard.  Perhaps there should be an update
> to POSIX on what is actually portable or not

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

-- 
vq

Re: Squiggly heredoc - new feature request

[Lawrence Velázquez]

On Mon, Aug 30, 2021, at 4:06 PM, Přemysl Šťastný wrote:
> I think, it would be nice, if you implemented Squiggly heredoc, which 
> solves this problem by ignoring both leading spaces and leading tabs. eg.
> 
> func()(
>    cat <<~ EOF
>      blabla
>    EOF
> )

'<<~' is already syntactically valid.

bash-5.1$ cat <<~
heredoc> foo
heredoc> bar
heredoc> ~
foo
bar

bash-5.1$ cat <<~EOF
heredoc> foo
heredoc> bar
heredoc> ~EOF
foo
bar

bash-5.1$ echo abc >EOF; cat <<~ EOF
heredoc> foo
heredoc> bar
heredoc> ~
abc

ksh93s (I think) implemented a version of this behavior using '<<#'.
That's currently a syntax error in bash, unless interactive_comments
is disabled.

bash-5.1$ shopt -s interactive_comments
bash-5.1$ cat <<# EOF
bash: syntax error near unexpected token `newline'

bash-5.1$ shopt -u interactive_comments
bash-5.1$ echo abc >EOF; cat <<# EOF
heredoc> foo
heredoc> bar
heredoc> #
abc

-- 
vq

Re: Squiggly heredoc - new feature request

[Lawrence Velázquez]

On Mon, Aug 30, 2021, at 5:22 PM, Přemysl Šťastný wrote:
> Will ksh93 version ever get to upstream?

I don't know what you mean by that.  ksh is not "downstream" of
bash; it is a separate project.  Whether bash incorporates this
feature or one like it is up to Chet, who hasn't yet chimed in.

> This ugly 'bug' is here for decades and really irritates me
> and many people, who ever used shell for larger scripting and
> don't like to use tabs.

I don't really have an opinion.  To me it's just another shell
scripting wart to get used to, and not even the ugliest one.
I would just prefer that a potential implementation not diverge
from prior art needlessly.

-- 
vq

Re: Squiggly heredoc - new feature request

[Lawrence Velázquez]

> On Aug 31, 2021, at 3:16 AM, Přemysl Šťastný  wrote:
> 
> I didn't realize yesterday, that ksh93 is not a nick name, but ksh version 
> 93. :D

Sort of.

> So it would be okey with you, if I try to implement it using <<#?

The bash maintainer (who is not me) hasn’t yet indicated whether this is 
something he’d be interested in pursuing. The behavior is underspecified (ksh 
does not blindly remove all leading whitespace), and there are still 
compatibility concerns (as I mentioned earlier, there is currently at least one 
circumstance in which ‘<<#’ is valid syntax).

> Is there any git repo of bash?

Yes.

https://savannah.gnu.org/git/?group=bash

-- 
vq
Sent from my iPhone

Re: Squiggly heredoc - new feature request

[Lawrence Velázquez]

On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote:
> ksh does not blindly remove all leading whitespace

For the curious, this is how ksh(1) describes it:

If '#' is appended to '<<', then leading spaces and tabs
will be stripped off the first line of the document and up
to an equivalent indentation will be stripped from the
remaining lines and from 'word'.  A tab stop is assumed to
occur at every 8 columns for the purposes of determining
the indentation.

-- 
vq

Re: help adding some features to 5.1

[Lawrence Velázquez]

On Wed, Sep 1, 2021, at 8:20 PM, Ananth Chellappa wrote:
> I hope I can make a genuine contribution at some point.

If you're hoping/planning on getting these changes accepted into
bash, it might be worth hashing out details with Chet before expending
your time and energy.  (I am not a contributor, nor do I have any
formal affiliation with the project.  I just write email.)

On the other hand, if this is for yourself, then hack away!

-- 
vq

Re: ?maybe? RFE?... read -h ?

[Lawrence Velázquez]

On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote:
> L A Walsh  writes:
> > I know how -h can detect a symlink, but I was wondering, is
> > there a way for bash to know where the symlink points (without
> > using an external program)?
> 
> My understanding is that it has been convention to use the "readlink"
> program for a very long time, so there's never been much demand to add
> it to bash.  Of course, looking at the options to readlink shows that
> there are several different meanings of "where a symlink points".

The distribution ships with a "realpath" loadable builtin, FWIW.

bash-5.1$ enable -f /opt/local/lib/bash/realpath realpath
bash-5.1$ type realpath
realpath is a shell builtin
bash-5.1$ readlink /usr/bin/cc
clang
bash-5.1$ realpath /usr/bin/cc
/usr/bin/clang

-- 
vq

Re: ?maybe? RFE?... read -h ?

[Lawrence Velázquez]

On Mon, Sep 6, 2021, at 6:46 PM, L A Walsh wrote:
> On 2021/09/05 20:54, Lawrence Velázquez wrote:
> > The distribution ships with a "realpath" loadable builtin, FWIW.
> >   
> 
> I didn't know that... um, my bash isn't quite there yet:
> 
> Ishtar:/> enable -f /opt/local/lib/bash/realpath realpath
> 
>   -bash: enable: cannot open shared object /opt/local/lib/bash/realpath: 
> /opt/local/lib/bash/realpath: cannot open shared object file: No such 
> file or directory

You have to adapt the path for your own installation (assuming your
installation includes the loadables to begin with).

-- 
vq

Re: help for needs to mention for ((...))

[Lawrence Velázquez]

On Sun, Sep 19, 2021, at 3:25 PM, 積丹尼 Dan Jacobson wrote:
> $ help for
> only mentions
>for name [ [ in [ word ... ] ] ; ] do list ; done
> and needs to be updated to mention
>for (( expr1 ; expr2 ; expr3 )) ; do list ; done

Not particularly intuitive, but:

bash-5.1$ help 'for (('
for ((: for (( exp1; exp2; exp3 )); do COMMANDS; done
Arithmetic for loop.

Equivalent to
(( EXP1 ))
while (( EXP2 )); do
COMMANDS
(( EXP3 ))
done
EXP1, EXP2, and EXP3 are arithmetic expressions.  If any expression is
omitted, it behaves as if it evaluates to 1.

Exit Status:
Returns the status of the last command executed.

-- 
vq

Re: current bash.git.devel segfaults on my code

[Lawrence Velázquez]

On Wed, Oct 20, 2021, at 5:07 PM, Alex fxmbsw7 Ratchev wrote:
> you got other cmd suggestions i can run to help debugging ? im very limited
> in bin.c debugging

You could bisect the devel branch to determine whether your problem
was caused by a change to bash and, if so, which commit is responsible.

https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#_binary_search
https://git-scm.com/docs/git-bisect

-- 
vq

Re: current bash.git.devel segfaults on my code

[Lawrence Velázquez]

On Wed, Oct 20, 2021, at 7:43 PM, Alex fxmbsw7 Ratchev wrote:
> to tell u honestly, im in no state to read freely happily new docs

I'll be honest as well: If you're not going to put in effort beyond
running commands that are spoon-fed to you, then I'm not going to
put in effort beyond dumping URLs into emails.

Of course, others who don't mind this asymmetry are free to provide
further assistance.

> if u dont specificly help with the cmds, i cannot succeed much

That's unfortunate.

-- 
vq

Re: bash git commands ( for noobs like me )

[Lawrence Velázquez]

On Fri, Oct 22, 2021, at 10:27 PM, Dennis Williamson wrote:
> I'm sure there are lists that provide git support.

Like this one.

https://groups.google.com/g/git-users

Or this one.

mailto:g...@vger.kernel.org

-- 
vq

Re: current bash.git.devel segfaults on my code

[Lawrence Velázquez]

On Sun, Oct 24, 2021, at 7:28 AM, Shehu Dikko wrote:
> Use this tldr client to get all the git tips you need and much else besides:
>
> https://github.com/raylee/tldr-sh-client
>
> tldr: https://tldr.sh

There's also #git on irc.libera.chat, if you prefer.

-- 
vq

Re: some string issue inside cmd not found handle

[Lawrence Velázquez]

On Sat, Nov 6, 2021, at 2:41 AM, Alex fxmbsw7 Ratchev wrote:
> cat function/command_not_found_handle
> m "$BASH_COMMAND"
>
> type m
> m is aliased to `vim'
>
> type command_not_found_handle
> command_not_found_handle is a function
> command_not_found_handle ()
> {
> vim "$BASH_COMMAND"
> }

lmao so you're going to go ahead and do this anyway, incredible

> foo
> # vim opens, with the bash cmd as arg ( threated as filename )
>
> "vim "$BASH_COMMAND"" [New] 0,0-1
>All

Do you expect BASH_COMMAND to have the value of the original command?
It only works that way within traps.  `command_not_found_handle`
isn't a trap.

bash-5.1$ command_not_found_handle() { declare -p BASH_COMMAND; }
bash-5.1$ foo
declare -- BASH_COMMAND="declare -p BASH_COMMAND"

This is the same behavior you'd see outside of `command_not_found_handle`.

bash-5.1$ declare -p BASH_COMMAND
declare -- BASH_COMMAND="declare -p BASH_COMMAND"

Maybe try using the positional parameters instead.

bash-5.1$ command_not_found_handle() { printf '<%s>\n' "$@"; }
bash-5.1$ foo a b c





-- 
vq

Re: bash conditional expressions

[Lawrence Velázquez]

On Fri, Nov 12, 2021, at 4:36 AM, Mischa Baars wrote:
> Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash
> 5.1.8) this returns a false:
> touch test; if [[ -N test ]]; then echo true; else echo false; fi;
>
> [...]
>
> As I understand it, -N stands for NEW and therefore should return a true
> when either a 'touch -a test' or a 'touch -am test' is given.

FWIW, there's some disagreement on this.

% cat foo_test
test -N foo
echo "$?"
% touch foo
% /bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test'
3.2.57(1)-release
0
% /opt/local/bin/bash -c 'echo "$BASH_VERSION"; . ./foo_test'
5.1.8(1)-release
1
% ksh -c 'echo "${.sh.version}"; . ./foo_test'
Version AJM 93u+ 2012-08-01
1
% yash -c 'echo "$YASH_VERSION"; . ./foo_test'
2.51
1
% zsh -c 'echo "$ZSH_VERSION"; . ./foo_test'
5.8
0

-- 
vq

Re: Document -x and -vx give the same results

[Lawrence Velázquez]

On Sun, Nov 14, 2021, at 11:40 AM, 積丹尼 Dan Jacobson wrote:
> Man page says:
>-vPrint shell input lines as they are read.
>-xPrint commands and their arguments as they are executed.
> Perhaps mention that -x and -vx give the same results, often or always.

They don't, though.

% bash -xc 'echo "$BASH_VERSION"'
+ echo '5.1.8(1)-release'
5.1.8(1)-release
% bash -xvc 'echo "$BASH_VERSION"'
echo "$BASH_VERSION"
+ echo '5.1.8(1)-release'
5.1.8(1)-release

-- 
vq

Re: Unclosed quotes on heredoc mode

[Lawrence Velázquez]

On Wed, Nov 17, 2021, at 7:35 AM, João Almeida Santos wrote:
> I’m a programming student currently on 42 School in Lisbon, and one of 
> our projects is to create a minishell, and to mimic the behavior of 
> bash.

Nice!

> While testing the heredoc mode, I realized that the $ is not 
> interpreted as variable expansion. That’s interesting.

Are you talking about your project or bash?  In the latter (and
related shells), expansion is only suppressed in a here-document
if, when the delimiter is specified, it is at least partially quoted.

$ cat < But the reason why I’m emailing you is that I whenever I tried to use 
> an unclosed quote on heredoc, it doesn’t seem to handle well…it never 
> finishes the heredoc.
> I tried \n for paragraph, verbatim inserting enter, closing quotes on 
> the next line, …don’t know what else to test.

This description is a bit hard to follow.  Could you provide a small
bit of code that demonstrates the issue?

-- 
vq

Re: Unclosed quotes on heredoc mode

[Lawrence Velázquez]

On Tue, Nov 23, 2021, at 10:35 PM, Martijn Dekker wrote:
> Op 20-11-21 om 23:54 schreef Robert Elz:
>> What the devel one does is unknown to me, I don't think I even have
>> the means to obtain it (I have nothing at all git related, and no interest
>> in changing that state of affairs).
>
> Github allows downloading a gzipped tarball of any branch's current 
> state via https://github.com///tarball/
>
> There's a regularly updated mirror of the bash repo here:
> https://github.com/bminor/bash/
>
> So, the URL to the .tgz for the current bash devel branch is:
> https://github.com/bminor/bash/tarball/devel

The official repository also provides a snapshot at
.

-- 
vq

Re: some.. bug .. ?

[Lawrence Velázquez]

On Sun, Nov 28, 2021, at 4:01 AM, Alex fxmbsw7 Ratchev wrote:
> printf 'e=. ; (( $# > 1 )) && $e afile "${@:1:$# -1}"' >afile ; . afile 1 2
> 3
>
> bash: : command not found
>
>
> 1. the cmd=. works out, no command error
> 2. on second+ run it shows this error, as bin/. is no command in $PATH
> 3. the command is not '' anyway its .
>
> 4. the first run is np, why, $e = . and then '.' is no bin command, why
> does bash run it without an eval
> 5. why doesnt it on later runs

I can't reproduce this.

% PS1='$ ' PS2='+ ' bash --norc; rm -f afile
$ printf '%s\n' "$BASH_VERSION"
5.1.8(1)-release
$ printf 'e=. ; (( $# > 1 )) && $e afile "${@:1:$# -1}"' >afile
$ . afile 1 2 3
$ . afile 1 2 3
$ . afile 1 2 3

-- 
vq

Re: Fwd: Bug: rm -rf /*/*

[Lawrence Velázquez]

On Tue, Nov 30, 2021, at 6:34 PM, Chet Ramey wrote:
> On 11/30/21 3:53 PM, Robert Swinford wrote:
>> (and globbing in zsh evals /*/* to //):
>
> Why? Under what circumstances is that correct?

I assume that OP is incorrectly describing zsh's default behavior
of intercepting risky ''rm'' commands and interactively requesting
confirmation.

$ zsh -f
% rm -rf /*/*
zsh: sure you want to delete all the files in /* [yn]?

This behavior is specific to ''rm'' and can be disabled [*].  In
other contexts, zsh expands ''/*/*'' more or less as usual.  This
can be verified trivially.

$ zsh -fc 'print -rC1 -- /*/*'

[*]: https://zsh.sourceforge.io/Doc/Release/Options.html#index-RMSTARSILENT

-- 
vq

Re: bash manual on interactive shell

[Lawrence Velázquez]

On Sun, Dec 12, 2021, at 9:03 PM, Mallika wrote:
> I'm a little confused about how all the and's and or's combine (I suppose
> it's obvious if you're a little more familiar with the material - but it
> would be great if it were possible to express this by indentation),

It's a relatively confusing state of affairs.  An unordered list
might help.

> but I'd actually decided to write in just to clarify that first line:
> "started without non-option arguments,"
>
> Does "option arguments" mean "option*al* arguments"?

No.  While all option arguments happen to be optional, not all
optional arguments are options.

An "option argument", roughly speaking, is an argument that begins
with one or two hyphen-minuses and affects the configuration of the
invoked shell.  They are described here:

https://www.gnu.org/software/bash/manual/html_node/Invoking-Bash.html

> If the double-negative* is *actually correct, wouldn't the same sentiment
> be expressed by "started with only option(al?) arguments"? Double-negatives
> are inherently confusing, so it would be helpful to avoid them.

Something like "with only option arguments" could easily be
misunderstood as "with one or more option arguments".

-- 
vq

Re: Zero-length indexed arrays

[Lawrence Velázquez]

On Thu, Dec 16, 2021, at 11:01 PM, Dale R. Worley wrote:
> A bit ago I was debugging a failing script at work.  It turns out that
> when you say
> FOO=(x y z)
> then the variable FOO is an array and is defined.  But when you say
> FOO=()
> then the variable FOO is an array (because ${#FOO[*]} substitutes an
> integer viz. 0) but it is *not* defined (because ${FOO[*]} generates an
> error when "set -u" is in effect).

Did you mean to say that ${#FOO[*]} causes an error?  Because
${FOO[*]} does not, à la $*:

% bash --version | head -n 1
GNU bash, version 5.1.12(1)-release (x86_64-apple-darwin18.7.0)
% bash -uc ': "${FOO[*]}"'
% bash -uc ': "${#FOO[*]}"'
bash: line 1: FOO: unbound variable

> It turns out that this can matter, if you do something like this:
>
> set -u# for safety
> ...
> if ...
> then
> FOO=(...)
> else
> FOO=()
> fi
> ...
> FOO_PLUS=("${FOO[@]}" x y z w)

I have to assume you meant something else here as well.  This example
never causes any errors.

% cat foo.bash; echo
set -u

if [[ -n "${1+set}" ]]; then
FOO=(a b c)
else
FOO=()
fi

FOO_PLUS=("${FOO[@]}" x y z w)
declare -p FOO_PLUS

% bash foo.bash
declare -a FOO_PLUS=([0]="x" [1]="y" [2]="z" [3]="w")
% bash foo.bash woot
declare -a FOO_PLUS=([0]="a" [1]="b" [2]="c" [3]="x" [4]="y" [5]="z" 
[6]="w")

Like ${FOO[*]}, ${FOO[@]} and $@ are exempt from ''set -u''.

-- 
vq

Re: Zero-length indexed arrays

[Lawrence Velázquez]

On Thu, Dec 16, 2021, at 11:45 PM, Lawrence Velázquez wrote:
> Did you mean to say that ${#FOO[*]} causes an error?  Because
> ${FOO[*]} does not, à la $*:
>
> [...]
>
> Like ${FOO[*]}, ${FOO[@]} and $@ are exempt from ''set -u''.

Perhaps you're using an old bash, like the one shipped with macOS?

% /bin/bash --version | head -n 1
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
% /bin/bash -uc ': "${FOO[*]}"'
/bin/bash: FOO[*]: unbound variable
% /bin/bash -uc ': "${FOO[@]}"'
/bin/bash: FOO[@]: unbound variable

If so, there's not much anyone here can do about it.

-- 
vq

Re: Format specifier for printf in manual

[Lawrence Velázquez]

On Tue, Dec 21, 2021, at 5:40 PM, fatiparty--- via Bug reports for the GNU 
Bourne Again SHell wrote:
> Have tried to read some information about the format specifier for 
> printf, particularly the width, precision and left justification for 
> %s, but could not find any.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html#tag_20_94_13
https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#index-printf

Please do not use this mailing list for inquiries that are not about
bugs.  There is no bug here.

-- 
vq

Re: Zero-length indexed arrays

[Lawrence Velázquez]

On Tue, Dec 21, 2021, at 10:48 PM, Dale R. Worley wrote:
> Lawrence Velázquez  writes:
>> Did you mean to say that ${#FOO[*]} causes an error?  Because
>> ${FOO[*]} does not, a la $*:
>
> The case that matters for me is the Bash that ships with "Oracle Linux".
> Which turns out to be version 4.2.46(2) from 2011, which is a lot older
> than I would expect.  But it *does* cause an error in that verison:
>
> $ ( set -u ; FOO=() ; echo "${FOO[@]}" )
> bash: FOO[@]: unbound variable
> $ bash -uc ': "${FOO[*]}"'
> bash: FOO[*]: unbound variable
> $ 
>
>> Like ${FOO[*]}, ${FOO[@]} and $@ are exempt from ''set -u''.
>
> It looks like that's a change since 4.2.46.

Yes, it appears to be from 4.4.

https://git.savannah.gnu.org/cgit/bash.git/tree/CHANGES?id=15409324f1974d41c183904ad575da7188058c1c#n1512

This document details the changes between this version,
bash-4.4-rc2, and the previous version, bash-4.4-beta2.

[...]

3.  New Features in Bash

a.  Using ${a[@]} or ${a[*]} with an array without any assigned
elements when the nounset option is enabled no longer throws
an unbound variable error.


> Is there text in the manual page about that?

I don't know.

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Fri, Jan 21, 2022, at 12:22 AM, L A Walsh wrote:
> On 2022/01/18 22:31, Alex fxmbsw7 Ratchev wrote
>>> Fix:
>>> Haven't looked deeply into the bash internals but sanitizing the directory
>>> name (along with other user-controlled substitutions in the prompt) should
>>> work.
>>> 
> Sanitizing? What's that?
> Especially in a way that won't break existing legal usages?

Curious what "existing legal usages" there are for allowing a change
of working directory to result in arbitrary escape sequences being
sent to your terminal.

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Tue, Jan 18, 2022, at 9:13 PM, Josh Harcombe wrote:
> If a folder that is being displayed as part of the PS1 prompt contains
> escape sequences, bash will interpret them literally instead of escaping
> them like zsh does for example. Escape sequences should be fine if directly
> part of the prompt string and I'm not aware of any way for this to cause
> issues other than messing with the prompt string in potentially unexpected
> ways.

Depends what you consider to be an issue.  Personally, I would be
less than pleased if my whole terminal turned red just because I
changed into a directory that happened to have a weird name.

% PS1='\w \$ ' bash
/tmp $ dir=$'\e[31m\e[41m\e[2J'
/tmp $ mkdir "$dir"
/tmp $ cd "$dir"  # lol

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Sat, Jan 22, 2022, at 5:57 AM, Andreas Schwab wrote:
> On Jan 21 2022, Lawrence Velázquez wrote:
>
>> Depends what you consider to be an issue.  Personally, I would be
>> less than pleased if my whole terminal turned red just because I
>> changed into a directory that happened to have a weird name.
>
> Put $(tput sgr0) in PS1.

It was a rhetorical example.  I don't actually use bash as my
interactive shell.

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Fri, Jan 21, 2022, at 3:29 PM, Chet Ramey wrote:
> On 1/21/22 1:43 AM, Lawrence Velázquez wrote:
>
>> Personally, I would be
>> less than pleased if my whole terminal turned red just because I
>> changed into a directory that happened to have a weird name.
>
> A mild annoyance at best, don't you think?

What can I say?  I'm easily annoyed!

But yeah, probably no more than an annoyance.

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Sat, Jan 22, 2022, at 6:10 PM, L A Walsh wrote:
> So I would ask which user-controlled prompts are "illegal" such that 
> they would be sanitized?

I guess you're concerned with "(along with other user-controlled
substitutions in the prompt)".  I'm not entirely sure what the OP
meant by that, and I don't think anyone else is talking about
anything but the results of \w and \W and such.

-- 
vq

Re: Bash not escaping escape sequences in directory names

[Lawrence Velázquez]

On Wed, Feb 2, 2022, at 9:30 AM, L A Walsh wrote:
> Instead of worrying about effects of dirnames on PS1, one might worry
> about how the directory names were created in the first place, and then
> worry about why one would deliberately 'cd' into such a directory.

https://en.wikipedia.org/wiki/Red_herring

-- 
vq

Re: Incorrect alias expansion within command substitution

[Lawrence Velázquez]

> On Sat, Feb 5, 2022 at 9:46 PM Chet Ramey  wrote:
>>
>> On 2/5/22 3:44 PM, Alex fxmbsw7 Ratchev wrote:
>> > maybe ask about an shopt feature to enable straight alias expansion
>> > when the aliases are following ..
>>
>> How would that, whatever it is, help you here?

I think he wants an option that allows expansion of arbitrarily
long sequences of aliases, regardless of lexical context.

On Sat, Feb 5, 2022, at 3:54 PM, Alex fxmbsw7 Ratchev wrote:
> it would make the whole work at alias level
> alias (symbolic) 1=$(( 2=1+2 3=+ 4=1+2 5=))
> 1 2 3 4 5
> works
> [i wish]

*screaming at the sky*

Have you considered not writing code like this?

-- 
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

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: 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: 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: 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 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: 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: 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 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: 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: 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: 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: 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: 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: [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: [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: >&"$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: 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: 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: 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: [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: 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: 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 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 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: 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 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: 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 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: 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: 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 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: 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: 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: 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