iately close
Is there maybe something broken in your setup?
Best regards,
Martin
padding
spaces, so that won't work.
But it's a suboptimal approach to begin with.
To check a shell option such as pipefail, pick one of these:
[[ -o pipefail ]]
shopt -qo pipefail
[[ :$SHELLOPTS: = *:pipefail:* ]]
-Martin
s is useful, but some re-ordering may be required to
accommodate interdependencies.)
5) finish with:
trap - SIGINT SIGQUIT # normal handling for ctrl-C and ctrl-\
-Martin
PS: my own preferred approach is to set
HISTFILE=$HOME/.bash_history.d/$EPOCHSECONDS.$$ so that (a) bashrc can't
eras
h! That's how everyone worked back when Bash version 2 was "new", even
for stuff that was (and still is) supported.
Chet: if you don't intend to remove this extension, please make that
commitment in writing in the documentation.
-Martin
expect that rule to be necessary, in the sense that it doesn't
offer any flexibility to the implementation.
-Martin
PS: Hmmm, well I guess repetition could be implemented by simply shifting
off as many args as there are conversions, and that would be a simple way
to get consistent repetition whe
ect to use
"#!/bin/bash5" or "#!/bin/bash4". And changes that introduce new
prohibitions or warnings, or retire old features, should always get a new
major version number, so that scripts that start with '#!/bin/bash5'
doesn't mysteriously break on some point release of Bash 5.
-Martin
>
On Sat, 8 Feb 2025 at 13:04, Oğuz wrote:
> On Saturday, February 8, 2025, Martin D Kealey
> wrote:
>>
>> ls -mU /proc/$$/fd
>> ls -log /proc/$$/fd/99
>>
>
> They should appear in the output of `ls -l /proc/self/fd' in order for it
> to be consid
POSIX mode is more picky rather than less.)
Failing all that, if you're dead-set on having this, please (a) send the
warning to BASH_XTRACEFD, so that it can be suppressed without redirecting
stderr; and (b) insert into the manual an explicit description of at least
one expansion explaining th
xperimenting to see whether the kind of redirection would
influence whether to set forcefork in execute_null_command(), since that
*appeared* to be the case, and that's why I used the “>|” redirection
operator. However some of my tests used other redirection operators and it
didn't seem any less prone to failure.
-Martin
x27;s a bare ‘~’.
It should probably also be pointed out that the parameters upon which a
quoted tilde prefix depends may have changed after the assignment, and the
effective search path may change accordingly.
-Martin
PS: POSIX 2024 §2.6.1
<https://pubs.opengroup.org/onlinepubs/979991
s: type
> chmod a-x test.sh
and re-do your tests. Explain why one test does not change while the other
fails in a different way.
-Martin
l
$ echo !!:$
echo /dev/null
/dev/null
5.2 states (correctly from my point of view):
_ ... Subsequently, expands to the last argument to the previous simple command
executed in the foreground, after expansion. ...
$ echo hello > /dev/null
$ echo $_
hello
Best regards,
Martin
tures and
not mentioning them at all.
-Martin
-Martin
On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
> This is documented in the manual:
>
In other words, it's broken by design.
> Try BASH_ENV instead:
>
> https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fENV
>
Don't forget ENV as well, for sh scripts.
-Martin
»
(I tests this on commit 49c2670226b045746d66765b23af37c1c7ba5597)
(see first two parts for background)
On Sun, 15 Dec 2024 at 00:35, Martin D Kealey
wrote:
> I've patched Bash to merge “shopt” and “set -o”, and now ...
>
Just to be clear, my new "options" module handles:
(1
or one of ();<>&|
Let that sink in for a bit.
Quotes can be opened and closed multiple times within a single WORD.
Different parts of a single WORD can be unquoted, or quoted in one of 4
different ways.
All of this is just one assignment:
this_is_a_NAME='everything after the = is a valid WORD, and this part of
it is in single quotes 'this-part-is-unquoted" this part is in double
quotes"$' this part is in special quotes 'and\ the\ spaces\ in\ this\ part\
are\ escaped\ with\ \ backslashes', which counts as a form of quoting'.
-Martin
>
imitation of course is because - unlike most contemporary languages -
the shell fails to distinguish "unset" from "nonexistent".
(This lack also leads directly to some arcane behaviour around « local ».)
-Martin
d processing of -O
Lastly, the current order for “$-” seems to be “abefhikmptuvxBCEHIPTcs”,
which is *almost* all lower-case then all upper-case, but not quite. In my
version of Bash the options are simply enumerated in raw ASCII order
(upper-case first). Does maintaining the current order matter?
to submit patches to implement these if you could give me some
guidance on which of them you would accept (or not).
I have some other issues that are indirect consequences of the changes I've
made to Bash, but I'll write those up separately.
-Martin
I started writing a response early in this thread and then set it aside.
My initial impression was that excluding most compound commands from being
reported in PIPESTATUS was at best questionable, but now I'm thinking
otherwise.
It is obviously useful to be able to inspect PIPESTATUS after compoun
›‹tab›‹tab›‹tab›‹tab›‹tab›
> Someone from 2008 appears to have the same issue
Ah yes, the internet, an infinite source of misinformation and
misunderstanding. Now that you understand the issue, please add a new reply
to that page.
-Martin
>
s appear when I type , but I
> can live with that.
>
Yeah, I wrote a tab completion package for iproute2, and getting slashes
before the colons in IPv6 addresses makes them unreadable. It drove me nuts
initially.
And then I want to wrap that in the zcomp visual menu
<https://github.com/kurahaupo/zcomp>, which adds a whole 'nother layer of
pain.
-Martin
x27; # shift-F9
In this, “hide” is completely generic; you can give it whatever extra
prompt you want, separately from the command to be hidden. In a few cases
you might have to increase the "up" parameter, particularly when you're
testing by hand.
-Martin
PS: some folk will tell
On Tue, 26 Nov 2024 at 12:43, Lawrence Velázquez wrote:
> 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 N
On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote:
> On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey
> wrote:
> >
> > How about this for a concrete proposal: let's split the current man page
> > into a page per topic. The following list is alphabetical, though I
&g
ason why they differ only in that case?
Would anyone object to adjusting the output of ‘command -V’ to be identical
to ‘type -a’?
-Martin
ess of any shopt to the contrary.)
That would include evaluating an empty *expression* as zero.
-Martin
On Mon, 25 Nov 2024 at 00:21, Oğuz wrote:
> In another document, not the manual.
>
If my suggested addition does not belong in the manual, then neither does
*any* mention of "character class", nor indeed the entire existing
description of "regular expression". Please provide a patch that removes
it's time to yield to common sense and
compassion.
-Martin
PS: point of order: $! is not the *value* of the variable !, but rather the
two-symbol syntax that when *executed* results in its value being
substituted. When read by a human, it's context-dependent whether the human
is expect
I don't see anyting wrong with the patch, but...
+bug reports may be [...] posted to the Usenet newsgroup
> .BR gnu.bash.bug .
>
Ummm?
Does Chet still read Usenet?
Does anyone else?
-Martin
PS: Sometimes I miss the good old days when Usenet was the social glue that
held a smal
decimal digits; or
>- the symbols that are “equivalent” to ‘c’ according to the current
>locale
>(in addition to 'c' itself, this typically includes 'C', but may also
>include accented variants such as 'ç', 'Ç', 'č', & 'Č');
>or
>- the (upper-case) letters ‘F’, ‘G’, ‘H’, ‘I’, ‘J’, ‘K’, & ‘L’.
>
> -Martin
be honest, I run so
many shells in parallel that re-loading the history from previous shells is
rarely useful. Rather, I tend to simply grep for the relevant line(s) in my
actual history file. My own fix was to write a script that runs at log-out
and edits the history file to convert the embedded newlines into semicolons.
-Martin
at 06:23, Paul Eggert wrote:
> On 2024-11-20 23:25, Martin D Kealey wrote:
> > 2. There exist deployed scripts that rely on the current behaviour.
> Any such scripts won't work on other shell implementations that do conform
> to POSIX here.
>
Who said POSIX? My entire point ha
uld add «shopt -s
forbid_empty_zero» to enforce that consistently everywhere, rather than
having some places where it works and other places where it's forbidden,
with the division being a moving target.
-Martin
s of writing numbers as a reason to forbid
treating an empty token as a valid way to write zero. I find such appeals
quite unconvincing, for the simple reason that human languages languages
have no rules at all for handling empty tokens (because they're
indistinguishable from no token at all).
-Martin
On Sun, 17 Nov 2024, 03:32 Chet Ramey, wrote:
> On 11/16/24 3:36 AM, Martin D Kealey wrote:
> I don't think a disclaimer saying "this manual is not what it does not
> claim to be" is particularly useful.
>
That's valid, but how else do we get people to read the
On Wed, 13 Nov 2024 at 01:49, Chet Ramey wrote:
> On 11/10/24 7:14 PM, Martin D Kealey wrote:
>
> > Perhaps what's really needed is to make sure that "ordinary" commands
> bound
> > using bash -x are completely broken (so people won't try to
(Choose your own preferred key instead of ctrl-_ of course)
These all do the same thing in different input modes: erase the current
line, then type "fg" and enter it. (If you actually want to keep the text
that was in the edit buffer, you can just paste it back in at the next
prompt; ctrl-Y ("yank") in emacs mode, and p or P ("put") in vi mode.)
-Martin
On Sat, 16 Nov 2024 at 15:01, Robert Elz wrote:
> Date:Sat, 16 Nov 2024 14:05:17 +1000
> From: Martin D Kealey
> Message-ID: d1_ebrgbusb2u1sxhyloqq...@mail.gmail.com>
>
> | I know, but "explicitly" is not the same as "highlighted
On Fri, 15 Nov 2024 at 00:20, Chet Ramey wrote:
> On 11/13/24 11:40 PM, Martin D Kealey wrote:
>
> > The fact that pipeline components are implicitly run in subshells is
> > arguably not highlighted well enough [...]
>
> The man page states that explicitly.
>
I kn
w capability, it seemed
like a good idea to demonstrate it.)
-Martin
or isn't present.
It would also be nice to have "make distclean" and "make develclean" as
separate targets.
-Martin
gt;> /path/to/xtrace-logfile.txt
BASH_XTRACEFD=3
set -x
source your_file
set +x
exec 3>&-
or in recent versions of Bash:
exec {BASH_XTRACEFD}>> /path/to/xtrace-logfile.txt
set -x
source your_file
set +x
exec {BASH_XTRACEFD}>&-
(This lets Bash choose an available filedescriptor, rather than hard-coding
"3")
-Martin
;ordinary" commands bound
using bash -x are completely broken (so people won't try to use them),
rather than almost working.
-Martin
have raised this point about 40 years ago.
-Martin
essage-ID: <
> cah7i3lrjfhfgcejhmrmwd7mu2hu4r_oumvszw3esrc+3xqg...@mail.gmail.com>
>
> | 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,
> | >
ge to have execve flag when it restarts itself, and when
it later can't find the executable, it can return -ENOEXEC instead of
-ENOENT.
-Martin
On Sun, 3 Nov 2024 at 05:13, Chet Ramey wrote:
> On 11/2/24 8:43 AM, hmms...@kpnplanet.nl wrote:
>
> > Bash Version: 5.2
> > Patch
ter.
Agreed, but I was just copying what's already there. So let's add that to
the list of things to fix.
-Martin
r
- ‘UP=../’ and ‘UPSRC=’ (empty) when running ‘/path/to/configure’; or
- ‘UP=’ and ‘UPSRC=’ (both empty) when doing something weird with
BUILD_DIR
so that
- cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR)
top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F)
will correctly set BUILD_DIR and TOPDIR
-Martin
On Sat, 19 Oct 2024, 15:05 Oğuz, wrote:
>
> #ifdef FOO
> if (foo && zot)
> #else
> if (bar && zot)
> #endif
> {
>
That's fine for the editors, but it's still a problem for "indent", as it
produces nested indentation:
#ifdef FOO
if (foo && zot)
#else
if (bar && zot)
#endif
{ …
On Fri, 18 Oct 2024, 13:09 Oğuz, wrote:
> On Friday, October 18, 2024, Martin D Kealey
> wrote:
>>
>> Talking of which, I note several places where there's a construct like:
>>
>> #ifdef FOO
>> > if (foo && zot)
>> > #else
>> &
gt; # define FOO_CONDITION() 1
> #endif
>
> if (FOO_CONDITION() && zot)
Would you accept patches that introduced either of these?
-Martin
one is a shell (like Bash) and
the other is a program it's launched.
On some operating systems there are extremely contrived ways to achieve
this, but then you face a far more fundamental problem: you can't tell
whether or not stdin has been replaced by the program itself, whereupon you
would wind up closing something that should be left alone.
-Martin
ot;${PROCEDURE_INFO}")
> this step would be redundant if printf had the flag.
>
Do you mean like this:
printf -v PROCEDURE_INFO %b "$other_var"
Though one has to wonder, why is it written as \n to begin with?
-Martin
After using printf, right now I need to lunch a second command…
Mmm, hungry, time for lunch.
y be a bug that should be fixed.
> Martin may be looking into that.
>
Indeed I am.
At this point I'm reminded of Zork's Introduction: "*You are in a maze of
twisty little passages, all alike. You are likely to be eaten by a Gru.*"
Trying to track longjmp() through four tra
== 1 && input_string[0] == CTLNUL)
saw_escape = 0; /* Avoid dequoting bare CTLNUL */
input_string[i] = '\0';
* check_read_timeout ();*
#if defined (READLINE)
if (edit)
free (rlbuf);
#endif
-Martin
PS: I've since run other tests that confirm the association I noted
The read builtin could return an exit status of (128|SIGALRM) in two
circumstances:
1. If a signal is caught during the read syscall, then either the read
system call returns -1 with EINTR and the error is reported. (Otherwise it
must return a positive byte count, causing the built-in continues un
Then when vim exits
or is suspended, Bash notices that it's still in raw mode (-icanon), but
doesn't otherwise know the details of exactly how you want it cooked
(+icanon but what else?).
I'll check on this when I get back to my PC.
-Martin
On Sat, 21 Sep 2024, 09:23 David Mobe
In 2024 an editor having such a simplistic approach counts as a bug.
But perhaps adding a variable would allow anyone to nominate their own
favourite, such as as BASHFC_TMPNAM=/tmp/bash-fc.$$.XX.sh
Alternatively, perhaps an extra line could be inserted at the start of the
b file, like « #!fc-
at warrants a CVE be issued against the script, not
against Bash.
-Martin
On Sat, 14 Sep 2024, 21:46 ~ via Bug reports for the GNU Bourne Again
SHell, wrote:
> Dear bug-bash team:
> I hope this email finds you well. During my recent security
> assessment of bash, I identified a poten
-03-17 21:46:59 +0000
>
(and that was just to fix a typo from when it was created in 1997)
-Martin
PS: It seems like that Makefile line should use “sh” rather than
“$(Program)”, otherwise it would be impossible to go “make depend” before
the initial build.
PPS: "mkdep" seems like a d
over an *actual* bug:
diff --git a/include/shmbutil.h b/include/shmbutil.h
index a8a59bf1a..1feee8535 100644
--- a/include/shmbutil.h
+++ b/include/shmbutil.h
@@ -86,7 +86,7 @@ extern int locale_utf8locale; /* XXX */
#define UTF8_SINGLEBYTE(c) (1)
#define UTF8_MBFIRSTCHAR(c)(0)
-#define*d* VALID_SINGLEBYTE_CHAR(c) (1)
+#define VALID_SINGLEBYTE_CHAR(c) (1)
#endif /* !HANDLE_MULTIBYTE */
-Martin
command
pathname or (to safely support setuid scripts on some non-Linux systems) a
magic path to a pre-opened filedescriptor.
That said, there's virtually no downside to this, and it *might* be useful
in some corner cases, as long as the script can tolerate the "do nothing"
fallback on systems where this is less feasible to implement.
-Martin
uggested patch amounts to (a slow version of):
if (*fmt != 0 && *++fmt != 'T')
which avoids the overrun but fails to report the error to the user.
-Martin
On Fri, 30 Aug 2024 at 22:28, Андрей Ковалёв
wrote:
> Hi there!
>
> I completely understand your point of vi
p is
> repeated.
> When it is resumed in foreground, it can do whatever is needed, and then
> (perhaps) be moved back to background later.
>
That's definitely where I was trying to go with my initial response, but
you've explained it better.
-Martin
Hi Chet
On Wed, 28 Aug 2024 at 23:58, Chet Ramey wrote:
> On 8/24/24 1:46 PM, Martin D Kealey wrote:
> > I've been making some tentative patches to the `devel` branch, and since
> I
> > have a fairly large bashrc, when I compile Bash with maximal debugging
>
try writing a welcome banner (or even just a single NL char) before
attempting tcgetattr(). (Maybe a zero-sized read or write might suffice?)
-Martin
investigate
different kinds of allocators, or perhaps a different approach to handling
signals?
-Martin
ack nested shells). With those I would be happy to have
~/.bash_history.d/$TTY, which would greatly reduce the number of files.
Would that be few enough files to satisfy you?
-Martin
On Wed, 21 Aug 2024, 00:38 , wrote:
> Bash or no bash, spreading history over dozens of files in
> `bash_histo
bashrc that are shipped with Bash by the
various distros. Maybe Bash should start shipping some kind of "standard
library" of functions that are *expected* to be included with any distro,
but are not actually built into the binary.
-Martin
PS: complaining about "inelegant" in rel
sorry, I meant HISTTIMEFORMAT rather than HISTTIMEFMT
On Tue, 20 Aug 2024 at 14:58, Martin D Kealey
wrote:
> The following suggestions, or close approximations, can all be implemented
> using the existing facilities.
>
> On Tue, 20 Aug 2024 at 05:52, wrote:
>
>> I w
The following suggestions, or close approximations, can all be implemented
using the existing facilities.
On Tue, 20 Aug 2024 at 05:52, wrote:
> I would suggest:
>
> 1. Append to history file immediately on each command.
>
Easily done by putting `history -a` into `PROMPT_COMMAND`
2. Restrict u
rce code directory, so it's easier to `git diff`
just one or the other. (In practice, that would mean moving some of the
code into a new subdirectory.)
-Martin
ue of SECONDS is the current
system time, minus the system clock when the process started or a value was
last assigned, plus whatever value was assigned (if any), with each of
reading of the system clock taken at whole second resolution.
-Martin
On Thu, 15 Aug 2024, 17:54 Bash-help via Bug report
ted to match any new available levels.
What was the original purpose of this? Was it just to double-check that
there weren't bugs in the rest of the shell_compatibility_level logic?
If so, would it be acceptable to omit this check from my new version?
-Martin
PS: This patch is dependent on a
Sorry, that was supposed to be a personal reply off-list.
On Sat, 10 Aug 2024 at 12:01, Martin D Kealey
wrote:
> On Thu, 8 Aug 2024 at 03:14, alex xmb sw ratchev
> wrote:
>
>> mr chet
>>
>
> I REALLY get annoyed when strangers call me "Mister Martin" or
On Thu, 8 Aug 2024 at 03:14, alex xmb sw ratchev wrote:
> mr chet
>
I REALLY get annoyed when strangers call me "Mister Martin" or write "Mr
Martin". I am NOT a child, so how DARE they mock me like that.
The short version: Some folk don't care, others don't
Enable Reverse Wraparound" settings are
enabled. If using some other terminal emulator, consult its documentation
for the corresponding settings.
-Martin
On Fri, 9 Aug 2024 at 05:40, Gioele Barabucci wrote:
> Hi,
>
> bash 5.2.21 produces severely wrong artifacts under the followin
might change in the future.
-Martin
On Tue, 6 Aug 2024, 01:17 Chet Ramey, wrote:
> On 8/1/24 4:12 AM, Martin D Kealey wrote:
>
>
> > It follows that the following assertions are allowed to fail:
> >
> >intptr_t i = 0;
> >assert(*(void*)i == (void*)0*)
iltin_var);
else
hash_flush (vcxt->table, push_exported_var);
-Martin
On Wed, 24 Jul 2024, Greg Wooledge wrote:
> Remember how -e is defined:
>
> -e [...] The shell does not exit if the command that fails is [...] any
> command in a pipeline but the last
diff --git a/doc/bash.1 b/doc/bash.1
index cd355a3..266fe35 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -10327,7
;.
Not when it's missing the second pair of braces; perhaps you intended to
use `echo x{{1..3},5}x`?
-Martin
uld wreak havoc,
including deleting or overwriting the wrong files or running the wrong
programs, and with no guarantee that there will be any warning indications.
All that said, if you want to risk breaking your own system, feel free to
add the relevant commands to `*PROMPT_COMMAND*` as suggested
On Mon, 8 Jul 2024 at 14:42, Oğuz wrote:
> On Monday, July 8, 2024, Martin D Kealey wrote:
>>
>> It's not possible to change "${BASH_SOURCE[@]}" without breaking some
>> existing code,
>>
>
> It's worth breaking existing code in this case.
or a script
author to do the right thing than to do the wrong thing. And all the better
if it could quietly fix the myriad scripts out there that assume [[ ${0%/*}
-ef . ]].
-Martin
have intentionally backgrounded processes as well as
user interaction.
-Martin
atic lines plus 4 lines for each substitution; hardly ideal
but it does work without needing any more features added to Bash.
(Realistically, proper error handling would be longer than this anyway, so
it's probably not *that* verbose.
-Martin
On Fri, 28 Jun 2024, 18:31 Oğuz, wrote:
> On Friday, June 28, 2024, Martin D Kealey wrote:
>
>> modern Perl scripts
>>
>
> No such thing.
>
For the purpose of this argument, "modern" means anything written in the
last 25 years, targeting Perl 5 rather
On Thu, 27 Jun 2024, 17:08 Oğuz, wrote:
> On Thursday, June 27, 2024, Martin D Kealey
> wrote:
>
>> [...]
>
>
> That's too much to read
>
You're under no obligation to read what I write, but then kindly don't
pretend that you're "replying&qu
mes more important if we look to eventually
implementing lexically scoped variables some time in the future.)
If you really can't stomach using {} around subscripts, there are other
ways to distinguish them, such as [numeric+expression+without+quotes] vs
["map key in quotes"], but t
ollution is
removed.
I would be happy to always have $(realpath $0) or $(realpath
$sourced_filename) in BASH_SOURCE if there was also a concomitant change to
preface '0' onto ARGC (and not change BASH_ARGV) when a file is sourced (or
a function is called) without any args. However I wo
ment that users must use
${BASH_SOURCE[@]:(-1):1} rather than $0 when asking my "Carp" module to
exclude its own "main" from backtraces.
But if someone else has already implemented this, then their code will be
subtly broken by this proposed change to Bash.
-Martin
>
ifferences?
• How would this interact with pipefail or lastpipe?
-Martin
-- Forwarded message -
From: ama bamo
Date: Tue, 25 Jun 2024, 02:21
Subject: Proposal for a New Bash Option: failfast for Immediate Pipeline
Failure
To:
Dear Bash Maintainers,
I have encountered a challeng
rmalised $0.
Otherwise ~.NUMBER expands to a partially normalised form of
${BASH_SOURCE[NUMBER]}. (This might be omitted from the initial
implementation; we probably need more experience to see if it's actually
useful.)
-Martin
On Thu, 20 Jun 2024, 10:12 konsolebox, wrote:
> On Thu, Jun
ic format?
However any formatting done as part of the expansion assumes that the
variable holds a "number" in some fixed format, rather than a localized
string.
Personally I think this would actually be a good idea, but it would be
quite a lot bigger project than simply added FP support.
-Martin
(Some time around 2014 I switched to
using the "named" timezones with simply TZ=NZ or TZ=Pacific/Auckland, but
I've occasionally used the old style when I needed to test behaviour in
"odd" time zones.)
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.
-Martin
e vague precisely *because* this is a
known issue.
-Martin
e builtin
printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
For 30+ years it has been my experience that the '.0' for Sunday is not
required, either in practice or (I *think*) by the POSIX specification.
-Martin
after-fork attribute on a
coproc fd if that's desired, but otherwise avoid deadlocks in the simple
cases.
-Martin
On Tue, 2 Apr 2024 at 00:31, Chet Ramey wrote:
> On 3/31/24 8:34 PM, Martin D Kealey wrote:
> > That's a good start, but it seems incomplete, and there's little --
> perhaps
> > no -- overlap with bug reports in this list.
>
And this is still the most fundamental
1 - 100 of 376 matches
Mail list logo
