On Tue, 15 Jul 2025, 03:46 Robert Elz, wrote:
> | > This happens because /sys/block/*/uevent show up as regular files,
> and
> | > reports a file size of 4096 in stat:
> | Which isn't the true file size.
>
> And I'd be reporting that as a kernel bug.
But linux seems to be filled with crap
Missed a comma…
On Mon, 14 Jul 2025, 03:43 Martin D Kealey, wrote
> an expression would be parsed and then when executed [COMMA] the
> expression itself - rather than the value resulting from evaluating it -
> could be assigned to a variable.
>
>
> Since when is removal of recursive evaluation being mooted?
>
Not by me, but if we're going down the path of parsing numeric expressions
at the same time as the surrounding shell commands, it would be useful to
have some sort of lambda assignment, so an expression would be parsed and
then when
On Thu, 10 Jul 2025 at 01:36, Chet Ramey wrote:
> If the expression hadn't contained $x, nothing would have been expanded,
> because expanding a word without any expansion characters is a waste of
> time. This arguably causes a problem in this case; it would have been
> more consistent to run the
On Mon, 7 Jul 2025 at 13:03, Collin Funk wrote:
> Martin D Kealey writes:
> > it's SLOW.
Any comments on this point?
It seems like the main causes of inadequate speed are:
(1) Lack of parallelism.
(2) A monolithic probe-test-result cache structure, that's either "all
To help me find bugs in a range of projects, I have a wrapper around gcc
that forces -Werror -pedantic.
I expect to get a lot of errors during builds - that's the point - but what
I didn't expect was for autoconf to be broken.
The main problem is that autoconf fails to recognize a range of standar
diff --git a/bashline.c b/bashline.c
index fb8aeea20..181585c5b 100644
--- a/bashline.c
+++ b/bashline.c
@@ -4142,7 +4142,7 @@ vi_advance_point (void)
}
}
#else
-rl_point++:
+rl_point++;
#endif
return point;
}
On Tue, 1 Jul 2025, 08:59 Zachary Santer, wrote:
> It appears bash has made the parser more complex by selectively
> removing the pre-expansion step for certain parts of expressions.
> That's bad because the rules for when that happens are undocumented
> [...]
>
By far the simplest approach for
On Thu, 26 Jun 2025 at 04:07, Oğuz wrote:
> On Wednesday, June 25, 2025, Richard Weinberger
> wrote:
> >
> > This can happen on filesystems where d_ino != st_ino
>
> i.e. a broken filesystem.
Or not broken.
There's a fairly obvious race condition where another process replaces a
direc
On Mon, 23 Jun 2025 at 19:02, Takaaki Konno wrote:
>
> x=abc
> case def in
> "${x#abc}"def) ;;
> "${x##abc}"def) ;;
> "${x%abc}"def) ;;
> "${x%%abc}"def) ;;
> "${x/abc/}"def) ;;
> "${x//abc/}"def) ;;
> "${x/#abc/}"def) ;;
> "
On Thu, 19 Jun 2025 at 07:37, Alvaro Falagan
wrote:
> Bash does not clean up all its internal memory and leaves at least one file
> descriptor (`/dev/pts/0`, fd 255) open at exit.
Why would it be a problem if memory is still allocated or filedescriptors
are still open at exit?
Memory pages and
In variables.c at line 6243 we have
eof_encountered_limit = (*temp && all_digits (temp)) ? atoi (temp) : 10;
Presumably in your build of Bash, as in mine, `int` is 32-bit, so the
maximum value convertible by atoi would be 2147483647.
Larger values are returned modulo 4294967296 (with 2's complemen
Hi Joel
On Sun, 8 Jun 2025 at 00:08, Joel Ebel via Bug reports for the GNU Bourne
Again SHell wrote:
> This is mostly an FYI, as I don't think our ridiculous environment needs to
> be supported, but the E2BIG test in exec3.sub never finishes in our testing
> environment due to ARG_MAX being set
On Thu, 5 Jun 2025 at 20:22, Duncan Roe wrote:
> On Wed, Jun 04, 2025 at 09:43:00AM -0400, Chet Ramey wrote:
> > Is it useful to combine multiple selected fields (-f) into one space-
> > separated field so `cut' can put the selected portions of each line into
> > a corresponding array element?
>
On Wed, 14 May 2025, 11:14 Александр Ушаков, wrote:
> For reference, I believe this qualifies for a CVE because:
> * It is a reproducible crash (DoS) in a security-sensitive component
> (command interpreter).
>
By this logic, there should be a CVE for gcc because when you give it « int
main (){
Hi Александр
On Thu, 24 Apr 2025 at 03:30, Александр Ушаков
wrote:
> #define current_delimiter(ds) \
> (ds.delimiter_depth && !(ds.delimiter_depth - 1 < 0) ?
> ds.delimiters[ds.delimiter_depth - 1] : 0)
This seems unnecessarily complex; why not simply
#define current_delimiter(ds) (ds.delim
function safe_source() {
> local saved_opts=$-
> local pipefail_on=0
>
> # Check if pipefail is set using 'shopt'
> if (set -o | grep -q 'pipefail *on'); then
>
'on' or 'off' is preceded by a tab character, plus arbitrary padding
spaces, so that won't work.
But it's a suboptimal a
It's important that sections of ~/.bashrc be ordered correctly to prevent
such issues. Just because someone tells you to add something to the *end*
of your .bashrc does not mean that's necessarily the best place to put it.
1) some boilerplate, including checking whether the shell is actually
inter
On Tue, 11 Mar 2025, 00:54 John Wiersba via Bug reports for the GNU Bourne
Again SHell, wrote:
> The alternative is to have people, like me, stumbling on this
> undocumented syntax and spending a considerable amount of time trying to
> explore what it is and why it is undocumented.
Hah! That's
On Mon, 24 Feb 2025 at 13:48, Phi Debian wrote:
> I also forgot to mention that C99 introduced this
>
>There may be no gaps
>in the numbers of arguments specified using '$'; for example, if
> argu‐
>ments 1 and 3 are specified, argument 2 must also be specified
> some‐
On Sat, 8 Feb 2025, 17:48 Robert Elz, wrote:
>
> | and if the correspondence with strtol() is to be taken at face value,
> | this would likewise imply that empty string is a valid representation
> for
> | zero, since strtol() reports that it has converted the entire string in
> | that cas
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
Hi Chet
We seem to have very similar opinions about strong backwards compatibility
in theory, and yet somehow we keep butting heads on how that pans out in
practice.
I'm concerned that the last ten years has seen a number of Linux
distributions *stop* including Bash by default, and it has ceased
Funny the bugs one finds when reading the source code to a program... I was
looking at the usage of INPUT_REDIRECT and TRANSLATE_REDIRECT in
execute_null_command() and thought “why compare against 8 values, when by
re-ordering enum r_instruction in command.h, a simple range check would
suffice?” Wh
On Tue, 4 Feb 2025 at 11:03, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> To address the above points, the following text (or similar language) is
> proposed for inclusion in the Bash Reference Manual:
>
> *[...] *
In interactive Bash sessions, any element of the `PATH` variabl
Bash is behaving correctly; this is not a bug in Bash. And this list is for
reporting bugs, not fixing user scripts, so rather than spoon-feed you an
explanation, I'm going to give you enough pointers to enable you to
discover it for yourself.
Start by reading what the manual says about reading co
On Tue, 7 Jan 2025, 21:24 Tobi Laskowski, wrote:
> the issue starts with misusing SHELLOPTS.
Some folk have taken issue with my suggestion that SHELLOPTS is broken by
design. Perhaps that was hyperbole, but it seems to me that if all possible
uses for a feature actually constitute misuses, then
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
On Sun, 22 Dec 2024, 03:49 Budi, wrote:
> How is Bash' code to store string of any characters should be containing
> pair of "" and '' at the same time explicitly, being exact verbatim so,
> ie. cannot be modified, escaped or etc, as expected from ordinary/naive
> human writing), into a variable
On Sat, 21 Dec 2024, 04:01 Zachary Santer, wrote:
> On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge wrote:
> > I don't think your definition of "explicit" matches mine.
>
> ${variable} and ${| command; } are explicit expansions in the sense
> that I had to write them in the script for the expansi
(see first part for background)
I've patched Bash to merge “shopt” and “set -o”, and now “make tests”
reports some minor differences. I would like some feedback on whether
they're significant enough to warrant fixing.
I've tried to mimic the current behaviour as closely as possible, including
kee
I'm trying to make sure that my modified version of Bash passes all the
tests, and in the process I'm finding some, erm, oddities.
Firstly, what seems to be a bug:
Looking in tests/printf7.sub it has
INT_MAX=$(getconf INT_MAX 2>/dev/null)
[ -z "$INT_MAX" ] && INT_MAX=2147483647 # assume 3
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
On Fri, 6 Dec 2024, 15:12 Frederick Abell, wrote:
> Description:
> `compete -f`/`complete -A file` do not work at all, whilst `complete
> -d`/`complete -A directory` work fine.
>
> $ cat
> a_dir/ b_dir/ c_file d_file
>
> # I was expecting to only see c_file and d_file.
Firstly this seems to
On Wed, 4 Dec 2024 at 14:48, Keith Thompson
wrote:
> On Tue, Dec 3, 2024 at 10:20 AM Chet Ramey wrote:
> > An easier workaround might have been removing `:' from COMP_WORDBREAKS.
>
> Sure, but that would affect all completions. I only want to change how
> completions
> work for my one custom com
On Thu, 28 Nov 2024 at 13:54, David Moberg wrote:
> Yes, if seems like the way to do this in bash. It's unfortunate because
> doing it with a binding is more elegant as it avoids polluting the terminal
> output and shell history.
>
You can avoid polluting history by inserting " fg\n" with a lead
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
On Tue, 26 Nov 2024 at 05:35, Andrew Davis wrote:
> When running 'help command' in the shell, the output contains:
>
> > -vprint a description of COMMAND similar to the `type' builtin
> > -Vprint a more verbose description of each COMMAND
>
> This seems to be opposite to the a
How about a counter-proposal: when not in POSIX mode, arguments that
correspond to numeric conversions in printf could be subject to normal
arithmetic evaluation, so that « printf %d '6*7' » will output “42”.
(Yes of course they should be subject to the single evaluation limit,
regardless of any s
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
On Mon, 25 Nov 2024 at 01:08, Andreas Kähäri wrote:
> I don't agree that the special parameters should be written as $! etc.
> since those are their _values_ when used in the shell (exactness is a
> virtue in a manual).
>
In a *printed* manual I would agree with you, but in a man page where the
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 small worldwide com
On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote:
> I think the manual is quite clear:
>
> Within [ and ], character classes can be specified
> using the syntax [:class:], where class is one of the
> following classes defined in the POSIX standard:
> alnum alpha
Hello Michael
The previously embedded lines (the for loop) now have got a timestamp (the
> one from the shell start?)!
> This is unwanted behavior, because now a cursor-up brings the separated
> lines.
>
More precisely, any history read from a history file will *not* be in
"command-oriented" mode
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
On Thu, 21 Nov 2024 at 02:33, Paul Eggert wrote:
there's little reason for Bash's non-POSIX mode to differ.
>
1. One person's "failure to fail" is another person's "useful undocumented
extension".
2. There exist deployed scripts that rely on the current behaviour.
Does anyone think these are n
On Wed, 20 Nov 2024, 07:36 Paul Eggert, wrote:
> However, I don't see why Bash should differ from POSIX behavior. Bash
> already diagnoses "printf %d x" and "printf %d ' '"; why should it be
> silent about "printf %d ''"?
>
>From a semantic perspective, because "" doesn't contain any non-digits.
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
On Sun, 17 Nov 2024 at 04:52, David Moberg wrote:
> That looks very complicated, how do interpret that? And where/when to run
> it?
>
To me this seems to have taken a wrong turn before the question was even
asked.
Just because readline has a "run a command" mode does NOT mean it's
necessarily th
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
On Thu, 14 Nov 2024 at 06:45, Chet Ramey wrote:
> On 11/12/24 8:17 PM, Grisha Levit wrote:
> > I'm not sure if this is the most idiomatic way to write the rule, but
> > if a libintl.h is generated, it needs to make it into the installed
> > headers directory to allow loadables to build.
>
AFAIK
On Thu, 7 Nov 2024, Chet Ramey wrote:
> y.tab.h isn't part of the devel branch, you need bison to build it, and
> it is included in the bash distributions. I see the problem here, though.
> I'll figure out a way to fix it that's compatible with it being included
> and not without too many releas
The disappearance of the variables that you export within your sourced file
is not a feature of the source command. That will happen to ANY command
that changes the shell's internal state, when run in a subshell.
The fact that pipeline components are implicitly run in subshells is
arguably not hig
On Fri, 8 Nov 2024 at 05:19, Chet Ramey wrote:
> The bind -x execution code could restore the terminal settings to icanon
> mode before executing the command, and then set them back to what readline
> is using (-icanon) before returning. This is not backwards compatible
> and would break all the
On Mon, 4 Nov 2024, 21:37 Robert Elz, wrote:
> | I guess I should s/POSIX/common Unix-like tradition/ and maybe
> | mumble something about BSD.
>
> you'd need to go to *every* OS that exists … Good luck with that.
Yeah I'm well aware this is futile whimsy.
I should have raised this point ab
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,
> | >
This is one of those cases I would file under "POSIX being annoyingly
literal".
POSIX says that the execve syscall reads the name of an interpreter (and
options) from a '#!' line, prefaces them onto the front of argv, and then
restarts itself. This is why some people argue that ENOENT is "logical"
On Sat, 26 Oct 2024, 00:05 Dmitry Goncharov,
wrote:
> >- cd $(@D) && $(MAKE) BUILD_DIR=$(UP)$(BUILD_DIR)
> >top_srcdir=$(UPSRC)$(top_srcdir) $(MAKEFLAGS) $(@F)
>
> It is really not a good idea to pass makeflags on the command line as a
> positional parameter.
Agreed, but I was just copy
On Fri, 25 Oct 2024 at 05:07, Grisha Levit wrote:
> These are reported by make --warn-undefined-variables.
>
> Most were being set previously (sometimes 20 years ago) and got left
> behind in recepies after their definitions have been removed. Others
> only get set in some configurations so it ma
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
>> &
It looks like a recent (last year) typo in sig.c breaks Minix compilation:
$ git log a61ffa78ed^!
> commit a61ffa78ede6df4d1127fddd2e8a1a77a7186ea1
> Author: Chet Ramey
> Date: 2023-01-03 10:23:11 -0500
> second set of ANSI C changes: C89-style function declarations, more
> inline functions
On Sun, 13 Oct 2024, 17:15 Oğuz, wrote:
> On Sun, Oct 13, 2024 at 3:18 AM Chet Ramey wrote:
> > You have two processes fighting over stdin.
>
> Why though? Can't bash just close the procsub's stdin when `:' returns?
>
Of course not. The operating system won't let processes meddle with each
othe
On Sat, 12 Oct 2024, 23:50 Saint Michael, wrote:
> From: Saint Michael
> Date: Sat, Oct 12, 2024 at 9:49 AM
> Subject: New feature
>
> The command printf needs a new flag, -e, that would mimic that way the
> same flag works with echo.
> …
> PROCEDURE_INFO=$(echo -e "${PROCEDURE_INFO}")
> this s
On Tue, 8 Oct 2024 at 06:26, Greg Wooledge wrote:
> From: *Thomas Oettli*
> > The result is two lines in the buffer (without "\n" in between). Do you
> understand now what I mean?
>
> If bash is returning nonzero status after reading a full line, then that
> may be a bug that should be fixed.
>
OK, running a similar test with instrumentation gets:
$ time (
trap ' echo BANG ' SIGALRM ;
while :; do printf TEST; sleep .00$((1+RANDOM%2)); echo; done |
for ((r=10 ;r>0; --r)) do line= ; read -t .002 line; rc=$?; [[ $line
= TEST ]] ; echo "STATUS $rc $? $line" ; done
) |&
sort | un
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
Does this happen with any raw-mode application, or just vim?
When using readline in Emacs mode, the terminal is necessarily in raw mode.
I suspect what you're seeing is that 'fg' bound to a key is bypasses the
normal "exit readline" that would restore the settings. Then when vim exits
or is suspe
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-
You seem to be implying that execstr contains a value that's under the
control of the input stream in a way that would allow malicious data on the
input stream to cause the shell to invoke arbitrary code.
I read the run_callback() function, and I don't see that as plausible,
unless you claiming th
As part of merging "shopt" and "set -o", I've had to update quite a lot of
files, including adding and removing #includes.
So I thought I should run "make depends" to fix up the Makefile.
Problem 1: the generated .depends file doesn't seem to be connected to the
Makefile.
Oh well, I'll just take
I have this wrapper in ~/sbin/gcc:
> #!/bin/sh
> exec /usr/bin/gcc -Werror -pedantic "$@"
so that I can fix every possible complaint about the code I'm writing.
Unfortunately, when I go “./configure --prefix=/some/where”, I get lots of
false negatives when probing for built-in functions, such a
On Sun, 1 Sept 2024 at 12:43, Lockywolf <
for_bug-bash_gnu.org_2024-09...@lockywolf.net> wrote:
> Dear Bash developers,
>
> May I ask for a small feature to be added to bash?
>
> At the moment exec changes IO redirections for the newly started
> processes, but if there is no command for exec'ing,
Hi Andrei
Ok, I see the problem.
This fault is triggered when the format string has '%(' but is missing the
closing ')' - so the entire remainder of the format string is tentatively
recorded as the time-format substring.
This line:
if (*++fmt != 'T')
should be changed to:
if (n > 0 || *
On Fri, 30 Aug 2024 at 04:17, Robert Elz wrote:
> SIGTTOU is also sent, unconditionally, by any attempt to change any of
> the terminal's attributes, and the process (group) (by default) stops.
> (I don't recall off hand whether simply fetching the attributes is
> enough to generate SIGTTOU.) J
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
>
On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso wrote:
> Chet Ramey wrote in
> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>:
> |On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
> |> ..and it seems that if bash starts a normal process then ICRNL is
> |> set, but if it starts a (process)& or only
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
support, its startup is ... underwhelmingly slothful.
So I decided to build it with profiling enabled, and see if I'd done
something to ruin its perform
sessions, and end up with the
> occasional unsaved session. Being able to filter the file directly lets
> us look things up without having to slice-and-splice into the internal
> history.
>
> On 2024-08-20 6:14 am, Martin D Kealey wrote:
> > "Missing/disappearing history"
"Missing/disappearing history" is entirely down to the lack of "writing
history as you go", and yes that would be reasonable to offer as a new
opt-in feature.
As for separation of sessions, I strongly suspect that anything between
*total* separation and *none* will result in so many ugly compromis
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
On Mon, 19 Aug 2024 at 06:45, shynur . wrote:
> I believe these output files should be added to `.gitignore` and generated
> during the `make` process.
Not doing so is deliberate in some cases.
In an ideal world, yes they should be generated during `make`, but that
would increase the "build to
The fundamental problem of using phrases like "the run time of the current
process" is that there's NO POSSIBLE adjectival qualifier that can be added
to such a phrase such that the combination correctly describes the actual
operation.
What's needed is a statement that the value of SECONDS is the
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 know any better, but
if you suspect t
HI Gioele
Typically problems with the prompt are because the \[ and \] are misplaced
or completely missing, but in this case the bug report indicates that they
have indeed been used correctly; so thankyou for checking that first.
The fact that characters are all printed in the same place (over ea
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*)
Hi Chet
According to ISO/IEC 9899-2017, §6.3.2.3(3):
*“An integer constant expression with the value 0, or such an expression
cast to type void * , is called a null pointer constant. If a null pointer
constant is converted to a pointer type, the resulting pointer, called a
null pointer, is guaran
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
On Tue, 23 Jul 2024, 15:50 Harald Dunkel, wrote:
> Hi folks,
>
> This feels weird:
>
Did you read the manual before trying any of these?
% echo x{1,2}x
> x1x x2x
> % echo x{1}x
> x{1}x
>
Why are you trying to use a multiplier syntax when you don't have more than
TL;DR: what you are asking for is unsafe, and should never be added to any
published version of any shell.
On Tue, 16 Jul 2024 at 17:47, David Hedlund wrote:
> Do you think that it would be appropriate to submit this feature request
> to the developers of the rm command instead.
>
This suggesti
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.
On Mon, 8 Jul 2024, 05:23 alex xmb sw ratchev, wrote:
> i dont get the BASH_SOURCE[n] one
> the point of prefix $PWD/ infront of relative paths is a static part of
> fitting into the first lines of the script , assigning vars
>
That's not the only use case.
Consider where you have a script that
On Thu, 4 Jul 2024, 03:21 Chet Ramey, wrote:
> Why not just wait for all process substitutions?
> Process substitutions [...] are not expected to survive their read/write
> file descriptors becoming invalid. You shouldn't need to `wait' for them;
> they're not true asynchronous processes.
>
A
On Sun, 30 Jun 2024 at 05:08, Zachary Santer wrote:
> On the other hand, I'm pretty sure
> command-1 | tee >( command-2 ) >( command-3 ) >( command-4 )
> will terminate as soon as command-1 and tee have terminated, but the
> command substitutions could still be running. If you want to run
> comma
1 - 100 of 254 matches
Mail list logo
