Re: $((expr)) allows the hexadecimal constant "0x"
2023年12月10日(日) 14:13 Martin D Kealey : > But even if you still thought this was worth doing, it wasn't necessary to > make $((10#)) completely illegal: Bash could look ahead and only intervene > if the following character is '-' (affecting $((10#-digits)) but not > $((10#))). I'm not a big fan of `10#[-+]digits' and invalidating `10#' either since the Bash change also broke mine [1,2], but I'd say the above lookahead switching is worse than the current behavior. In the above way, there is still a backward compatibility problem with $((10#$X-digits)) with an empty X. One might suggest that the arithmetic lexer can reference the original string before the shell expansions, but the arithmetic evaluation does not work in that way. For example, there is the same problem with « let "10#$X-digits" » where the shell expansion and the arithmetic evaluation are clearly separated. It's too late, but a better way could have been introducing the function-call syntax and supporting signed n-adic numbers through e.g. « int([-+]digits, n) ». [1] https://github.com/akinomyoga/ble.sh/commit/2ea48d7cd4fe2a808b20e3c4c81f662f5a5f5451 [2] https://github.com/akinomyoga/ble.sh/commit/7545ea31bda2e34e25b53c6550270397ccc77361
Re: bash should consult .config/bash/...
2023年12月10日(日) 13:23 Oğuz :
> Trends come and go. If there is demand for this feature bash should do it
> by honoring an environment variable like BASH_HOME when looking for rc
> files instead of exploring a fixed path.
In that case, a question would be what would be the standard way to
specify the Bash-specific variable, BASH_HOME. We cannot set it in
~/.bashrc because it should be specified before Bash decides the
location of .bashrc.
- Maybe the package managers of distributions can specify the
configure option -DSYS_BASHRC and set BASH_HOME there. But, in that
case, ~/${XDG_CONFIG_HOME:-~/.config/bash}/bashrc could be directly
sourced from SYS_BASHRC, which is already possible with the current
Bash. Another problem is that if it is not set up by the package or
the system administrators, the user cannot use it.
- Besides, Zsh seems to support ZDOTDIR, which can be used to specify
the location of user configurations. The Zsh users seem to specify
ZDOTDIR in /etc/zshenv or /etc/zsh/zshenv. This approach has the
same problem that a user needs to ask a system administrator to
configure /etc/zshenv as the user likes.
By the way, even if we forget about `.config/bash', it may be more
consistent to have a variable like the suggested one. There are
already similar variables, ENV and BASH_ENV. However, the former is
only used in the interactive posix mode, and the latter is only used
in the non-interactive non-posix mode. There does not seem to be a
similar variable that can be used in the interactive non-posix mode
and the non-interactive posix mode.
- interactive posix -> $ENV
- interactive non-posix -> N/A (hardcoded to be ~/.bashrc)
- non-interactive posix -> N/A
- non-interactive non-posix -> $BASH_ENV
--
Koichi
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, but I wanted to point out how easy this is to work
> around.
>
WRITING a work-around is trivial. I did that a long time ago.
DEPLOYING a work-around is a much bigger deal. I have no way of contacting
most of my users, and they weren't installing packages that I could push
updates to. I'm still getting sporadic complaints from users I've never
heard of, as they finally upgrade to newer versions of Bash and my old
scripts fail as a result.
To say that I'm peeved by the unnecessary work this has created for me
would be an understatement.
Quick hack changes like this need to be considered carefully, not rushed
through in a few days.
And sometimes Bash isn't the thing that needs fixing. Maybe the manual
needs to be clearer that "#" is not an "operator" like "+" or "/" but
rather part of an unsigned integer constant (and that "-" is NOT part of
such a constant).
But even if you still thought this was worth doing, it wasn't necessary to
make $((10#)) completely illegal: Bash could look ahead and only intervene
if the following character is '-' (affecting $((10#-digits)) but not
$((10#))).
Moreover, it only needed to output a warning, rather than fail, perhaps
“Warning: base# may only be followed by digits; "-" interpreted as
subtraction rather negation.”
If I were fixing this today, I would introduce a new category of
diagnostics that are only displayed when set -x is in effect (and sent to
>&${BASH_XTRACEFD-2}). Then I'd raise such a warning about 10#- but with
the old zero value.
-Martin
>
Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, jidanni wrote: > Maybe on the list of config files bash looks at, > there should be also .config/bash/... as that is > the trend these days... > Trends come and go. If there is demand for this feature bash should do it by honoring an environment variable like BASH_HOME when looking for rc files instead of exploring a fixed path. -- Oğuz
Re: bash should consult .config/bash/...
On Sat, Dec 9, 2023, at 10:28 PM, Koichi Murase wrote: > 2023年12月10日(日) 12:10 jidanni : >> Maybe on the list of config files bash looks at, >> there should be also .config/bash/... as that is > > There was a discussion: > > https://lists.gnu.org/archive/html/bug-bash/2021-05/threads.html#00024 > https://lists.gnu.org/archive/html/bug-bash/2021-11/threads.html#00036 See also: - "Suggestion/question" https://lists.gnu.org/archive/html/bug-bash/2021-06/threads.html#3 - "[Suggestion] Relocate user startup files to their own subdirectory" https://lists.gnu.org/archive/html/help-bash/2022-07/threads.html#1 PS: Wow, I didn't know the message links on the archive index pages were all anchored. That's nifty, and good to know. -- vq
Re: bash should consult .config/bash/...
2023年12月10日(日) 12:10 jidanni : > Maybe on the list of config files bash looks at, > there should be also .config/bash/... as that is There was a discussion: https://lists.gnu.org/archive/html/bug-bash/2021-05/threads.html#00024 https://lists.gnu.org/archive/html/bug-bash/2021-11/threads.html#00036
bash should consult .config/bash/...
Maybe on the list of config files bash looks at, there should be also .config/bash/... as that is the trend these days...
Re: $((expr)) allows the hexadecimal constant "0x"
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, but I wanted to point out how easy this is to work around.
$ number=0196
$ unset somevar
$ printf '%s\n' "$(( 10#${number} ))"
196
$ printf '%s\n' "$(( 10#${somevar} ))"
-bash: 10#: invalid integer constant (error token is "10#")
$ printf '%s\n' "$(( 10#0${number} ))"
196
$ printf '%s\n' "$(( 10#0${somevar} ))"
0
$ printf '%s\n' "$(( 10#${number:-0} ))"
196
$ printf '%s\n' "$(( 10#${somevar:-0} ))"
0
Re: maintaining Bash scripts across versions of Bash, here's what I
do. I implement everything in the earliest version of Bash I care to
support, Bash 4.2 on RHEL 7. That sits in my bash-4.2 branch in Git.
Then I've got a bash-4.4 branch and a rhel-9 branch. As I find little
improvements I can only make in later versions of Bash, I'll implement
those changes in the first branch where they are supported. Besides
that, everything I do in the bash-4.2 branch is going to get merged
into the bash-4.4 branch, and from there into the rhel-9 branch.
Then I don't have a reason to wait a decade to take advantage of new
Bash features, while Bash installations that support them slowly
become the norm. The changes in my scripts, at least, going from
bash-4.2 to rhel-9 are pretty minimal. So implementing little things
as I come across them and dealing with some merge conflicts isn't a
big deal.
That said, this is not a large codebase, and I'm not aware of anything
in the bash-4.2 branch that wouldn't work under RHEL 9.
Zack
