Date:Wed, 30 Jul 2025 09:31:52 -0600
From:Stan Marsh
Message-ID:
| I wonder why "" was previously special-cased.
Once upon a time, chdir("") would have acted the same as chdir(".")
because in the kernel, the pathname lookup would see that this is
a relative path (
Date:Tue, 15 Jul 2025 23:17:56 +1000
From:Martin D Kealey
Message-ID:
| For stat to give an accurate answer, a snapshot of the content would have
| to be generated, counted, and discarded,
Not at all - simply define the format in such a way that the size is
eit
Date:Mon, 14 Jul 2025 15:22:35 -0400
From:Chet Ramey
Message-ID: <90a41c5d-c407-4a36-b7b1-21a9201b4...@case.edu>
| Say you have something like
|
| if command; then
| declare -i X
| X=some-random-expression
| fi
|
| How does the parser determine
Date:Mon, 14 Jul 2025 10:52:50 -0400
From:Chet Ramey
Message-ID: <2702d742-d1d6-4929-9024-028a2d5cf...@case.edu>
| One of the assumptions bash makes is that when the kernel tells it the size
| of a regular file using stat(2), it's telling the truth,
That's entire
Date:Mon, 14 Jul 2025 10:34:12 -0400
From:Chet Ramey
Message-ID: <6a02a36f-d31d-4816-8988-5a4ccf960...@case.edu>
| The short story is that `wait -n' now returns the status of any process
| that's completed and hasn't been waited for yet, just like `wait'. It's
Date:Sat, 12 Jul 2025 18:52:55 -0400
From:Zachary Santer
Message-ID:
| Now I'm drifting into Martin Kealey's camp. I don't want a new syntax
| for associative array subscripts, but I would give up some backwards
| compatibility in return for having arithmetic
Date:Wed, 9 Jul 2025 14:00:46 -0400
From:Greg Wooledge
Message-ID: <20250709180045.ga28...@wooledge.org>
| If that's true, then I don't understand why these two commands give
| different results:
|
| (( hash[\$key]++ ))
| let "hash[\$key]++"
|
|
Date:Mon, 30 Jun 2025 10:44:24 -0400
From:Greg Wooledge
Message-ID: <20250630144424.gj32...@wooledge.org>
| Unfortunately, that's not true. You need $ if you want to use any
| special parameters in an arithmetic context, such as $# or $1.
There are a zillion oth
Date:Sun, 29 Jun 2025 08:13:07 -0600
From:Stan Marsh
Message-ID:
| So, is this POSIX, or just a dash-extension?
It is original Bourne Shell (from 7th edition Bell Labs Unix)
and is (or should be) supported by every Bourne-compatible shell.
It definitely is in POS
Date:Thu, 19 Jun 2025 09:27:20 +0200
From:microsuxx
Message-ID:
| bash -e -c 'echo $(exit 1) ; wait -n ; echo survived'
You really need to stop proposing nonsense when you have no idea
what is happening, or why:
bash -ec 'true; wait -n; echo survived'
Date:Thu, 12 Jun 2025 12:26:17 -0400
From:Chet Ramey
Message-ID: <86c23b56-de98-431d-be83-727013b65...@case.edu>
| This isn't unreasonable, at least for the change to allow quoted characters
| in function names.
If that also includes any characters which would ne
Date:Thu, 12 Jun 2025 09:09:42 -0400
From:Chet Ramey
Message-ID: <3ed55e81-00e3-4f91-8fdd-f7fba7bc9...@case.edu>
| >| That wouldn't have been backwards compatible, so I didn't add quote
| >| removal.
| > Really, in what cases?
| In every case. If y
Date:Wed, 11 Jun 2025 10:09:46 -0400
From:Chet Ramey
Message-ID:
| That wouldn't have been backwards compatible, so I didn't add quote
| removal.
Really, in what cases? Like Koichi Murase showed, I can't find any
way to get a quote char (without objection) int
Date:Wed, 11 Jun 2025 10:07:37 -0400
From:Chet Ramey
Message-ID: <7ef0aaf1-e56e-433e-9d29-4ad232871...@case.edu>
| That's the function name. In general, a function name is a WORD that
| does not undergo any word expansions, not even quote removal.
Not doing expan
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't bash that has cha
Date:Tue, 10 Jun 2025 17:34:44 -0400
From:Zachary Santer
Message-ID:
| Functions can be declared inside of other functions, so I thought
| doing the following was pretty slick:
Function definitions aren't declarations in any sense similar to
other programming l
Date:Wed, 4 Jun 2025 00:57:15 +0900
From:Koichi Murase
Message-ID:
| > xx. <( and >( can now be used in function names.
|
| What is the background of this change?
I think I agree with the point here -- while I strongly believe that
almost anything should be p
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 `cat' produces.
Date:Thu, 27 Mar 2025 17:22:03 -0400
From:Chet Ramey
Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu>
| The shell should assume that setting a shell variable means the
| user wants to modify the shell's locale settings.
Yes, of course, the question is
Date:Wed, 26 Mar 2025 16:05:57 -0400
From:Chet Ramey
Message-ID:
| There is a precedence hierarchy associated with locale environment
| variables, since setting and unsetting environment variables is under
| the user's control.
This brings up an unrelated, bu
Date:Sat, 15 Mar 2025 21:54:18 -0500
From:MacBeth
Message-ID:
| bash(1) claims it to be:
Actually, I don't think it does,
| There are three quoting mechanisms: the escape character, single
| quotes, and double quotes.
|
| A non-quoted backsla
Date:Sun, 16 Mar 2025 02:35:12 +0100
From:Steffen Nurpmeso
Message-ID: <20250316013512.2aC3SIyk@steffen%sdaoden.eu>
| The problem is not an empty field.
Your problem might not be, but it all derives from that.
| The problem is that ":a:" has to be splitted to ""
Date:Sat, 15 Mar 2025 18:08:48 -0500
From:MacBeth
Message-ID:
| However you could fake it, by including backslashes in the delimiter,
| which would allow literal newlines, but bash would ignore them as they
| are escape sequences.
bash does, so does mksh, zs
Date:Sat, 15 Mar 2025 23:59:24 +0100
From:Steffen Nurpmeso
Message-ID: <20250315225924.1YC4dm9D@steffen%sdaoden.eu>
| |And further, i have zero idea how shells come to the result that
| |they do if they do *not* split the fields individually. But if
| |they
Date:Sat, 15 Mar 2025 23:41:45 +0100
From:Steffen Nurpmeso
Message-ID: <20250315224145.YPWRnxq7@steffen%sdaoden.eu>
| * Expands to the positional parameters, starting from one,
| initially producing one field for each positional parameter that
| is set
I should have added in my last reply that if you want to investigate
field splitting, and how it works in various cases, use the expansion
of a simple variable
x=whatever
IFS=something
echo $x
or better:
args() {
printf '#=%d' "$#"
Date:Sat, 15 Mar 2025 19:42:54 +
From:Nikola Novak via Bug reports for the GNU Bourne Again SHell
Message-ID:
| OK, thank you!
| It's a relief, actually, to hear that. :)
The reason for this is that POSIX says (XCU 2.7.4):
The here-document shall
Date:Fri, 14 Mar 2025 22:47:38 +0100
From:Steffen Nurpmeso
Message-ID: <20250314214738.Milbudgm@steffen%sdaoden.eu>
| I cannot reproduce this, both NetBSD sh and bash say
|
| set -- '' '' a '' '' b '' '';echo $#,$*; set -- $*; echo $#,$*
| 8, a b
| 2,a
Date:Fri, 14 Mar 2025 01:34:48 +0100
From:Steffen Nurpmeso
Message-ID: <20250314003448.DdqG5Ont@steffen%sdaoden.eu>
| I am deeply sorry, but i have one more difficulty that i fail to
| explain to myself.
As always, there are no rules for this for MUAs so you can
Date:Sat, 22 Feb 2025 09:48:29 +0100
From:Andreas Schwab
Message-ID: <87r03q5pr6@linux-m68k.org>
| As long as NL_ARGMAX >= 999.
A correction - I just checked the POSIX spec again, and it appears
that they copied the text from printf(3) into printf(1) - that sim
Date:Sat, 22 Feb 2025 09:48:29 +0100
From:Andreas Schwab
Message-ID: <87r03q5pr6@linux-m68k.org>
| On Feb 22 2025, Phi Debian wrote:
| > I forgot to mention your trick to nuke the fmt reuse still works
| > $ printf '%s %s %s %999$s' A B C D E F G
| > A B C
Date:Fri, 21 Feb 2025 10:55:56 -0500
From:Chet Ramey
Message-ID:
| That is bizarre and indefensible.
Like I said, it isn't what I'd do, but it is easy to see how an
implementation might end up like that (and ksh93's might be one of
the first of them, which kind of
Date:Fri, 21 Feb 2025 09:08:13 -0500
From:Chet Ramey
Message-ID: <59a1d1d0-b6eb-4652-9e77-1fc4c5992...@case.edu>
| Given the following, which POSIX says is unspecified:
|
| printf '%s %3$s %s\n' A B C D
|
| ksh93-u+m prints "A D", which is just wrong.
It ac
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, yash, and all derive
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 wron
Date:Sat, 8 Feb 2025 19:33:10 -0500
From:Greg Wooledge
Message-ID: <20250209003310.gm29...@wooledge.org>
| You really want bash's ${var//search/replace} feature for the
| renaming step,
In some cases I might agree, not necessarily about the
mechanism, but about d
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
|
Date:Sat, 8 Feb 2025 10:09:30 +0100
From:Phi Debian
Message-ID:
| Why 2#1 is invalid ?
It isn't a valid form for a C constant.bash allows that kind of thing
in its arithmetic contexts, but this is not one.
You did notice that printf printed '2' not the bash
Date:Sat, 8 Feb 2025 13:21:34 +1000
From:Martin D Kealey
Message-ID:
| While POSIX doesn't directly specify what happens when converting
| an empty-string to a number,
It also doesn't say what should be done when converting %%% into a number
either, but I doub
Date:Mon, 03 Feb 2025 19:00:28 -0500
From:Zeffie via Bug reports for the GNU Bourne Again SHell
Message-ID: <875b2e87e5d847a4aa04ba2b31bec...@zeffie.com>
| To whom it may concern,
That is most probably not anyone on this list - you'd need to contact
the list maint
Date:Thu, 30 Jan 2025 11:00:36 -0600
From:MacBeth
Message-ID:
| errwait() { while wait -n || return; do :; done; }
Yes, that would also be good (could have the -p added as well if desired).
kre
Date:Thu, 30 Jan 2025 06:03:18 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| `while wait -n; do :; done' already does that
Not quite, after that loop $? = 0 (always) so there's no way to
tell whether or not one of the commands failed, which I suspect
was the orig
Date:Sun, 12 Jan 2025 22:39:57 -0500
From:Greg Wooledge
Message-ID: <20250113033957.gc27...@wooledge.org>
| At the risk of going a bit off topic, may I ask *why* the shell does
| that? Were there any files or data stream conventions in common use
| in the 1970s
Date:Sun, 12 Jan 2025 16:55:05 -0500
From:Greg Wooledge
Message-ID: <20250112215505.gb27...@wooledge.org>
| Right. You explained why it works the way it does. But from a user's
| point of view, it's just unexpected behavior.
It is unexpected, because users beli
Date:Sun, 5 Jan 2025 11:17:05 +
From:Tobi Laskowski
Message-ID:
| It is not possible to have a naive SHELLOPTS=myopt configured outside
| the shell without all future options being exported implicitly.
I have never used SHELLOPTS, and have never tested this
Date:Sun, 22 Dec 2024 13:45:19 +1000
From:Martin D Kealey
Message-ID:
| But a nagging question is why does the text contain both ' and "
| characters?
My guess (and that is all it is) is that the answer isn't that it contains
both, but that it might contain eit
Date:Sun, 22 Dec 2024 09:39:11 +0700
From:Robert Elz
Message-ID: <10875.1734835...@jacaranda.noi.kre.to>
| Not sure about current bash
I must has been bashed in the brain there, I meant dash,
bash has had this for eons (as have most of the others in
which it
Date:Sat, 21 Dec 2024 19:47:31 -0500
From:Greg Wooledge
Message-ID: <20241222004731.go29...@wooledge.org>
| Either way, it's not widespread yet, and one shouldn't expect it to be
| available outside of bash.
If it were only in bash it would never have made it int
Date:Sat, 21 Dec 2024 13:49:48 -0500
From:Greg Wooledge
Message-ID: <20241221184948.gm29...@wooledge.org>
| Choice #2: use $'...' quoting,
| Choice 2 is a bash extension.
No it isn't, or at least not any more. Dollar-Quote quoting (sometimes
called C-stye strin
Date:Wed, 18 Dec 2024 13:56:48 -0800
From:Kaz Kylheku
Message-ID:
| The $$ parameter is expanded to a decimal numeric word
| *before* the while command is executed,
No it isn't.
| so the background process is referencing the correct PID of the parent.
But th
Date:Sat, 14 Dec 2024 19:21:50 -0500
From:Greg Wooledge
Message-ID: <20241215002150.gc30...@wooledge.org>
| The output of "set" includes more than just variables. It also includes
| shell functions.
But that's a clear standards violation - but to be clear, if po
Date:Tue, 26 Nov 2024 16:23:56 +1000
From:Martin D Kealey
Message-ID:
| I'm not convinced that ‘command’ should mention aliases at all, since
| ‘command -v "$var"’ should tell you what ‘"$var"’ will do.
| What it *won't* do is be expanded as an alias.
Absolut
Date:Sun, 17 Nov 2024 12:16:40 -0600
From:Mike Peters
Message-ID:
| * (Although I have yet to determine any purpose or significance of
| these redirections in the manual, other than simply not causing an error,
| as it "do[es] not affect the current shell envi
Date:Sat, 16 Nov 2024 14:05:17 +1000
From:Martin D Kealey
Message-ID:
| I know, but "explicitly" is not the same as "highlighted", let alone "well
| enough".
Please, nothing at all like you're suggesting. Man pages are not, and
not intended to be, tutorials.
Date:Thu, 14 Nov 2024 00:30:32 +0100
From:"#!microsuxx"
Message-ID:
| i just dunno the exec cmd to bring back the fd 1 and 2 after usage back to
| tty , or restore from saved
Assuming that this is even slightly relevant to the question here (whether
any of thi
Date:Wed, 13 Nov 2024 15:18:58 -0800
From:Yuri
Message-ID:
| I need to (1) source the user script, (2) save this script's output to a
| dedicated file, (3) keep the same output in stdout, and (4) keep
| environment variables that the user script sets for late
Date:Mon, 4 Nov 2024 19:30:23 +1000
From:Martin D Kealey
Message-ID:
| I guess I should s/POSIX/common Unix-like tradition/ and maybe
| mumble something about BSD.
Yes, but this would not be the place where it is appropriate to
request system call changes - wha
Date:Mon, 4 Nov 2024 06:55:54 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| On Monday, November 4, 2024, Martin D Kealey
| wrote:
|
| > POSIX says that the execve syscall reads the name of an interpreter (and
| > options) from a '#!' line,
| >
|
| W
Date:Fri, 18 Oct 2024 16:28:06 -0400
From:Chet Ramey
Message-ID:
| At the time (previous edition of the standard), POSIX defined whitespace
| as "In the POSIX locale, white space consists of one or more (
| and characters), , , ,
| and characters."
Yes,
>From the earlier message (just replying to this one to get the
new Subject: which fits better)...
zsan...@gmail.com said:
| I can work around function names needing to be valid shell 'name's by
That one bash could easily fix if it wanted to, there's never been a
POSIX requirement that only "n
Date:Thu, 17 Oct 2024 17:14:52 -0400
From:Chet Ramey
Message-ID: <9d279d7f-ea94-4f75-9a52-059f6d2b9...@case.edu>
| > Maybe those defenders can elucidate what purpose that behavior
| > would serve.
|
| kre's on the list, maybe he'll speak up.
Sorry, I largely
Date:Thu, 17 Oct 2024 18:44:59 -0400
From:Greg Wooledge
Message-ID:
| Between bash 4.4 and 5.0, the definition of "IFS whitespace" has apparently
| been expanded:
Not going to comment on bash, or its manual, specifically, but the
standard allows anything that th
Date:Thu, 26 Sep 2024 10:39:23 -0400
From:Chet Ramey
Message-ID:
| If it's going to be unspecified, it will be because there are conflicting
| implementations, not because we can't decide on the right language.
Yes, of course, and it wasn't the wording I meant,
Date:Wed, 25 Sep 2024 16:15:07 -0400
From:Chet Ramey
Message-ID: <20daab70-09e2-4dfa-a98a-4ba29b622...@case.edu>
| Do you think the text you quoted satisfies the "unless otherwise specified?"
I think "unspecified whether it is removed at A or B" is fairly clear
tha
Date:Wed, 25 Sep 2024 11:06:10 -0400
From:Chet Ramey
Message-ID:
| So you are saying that prompt notifications and `jobs' have the same
| effect. POSIX implies but does not require this, and there is differing
| behavior among current implementatations.
What i
Date:Thu, 19 Sep 2024 00:45:44 +0200
From:Steffen Nurpmeso
Message-ID: <20240918224544.aXWgbZu-@steffen%sdaoden.eu>
| Woops. I did not know that, i always separate {} at the beginning
| an the end, yet not ().
'(' and ')' (parentheses) are operators, '{' and '}'
Date:Wed, 18 Sep 2024 23:05:06 +0200
From:Steffen Nurpmeso
Message-ID: <20240918210506.9rRUe2TG@steffen%sdaoden.eu>
| I am totally surprised they all swallow this code, there is no
| separating whitespace in between the ; and the } which closes the
| function --
Date:Wed, 18 Sep 2024 07:21:30 -0400
From:Greg Wooledge
Message-ID:
| On Wed, Sep 18, 2024 at 08:05:10 +0300, Oğuz wrote:
| > It boils down to this:
| > f(){ echo $#;}; set "" "" ""; IFS=x; f $*
| > bash, NetBSD and FreeBSD sh, and ksh88 all agree and pri
Date:Wed, 24 Jul 2024 13:22:07 + (UTC)
From:morshalev@morsh.c.edafarm-workstations-prod.internal
Message-ID:
<20240904151336.D40A9142EBC@morsh.c.edafarm-workstations-prod.internal>
There is no bug here.
| if source command.sh ; then
| command.sh contain 'set
Date:Fri, 30 Aug 2024 00:39:40 +0200
From:Steffen Nurpmeso
Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu>
| On Linux it seems not even to cause TTOU if you set
| attributes which are effectively identical to what is already
| active
Yes, my wording wa
Date:Thu, 29 Aug 2024 10:40:25 -0400
From:Chet Ramey
Message-ID:
| It's not a big problem. You're in the background if your process group is
| not equal to the terminal's process group.
That's more or less sufficient to determine if the process is in a backgroun
Date:Wed, 28 Aug 2024 02:03:54 +0200
From:Steffen Nurpmeso
Message-ID: <20240828000354.qZaQvm7v@steffen%sdaoden.eu>
| That confuses me again, unfortunately i got a bug report and
| distracted. I mean, i would
|
| 1. skip leading whitespace anyhow (IFS or not,
Date:Tue, 27 Aug 2024 22:02:34 +0200
From:Steffen Nurpmeso
Message-ID: <20240827200234.95X76_wN@steffen%sdaoden.eu>
| Any character in IFS delimits a field, adjacent IFS whitespace
| characters are then ignored.
Not quite. Any sequence of any amount of IFS
Date:Sun, 25 Aug 2024 04:08:58 +0200
From:Steffen Nurpmeso
Message-ID: <20240825020858.nrX4pFTm@steffen%sdaoden.eu>
| (The only thinkable answer is that the step that my MUA does,
| namely resolving $* as a single string first, does not happen,
| right?
That's
Date:Sat, 24 Aug 2024 02:33:26 +0200
From:Emanuele Torre
Message-ID:
| No. It is working correctly.
It is indeed.
| This $1 is unquoted, it will be split. You need to use "$1" if you don't
| want it to split.
Alternatively, make a() be
a()
{
Date:Fri, 23 Aug 2024 23:47:06 +0200
From:Steffen Nurpmeso
Message-ID: <20240823214706.oskn9OEF@steffen%sdaoden.eu>
| So IFS whitespace only if part of $IFS.
That is the definition of IFS whitespace.
| So this "adjacent" even if *not* part of $IFS.
No, only cha
Date:Wed, 21 Aug 2024 11:00:19 -0400
From:Chet Ramey
Message-ID: <1b229634-888f-4f06-8761-c16d62501...@case.edu>
| POSIX doesn't actually say that. It says, in a couple of different places,
| "the message shall be written immediately prior to writing the next prom
Date:Wed, 21 Aug 2024 12:09:06 -0400
From:Grisha Levit
Message-ID:
| I've found using
|
| bash --norc -in <<< INPUT
|
| invaluable for testing input handling so I hope that remains an option.
That kind of thing (not precisely that) is why the NetBSD s
Date:Sun, 18 Aug 2024 02:09:10 +0200
From:Milana <948...@riseup.net>
Message-ID:
| I recently encountered an issue while experimenting with different shell
| options in Bash. When launching Bash with both the `-n` (noexec) and `-o
| ignoreeof` flags in interac
Date:Thu, 15 Aug 2024 23:33:42 +0200
From:Steffen Nurpmeso
Message-ID: <20240815213342.t6-hdjZT@steffen%sdaoden.eu>
| I have extended the test a bit, and i also see word split
| differences.
There are so many problems with this test, that I'm not sure
it is worth
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"
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
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
Date:Sat, 13 Jul 2024 08:57:18 +0200
From:Andreas =?iso-8859-1?B?S+Ro5HJp?=
Message-ID:
| After the "export", the variable has been *set*.
That's right, but there's no point answering that message here,
the anonymous poster will almost certainly never see it.
Law
Date:Fri, 12 Jul 2024 11:48:15 -0400
From:Chet Ramey
Message-ID: <258bcd3a-a936-4751-8e24-916fbeb9c...@case.edu>
| Not really, since the original intent was to wait for the *next* process
| to terminate.
There are two issues with that. The first is "next after
Date:Fri, 12 Jul 2024 03:53:01 +0200
From:David Hedlund
Message-ID: <820e6ee2-7444-4a01-991a-3530c2591...@gnu.org>
| Thanks, Lawrence! I found this discussion helpful and believe it would
| be a valuable feature to add. Can I submit this as a feature request?
Yo
Date:Thu, 11 Jul 2024 16:01:20 -0400
From:Chet Ramey
Message-ID: <2739cbbc-d44e-423e-869e-f2884c148...@case.edu>
| The bug in bash-4.2 was that [...]
| This would have been clearer to see (and more misleading) if the variable
| x also had a value at the global
Date:Tue, 25 Jun 2024 10:25:48 -0400
From:Chet Ramey
Message-ID: <983be032-0b60-4313-a18a-5fd74d5b5...@case.edu>
| On 6/24/24 4:36 PM, Gioele Barabucci wrote:
| > the manpage states:
| >> The --rcfile file option will force bash to
| >> read and execute comman
From: Alain BROSSARD
| I did think about the case to parse the output, but this means that you
| already know that the problem is triggered by calling an external program.
I think there is some miscommunication going on here. The message I
sent had nothing to do with the original problem
Date:Fri, 14 Jun 2024 07:28:41 +
From:Alain BROSSARD
Message-ID:
Most of this looks to be solved, or solvable now, but I see no-one seems
to have replied to this particular comment:
| Add to this that it is extremely difficult to check whether -a is set
| o
Date:Fri, 14 Jun 2024 13:34:28 +1200
From:Martin D Kealey
Message-ID:
| To be clear, this isn't a bug report, but rather a feature request to
| implement a common extension, and to interpret TZ=...,M*m.w* printf in line
| with the rest of GNU.
To that you'd w
Date:Fri, 14 Jun 2024 00:31:31 +1200
From:Martin D Kealey
Message-ID:
| I also note a minor bug/issue with printf in Bash 5.3-alpha: the builtin
| printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
That's user error, POSIX format requires 3
Date:Thu, 13 Jun 2024 11:51:13 -0400
From:"Dale R. Worley"
Message-ID: <87jzisx2mm@hobgoblin.ariadne.com>
| For instance, how should this be logged?
|
| $ { echo foo ; echo bar ; } >/dev/null
In the NetBSD shell:
[jacaranda]{2}$ { echo foo ; echo bar
Date:Wed, 12 Jun 2024 19:31:13 +0200
From:Angelo Borsotti
Message-ID:
| I would stress the importance of this: the purpose of scripts is
| to execute commands,
Yes.
| informing the caller of what they execute,
No. If a script wants to provide output like
Date:Thu, 13 Jun 2024 14:41:24 +
From:Alain BROSSARD via Bug reports for the GNU Bourne Again SHell
Message-ID:
| 1. Bash with -a , under some conditions, exports to the environment
| the variable COLUMNS which it shouldn’t
That one is debatable
Date:Mon, 10 Jun 2024 07:41:27 -0400
From:Zachary Santer
Message-ID:
| I assume the coproc fd behavior of
| being closed after most forks is not handled through a system fd flag,
| though if there is a system fd flag that would cause an fd to
| automatically
Date:Wed, 5 Jun 2024 13:31:20 -0400
From:Saint Michael
Message-ID:
| the most obvious use of floating variables would be to compare
| balances and to branch based on if a balance is lower than a certain
| value
In addition to what Greg suggested, for the very
Date:Wed, 5 Jun 2024 11:09:45 -0400
From:Greg Wooledge
Message-ID:
| > to convert floats back into integers again, controlling how
| > rounding happens).
|
| Ironically, that last one is the one we already *do* have.
Yes, I know about printf (and while POSIX
Date:Wed, 5 Jun 2024 08:40:51 -0400
From:Zachary Santer
Message-ID:
| The magnification factor is handled as a
| fractional number - 1.5, 1.75, etc. So, to change the magnification
| factor by increments of 0.25 or 0.5, I had to print an expression into
| b
Date:Thu, 23 May 2024 09:04:48 -0400
From:Chet Ramey
Message-ID:
| The bash output clearly tells you the
| order of operations, which is the whole purpose of -x.
But it can be horribly misleading. Consider what bash does with
this similar case (I used 5.3a1 b
1 - 100 of 549 matches
Mail list logo
