On Sat, Jul 12, 2025, at 8:51 PM, Robert Elz wrote:
> Date:Sat, 12 Jul 2025 18:52:55 -0400
> From:Zachary Santer
> Message-ID:
>
>
> | Same applies to parameter expansion syntax errors.
>
> The NetBSD shell used to do that (and POSIX even allows it), but
> it turns out
On Sun, Jul 13, 2025, at 4:53 PM, jason stein wrote:
> It's a history of all the paths we used with cd command, so it might be
> confusing due to legacy use of history, but it is a type of history.
Sure, in an abstract sense. However, in practice bash extensively
refers to the command history as
> On Jul 13, 2025, at 3:58 PM, Lawrence Velázquez wrote:
>
> On Sun, Jul 13, 2025, at 3:17 PM, jason stein wrote:
>> *Pull Request:*
>> https://github.com/jstein916/bash/pull/1
>
> In general it's preferable to provide a patch directly (either inline
>
On Sun, Jul 13, 2025, at 3:17 PM, jason stein wrote:
> *Pull Request:*
> https://github.com/jstein916/bash/pull/1
In general it's preferable to provide a patch directly (either inline
or as an attachment), rather than requiring prospective reviewers to
visit an external site.
> *What the command
On Sat, Jul 12, 2025, at 6:52 PM, Zachary Santer wrote:
> let is a builtin, and its argument is always just going to be a
> string, so people could continue to form arithmetic expressions at
> runtime using that, if they are determined to do so.
((...)) is not the only arithmetic context. The "le
On Sun, Jul 6, 2025, at 10:25 PM, Martin D Kealey wrote:
> To help me find bugs in a range of projects, I have a wrapper around gcc
> that forces -Werror -pedantic.
>
> [...]
>
> A significant source of detection failures is that the probes assume that
> K&R function declarations (without parameter
On Sun, Jun 29, 2025, at 11:41 AM, Greg Wooledge wrote:
> The colon variants ${var:-word} were added later, IIRC by ksh.
Looks like the System III shell released them first:
https://www.in-ulm.de/~mascheck/bourne/#system3
--
vq
On Sat, Jun 28, 2025, at 10:00 PM, Wiley Young wrote:
> I don't see any other written instances of omitting a ':' amongst the
> examples in these x4 descriptions.
>
> Whether the existing omission was intentional or no, I think it would be
> helpful for the reader to point up how that one line of c
On Mon, Jun 23, 2025, at 10:30 PM, nkkralev--- via Bug reports for the GNU
Bourne Again SHell wrote:
> Hello microsuxx,Thank you for the replies.I did
> some more manual testing, the wait -n builtin looks kinda
> sketchy because of what the bash manpage of the builtin wait says,
> during testin
On Thu, Jun 19, 2025, at 6:10 PM, Lawrence Velázquez wrote:
> This changed in bash 5.2:
>
> There is a new shell option, `patsub_replacement'. When
> enabled, a `&' in the replacement string of the pattern
> substitution expansion is replaced by the
On Thu, Jun 19, 2025, at 5:28 PM, Jeff Ketchum wrote:
> $ cat replacestring.sh
> original_string="1|2|3|4"
> replace_string=':\\'
> echo "original: ${original_string} replace:${replace_string}"
> echo "unquoted ${original_string/2/${replace_string}}"
> echo "quoted ${original_string/2/"${replace_
On Sat, Jun 7, 2025, at 12:55 PM, Martin D Kealey wrote:
> However there might be some objections to relying on the printf built-in,
> since in theory Bash could be built without it, in which case I suggest:
>
> [...]
>
> +for (( m = n = argmax / ${#argmax} + 1 ; o = m & m-1 ; m = o )) do :; done
>
On Fri, Jun 6, 2025, at 9:29 AM, Stan Marsh wrote:
> I.e., yes, I get the theoretical reasons, but it generates confusion
> for the user
>
> [...]
>
> Of course,
> you still have to "enable" them in your script or shell in order to
> actually use them.
Exactly, you have to explicitly opt into us
On Thu, Jun 5, 2025, at 8:37 AM, Stan Marsh wrote:
> Actually, I am not too fond of the habit of having builtins (particularly
> those supplied as part of the distribution) with the same name as well-known
> Unix commands.
It allows for potential drop-in replacement if the external commands
are un
On Fri, May 30, 2025, at 3:36 AM, Martin Schulte wrote:
> https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says:
>
> 19. Literal tildes that appear as the first character in elements of
> the PATH variable are not expanded as described above under Tilde
> Expansion.
>
> Is this
On Sat, May 24, 2025, at 4:47 PM, Greg Wooledge wrote:
> On Sat, May 24, 2025 at 15:00:21 -0500, Bob Mroczka wrote:
>> #!/bin/bash
>> set -o pipefail
>> shopt -s expand_aliases
>> alias ub='echo hi'
>> echo "alias ub='echo bye'" >~/.alias
>> cat ~/.alias
>> source ~/.alias && u
On Sat, Mar 29, 2025, at 4:52 PM, Lawrence Velázquez wrote:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/locale.h;hb=glibc-2.41#l33
> https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/langinfo.h;hb=glibc-2.41#l584
> https://sourceware.org/git/?p=glibc.git;a=blob;f=l
On Sat, Mar 29, 2025, at 2:25 PM, Chet Ramey wrote:
> How does a locale doing this expose the category to the programmer?
> I suppose all possible additional locale categories have to be available
> to setlocale() somehow, via and the documentation.
Yeah, looks like POSIX explicitly permits that:
On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote:
> On 3/26/25 6:29 PM, Robert Elz wrote:
>> LANG is generally just the fallback for categories that haven't been
>> set to something else. For this, assume the LC_ALL had never been
>> set (setting LANG after that is set should probably just do n
On Sat, Mar 15, 2025, at 7:08 PM, MacBeth wrote:
> On Sat, Mar 15, 2025 at 12:33 PM Greg Wooledge wrote:
>> On Sat, Mar 15, 2025 at 16:14:00 +, Nikola Novak via Bug reports for the
>> GNU Bourne Again SHell wrote:
>> > How do you end the heredoc with a multiline delimiter such as the
>> > fo
On Mon, Mar 10, 2025, at 12:38 PM, Zachary Santer wrote:
> There are other weird, undocumented things that you could have the
> same conversation about. ${#@} is equivalent to ${#}
This is documented and not at all weird. $# came from Bourne, and
${#@} is a logical extension of ${#var} that happe
On Sat, Mar 8, 2025, at 3:05 PM, Kaz Kylheku wrote:
>
> $ echo {a..{z,y}}
> a..z a..y
>
> Is this documented? I would expect it to produce
>
> {a..z} {a..y}
This is fixed in the devel branch:
$ git -C ~/src/bash checkout -q c3ca11424d2ae66cafa2f931b008dfb728e209a5
$ { ~/src/
On Fri, Mar 7, 2025, at 12:23 PM, John Wiersba via Bug reports for the GNU
Bourne Again SHell wrote:
> You're discouraging it's use by not documenting it.
That is the point, I believe.
> BTW, according to those links below, apparently zsh documents it
This is true.
https://zsh.sourceforge.io/D
On Thu, Mar 6, 2025, at 9:06 PM, Kaz Kylheku wrote:
> But Bash cannot do this. The reason is that brace expansion is already
> a deviation from POSIX.
POSIX.1-2024 does permit brace expansion syntax as an extension,
although it doesn't use the term "brace expansion" or prescribe any
specific seman
On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote:
> {0} is no expansion
> {0,} is
> it must be 2+
And this is documented. It is not a bug.
A correctly-formed brace expansion must contain unquoted
opening and closing braces, and at least one unquoted comma
or a valid seque
On Wed, Feb 19, 2025, at 9:48 PM, Dale R. Worley wrote:
> What it is really doing is "declare foo to
> be the history file, and then read its contents and put them in the
> history list". The problem as I see it is that the easiest to spot part
> of the documentation is
>
> -r Re
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 expression are not treated
> spe
On Wed, Feb 12, 2025, at 2:02 PM, Andrés Rodríguez Reina wrote:
> And I also
> agree that any other substitution is subject to cause the same
> confusion, but the case with the tilde expansion produces more damage
> to inexperienced users. I mean: "rm -rf *" just deletes the whole
> folder cont
On Wed, Feb 12, 2025, at 10:50 AM, Andrés Rodríguez Reina wrote:
> In my opinion, it would be useful to have a warning be issued
> when in interactive mode, when at the current working directory a
> file/folder named '~' exists, and a command with a parameter starting
> with ~ is used (w
On Tue, Feb 11, 2025, at 9:18 AM, Greg Wooledge wrote:
> Look at the definition of set -e:
>
> -e Exit immediately if a pipeline (which may consist of a
> single simple command), a list, or a compound command
> (see SHELL GRAMMAR abov
On Mon, Feb 10, 2025, at 2:24 PM, Phi Debian wrote:
> On Mon, Feb 10, 2025 at 5:48 PM Chet Ramey wrote
>
>>
>> There isn't a reward for brevity or obfuscation; say what you mean:
>>
>> isnum2()
>> {
>> case "$1" in
>> [-+] | '') return 1;; # empty or bare `-' or `+'
>>
On Mon, Feb 10, 2025, at 1:05 PM, Andreas Schwab wrote:
> On Feb 10 2025, Greg Wooledge wrote:
>
>> No, I've shown that it *is* working in older versions of bash, and I'm
>> asking *why*.
>
> Does it? If it did, it should have printed -23, not -19.
Yeah, it doesn't work. The pattern ?([-+]) matc
On Sat, Feb 8, 2025, at 8:57 PM, Ángel wrote:
> I expect you to take this issue seriously and take the needed measures
> to ensure their wrong ways are fixed.
Alas, OP announced off-list that they have unsubscribed. If you
were to send your guidance to them directly, I'm sure they would
show you
On Tue, Feb 4, 2025, at 12:03 AM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> On 2025-02-03 23:54, Greg Wooledge wrote:
>
> We are talking about shtty.c
>
> Read the code and figure it out yourself since your so smart.
As the bug reporter, you're the one who has to prove there'
On Mon, Feb 3, 2025, at 11:37 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> READ THIS
>
> To be more clear here the GNU BASH shell that I tested with is merely
> a test case and the configuration was very harsh :
>
> $ ./configure --prefix=/home/dclarke/local --enable-threads
On Mon, Feb 3, 2025, at 11:08 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> READ THE BUG REPORT
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284513
Yes, let's.
The default FreeBSD bourne shell /bin/sh seems to ignore
the terminal config flag echoctl an
On Mon, Feb 3, 2025, at 10:24 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Focus on $BASH_VERSION:
>While you argue about testing for $BASH_VERSION, this point isn’t
> central to the bug report. The issue is about terminal reinitialization
> in sh‑mode (when Bash is inv
On Mon, Feb 3, 2025, at 8:52 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Every technical comment deserves thoughtful consideration. When a
> maintainer responds without reading and understanding the posts, or
> worse, dismisses them with drivel (as I found Lawrence’s respo
On Mon, Feb 3, 2025, at 5:43 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Thank you for taking the time to not review the FreeBSD bug report (Bug
> 284513) in full before responding. Your willingness to speculate on
> behaviors without testing in the relevant environment is
On Mon, Feb 3, 2025, at 2:57 PM, dale.wor...@comcast.net wrote:
> Within that context, if an element of PATH contains a '~' character, you
> don't expect that to cause execution requests to look in your home
> directory, because '~' isn't the name of your home directory.
Yes, that was the whole po
On Thu, Jan 30, 2025, at 9:12 PM, Greg Wooledge wrote:
> Even POSIX finally caved in and added examples
> showing both syntaxes, not expecting the reader to extrapolate from
> multiple sources.
The devel and bash-5.3-testing branches have more examples as well.
https://git.savannah.gnu.org/cgit/b
On Sun, Jan 26, 2025, at 5:40 PM, Pete Edwards wrote:
> The set command executed should list the shell variables and values,
> which
> it does, but it is followed by other text, which looks like script text
> that has no purpose in the output expectred.
The `set' built-in is documented to print b
On Thu, Jan 23, 2025, at 6:37 PM, Keith Thompson wrote:
> Description:
> A literal '~' or other tilde-prefix at the beginning of an
> element of $PATH is expanded when a command is executed
> from the bash prompt. This is undocumented and inconsistent with
> the behavior of other c
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` should work or not.
It sho
On Sat, Jan 18, 2025, at 5:10 PM, Lawrence Velázquez wrote:
> spilled so much text
bah, who needs proofreading anyway. everyone loves mangled metaphors
--
vq
On Sat, Jan 18, 2025, at 4:30 PM, Wiley Young wrote:
> On Sat, Jan 18, 2025 at 9:00 AM Greg Wooledge wrote:
>
>> So, if a sentence is ambiguous, then your assertion that it "can't not
> be read that way" must be false.
>
> I'm sorry you didn't get it on the first read through, Greg.
Ironic that so
On Sat, Jan 18, 2025, at 4:47 PM, Greg Wooledge wrote:
> On Sat, Jan 18, 2025 at 16:42:59 -0500, Lawrence Velázquez wrote:
>> It is true that the man page and texinfo manual do not define
>> "character". (It does not mean "abstraction"; I'm not su
On Sat, Jan 18, 2025, at 3:07 PM, Wiley Young wrote:
> Delving into the free Writing 101 lessons here
I would like a refund, please.
> On Sat, Jan 18, 2025 at 4:16 AM Lawrence Velázquez wrote:
>> " I find Wiley's main thesis -- that this sentence reads as a sort
&g
On Fri, Jan 17, 2025, at 7:55 AM, Greg Wooledge wrote:
> On Thu, Jan 16, 2025 at 21:16:47 -0800, Wiley Young wrote:
>> But sentence six is an emphatic concern if you ask me, for how "character"
>> reads as "alphabetic character". Also how sentences five and six can be
>> read as contradictory.
>
>
On Thu, Jan 16, 2025, at 8:05 PM, Wiley Young wrote:
> In Parameter Expansions / Case Modification:
>
> [S1]
> The first sentence reads, "alphabetic characters," which can imply that
> wherever else in the paragraph the word "characters" is used, that the
> intended meaning is "alphabetic charact
On Mon, Jan 13, 2025, at 3:03 AM, Félix Hauri wrote:
> Re-reading man page and this discussion, I thing either this variable is
> wrongly named "IFS", as `S` stand for "separator"
Okay. Not like it's going to change.
> Btw, the command "mapfile" (readarray) seem more suitable** than "read" for
On Sun, Jan 12, 2025, at 10:19 AM, MacBeth wrote:
> On Sun, Jan 12, 2025 at 8:58 AM MacBeth wrote:
>
>> And here is a version you would have to use without `sed` to get the line
>> first, before you can append the field terminator to it:
>>
>> delim=,
>> {
>> while IFS= read -r row; do
>>
On Wed, Jan 8, 2025, at 1:25 PM, Jeff Ketchum wrote:
> I ran into a strange bug using newer versions of bash, I haven't isolated
> it to a specific release.
It looks like 5.0 introduced the problem.
> In using unicode group separator character U 241D,
> https://www.compart.com/en/unicode/U+241D,
On Sun, Dec 29, 2024, at 3:54 PM, Daniel Colascione wrote:
> Are you really indifferent as to whether array indexes should be
> evaluated once or twice? Have you seen
> https://yossarian.net/til/post/some-surprising-code-execution-sources-in-bash/?
I'm aware of the pitfalls described therein, an
On Sun, Dec 29, 2024, at 3:44 PM, Daniel Colascione wrote:
> I wonder whether it would be possible to add a simple catch-all command
> that would encompass a set of options that can't be defaults but that
> make writing shell scripts easier, e.g. set -euo pipefail, nullglob,
> inherit_errexit, extg
Also replace "behaviour" with "behavior", which the project prefers.
This applies on top of commit bb56d620e075e3c96ae84b52de6b74683d9ab320,
the current tip of the devel branch.
---
CHANGES | 14 +++---
CHANGES-5.3 | 14 +++---
NEWS
On Fri, Dec 27, 2024, at 6:47 PM, Greg Wooledge wrote:
> You might have been raised on some other language where the && and ||
> operators have different precedence. In the shell language, they have
> the same precedence.
However, the && and || arithmetic operators do have C-like precedence.
On Tue, Dec 24, 2024, at 12:10 PM, Zachary Santer wrote:
> Some other nonsense real quick:
>
> zsant@Zack2021HPPavilion MSYS ~/repos/bash
> $ : ${| REPYL="whatever"}
> ; }
> bash: syntax error near unexpected token `;' while looking for matching `}'
> bash: DEBUG warning: current_token (10) != she
On Sat, Dec 21, 2024, at 1:52 PM, Greg Wooledge wrote:
> On Sat, Dec 21, 2024 at 09:56:15 -0800, Eric Pruitt wrote:
>> You need to escape one of the types of quotes. Double quotes is
>> generally simpler:
>
> Only in this restricted case. Using double quotes as the outer layer
> means you have to
On Fri, Dec 20, 2024, at 8:09 AM, Greg Wooledge wrote:
> help -d cdoes not exactly match anything, so it's treated like c\*
Is this documented somewhere? I'm not seeing anything about it in
the man page or texinfo manual.
--
vq
On Wed, Dec 18, 2024, at 9:39 PM, Zachary Santer wrote:
> $ set -u
> $ unset REPLY
> $ printf '%s\n' "${REPLY}"
> bash: REPLY: unbound variable
> $ printf '%s\n' "${| :; }"
>
> $ printf '%s\n' "${| unset REPLY; }"
FWIW, this agrees with mksh R59 2020/10/31 but not zsh master.
(I'll be raising the
On Thu, Dec 12, 2024, at 2:01 AM, Mike Jonkmans wrote:
> Yes, the posix grammar doesn't allow it.
> But it is not clear, from the bash documentation,
> that a pipeline is not a command.
Sure, the documentation doesn't explicitly say that. But it also
doesn't say that pipelines are composed of pip
On Wed, Dec 11, 2024, at 3:50 AM, Mike Jonkmans wrote:
> Or worse: '! true | ! true' is a syntax error!?
> Also errors in dash, but not in ksh.
> Can a command - as part of a pipeline - not be a pipeline?
Not directly, no. (Andreas has already given a workaround.)
https://pubs.opengroup.org/onli
On Sun, Dec 8, 2024, at 3:27 AM, Yuri Kanivetsky wrote:
> $ bash -c 'IFS=x; a=ax; f() { for arg; do echo "($arg)"; done; }; f $a'
> (a)
>
> $ bash --version
> GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
>
> I.e. IFS non-whitespaces are not stripped at the beginning of a word,
> but if
On Mon, Dec 2, 2024, at 3:27 PM, Chet Ramey wrote:
> On 11/30/24 10:41 PM, Lawrence Velázquez wrote:
>> On Sat, Nov 30, 2024, at 9:36 PM, Dan Jacobson wrote:
>>> We see for simple
>>> $ history
>>> output, there's no way to change the file it reads, at le
On Sat, Nov 30, 2024, at 9:36 PM, Dan Jacobson wrote:
> We see for simple
> $ history
> output, there's no way to change the file it reads, at least with the
> current (same PID) shell.
Why is "same PID" a requirement? Why isn't something like this
sufficient?
history_f() (
On Mon, Nov 25, 2024, at 9:47 PM, #!microsuxx wrote:
> V adds english text
That's not what I'm talking about.
--
vq
On Mon, Nov 25, 2024, at 9:03 PM, Martin D Kealey wrote:
> I keep "similar" there because ‘type -a COMMAND’ shows all possible matches
> for COMMAND, whereas ‘command -V’ only does that when COMMAND is NOT an
> alias.
I'm not seeing that "command -V" behavior.
$ type -a bash
bash
On Mon, Nov 25, 2024, at 3:18 PM, Lawrence Velázquez wrote:
> $ unset IFS
Sorry, this is from an earlier draft in which I used $* to generate
the string of space-separated letters. I just forgot to remove it;
it isn't relevant for the example I actually sent.
--
vq
On Mon, Nov 25, 2024, at 2:18 PM, marcel.plch via Bug reports for
the GNU Bourne Again SHell wrote:
> Not in one place the pattern "[[:space:]]" is mentioned.
Why should the "space" character class be called out in particular?
It's not special.
> If adding just one sentence containing "[[:space:]
On Sun, Nov 24, 2024, at 10:08 AM, Andreas Kähäri wrote:
> On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote:
>> Similar cases exist elsewhere within the man page. For example, if you
>> search for $! or $$ you will not find the section that documents them.
>> You would have to know th
On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU
Bourne Again SHell wrote:
> I am trying to do some file management in bash and I have strings in
> this format:
>
> 1 dir/hello.txt
> 2 dir2/bar.jpg
>
> When I run this substitution:
> ${FOO/[:space:]*/Hello}
> I get this r
On Sun, Nov 17, 2024, at 1:16 PM, Mike Peters wrote:
> On 2024-11-16 22:56, Lawrence Velázquez wrote:
>> Be aware that <(> Emanuele brought it up [2]; it will not work in future releases.
>
> I don't know what documentation it was missing from, but this usage is
> c
On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
>> Description:
>> Process substitution does not generate properly when pulling from
>> another file descriptor, although it works when pulling from a file
>> directly. In t
On Mon, Oct 21, 2024, at 4:23 PM, Zachary Santer wrote:
> On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey wrote:
>>
>> On 10/21/24 9:54 AM, Robert Elz wrote:
>> > From the earlier message (just replying to this one to get the
>> > new Subject: which fits better)...
>> >
>> > zsan...@gmail.com said:
>
On Sun, Oct 20, 2024, at 8:51 PM, Zachary Santer wrote:
> Item 8 is just odd and is on the verge of being a dealbreaker. Not to
> go off on another tangent, but what on Earth?
>
> Item 3 is also a weird thing to do
Neither of these is "odd" or "weird". They are consistent with
other shells and sp
On Sat, Oct 12, 2024, at 2:22 AM, David Moberg wrote:
> So this kind of bugfix is not enough to ever trigger a new release on its
> own? (sounds wise)
No, but Chet does periodically release particularly important fixes
as patches against the most recent release. (Those make up most of
the commits
On Sat, Oct 12, 2024, at 1:43 AM, David Moberg wrote:
> Oh, is this already fixed?
Yes.
> What am I looking at?
The commit that fixed it.
> This link shows a big commit to bash. Is it merged to main/release?
No. It won't be until Chet releases 5.3.
> Can I try it out?
See Oğuz's message.
>
On Sat, Oct 12, 2024, at 1:11 AM, David Moberg wrote:
> Has anyone been able to take a more deep look?
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=254081c09767738833cdf161b4bc3feb1a51690a
--
vq
On Wed, Sep 18, 2024, at 1:22 AM, John Devin wrote:
> On line 3987 of bash.1 (here:
> https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1#n3987),
> `The\fBextglob\fP` is missing a space between 'The' and 'extglob'.
This was fixed on the "devel" branch in 2022.
https://git.savannah.gnu.org/
This question is more appropriate for help-bash than bug-bash.
On Tue, Sep 17, 2024, at 2:21 AM, William Park wrote:
> Hi all,
>
> Is there fast way of splitting and joining of strings in the recent Bash
> versions?
Define "fast".
> For splitting, I'm aware of
> old="a,b,c"
> IFS=, re
On Sun, Aug 25, 2024, at 6:24 PM, youheng@gmail.com wrote:
> Bash Version: 5.1
>
> Patch Level: 16
Note that this version of bash is outdated and will not receive
further updates. The current release is 5.2.
> All the following scripts can create a Segmentation Fault
>
> eva
On Sat, Aug 24, 2024, at 11:49 PM, Lawrence Velázquez wrote:
> Correct. Since you're using $* unquoted in a context where field
> splitting is performed, the shell does not expand it to a single
> field.
That is, unless there's a single positional parameter that is not
further split.
--
vq
On Sat, Aug 24, 2024, at 10:08 PM, Steffen Nurpmeso wrote:
> One hopefully last thing in this regard for me,
>
> c() { echo "$# 1<$1> 2<$2> 3<$3> *<$*> @<$@>"; }
This easily obfuscates the structure of the "$@" expansion. You'd
be better off with something like this, which prints each positiona
On Tue, Aug 20, 2024, at 1:42 AM, supp...@eggplantsd.com wrote:
> The suggestion is that the default behavior needs some work
The default behavior is unlikely to change. For every cherry-picked
example of someone unsatisfied with it (bugs aside), there is likely
someone else who prefers it as is
On Sat, Aug 17, 2024, at 6:41 AM, Freek de Kruijf wrote:
> Apparently I have a problem with the concept of $@
Greg has already tried explaining it, so I'll just focus on a few details:
> I see it as list of zero or more non-whitespaced elements
When used in a context where splitting is performe
On Fri, Aug 16, 2024, at 6:29 PM, Lawrence Velázquez wrote:
> There is no problem with "$@" or functions here. The "problem" is
> that "$@" expands to multiple fields when there are two or more
> positional parameters, so (as the error message says) you
On Fri, Aug 16, 2024, at 12:59 PM, freek--- via Bug reports for the GNU Bourne
Again SHell wrote:
> Description:
>
> Using the following script with a function
>
> #!/bin/bash
> init() {
> [ -n "$@" ] && echo $@
> }
> init $@
>
> and calling the script as follows:
>
> :~> LC_ALL=C . ./test.sh a b
On Thu, Jul 18, 2024, at 8:57 AM, Greg Wooledge wrote:
> $a is equivalent to ${a[0]}.
This is documented, by the way. It is not a bug.
"Referencing an array variable without a subscript is equivalent to referencing
with a subscript of 0."
https://www.gnu.org/software/bash/manual/html_node/Arra
On Tue, Jul 16, 2024, at 3:47 AM, David Hedlund wrote:
> Do you think that it would be appropriate to submit this feature request
> to the developers of the rm command instead.
How would this help? The rm utility cannot change the working directory of the
shell that invokes it, or of any other
On Thu, Jul 11, 2024, at 9:53 PM, David Hedlund wrote:
> On 2024-07-12 00:54, Lawrence Velázquez wrote:
>> (You're free to argue that bash *should* behave this way, but that's
>> a feature request, not a bug report. And having bash automatically
>> update its workin
On Thu, Jul 11, 2024, at 6:08 PM, David Hedlund wrote:
> Expected behaviour
> When a directory is deleted while the user is inside it, the terminal
> should automatically return to the parent directory.
>
> ```
> user@domain:~/test$ mkdir ~/test && cd ~/test && touch foo && ls
> foo
> user@do
On Thu, Jul 11, 2024, at 9:42 AM, Dr. Werner Fink wrote:
> I've a report that with later bash the following which works in bash-4.2
>
> [...]
>
> linux-40cm:~ # x () {
> > local x=y
> > declare -p x
> > echo $x
> > unset x
> > declare -p x
> > echo $x
> > }
> linux-40cm:~ # x
On Sat, Jun 15, 2024, at 5:30 PM, Saint Michael wrote:
> in this code:
> data="'1,2,3,4','5,6,7,8'"
>
> # Define the processing function
> process() {
> echo "There are $# arguments."
> echo "They are: $@"
> local job="$1"
> shift
> local a="$1"
> shift
> local b="$1"
>
On Mon, May 27, 2024, at 8:58 PM, porterleete wrote:
> The man page for printf says that for integer m, %m$ lets you
> specify which argument that the conversion specification will use.
> Similarly, using *m$ instead of * in a conversion specification lets
> you specify which argument the * will
On Fri, May 24, 2024, at 9:04 AM, Koichi Murase wrote:
> 2024年5月24日(金) 19:18 Martin D Kealey :
>> On Tue, 21 May 2024 at 23:16, Koichi Murase wrote:
>>> However, I personally do not think the FPATH mechanism is useful
>>> because a file can only contain one function per file. Significantly
>>> non
On Sat, May 18, 2024, at 11:17 AM, Phi Debian wrote:
> I am xing fingers the consensus, if any of theses takes off,
> is to have [...] protection against alias source='source -i'
This seems out of scope, regardless of what happens with "-i".
> I really depend on actual 'source' behavior, and can
On Sat, May 18, 2024, at 11:41 AM, Matheus Afonso Martins Moreira wrote:
>> I am xing fingers the consensus, if any of theses takes off,
>> is to have the -i implemented (not omitted)
>
> Me too. Do you know anyone else who could be impacted?
> Consensus might move in that direction if more voices
The devel man page and texinfo manual both describe the upcoming
GLOBSORT variable with the following sentence, which has a stray
comma at the end. (I omitted it in my last message to kre.)
A sort specifier of `nosort' disables sorting completely;
the results are returned in the o
On Thu, May 16, 2024, at 11:36 PM, Robert Elz wrote:
> Date:Thu, 16 May 2024 11:36:50 -0400
> From:Chet Ramey
> Message-ID: <613852f3-c9ef-43d8-821b-37be3d9e9...@case.edu>
>
> | I have high hopes for `GLOBSORT', though.
>
> That is at least a plausible name - never heard
1 - 100 of 320 matches
Mail list logo
