On 2023-09-07 03:03, Rob Landley wrote:
On 9/6/23 05:28, Dragan Simic wrote:
Thank you for this detailed clarification. It's good to know that the
2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
You didn't change the URL. You didn't update the SUSvX number. It's
still
On 9/6/23 05:28, Dragan Simic wrote:
> Thank you for this detailed clarification. It's good to know that the
> 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
You didn't change the URL. You didn't update the SUSvX number. It's still says
"issue 7" at the top. That's YOU
On 9/6/23 12:03 PM, Eric Blake wrote:
The austin group has decided what they'd like to do, and what they'd like
implementors to do. The question is whether or not people go along with it.
The Austin Group decided merely:
If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
On Wed, Sep 06, 2023 at 10:45:09AM +0700, Robert Elz wrote:
>
> However, my "read of the room" at the minute is that this simply won't
> happen, and printf(1) %b will remain as it is, and not be removed any
> time soon (or probably, ever). If printf(1) ever really needs a method
> to output in
On Wed, Sep 06, 2023 at 09:03:29AM -0400, Chet Ramey wrote:
> On 9/5/23 10:13 PM, William Bader wrote:
> > Has bash ever had a change before that would break valid scripts?
>
> Yes, but I try to keep those to a minimum.
>
> > Could the printf format change be settable by a variable or by an
On 9/5/23 7:00 PM, Emanuele Torre wrote:
If you have a CHLD trap set, and you run any command that has more than
one command substitution, or an array subscript with more than one
command substituion in an arithmetic context, or also in a prompt
string, you will get parse errors.
Thanks for
On 2023-09-06 17:10, Robert Elz wrote:
Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic
Message-ID: <03abecb9d905252bd63867d1c8b2a...@manjaro.org>
| It's good to know that the
| 2013, 2016 and 2018 versions/revisions of POSIX actually don't
count.
As Chet
On 2023-09-06 15:07, Chet Ramey wrote:
On 9/6/23 6:28 AM, Dragan Simic wrote:
No invalidation would be happening now, merely a note in the coming
standard
that the %b in printf(1) would (might) be removed in a later version
of
the standard - so implementations have time to implement
Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic
Message-ID: <03abecb9d905252bd63867d1c8b2a...@manjaro.org>
| It's good to know that the
| 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
As Chet said, that is not what I meant. The
The following 'hash -d' statements have different exit statuses.
bash --noprofile --norc -c \
'hash -d ls; echo $?' ## 0
bash --noprofile --norc -c \
'cat /dev/null; echo $?' ## 1
This depends on a hashable command being given (e.g. cat
On Wed, Sep 06, 2023 at 02:13:44AM +, William Bader wrote:
> Has bash ever had a change before that would break valid scripts?
Yes. Many times, sadly. Most recently, bash 5.2 introduced some changes
to how associative array indexes are handled, which will break
backward compatibility in
Has bash ever had a change before that would break valid scripts?
Could the printf format change be settable by a variable or by an option like
the -e/-E in echo?
Is it necessary for bash printf to match C printf?
I suppose that it is already decided.
Could the bash printf implementation warn
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'
On 9/6/23 4:02 AM, Oğuz wrote:
I don't think bash should deprecate %b.
I don't have any plans to change %b.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
On 9/6/23 6:28 AM, Dragan Simic wrote:
No invalidation would be happening now, merely a note in the coming standard
that the %b in printf(1) would (might) be removed in a later version of
the standard - so implementations have time to implement something to
replace it, and applications to stop
On 9/5/23 10:13 PM, William Bader wrote:
Has bash ever had a change before that would break valid scripts?
Yes, but I try to keep those to a minimum.
Could the printf format change be settable by a variable or by an option
like the -e/-E in echo?
It could, sure. Anything is possible.
Is
On 9/5/23 7:34 PM, Rob Landley wrote:
C23 is going to use %b to print binary literals.
Upper case %B was taken?
I asked the same question. The short answer is that no one trusts the C
committee.
https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00121.html
--
``The lyf so short, the
On 2023-09-06 05:45, Robert Elz wrote:
Date:Tue, 05 Sep 2023 22:32:39 +0200
From:Dragan Simic
Message-ID: <7cfed11b50d35cbfaaa647c1fcd39...@manjaro.org>
| Are there any official explanations why is the invalidation
actually
| happening now?
It was proposed
On Wed, Sep 6, 2023 at 9:38 AM Robert Elz wrote:
> Adding a different %b to printf(1) wasn't currently even proposed, just
> deprecating the current one so it wouldn't conflict with the usage of
> %b in printf(3) (which is being defined in C23, and is apparently already
> firmly entrenched, even
Date:Wed, 6 Sep 2023 08:13:23 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| What's the point? Does anyone need this feature in their shell scripts (and
| can't afford to use bc for it)?
Adding a different %b to printf(1) wasn't currently even proposed, just
20 matches
Mail list logo
