Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, 21 May 2024 at 23:16, Koichi Murase wrote: > 2024年5月21日(火) 14:56 Phi Debian : > > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > > know if that would be good enough for the initial purpose. > > There are already shell-function implementations at >

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Tue, 21 May 2024 at 03:44, Chet Ramey wrote: > On 5/17/24 1:15 PM, Robert Elz wrote: > > >| If `nosort' means no sorting, there is no imposed ordering, and > ascending > >| and descending are meaningless. > > > > Sure, but directory order, and reverse directory order aren't (and

Re: [PATCH v2 5/8] builtins/source: parse the -i option

On Fri, 17 May 2024 at 04:18, Chet Ramey wrote: > On 5/16/24 11:54 AM, G. Branden Robinson wrote: > > At 2024-05-16T11:36:50-0400, Chet Ramey wrote: > >> On 5/15/24 6:27 PM, Robert Elz wrote: > >>> and any attempt to use a relative path (and you > >>> can exclude ./anything or ../anything from

Re: proposed BASH_SOURCE_PATH

On Thu, 16 May 2024 at 03:03, Chet Ramey wrote: > On 5/14/24 2:08 AM, Martin D Kealey wrote: > > I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I > would > > like to suggest three tweaks to its semantics. > > > > A common pattern is to unpac

Re: proposed BASH_SOURCE_PATH

On Thu, 16 May 2024 at 02:48, Koichi Murase wrote: > 2024年5月14日(火) 15:09 Martin D Kealey : > > 1. I therefore propose that where a relative path appears in > > BASH_SOURCE_PATH, it should be taken as relative to the directory > > containing $0 (after resolving symlinks),

Re: proposed BASH_SOURCE_PATH

On Tue, 14 May 2024 at 20:10, konsolebox wrote: > On Tue, May 14, 2024 at 2:09 PM Martin D Kealey > wrote: > > 2. Search BASH_SOURCE_PATH when any relative path is given, not just a > path > > that lacks a '/', so that libraries can be organized into subdirect

proposed BASH_SOURCE_PATH

I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would like to suggest three tweaks to its semantics. A common pattern is to unpack a script with its associated library & config files into a new directory, which then leaves a problem locating the library files whose paths are

Re: Re: Re: [PATCH 0/4] Add import builtin

On Sun, 5 May 2024 at 11:50, Koichi Murase wrote: > > Ideally, they'll be using bash's native import under the hood! > > Yes, module managers still need to implement their own "import" > command while using the proposed "import" primitive under the hood, > and it's simply interchangeable with

Readdelim (was Re: Examples of concurrent coproc usage)

On Sun, 28 Apr 2024, 05:03 Carl Edquist, wrote: > > > I would hope that mapfile/readarray could do better, since it's not > > obligated to leave anything in the input stream. > > That is an interesting thought, although mapfile seems to read a byte at a > time also. > > [I'm not suggesting this

Re: [Help-bash] difference of $? and ${PIPESTATUS[0]}

On Mon, 22 Apr 2024, 18:13 felix, wrote: > Hi, > > Coming on this very old thread: > > [the] man page say[s]: > > PIPESTATUS > An array variable (see Arrays below) containing a list of exit > status values from the processes in the most-recently-executed >

Re: Examples of concurrent coproc usage?

On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote: > When I say "token" I just mean a record with whatever delimiter you're > referring to using. Ok that makes sense. Assuming the reading stops after consuming the first delimiter (which is > necessary for the 'read' builtin), then you end up

Re: Examples of concurrent coproc usage?

On Sun, 21 Apr 2024, 10:13 Carl Edquist, wrote: > On Thu, 18 Apr 2024, Martin D Kealey wrote: > > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) > > to add a new system call such as readln() or readd()? > > You mean, specifically in order to impl

Re: Examples of concurrent coproc usage?

On Sat, 20 Apr 2024 at 01:14, Chet Ramey wrote: > On 4/17/24 8:55 PM, Martin D Kealey wrote: > > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) to > > add a new system call such as readln() or readd()? > > They'd probably point you to an optimize

Re: Examples of concurrent coproc usage?

On Wed, 17 Apr 2024, Chet Ramey wrote: > On 4/16/24 2:46 AM, Carl Edquist wrote: > > > But the shell is pretty slow when you ask it to shovel data around like > > this.  The 'read' builtin, for instance, cautiously does read(2) calls of a > > single byte at a time. > > It has to do it that way

Re: [PATCH v2 04/18] doc/bash.1: improve typography of ellipses

On Thu, 1 Feb 2024 at 07:54, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > v2: Prevent confclit with PATCH v2 01/18. > Apply ellipsis advice from groff_man_style(7). > • The dummy character escape sequence \& follows the ellipsis when further > text will follow after space on the

Re: Parsing regression with for loop in case statement

I can confirm that this changed between 4.4.23(49)-release and 5.0.0(1)-beta, which coincides with the parser being largely rewritten. On Thu, 11 Apr 2024 at 12:51, wrote: > The POSIX shell grammar specifies that a newline may optionally appear > before the in keyword of a for loop. I don't

Re: Potential Bash Script Vulnerability

, 9 Apr 2024 10:42:58 +1200 > Martin D Kealey wrote: > > > On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote: > > > > > the method by which vim amends files is similar to that of sed -i. > > > > > > > I was about to write "nonsense, vim

Re: Potential Bash Script Vulnerability

On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote: > the method by which vim amends files is similar to that of sed -i. > I was about to write "nonsense, vim **never** does that for me", but then I remembered that using ":w!" instead of ":w" (or ":wq!" instead of ":wq") will write the file as

Re: Examples of concurrent coproc usage?

I'm somewhat uneasy about having coprocs inaccessible to each other. I can foresee reasonable cases where I'd want a coproc to utilize one or more other coprocs. In particular, I can see cases where a coproc is written to by one process, and read from by another. Can we at least have the

Re: Manual: clarify what POSIX stands for

On Thu, 25 Jan 2024, 20:04 Alan Urmancheev, wrote: > Currently, Bash's manual definitions section mentions POSIX, but doesn't > explain what that abbreviature stands for ... > I think that abbreviatures can be confusing, especially when you don't get > to know what they stand for. > I

Bug tracking

On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > On 11/30/23 5:18 AM, Martin D Kealey wrote: > > > If there's a bug tracking system beyond "threads in a mailing list", I'd > > like to know how I can get access to it. > > https://savannah.gnu.org/support

Re: Debian bug #929178: wrong trap displayed inside functions

On Tue, 26 Mar 2024 at 04:05, Oğuz wrote: > On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson > wrote: > > [1] > > [1] http... > > I keep seeing this. Why don't you guys just paste the link? > When forwarding incoming HTML to a text-only list, most mailing list servers will put the

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

Hi Dan How about « fc -ln » ? It might be helpful to have explicit cross-references between the help displays for «history» and «fc». -Martin On Sun, 24 Mar 2024 at 15:40, Dan Jacobson wrote: > $ help history > should mention how in the world one is supposed to just print the plain >

Re: multi-threaded compiling

> On Mon, Mar 11, 2024 at 8:20 PM Chet Ramey wrote: > > On 3/11/24 2:50 PM, Mischa Baars wrote: > > > Which sort of brings us back to the original question I suppose. Who > does > > > that line of code function from a script and why does it fail from the > > > command line? > > > > Job control

Re: multi-threaded compiling

In section one, the problem is that "wait -n" does not do what you think it does. (Lots of us think this behaviour is broken, and it may be fixed in an upcoming version of Bash.) You don't need '-n' when you specify a PID; the fix is simply to remove it. In section two, the problem is that quote

Re: human-friendly ulimit values?

Personally I don't have any problem with 800 kB == 8 GB or 104857600 KiB == 100 GiB, but it's not as if having nice round power-of-two numbers really matters in *this* case, where 107500 KiB is close enough to 1 TiB. But I guess not everyone is as comfortable with mental arithmetic. On

Re: declare -f does not output esac pattern correctly

On Tue, 27 Feb 2024 at 18:48, Oğuz wrote: > On Tuesday, February 27, 2024, Martin D Kealey > wrote: > >> I've been thinking for a while now that POSIX made a mistake when it >> permitted ';;' before the closing 'esac'. >> > > I think that decision was made befo

Re: declare -f does not output esac pattern correctly

I've been thinking for a while now that POSIX made a mistake when it permitted ';;' before the closing 'esac'. If ';;' were prohibited there, then the parser could be sure that the next word after every ';;' would be a pattern, even if it looks like 'esac'. But as things stand, there's an

Re: Bug: Ligatures are removed as one character

n Fri, 23 Feb 2024, Chet Ramey wrote: > On 2/19/24 9:26 PM, Avid Seeker wrote: > > When pressing backspace on Arabic ligatures (including characters with > > diacritics), they are removed as if they are one character. > > As you might guess, readline doesn't know much about Arabic, per se. In a >

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

On Wed, 21 Feb 2024 at 08:09, Chet Ramey wrote: > On 2/20/24 4:11 AM, Martin D Kealey wrote: > > Ideally each function invocation would have its own variable namespace, > > only using the global namespace as a fall-back, but that creates > > complications with exported var

Re: [PATCH] retry opening startup files on EINTR

On Wed, 21 Feb 2024 at 02:37, Grisha Levit wrote: > sigaction(2) says: > > The affected system calls include open(2), read(2), write(2), > sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications > channel or a slow device (such as a terminal, but not a regular file) > >

Re: Bug: Ligatures are removed as one character

It's been a long time since I looked into Unicode, but this is what I remember. Depending on the Unicode normalisation level, backspace is *supposed* to remove a letter and all its associated combining marks. The root problem seems to be that some Arabic letters change from "non-combining" to

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

On Sat, 17 Feb 2024 at 02:32, Chet Ramey wrote: > Let's say we take the approach of restricting attribute changes on readonly > variables to export/trace/local. > > Should it be an error to attempt to set other attributes (it already is > with nameref), or should declare silently ignore it? > I

Re: About `M-C-e` expand result `'` failed

On Sat, 3 Feb 2024 at 07:21, Chet Ramey wrote: > On 2/2/24 3:36 PM, Zachary Santer wrote: > > Ultimately, what I'm saying is that a different bindable function that > performs all the shell expansions other than quote removal would be more > useful than shell-expand-line. > > OK, I'll take that

Re: About `M-C-e` expand result `'` failed

On Sun, 4 Feb 2024 at 15:17, Koichi Murase wrote: > 2024年2月4日(日) 12:59 Martin D Kealey : > > I am generally concerned about breaking changes that affect existing > scripts, but I see changes to readline as less problematic, > > I also assume shell scripts, but shell scrip

Re: About `M-C-e` expand result `'` failed

On Sun, 4 Feb 2024, 02:01 Koichi Murase, wrote: > I now think I should leave a comment because even Martin (who I believed > was one of the careful people about backward compatibility as seen in > [1,2]) seems to suggest a breaking change. > That's a fair point. I am generally concerned about

Re: About `M-C-e` expand result `'` failed

On Wed, 31 Jan 2024 at 01:04, Andreas Schwab wrote: > On Jan 30 2024, Zachary Santer wrote: > > There's no way this is the intended behavior, right? > > The command is doing exactly what it is documented to do, that is do all > of the shell word expansions. > If that's how the documentation is

Re: ./script doesn't work in completion function

Chet has since pointed out that the debugger is not involved at all. On Mon, 22 Jan 2024, 18:17 Grisha Levit, wrote: > > That's not quite what happens. These scripts get executed by forking the > current bash process (without exec). The new shell resets its state and > runs the script. > I'm

Re: ./script doesn't work in completion function

Hi Oğuz On Sun, 21 Jan 2024 at 03:20, Oğuz wrote: > $ echo echo foo bar >s > $ chmod +x s > You seem to have created an invalid executable. It seems that scripts without a #! can only be run with help from the debugger library; for example, this is what I get when I run up

Re: completion very slow with gigantic list

How about: Don't sort the list, or consider "lazy sorting" only the portion of the list that's going to be displayed. (I'd suggest using an incremental Quicksort, which can yield a sorted sublist in almost linear time. (I started working on this for my zcomp module until I realised it was already

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

Random irreversible behaviour change strikes again. This changed in Bash 4.3.0, and to make matters worse, shopt -s compat42 does not restore the previous behaviour. Up to Bash 4.2, read -N1 would indeed set the receiving variable to empty while returning a zero status, having read only one

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

On Tue, 12 Dec 2023, 05:56 Zachary Santer, wrote: > On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey wrote: > > Part of the issue here is that distros -- Red Hat, at least -- never > > upgrade the version of bash they started with. Red Hat will `support' > > bash-4.2 as long as they support RHEL 7. >

Re: complete NAME seems to diasable completion for NAME in the case of git

On Fri, 22 Dec 2023, 05:55 Andreas Schwab, wrote: > If you want to print existing completions, use > complete -p [NAME...]. > The problem is, there's a documentation error. "help complete" says "if no options are supplied…" when it should say something more like "if the -p option is given, or

Re: issue with debug trap

On Sat, 16 Dec 2023 at 07:21, Giacomo Comes wrote: > debugon () { > trap 'if (($?)); then echo "$((LINENO-1)): $(sed -n "$((LINENO-1))p" > "$0")" ; fi' DEBUG > } > debugoff () { > trap '' DEBUG > } > > Although LINENO is the command that's about to be executed, that does not imply that

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

On Mon, 11 Dec 2023 at 06:55, Chet Ramey wrote: > It came up as a bug report in > > https://lists.gnu.org/archive/html/bug-bash/2019-06/mstheng00042.html > > > (part of the followup discussion after the second linked thread

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

On Sun, 10 Dec 2023, 12:15 Zachary Santer, wrote: > On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey > wrote: > > > > This change will break scripts that use $((10#$somevar)) to cope with > > > > somevar having leading zeroes OR BEING EMPTY. > Beside the point, b

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

Apropos the intentional breakage of ((10#$X)) I wrote (back in June 2023): > > Is there any chance this can be reversed before it becomes an official release? to which Chet replied: > This happened years ago. I have to admit that I'm finding that being a maintainer for a large suite of Bash

Re: Command hangs when using process substitution

Perhaps some background would help here; I start by highlighting this section in "man xclip": -l, -loops number of X selection requests (pastes into X applications) to wait for before exiting, with a value of 0 (default) causing xclip to wait for an unlimited number of

Re: test -lt inconsistent about white space

I'm more concerned that the error message is misleading; "integer expression expected" is NOT true; rather an integer LITERAL is expected (meaning an optional sign followed by one or more digits). As for fixing the inconsistency, I would rather get rid of whitespace skipping entirely, perhaps

Re: bash tries to parse comsub in quoted PE pattern

On Wed, 18 Oct 2023 at 22:19, Zachary Santer wrote: > On Tue, Oct 17, 2023 at 5:56 PM Emanuele Torre > wrote: > > > bash-5.1$ letters=( {a..z} ); echo "${letters["{10..15}"]}" > > k l m n o p > ... > So how important is it to maintain undocumented behavior? > This is the expected

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 02:03 Robert Elz, wrote: > Date:Sat, 14 Oct 2023 14:46:12 +1000 > From: Martin D Kealey > Message-ID: a2+3nnknhm5a+...@mail.gmail.com> > > > | Back when I used the Bourne Shell we didn't have `local`, so we used to &

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 03:15 Ti Strga, wrote: > On Fri, Oct 13, 2023 at 5:59 PM Grisha Levit > wrote: > > IMHO you'd be better off just putting a `{` line at the start and `}` > line at the end of your scripts > The big weakness of the "{}" approach is that if a writer forgets to do > that,

Re: variable set in exec'ing shell cannot be unset by child shell

On Sun, 15 Oct 2023, 03:05 Greg Wooledge, wrote: > On Sat, Oct 14, 2023 at 12:55:21PM -0400, Ti Strga wrote: > > it's just the "[[ -v foo ]]" tests to see where along the cloning > process we are. > > *Shudder* > Likewise, b. If the *real* goal is to overwrite a running script with a new

Re: variable set in exec'ing shell cannot be unset by child shell

On Sat, 14 Oct 2023 at 06:33, Robert Elz wrote: > The issue we have (which possibly might be similar in bash, but only > possibly - but it would explain the symptoms) is that when one does > > VAR=value command > > "VAR" is essentially made a local variable for command, so its value > in

Re: Warn upon "declare -ax"

On Wed, 6 Sep 2023, 01:46 Kerin Millar, wrote: > My pet name for it is arrayshock. > > $ arr=(foo bar baz) > $ export arr > $ env | grep ^BASH_ARRAY_ > BASH_ARRAY_arr%%=([0]="foo" [1]="bar" [2]="baz") > $ ./bash -c 'declare -p arr' > declare -ax arr=([0]="foo" [1]="bar" [2]="baz") > I've often

Re: RFC: changing printf(1) behavior on %b

If compatibility with C is really that important, shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s doesn't provide significant utility, and arguably differs from C's "take an int and output the corresponding single byte", not "take the first byte of a string and output that".

Re: give_terminal_to() / maybe_give_terminal_to() race

On Fri, 1 Sep 2023, 15:51 Earl Chew, wrote: > The controlling terminal must be reconfigured before the parent gets to > wait() for the job, and before the child gets to exec() the program (or their equivalents). This second point makes sense, but I don't really see why the first point is

Re: using exec to close a fd in a var crashes bash

On Wed, 23 Aug 2023, 12:20 Greg Wooledge, wrote: > > echo Hi {X}>/dev/null > > ls -l "/proc/$$/fd/$X" > > That's a really strange example. I wonder what would lead someone to > write that particular redirection. Oh I merely wanted to point out that the redirection persists beyond the echo

Re: using exec to close a fd in a var crashes bash

On Wed, 23 Aug 2023, 05:29 Greg Wooledge, wrote: > Excuse me now, while I go and close several open FDs in the shell where > I tested something the other day, which I had no idea were left open. > It's even worse than that; try: echo Hi {X}>/dev/null ls -l "/proc/$$/fd/$X" -Martin >

Re: using exec to close a fd in a var crashes bash

On Sun, 20 Aug 2023, 14:15 Grisha Levit, wrote: > [...] it would probably make sense to undo them if the exec fails and the > shell is not going to exit. > Just one question: how? The sequence of dup2() and close() calls has to occur before the execve() call. Whilst they could be undone by

Re: SLA Information

This has come to the bash-bug volunteers mailing list. Many of us, myself included, offer software consulting services, and would happily provide the support you seek, but it would be helpful if you could clarify the type of support that you're looking for: (a) bug fixes for bash itself, or (b)

Re: Assignment to RO variable

On Wed, 16 Aug 2023 at 14:24, Dennis Williamson wrote: > Your use of colon as a comment character is confusing. > Colon is only confusing if one mistakes it for a comment. Colon is not a comment, it's a command, and therefore included in xtrace output. Of course, the real problem is that

Re: ! history expansion occurs within arithmetic substitutions

On Tue, 15 Aug 2023 at 01:41, Chet Ramey wrote: > On 8/11/23 4:19 PM, Martin D Kealey wrote: > > I think it would be helpful to start this sentence with "The selected > > line…", to differentiate from the line just entered containing a "!". > > It'

Re: ! history expansion occurs within arithmetic substitutions

On Sat, 12 Aug 2023, 02:29 Dale R. Worley, wrote: > … The line is broken into words in the same fashion as when reading > input, so that several metacharacter-separated words surrounded by quotes > are considered one word. … I think it would be helpful to start this sentence with "The

Re: ! history expansion occurs within arithmetic substitutions

On Tue, 8 Aug 2023, 23:24 Zachary Santer, wrote: > Description: > Similarly, history expansion occurs within arithmetic substitutions. This > will never, ever be what the user wants. Correction: it will never ever be what YOU want. I can certainly think of uses for history expansion in

Re: comments inside command subst are handled inconsistently

On Sun, 30 Jul 2023, 08:22 Chet Ramey, wrote: > On 7/28/23 1:51 PM, Martin D Kealey wrote: > > > maybe it's time to start issuing a warning > > when [backticks are] used at all? 浪 > > There's no reason to use `` over $(...), but that form is still a required > POSIX

Re: git amend commit with backticks on cli causes tty to crash

On Fri, 21 Jul 2023, 03:31 Wiley Young, wrote: > The first time I saw this bug, tty3 crashed and isn't available any more > in /dev/pts . Partially reproducing the bug, ttys have crashed but they > become available for use again when I press Ctrl-Shift-t from > xfce4-terminal. > Point of order,

Re: comments inside command subst are handled inconsistently

On Thu, 27 Jul 2023, 18:31 Denys Vlasenko, wrote: > Try these two commands: > > $ echo "Date: `date #comment`" > Date: Thu Jul 27 10:28:13 CEST 2023 > > $ echo "Date: $(date #comment)" > > )" > Date: Thu Jul 27 10:27:58 CEST 2023 > > > As you see, #comment is handled differently in `` and $(). >

Re: problem anomalies , possibly aliases related

On Fri, 21 Jul 2023, 04:09 Greg Wooledge, wrote: > On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote: > > Saying that this *ought* to be done using aliases is not reasonable, as > it > > means forgoing the other stuff that functions can do, like taking > &g

Re: problem anomalies , possibly aliases related

On Thu, 20 Jul 2023, 23:28 Greg Wooledge, wrote: > The idea that this would "work" is quite surprising to me. Shell functions are SO unlike functions in other languages that it surprises me that anyone would assume any particular parallel holds. Everything about them is dynamic: where they

Re: problem anomalies , possibly aliases related

On Thu, 20 Jul 2023, 18:03 Grisha Levit, wrote: > Sounds like you want all the commands in the alias to be executed as a > group -- so you can just write it as one: > > alias bad='{ echo fail; continue; }' > That right there USED to work as a function: bad() { echo fail; continue; } But then

Re: problem anomalies , possibly aliases related

Hi Alex Aliases are not functions, and they don't work the same way. A function is like a separate script, except that it runs in the same process & context as the caller. Its meaning is determined as the script RUNS. An alias is quite different: it replaces tokens while the script is being

Re: slash appended to tab so its two // at end

Hi Alex On Wed, 19 Jul 2023 at 12:01, alex xmb ratchev wrote: > i in 5.2.15 bash aarch64 termux did > > $ cp -ap db2.*/ > What does your bash say in response to this: $ type -a $( ( complete -p cp || complete -p -D ) 2> /dev/null | tee -a /dev/stderr | sed -n 's/.* -F \([^ ]*\).*/\1/p' )

Re: [PATCH 1/2] <<# indent-stripping heredoc

On Sat, 15 Jul 2023, 10:18 Dennis Williamson, wrote: > Would a declared spaces-per-level indent amount be useful? Something like > <<4# that would be the script writer's responsibility to conform to since > they set it. This might be in addition to the already proposed <<#. > I briefly pondered

Re: [PATCH 1/2] <<# indent-stripping heredoc

On Fri, 14 Jul 2023 at 09:47, Grisha Levit wrote: > This patch implements the ksh93-style <<# redirection operator to enable > indentatable heredocs. On the whole I think this is great, and thankyou for working up the patch, but I would like to offer some comments and suggestions: Firstly,

Re: maybe a bug in bash?

On Thu, 29 Jun 2023 at 23:42, Greg Wooledge wrote: > The answer to this is [...] just ssh in as root instead of nonroot + sudo. > > Some folks will scream that this is a bad idea, horrible practice, can't > do it, etc. These folks are idiots. Ssh can be configured to allow root > logins only

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

On Thu, 29 Jun 2023 at 19:45, Denys Vlasenko wrote: > IIRC bash used to allow numeric constants of the > BASE#DIGITS form even if the DIGITS part was empty. > IOW: not only "64#0", but "64#" too was accepted > as a valid zero constant. > > This no longer works in 5.2.15, probably better than >

Re: Enable compgen even when programmable completions are not available?

Jun 2023 17:09:47 +1000 > Martin D Kealey wrote: > > > Hi Eli > > > > How about using the shell itself to parse the output of "typeset" (an > alias > > for "declare"), but redefining "declare" to do something different. This > is > &g

Re: Enable compgen even when programmable completions are not available?

Hi Eli How about using the shell itself to parse the output of "typeset" (an alias for "declare"), but redefining "declare" to do something different. This is a bit verbose but it works cleanly: ``` ( function declare { while [[ $1 = -* ]] ; do shift ; done printf %s\\n "${@%%=*}" }

Re: problem with continuation prompt on newlines with history back

Hi Alex Is your history set to line mode or command mode? This changes whether recalling a multi-line history item gets put in the input buffer all at once or only one line of it, and that in turn changes whether you see PS2 in between the lines. On Sat, 24 Jun 2023, 03:34 alex xmb ratchev,

Re: Command execution by creating file.

The assertion "should just print the name of [the] file" is mistaken. You seem to have conflated autocompletion (which occurs while typing, usually in response to the TAB key, which is prior to parsing a command which in turn is prior to invoking it) with filename generation (which occurs as a

Re: [PATCH] add semicolon if last word in command group ends in

On Sun, 11 Jun 2023, 09:31 Grisha Levit, wrote: > The command printing code can fail to add a required semicolon when the > last word in the command ends with `&' > This could be obviated by unconditionally outputting a newline instead of a semicolon. I acknowledge that this style isn't to

array size vs index of last element (was Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context)

On Tue, 23 May 2023 at 23:32, Chet Ramey wrote: > On 5/22/23 10:56 PM, Martin D Kealey wrote: > > > For example, if one is filling an array in random order, rather than > > progressively adding to the end, then it is useful and makes sense to be > > able to ask the arr

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

On Mon, 22 May 2023, 12:59 Emanuele Torre, wrote: > I am not really proposing a major change to the behaviour of nounset, I > am only pointing out the incorrect bash behaviour for that case. I disagree: this would constitute a major change, breaking behaviour that is (for good reasons)

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

gestion about non-sparse arrays. On Mon, 22 May 2023 at 07:01, Martin D Kealey wrote: [...] > 2. ${#array[@]} gives the number of elements rather than the last index > (minus 1). Being able to declare an array as non-sparse (so that all gaps > "exist" with some default value) would fix this. > -Martin

Re: setarray[unsetkey] doesn't trigger nounset in arithmetic context

(I assume this is a continuation of the discussion in #bash on Libera.chat yesterday?) The primary use of `set -u` is to detect misspelled variable names, and misspelled keys for associative arrays seems like a reasonable extension of that, if you assume that they're in some sense a fixed list,

Re: `wait -n` returns 127 when it shouldn't

On Thu, 18 May 2023 at 02:13, Chet Ramey wrote: > It's possible for the shell to reap both background jobs before `wait -n' > is called. The underlying function returns < 0 when there aren't any > unwaited-for jobs, which the wait builtin translates to 127. > I know that some platforms (used

Re: `wait -n` returns 127 when it shouldn't

On Wed, 17 May 2023 at 03:35, Aleksey Covacevice < aleksey.covacev...@gmail.com> wrote: > Description: > `wait -n` sometimes returns with status code 127 even though there are > unwaited-for children. > > Repeat-By: > The following script does finish after a while: > > waitjobs() { > local

Fwd: EOF at PS2

On Thu, 4 May 2023 at 05:20, Chet Ramey wrote: > On 4/26/23 5:38 PM, Grisha Levit wrote: > > The setting of ignoreeof is ignored at PS2: > > > > bash --norc -o ignoreeof > > $ uname \ > >> ^D > > Linux > > (bash exits) > It's never been active in this situation, because it doesn't meet the >

Re: history fails with - in string

"Word" means something different in history expansion than it does in the rest of the shell, because it happens before the normal lexical processing. In effect, it means the same as an identifier in C. A history expansion consists of a line selector (!cmdname) optionally followed by colon and a

Re: Junk at the end on history

Is there any chance that your history contains a raw escape sequence that trigger the terminal to report attributes using `CSI…c` as described in the first answer to https://stackoverflow.com/questions/29939026/what-is-the-ansi-escape-code-sequence-escc Using "tail" would limit the output to just

Re: [PATCH 3/4] Port unwind protection to C23

On Mon, 27 Mar 2023 at 18:35, Paul Eggert wrote: > The problem can also occur on platforms where calling conventions differ > depending on type even if the two types have the same representation, and > this can (and has) occurred on platforms with linear address spaces. > Indeed, this is

Re: [PATCH 3/4] Port unwind protection to C23

While C has never guaranteed that pointers all have the same size & alignment, POSIX does provide this guarantee, although indirectly (it has to be true for dlsym() to work, for example). Bash seems to need an environment that's "kinda POSIX" (at least emulating the POSIX process & signal

Re: $SECONDS and timeout values use realtime `gettimeofday()`

On Fri, 24 Mar 2023 at 10:42, William Kennington via Bug reports for the GNU Bourne Again SHell wrote: > It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC, > )` as it would usually make the most sense when you want to know the > time since the script started. Generally new

Re: Document that here strings don't support brace expansion.

I suggest avoiding enumerating exclusions (including removing any existing ones), and adding an explanation that "expansions that can produce multiple words are excluded". On Wed, 15 Mar 2023, 15:52 Alex Bochannek, wrote: > Chet, > > Thank you for the thoughtful responses. My thoughts below got

Re: Cmd history is not displaying correctly

I suspect the history file is corrupt; truncating a file while another process has it open for writing can do strange things. On Sun, 19 Feb 2023, 23:05 Mr. Dick Steel, wrote: > WARNING: The following will REPLACE your > current .bash_history file! Take care. > > 1. Start you

Re: Having an alias and a function with the same name leads to some sort of recursion

On 2/14/23 2:58 PM, Dale R. Worley wrote: > Though I think by "keyword" he means "reserved word". > Yes, though in my defense, the bash man page liberally uses the term "keyword". On Fri, 17 Feb 2023 at 01:14, Chet Ramey wrote > I think the issue is that he's applying a grammar interpretation

Re: Bash 5.2 breaks our Arch Linux devtools

On Wed, 15 Feb 2023 at 23:29, Tobias Powalowski via Bug reports for the GNU Bourne Again SHell wrote: > Hi, > latest 5.2.x seems to have introduced a change in shopt extglob: > https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/133 > I'm not sure if my proposed fix for this is

Re: Regression in pattern substitution with compat42

On Tue, 14 Feb 2023 at 01:00, Chet Ramey wrote: In this case, the behavior is controlled by an option. You just don't like > the default setting. > We had this exact same discussion back in November. > Too right I don't like it, and the previous discussion was wholly unsatisfactory. I do not

Re: "builtin jobs" does not output to stdout.

The contorted rules for reporting the state of the parent shell suggest that maybe the entire approach needs re-thinking. Several approaches come to mind. 1. Create a built-in “parent” command where “parent ulimit” or “parent trap” answers based on the parent shell rather than the subshell

  1   2   >