Re: Potentially misleading documentation of SECONDS variable

The variable $SECOND won't intend to be exact to the nanoseconds! Not even to 1/100th... This variable is intended to show current time of execution, at SECOND resolution. This variable is simply incremented each time SYSTEM CLOCK increment his SECOND part of current time. Try this little command

Re: 'wait -n' with and without id arguments

On Wed, Aug 14, 2024 at 3:26 PM Chet Ramey wrote: > > On 8/12/24 11:57 AM, Zachary Santer wrote: > > > > Nobody had any answers in my help-bash > > thread on this topic, but does the devel branch have any build > > dependency that differs from those of the master and pre-release > > branches? > >

Re: improving '{...}' in bash?

This will juste require embeding second braces: Le Tue, Jul 23, 2024 at 07:50:24AM +0200, Harald Dunkel a écrit : > % echo x{1..3,5}x > x1..3x x5x > > I would have expected "x1x" and "x1x x2x x3x x5x". Try: $ echo x{{1..3},5}x x1x x2x x3x x5x -- Félix Hauri -- http://www.f-

Re: pwd and prompt don't update after deleting current working directory

Le Tue, Jul 16, 2024 at 09:08:14AM -0400, Chet Ramey a écrit : > On 7/16/24 3:47 AM, David Hedlund wrote: > > > > > > pwd -P >/dev/null 2>&1 || cd .. > > > > > Do you think that it would be appropriate to submit this feature request > > to the developers of the rm command instead. > > You can tr

Re: 'wait -n' with and without id arguments

On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey wrote: > > On 8/7/24 2:47 PM, Zachary Santer wrote: > > > Now I understand that this is because the list of terminated child > > processes that 'wait -n' currently ignores is only used in the > > interactive shell. > > It's not, but there might be some va

Re: 'wait -n' with and without id arguments

Date:Wed, 14 Aug 2024 15:21:44 -0400 From:Chet Ramey Message-ID: <1413a9a0-cbef-44c5-8072-a3be7294e...@case.edu> | I'm not sure returning the status of some random process from some | arbitrary point in the past is going to be valuable. Not "some random process"

Re: Question on $@ vs $@$@

Hello. I only respond to this to reduce the noise. Chet Ramey wrote in <1bba673e-5ab9-4263-9d88-124854793...@case.edu>: |On 8/13/24 8:45 PM, Steffen Nurpmeso wrote: |> I include bug-bash even though i think bash is correct, but there |> lots of people of expertise are listening, so, thus. |>

Re: 'wait -n' with and without id arguments

On 8/12/24 11:57 AM, Zachary Santer wrote: On Mon, Aug 12, 2024 at 11:12 AM Chet Ramey wrote: That stuff changed last month, after bash-5.3-alpha was released. Before that change, neither interactive nor non-interactive shells checked the list of saved statuses. The difference was when the use

Re: 'wait -n' with and without id arguments

On 8/9/24 9:29 PM, Zachary Santer wrote: On Fri, Aug 9, 2024 at 10:38 AM Chet Ramey wrote: When I source your script on macOS with the current devel build, I get the set of notification messages and termination with a false argument, and an infinite loop with a true argument. So basically, '

Re: 'wait -n' with and without id arguments

On 8/7/24 2:47 PM, Zachary Santer wrote: Now I understand that this is because the list of terminated child processes that 'wait -n' currently ignores is only used in the interactive shell. It's not, but there might be some value here. If you want the behavior of 'wait -n' to be consistent

Re: Question on $@ vs $@$@

On 8/13/24 8:45 PM, Steffen Nurpmeso wrote: Hello. I include bug-bash even though i think bash is correct, but there lots of people of expertise are listening, so, thus. Sorry for cross-posting, nonetheless. Given this snippet (twox() without argument it is) one() { echo "$# 1<$1>"; } two

Re: [PATCH] read: unsigned char delim issues

On 8/13/24 3:00 PM, Grisha Levit wrote: The new read_mbchar code is missing an (unsigned char) cast, causing an invalid continuation byte >0x7F to fail to be recognized as a delimiter on platforms where char is signed. $ printf '\317_' | { read -d _; echo "${REPLY@Q}"; } $'\317' $

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 17:58:15 +0300, Oğuz wrote: > On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > > However, as ksh93 makes "" from this > > expansion, and so probably ksh88 might have done as well > > No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0. HP-UX 10.20 a

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > However, as ksh93 makes "" from this > expansion, and so probably ksh88 might have done as well No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.

Re: Question on $@ vs $@$@

Date:Wed, 14 Aug 2024 09:23:49 -0400 From:Greg Wooledge Message-ID: | The most obvious would be to treat "$@$@" as if it were "$@" "$@", That would clearly be wrong when there are positional parameters. | As a human trying to read this expression and figure out

Re: Question on $@ vs $@$@

Date:Wed, 14 Aug 2024 11:04:08 +0200 From:Marc Chantreux Message-ID: | I'm really currious: do you see another one ? The case he was asking about is when $# is 0 (no positional params set) and whether "$@$@" should result in "" (1 arg) or nothing (0 args). Upon r

Re: shopt compat

On 8/14/24 2:25 AM, Martin Kealey wrote: Hi Chet I have worked up a patch that considerably simplifies the logic for setting and displaying the shopt compatXX settings, by getting rid of the numberous boolean variables and simply computing the setting level directly. Thanks. The boolean variab

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 11:04:08 +0200, Marc Chantreux wrote: > > We know what "$@" is supposed to do. And something like "x${@}y" is > > well-defined also -- you simply prefix "x" to the first word, and append > > "y" to the final word. > > > But I don't know how "$@$@" is supposed to be interpr

Re: printf inconsistent results for %.0f

On 8/13/24 7:05 PM, Grisha Levit wrote: On Mon, Aug 12, 2024, 11:04 Chet Ramey > wrote: My question is why the (admittedly old) gnulib replacement strtod/strtold is messing things up. Looks like printf(3) gets called with a `Lf' conversation specifier and a

Re: Question on $@ vs $@$@

> We know what "$@" is supposed to do. And something like "x${@}y" is > well-defined also -- you simply prefix "x" to the first word, and append > "y" to the final word. > But I don't know how "$@$@" is supposed to be interpreted. I do not see > anything in the official wording that explains how

Re: Question on $@ vs $@$@

On Wednesday, August 14, 2024, Steffen Nurpmeso wrote: > > one() { echo "$# 1<$1>"; } > two() { one "$@"; } > twox() { one "$@$@"; } > two > two x > twox > twox x > $ dash shbug.sh > 0 1<> > 1 1 > 1 1<> > 1 1 > #?0|kent:tmp$ bash shbug.sh > 0 1<> > 1 1 > 0 1<>