uring the "configure" step) ?
A lot of people won't have the texinfo tools installed, and bash
itself builds just fine without them. So, my understanding/guess is
that the documentation part is considered "optional", and will be
built if the tools are present, but skipped i
(Followup to my previous post)
To answer my own question, I guess it is pretty obvious that the answer to "How
to
fix?" is "Install texinfo and re-run the make install", but it raises two
important
questions:
1) Why is the error ignored, making it almost impossible to determine that
I found the problem (I think). See below:
--- Cut Here ---
make[1]: Entering directory '/home/username/Build/bash-5.3-rc2/doc'
rm -f bashref.info
makeinfo --no-split -I../lib/readline/doc ./bashref.texi
make[1]: makeinfo: Command not found
Makefile:181: recipe for target 'bashr
x27;t reproduce this.
After I configure --prefix=/fs1/install and run `make install', I get:
$ ls /fs1/install/share/man/man1/
bash.1 bashbug.1
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrate
ly be
preferred over let.[0]
You might find this discussion interesting. It discusses the problems with
double-evaluation of array subscripts and describes the changes that ended
up in bash-5.2.
https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html
--
``The lyf so short, the craft so lo
I did: ./configure --prefix=$HOME/local/bash5
Then make and then make install (all of this is done as a non-root user).
It created the directory listed above and all the necessary subdirs, including
share/man/man1, but left that directory empty.
Shouldn't (at least) a copy of "bash.1&
once, it can get a
bit cranky. Wait a few minutes and try again, is all I can suggest.
> >(( hash[$key]++ ))# is not safe
> >let 'hash[$key]++'# is safe
>
> Could you explain what the issue/problem is? What makes it unsafe?
>
> And, I reall
On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote:
> BTW, and only tangentially related, "man bash" says that "let" and "(( ))" are
> exactly the same, but "shellcheck" thinks otherwise. "shellcheck" says you
> should
> use &qu
Greg Wooledge wrote:
> On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote:
>> BTW, and only tangentially related, "man bash" says that
>> "let" and "(( ))" are exactly the same, but "shellcheck"
>> thinks otherwise. "she
On Fri, Jun 13, 2025 at 07:57:54 -0600, Stan Marsh wrote:
> Also, note that if you are running with "set -e" (or "trap ... ERR"), then
> having
> "let" (or "(( ))") return a non-zero exit status when it happens to evaluate
> to zero,
> could cause an unexpected script abort.
This is why I linked
>All of this is intentional, and not a bug.
It is possible to be both.
But, yes, it reflects a fundamental inconsistency in the C/Unix ecosystem.
The fact that in most programming languages (e.g., C, AWK), 0 means false and
non-zero
means true, but in the shell, it is the opposite.
E.g., in AWK
On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote:
> BTW, and only tangentially related, "man bash" says that "let" and "(( ))"
> are exactly
> the same, but "shellcheck" thinks otherwise. "shellcheck" says you should
> us
On Fri, Jun 13, 2025 at 12:41:16 +0300, Stamatis Mavrogeorgis wrote:
> The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic
> erroneously return exit code 1 when a variable is either incremented by
> "++" or decremented
>Description:
>The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic
>erroneously return exit code 1 when a variable is either incremented by
>"++" or decremented by "--" from 0 or incremented by "+=
(2025-05-19) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: 15
Release Status: release
Description:
The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic
erroneously return exit code 1 when a variable is eith
On 6/10/25 6:54 PM, Robert Elz wrote:
ps: in general, usually, mktemp() isn't the best interface to use, there
are race conditions, but whether that matters depends upon just what it
is being used for,
Sometimes you need to generate a name for a file system object that isn't
a regular file (or
iscussion about
it: https://lists.gnu.org/archive/html/bug-bash/2021-01/msg00112.html
It's still a well-meaning but spurious warning.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ram
Date:Tue, 10 Jun 2025 18:29:00 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
The original response was fine.
| This came up a few times and the answer is always along the lines of "it
| works fine, ignore the warning".
And beyond that, it isn'
Somebody flitted:
> Nah
This is not an answer. This is just someone blowing off steam.
=
Please do not send me replies to my posts on the list.
I always read the replies via the web archive, so CC'ing to me is unnec
On Tuesday, June 10, 2025, Stan Marsh wrote:
>
> Should I be concerned about the warning?
>
Nah
--
Oğuz
t: https://lists.gnu.org/archive/html/bug-bash/2021-01/msg00112.html
--
Oğuz
See below. As far as I can tell, it built OK.
Should I be concerned about the warning?
--- Cut Here ---
rm -f bash
gcc -std=gnu11 -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
-L./lib/tilde -L./lib/malloc -L./lib/sh -rdynamic -g -O2 -o bash shell.o
eval.o y.tab.o general.o
The second release candidate of bash-5.3 is now available with the URLs
ftp://ftp.cwru.edu/pub/bash/bash-5.3-rc2.tar.gz
https://ftp.gnu.org/pub/gnu/bash/bash-5.3-rc2.tar.gz
and from the bash-5.3-testing branch in the bash git repository
(http://git.savannah.gnu.org/cgit/bash.git/log/?h=bash-5.3
On 5/21/25 5:02 PM, Bruce Dubbs wrote:
In linuxfromscratch we do a preliminary build of bash in order to
run it later in a chroot environment without any dependencies from the host
system:
./configure --prefix=/usr \
--build=x86_64-pc-linux-gnu \
--host
On 5/22/25 12:48 AM, Oğuz wrote:
On Thursday, May 22, 2025, Bruce Dubbs wrote:
with cstd-23 'bool' is a keyword
This is something the configure script should check. Otherwise why have one?
When you are cross-compiling, config.h is for the target system, not the
build system. You need a cons
On Thursday, May 22, 2025, Bruce Dubbs wrote:
> with cstd-23 'bool' is a keyword
This is something the configure script should check. Otherwise why have one?
--
Oğuz
In linuxfromscratch we do a preliminary build of bash in order to
run it later in a chroot environment without any dependencies from the host
system:
./configure --prefix=/usr \
--build=x86_64-pc-linux-gnu \
--host=x86_64-lfs-linux-gnu
On 5/16/25 10:52 PM, Bruce Dubbs wrote:
We have looked at bash-5.3-rc1 which was released om April 8th and that
does build with gcc-15. Can you give us an idea when the stable bash-5.3
will be released?
I will release the second release candidate of bash-5.3 as soon as I can go
through the
On 5/12/25 8:04 PM, Adam Purkrt wrote:
GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
OS: Gentoo Linux
Originally met this while the download of iso file in firefox was
nearing completion, and I was preparing myself to move the
downloaded foobar.iso file elsewhere. I opened terminal
Bruce Dubbs wrote:
> At the linuxfromscratch project, we document for users how to build a
> relatively complete Linux system from source code. When we do this we
> consider bash to be one of the most important packages in the system.
>
> https://www.linuxfromscratch.org/
At the linuxfromscratch project, we document for users how to build a relatively
complete Linux system from source code. When we do this we consider bash to be one
of the most important packages in the system.
https://www.linuxfromscratch.org/lfs/view/stable/
Our policy is to use the most
GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
OS: Gentoo Linux
Originally met this while the download of iso file in firefox was
nearing completion, and I was preparing myself to move the
downloaded foobar.iso file elsewhere. I opened terminal with bash,
typed "mv foobar.&qu
| I suspect this is the result your
| programmable completion specification for `cat' produces.
I suspect it is more likely that the readline config option
"match-hidden-files" is "on" (which seems to be its default).
Good catch; I have that disabled in my environment.
--
``The lyf s
Date:Fri, 25 Apr 2025 15:44:47 -0400
From:Chet Ramey
Message-ID: <9d1a2482-d47f-4c49-9581-45c5db81d...@case.edu>
| I can't reproduce this using bash-5.2.37.
I can.
| I suspect this is the result your
| programmable completion specification for `ca
Thanks, I'll check it out.
On Sat, 26 Apr 2025, 1:14 am Chet Ramey, wrote:
> On 4/25/25 11:18 AM, Tanmay Jagtap wrote:
> > *Dear Bash Maintainers,*
> >
> > I have encountered an issue with Bash autocompletion on my system.
> > Specifically, a file beginning with
On 4/25/25 11:18 AM, Tanmay Jagtap wrote:
*Dear Bash Maintainers,*
I have encountered an issue with Bash autocompletion on my system.
Specifically, a file beginning with three dots (e.g., ...Hiding-From-You)
is autocompleted even when no dot (.) has been typed, which seems
inconsistent with
*Dear Bash Maintainers,*
I have encountered an issue with Bash autocompletion on my system.
Specifically, a file beginning with three dots (e.g., ...Hiding-From-You)
is autocompleted even when no dot (.) has been typed, which seems
inconsistent with typical Bash behavior where hidden files are
URL:
<https://savannah.gnu.org/bugs/?67045>
Summary: bash parsing error, when using readline,
backslashes, and
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Tue 22 Apr 2025 08:41:19 PM UTC
Ca
On 4/19/25 12:02 AM, Antti Savolainen wrote:
https://www.gnu.org/software/bash/manual/html_node/Directory-Stack-Builtins.html
pushd on this page is missing an anchor and I'm unable to link
directly to it due to that.
Looks like the scripts that generate the HTML require that @item come
b
On 2025-04-14 at 10:59 -0400, Greg Wooledge wrote:
> Are bilingual but primarily-English-speaking end users expected to put
> "en@quot" as their preferred language in the LANGUAGE variable, in order
> to get messages in English?
>
> Would creating an empty /usr/share/locale/en/LC_MESSAGES/bash.mo
https://www.gnu.org/software/bash/manual/html_node/Directory-Stack-Builtins.html
pushd on this page is missing an anchor and I'm unable to link
directly to it due to that.
On 4/14/25 10:56 AM, Kaulkwappe wrote:
Hi Chet!
Can you confirm that Bash really has translations for 'en_US'? Because you say:
If there is no installed locale for en_US [...]
No, very few programs do. The Debian 12 system I looked at claims to have
en_US installed, but nothing in
++
On Mon, Apr 14, 2025, 16:46 Chet Ramey wrote:
> On 4/13/25 11:37 AM, microsuxx wrote:
> > seems to cycle between lc : parts one loose ..
>
> No, these are all translated strings.
>
> >> hobbit:~$ LANGUAGE=en_US:es_ES bash --version
> >> GNU bash, versió
) is responsible for overriding
> the `active category', which is LC_MESSAGES, according to what it finds
> in $LANGUAGE.
>
> If there is no installed locale for en_US, or no LC_MESSAGES bash.mo file
> in the right place, gettext(3) will ignore that locale in $LANGUAGE.
>
Hi Chet!
Can you confirm that Bash really has translations for 'en_US'? Because you say:
> If there is no installed locale for en_US [...]
In my scenario en_US is installed – but Bash (or gettext) doesn't seem to find
it, which does not make much sen
On 4/13/25 11:37 AM, microsuxx wrote:
seems to cycle between lc : parts one loose ..
No, these are all translated strings.
hobbit:~$ LANGUAGE=en_US:es_ES bash --version
GNU bash, versión 5.2.15(1)-release (x86_64-pc-linux-gnu)
Note the accented `o'.
Copyright (C) 2022 Free Sof
On 4/13/25 10:06 AM, Kaulkwappe wrote:
Hi!
I use Fedora 41 KDE and my first and default language is English (primary) and
my second language (secondary) is German. However, the Bash shell wrongfully
uses the secondary language:
bash --version
GNU bash, Version
seems to cycle between lc : parts one loose ..
On Sun, Apr 13, 2025, 16:46 Greg Wooledge wrote:
> On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote:
> > > bash --version
> > > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu)
> > > Copyright (C)
On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote:
> > bash --version
> > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu)
> > Copyright (C) 2022 Free Software Foundation, Inc.
> > Lizenz GPLv3+: GNU GPL Version 3 oder jünger
> > <http://gnu.or
Hi!
I use Fedora 41 KDE and my first and default language is English (primary) and
my second language (secondary) is German. However, the Bash shell wrongfully
uses the secondary language:
> bash --version
> GNU bash, Version 5.2.32(1)-release (x86_64-redhat-lin
On 4/4/25 4:18 PM, Jens Schmidt wrote:
[bashbug output manually adapted to real version ...]
Bash Version: 5.3
Commit: a6767763de5e7859107711b166a64a9e4a77a8ae
Release Status: compiled from recent devel branch
Description:
Bash skips empty lines when reading history file in multiline mode
broken cmd
plz fixx
greets++ ur microsucker ..
On Mon, Apr 7, 2025, 22:34 Chet Ramey wrote:
> On 4/4/25 4:18 PM, Jens Schmidt wrote:
>
> > [bashbug output manually adapted to real version ...]
> > Bash Version: 5.3
> > Commit: a6767763de5e7859107711b166a64a9e4a77a8ae
> >
The first release candidate of bash-5.3 is now available with the URLs
ftp://ftp.cwru.edu/pub/bash/bash-5.3-rc1.tar.gz
https://ftp.gnu.org/pub/gnu/bash/bash-5.3-rc1.tar.gz
and from the bash-5.3-testing branch in the bash git repository
(http://git.savannah.gnu.org/cgit/bash.git/log/?h=bash-5.3
On 2025-04-07 22:34, Chet Ramey wrote:
> On 4/4/25 4:18 PM, Jens Schmidt wrote:
>
>> [bashbug output manually adapted to real version ...]
>> Bash Version: 5.3
>> Commit: a6767763de5e7859107711b166a64a9e4a77a8ae
>> Release Status: compiled from recent dev
one small addition , <<'foo' ( with quotes is used ) ..
.. should tell bash expliciply preserve data ..
On Mon, Apr 7, 2025, 23:51 microsuxx wrote:
> i dunno what lithist is , but remaining data one to one is a big bug thats
> gotta be fixed
> its like u write foo &quo
Must be some kindof bug with fasd
(https://github.com/whjvenyl/fasd). Any idea how fasd could cause
`;exit` to be interpreted as a valid command? Running `alias exit`
shows that it's not aliased to anything.
Weird that fasd causes `;exit` to be a valid command, and also that it
causes bash to ex
: Linux sappc1 6.12.17-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.12.17-1 (2025-03-01) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
[bashbug output manually adapted to real version ...]
Bash Version: 5.3
Commit: a6767763de5e7859107711b166a64a9e4a77a8ae
Release Status: compiled from recent devel
> shows that it's not aliased to anything.
>
> Weird that fasd causes `;exit` to be a valid command, and also that it
> causes bash to execute it when loading if it's the last thing in the
> history file. I'll raise a bug report on the fasd GitHub. Apologies
> for the
yea make bug report
.. in my experience , such bash codes on github have very low code quality
..
peace .. ++
On Wed, Mar 26, 2025, 15:09 Ethan Gascoigne wrote:
> I do have an alias with `&& exit` in it, but removing that alias
> doesn't get rid of the bug. I've tes
On Tue, Mar 25, 2025 at 05:55:23PM -0400, Greg Wooledge wrote:
> On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote:
> > when bash reads exit cmd it will exit
> > so bash reads rc and exits ..
> > also .. u may have a ';exit' alias ..
>
> The claim is th
when bash reads exit cmd it will exit
so bash reads rc and exits ..
also .. u may have a ';exit' alias ..
On Tue, Mar 25, 2025, 22:15 microsuxx wrote:
> dude if u tell bash to exit it will exit ..
>
> On Tue, Mar 25, 2025, 20:41 Ethan Gascoigne wrote:
>
>> From: e
ah bash history file ..
.. yea i tried , bash dev doesnt segfault or anything , with it on a line
and without an ending newline
warm greetings .. :))
On Tue, Mar 25, 2025, 22:56 Greg Wooledge wrote:
> On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote:
> > when bash reads exit cm
On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote:
> when bash reads exit cmd it will exit
> so bash reads rc and exits ..
> also .. u may have a ';exit' alias ..
The claim is that the ;exit appears in .bash_history (not .bashrc)
and that this somehow causes a new insta
dude if u tell bash to exit it will exit ..
On Tue, Mar 25, 2025, 20:41 Ethan Gascoigne wrote:
> From: ethan
> To: bug-bash@gnu.org
> Subject: ;exit in bash history causes bash to exit
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_
Hello Ethan,
I can't reproduce the problem:
> Repeat-By:
> Open a terminal with bash as the shell
> Type `;exit`
This results in
bash: syntax error near unexpected token `;'
but not in closing the shell.
> Re-open the terminal, it will immed
From: ethan
To: bug-bash@gnu.org
Subject: ;exit in bash history causes bash to exit
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-fexceptions -Wp
So, I was using the command bash in the terminal, and now all my files are
deleted. I think the bash command was the reason. I can turn it back.
Sent from my iPad
great hint! many thanks
On Thu, 20 Feb 2025 at 14:26, Koichi Murase wrote:
> 2025年2月20日(木) 20:51 Timotei Campian :
> > echo !(file.f*)
> >
> > *bash --pretty-print test.sh*
>
> If this script file "test.sh" will be used as an independent
> executabl
On 2/20/25 11:04 AM, Koichi Murase wrote:
Thank you. I didn't know this behavior. Is that documented? I tried to
find it in the description of `--pretty-print', but I realized that
the --pretty-print option itself is undocumented.
It's not. It's just a novelty.
--
``The lyf so short, the cr
2025年2月20日(木) 23:37 Chet Ramey :
> > $ bash --pretty-print -O extglob test.sh
>
> You can use BASH_ENV for this. The primary reason that pretty-printing mode
> doesn't suppress execution until after any startup files are read is to
> allow a custom startup file to set the
int a file with the actual set of shell
options that the file is supposed to be parsed, you need to set them
in the command-line options of Bash. In the present case, you can run
it in the following way:
$ bash --pretty-print -O extglob test.sh
You can use BASH_ENV for this. The primary reason tha
Je Thu, Feb 20, 2025 at 08:29:19AM -0500, Greg Wooledge skribis:
> On Thu, Feb 20, 2025 at 21:25:45 +0900, Koichi Murase wrote:
> > $ bash --pretty-print -O extglob test.sh
>
> Yeah, I misread the question a little bit. Sorry about that.
>
> By the way, is this considered
On Thu, Feb 20, 2025 at 21:25:45 +0900, Koichi Murase wrote:
> $ bash --pretty-print -O extglob test.sh
Yeah, I misread the question a little bit. Sorry about that.
By the way, is this considered a bug:
hobbit:~$ bash -O extglob --pretty-print x
bash: --: invalid option
Usage: bash [GNU l
2025年2月20日(木) 20:51 Timotei Campian :
> echo !(file.f*)
>
> *bash --pretty-print test.sh*
If this script file "test.sh" will be used as an independent
executable file, to make it work, you need to put "shopt -s extglob"
at the beginning of the file as Greg explain
On Thu, Feb 20, 2025 at 13:50:29 +0200, Timotei Campian wrote:
> *OS*=debian12
> *BASH_VERSION*="5.2.15(1)-release"
>
> the script test.sh has the following content:
>
> echo !(file.f*)
>
>
> Now calling bash pretty-print result in this error:
>
>
*OS*=debian12
*BASH_VERSION*="5.2.15(1)-release"
the script test.sh has the following content:
echo !(file.f*)
Now calling bash pretty-print result in this error:
*bash --pretty-print test.sh*
file1: line 2: syntax error near unexpected token `('
file1: line 2: `echo !(file.f*)'
On Wed, Feb 12, 2025, at 9:18 PM, LY via Bug reports for the GNU Bourne Again
SHell wrote:
> I think there is a grammar error in this sentence
> in https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html
>
> "but double quote characters in expressio
Hi,
I think there is a grammar error in this sentence
in https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html
"but double quote characters in expression are not treated specially are
removed."
This sentence should be changed to
"but double quot
Date:Sun, 9 Feb 2025 08:52:07 -0500
From:Greg Wooledge
Message-ID: <20250209135207.gn29...@wooledge.org>
| Oh, that must be another 2024 change.
As my earlier correction indicated, it didn't happen.
It turns out that all the *ash shells (bash, ya
On Sun, Feb 09, 2025 at 12:30:33 +0700, Robert Elz wrote:
> | and "read -p" for the prompt.
>
> which could be just a printf without a trailing \n before the
> read -- but doesn't need to be as read -p is in the standard.
Oh, that must be another 2024 change. The manpages-posix package I've
go
Date:Sun, 09 Feb 2025 12:30:33 +0700
From:Robert Elz
Message-ID: <16760.1739079...@jacaranda.noi.kre.to>
| read -- but doesn't need to be as read -p is in the standard.
I was sure that had been added, but as usual when I am relying
on memory I was wrong, -p isn't i
;
| command,
Sure, that one I agree with, and makes it much easier, I was just
maintaining the original design as much as possible.
| The only bash extensions we really want, then, are the parameter
| expansion for the renaming step,
which, as above, isn't really needed at all.
| a
nly the case here, and in most other cases.
You really want bash's ${var//search/replace} feature for the
renaming step, so as long as you're already using that, you might
as well use any other bash features that make your job easier.
For the problem as stated (no recursion), we c
Date:Sat, 8 Feb 2025 12:08:10 -0500
From:Greg Wooledge
Message-ID: <20250208170810.gl29...@wooledge.org>
| OK, I think you have something like this:
|
| while read -r f; do
| if [[ $f = *[[:space:]]* ]]; then
| read -r -p "Fix <$f>? " yn
|
On 2/8/25 10:48 AM, carlyle_moul...@optusnet.com.au wrote:
Then follows a while read REPLY; do # loop to read records from
/tmp/$USER/tempfile1
# The first record is discarded, from the remainder the File_Name is
extracted and passed to a functionas a quoted string to function
File_Contains_Blan
On Sun, Feb 09, 2025 at 02:48:42 +1100, carlyle_moul...@optusnet.com.au wrote:
> I have a script to go through file names in the current directory,
> check whether they contain blanks and optionally replace blanks with
> underscores.
for f in *[[:space:]]*; do
read -r -p "Fix <$f>? " yn
if
From: carl
To: bug-bash@gnu.org
Subject: [50 character or so descriptive subject here (for reference)]
In a script two instances of the read builtin mutually interfere
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS
On 2/4/25 8:42 PM, Wiley Young wrote:
Hi,
Please say something if this patch should be sent someplace else.
If you do send this along to the github repo for this project, you might
consider saving the diff output to a file and attaching it to something
instead of pasting it and letting your
On 2/4/25 8:42 PM, Wiley Young wrote:
Hi,
Please say something if this patch should be sent someplace else.
https://github.com/clarity20/shellmath
It's probably due for an update; that repo hasn't changed in years.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
en addressed:
* doc/bash/examples/shellmath/shellmath.sh
+ Remove trailing spaces and tabs.
+ Workaround of problematic use of "10#$fractionalSum" syntax by
replacing it with an admittedly awkward
"${fractionalSum//[^-]}10#${fractionalSum//[^0-9]}" expansion syntax. For
the loadable builtins in bash-5.3-beta build with a minimal config.
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
n FreeBSD that just
seems very hard to track down. The default bourne shell on FreeBSD
machines seems to totally wreck havok on the stty terminal setting we
call "echoctl". So I figure the best way to file a bug report and to
demonstrate that something is borked was to build the bash shell w
On 1/22/25 8:03 AM, MacBeth wrote:
$ unset BASH_COMPAT
$ declare -p BASH_COMPAT
bash: declare: BASH_COMPAT: not found
$ BASH_COMPAT=foobar
bash: BASH_COMPAT: foobar: compatibility value out of range
$ declare -p BASH_COMPAT
declare -- BASH_COMPAT="foobar"
$ BASH_COMPAT=4.4 /opt/ho
On 1/21/25 9:49 PM, MacBeth wrote:
re: GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin23.4.0)
---
1) `shopt compat50` does not exist. The manpage does specify that
'compat50' is a valid option for `shopt` under BUILTINS/shopt. Yet bash
provides an error when trying to read
2025年1月22日(水) 22:03 MacBeth :
> Or perhaps that second error is produced by the parent shell before
This. The error message is printed even for "/bin/echo":
$ BASH_COMPAT=foo
bash: BASH_COMPAT: foo: compatibility value out of range
$ BASH_COMPAT=4.4 /bin/echo hello
bash: BAS
On Tue, Jan 21, 2025 at 11:25 PM Lawrence Velázquez wrote:
> On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote:
> > "Bash-5.0 is the final version for which there will be an individual
> shopt
> > option for the previous version. Users should use BASH_COMPAT on bash-5.0
devel branch:
https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?h=devel&id=42c49d621d9341a530bca9422d787593e6bb#n11877
--
Koichi
On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote:
> "Bash-5.0 is the final version for which there will be an individual shopt
> option for the previous version. Users should use BASH_COMPAT on bash-5.0
> and later versions."
>
> ...Not sure if this means `shopt compat50
re: GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin23.4.0)
---
1) `shopt compat50` does not exist. The manpage does specify that
'compat50' is a valid option for `shopt` under BUILTINS/shopt. Yet bash
provides an error when trying to read or change it:
> shopt compat5
s into two separate windows in my
editor and view them together.
What I've started to do once I learned how much parallelism was intended
between doc/bash.1 and doc/bashref.texi, was to open them in adjacent
vertical windows in vim. Of course I know Emacs can do the same.
I don't u
1 - 100 of 1488 matches
Mail list logo
