How about:
Don't sort the list, or consider "lazy sorting" only the portion of the
list that's going to be displayed. (I'd suggest using an incremental
Quicksort, which can yield a sorted sublist in almost linear time. (I
started working on this for my zcomp module until I realised it was already
Hi Oğuz
On Sun, 21 Jan 2024 at 03:20, Oğuz wrote:
> $ echo echo foo bar >s
> $ chmod +x s
>
You seem to have created an invalid executable. It seems that scripts
without a #! can only be run with help from the debugger library; for
example, this is what I get when I run up bash_5.1.3p47
Chet has since pointed out that the debugger is not involved at all.
On Mon, 22 Jan 2024, 18:17 Grisha Levit, wrote:
>
> That's not quite what happens. These scripts get executed by forking the
> current bash process (without exec). The new shell resets its state and
> runs the script.
>
I'm br
On Wed, 31 Jan 2024 at 01:04, Andreas Schwab wrote:
> On Jan 30 2024, Zachary Santer wrote:
> > There's no way this is the intended behavior, right?
>
> The command is doing exactly what it is documented to do, that is do all
> of the shell word expansions.
>
If that's how the documentation is i
On Sun, 4 Feb 2024, 02:01 Koichi Murase, wrote:
> I now think I should leave a comment because even Martin (who I believed
> was one of the careful people about backward compatibility as seen in
> [1,2]) seems to suggest a breaking change.
>
That's a fair point.
I am generally concerned about b
On Sun, 4 Feb 2024 at 15:17, Koichi Murase wrote:
> 2024年2月4日(日) 12:59 Martin D Kealey :
> > I am generally concerned about breaking changes that affect existing
> scripts, but I see changes to readline as less problematic,
>
> I also assume shell scripts, but shell scrip
On Sat, 3 Feb 2024 at 07:21, Chet Ramey wrote:
> On 2/2/24 3:36 PM, Zachary Santer wrote:
> > Ultimately, what I'm saying is that a different bindable function that
> performs all the shell expansions other than quote removal would be more
> useful than shell-expand-line.
>
> OK, I'll take that
On Sat, 17 Feb 2024 at 02:32, Chet Ramey wrote:
> Let's say we take the approach of restricting attribute changes on readonly
> variables to export/trace/local.
>
> Should it be an error to attempt to set other attributes (it already is
> with nameref), or should declare silently ignore it?
>
I
It's been a long time since I looked into Unicode, but this is what I
remember.
Depending on the Unicode normalisation level, backspace is *supposed* to
remove a letter and all its associated combining marks.
The root problem seems to be that some Arabic letters change from
"non-combining" to "co
On Wed, 21 Feb 2024 at 02:37, Grisha Levit wrote:
> sigaction(2) says:
>
> The affected system calls include open(2), read(2), write(2),
> sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications
> channel or a slow device (such as a terminal, but not a regular file)
>
>
On Wed, 21 Feb 2024 at 08:09, Chet Ramey wrote:
> On 2/20/24 4:11 AM, Martin D Kealey wrote:
> > Ideally each function invocation would have its own variable namespace,
> > only using the global namespace as a fall-back, but that creates
> > complications with exported var
n Fri, 23 Feb 2024, Chet Ramey wrote:
> On 2/19/24 9:26 PM, Avid Seeker wrote:
> > When pressing backspace on Arabic ligatures (including characters with
> > diacritics), they are removed as if they are one character.
>
> As you might guess, readline doesn't know much about Arabic, per se. In a
> U
I've been thinking for a while now that POSIX made a mistake when it
permitted ';;' before the closing 'esac'. If ';;' were prohibited there,
then the parser could be sure that the next word after every ';;' would be a
pattern, even if it looks like 'esac'. But as things stand, there's an
ambigui
On Tue, 27 Feb 2024 at 18:48, Oğuz wrote:
> On Tuesday, February 27, 2024, Martin D Kealey
> wrote:
>
>> I've been thinking for a while now that POSIX made a mistake when it
>> permitted ';;' before the closing 'esac'.
>>
>
> I think th
Personally I don't have any problem with 800 kB == 8 GB or 104857600
KiB == 100 GiB, but it's not as if having nice round power-of-two numbers
really matters in *this* case, where 107500 KiB is close enough to 1
TiB. But I guess not everyone is as comfortable with mental arithmetic.
On Thu
In section one, the problem is that "wait -n" does not do what you think it
does. (Lots of us think this behaviour is broken, and it may be fixed in an
upcoming version of Bash.) You don't need '-n' when you specify a PID; the
fix is simply to remove it.
In section two, the problem is that quote r
> On Mon, Mar 11, 2024 at 8:20 PM Chet Ramey wrote:
> > On 3/11/24 2:50 PM, Mischa Baars wrote:
> > > Which sort of brings us back to the original question I suppose. Who
> does
> > > that line of code function from a script and why does it fail from the
> > > command line?
> >
> > Job control and
Hi Dan
How about « fc -ln » ?
It might be helpful to have explicit cross-references between the help
displays for «history» and «fc».
-Martin
On Sun, 24 Mar 2024 at 15:40, Dan Jacobson wrote:
> $ help history
> should mention how in the world one is supposed to just print the plain
> history,
On Tue, 26 Mar 2024 at 04:05, Oğuz wrote:
> On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson
> wrote:
> > [1]
> > [1] http...
>
> I keep seeing this. Why don't you guys just paste the link?
>
When forwarding incoming HTML to a text-only list, most mailing list
servers will put the hyperlinks
On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote:
> On 11/30/23 5:18 AM, Martin D Kealey wrote:
>
> > If there's a bug tracking system beyond "threads in a mailing list", I'd
> > like to know how I can get access to it.
>
> https://savannah.gnu.org/suppo
On Thu, 25 Jan 2024, 20:04 Alan Urmancheev, wrote:
> Currently, Bash's manual definitions section mentions POSIX, but doesn't
> explain what that abbreviature stands for
...
> I think that abbreviatures can be confusing, especially when you don't get
> to know what they stand for.
>
I suspect
I'm somewhat uneasy about having coprocs inaccessible to each other.
I can foresee reasonable cases where I'd want a coproc to utilize one or
more other coprocs.
In particular, I can see cases where a coproc is written to by one process,
and read from by another.
Can we at least have the auto-clo
On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
> the method by which vim amends files is similar to that of sed -i.
>
I was about to write "nonsense, vim **never** does that for me", but then I
remembered that using ":w!" instead of ":w" (or ":wq!" instead of ":wq")
will write the file as norm
llar wrote:
> On Tue, 9 Apr 2024 10:42:58 +1200
> Martin D Kealey wrote:
>
> > On Mon, 8 Apr 2024 at 01:49, Kerin Millar wrote:
> >
> > > the method by which vim amends files is similar to that of sed -i.
> > >
> >
> > I was about to write
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAG
I can confirm that this changed between 4.4.23(49)-release and
5.0.0(1)-beta, which coincides with the parser being largely rewritten.
On Thu, 11 Apr 2024 at 12:51, wrote:
> The POSIX shell grammar specifies that a newline may optionally appear
> before the in keyword of a for loop.
I don't se
On Thu, 1 Feb 2024 at 07:54, G. Branden Robinson <
g.branden.robin...@gmail.com> wrote:
> v2: Prevent confclit with PATCH v2 01/18.
> Apply ellipsis advice from groff_man_style(7).
> • The dummy character escape sequence \& follows the ellipsis when further
> text will follow after space on the ou
On Wed, 17 Apr 2024, Chet Ramey wrote:
> On 4/16/24 2:46 AM, Carl Edquist wrote:
>
> > But the shell is pretty slow when you ask it to shovel data around like
> > this. The 'read' builtin, for instance, cautiously does read(2) calls of a
> > single byte at a time.
>
> It has to do it that way to
On Sat, 20 Apr 2024 at 01:14, Chet Ramey wrote:
> On 4/17/24 8:55 PM, Martin D Kealey wrote:
> > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) to
> > add a new system call such as readln() or readd()?
>
> They'd probably point you to an opt
On Sun, 21 Apr 2024, 10:13 Carl Edquist, wrote:
> On Thu, 18 Apr 2024, Martin D Kealey wrote:
> > Has anyone tried asking any of the kernel teams (Linux, BSD, or other)
> > to add a new system call such as readln() or readd()?
>
> You mean, specifically in order to impl
On Mon, 22 Apr 2024, 09:17 Carl Edquist, wrote:
> When I say "token" I just mean a record with whatever delimiter you're
> referring to using.
Ok that makes sense.
Assuming the reading stops after consuming the first delimiter (which is
> necessary for the 'read' builtin), then you end up wit
On Mon, 22 Apr 2024, 18:13 felix, wrote:
> Hi,
>
> Coming on this very old thread:
>
> [the] man page say[s]:
>
> PIPESTATUS
> An array variable (see Arrays below) containing a list of exit
> status values from the processes in the most-recently-executed
> foreg
On Sun, 28 Apr 2024, 05:03 Carl Edquist, wrote:
>
> > I would hope that mapfile/readarray could do better, since it's not
> > obligated to leave anything in the input stream.
>
> That is an interesting thought, although mapfile seems to read a byte at a
> time also.
>
> [I'm not suggesting this s
On Sun, 5 May 2024 at 11:50, Koichi Murase wrote:
> > Ideally, they'll be using bash's native import under the hood!
>
> Yes, module managers still need to implement their own "import"
> command while using the proposed "import" primitive under the hood,
> and it's simply interchangeable with the
I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would
like to suggest three tweaks to its semantics.
A common pattern is to unpack a script with its associated library & config
files into a new directory, which then leaves a problem locating the
library files whose paths are o
On Tue, 14 May 2024 at 20:10, konsolebox wrote:
> On Tue, May 14, 2024 at 2:09 PM Martin D Kealey
> wrote:
> > 2. Search BASH_SOURCE_PATH when any relative path is given, not just a
> path
> > that lacks a '/', so that libraries can be organized into subdirect
On Thu, 16 May 2024 at 02:48, Koichi Murase wrote:
> 2024年5月14日(火) 15:09 Martin D Kealey :
> > 1. I therefore propose that where a relative path appears in
> > BASH_SOURCE_PATH, it should be taken as relative to the directory
> > containing $0 (after resolving symlinks), ra
On Thu, 16 May 2024 at 03:03, Chet Ramey wrote:
> On 5/14/24 2:08 AM, Martin D Kealey wrote:
> > I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I
> would
> > like to suggest three tweaks to its semantics.
> >
> > A common pattern is to unpac
On Fri, 17 May 2024 at 04:18, Chet Ramey wrote:
> On 5/16/24 11:54 AM, G. Branden Robinson wrote:
> > At 2024-05-16T11:36:50-0400, Chet Ramey wrote:
> >> On 5/15/24 6:27 PM, Robert Elz wrote:
> >>> and any attempt to use a relative path (and you
> >>> can exclude ./anything or ../anything from th
On Tue, 21 May 2024 at 03:44, Chet Ramey wrote:
> On 5/17/24 1:15 PM, Robert Elz wrote:
>
> >| If `nosort' means no sorting, there is no imposed ordering, and
> ascending
> >| and descending are meaningless.
> >
> > Sure, but directory order, and reverse directory order aren't (and that's
On Tue, 21 May 2024 at 23:16, Koichi Murase wrote:
> 2024年5月21日(火) 14:56 Phi Debian :
> > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't
> > know if that would be good enough for the initial purpose.
>
> There are already shell-function implementations at
> /examples/fun
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
On Wed, 10 Apr 2024 at 03:58, Carl Edquist wrote:
> Note the coproc shell only does this with pipes; it leaves other user
> managed fds like files or directories alone.
>
> I have no idea why that's the case, and i wonder whether it's intentional
> or an oversight.
>
Simply closing all pipes is
On Tue, 11 Jun 2024 at 21:52, Grisha Levit wrote:
> POSIX says about the TZ variable:
>
> If the dst field is specified and the rule field is not, it is
> implementation-defined when the changes to and from DST occur.
>
> musl seems to interpret `TZ=EST5EDT` as having DST always in effect
On Fri, 14 Jun 2024 at 06:13, Dan Jacobson wrote:
> ./k
> make: ./k: No such file or directory
>
This is a problem with the POSIX spec for the execve system call and its
obligatory return codes.
"No such file or directory" is arguably the correct message to show when
the kernel returns the ENOE
On Fri, 14 Jun 2024 at 10:52, Robert Elz wrote:
> | 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 values after the M:
"User error" is not th
On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote:
>
> Let's say, if var is in the form of a C floating-point literal,
> ${var@F} would expand it to the locale-dependent formatted number, for
> use as an argument to printf or for output directly. And then ${var@f}
> would go the other way, takin
I support BASH_SOURCE_PATH as replacing the normal PATH search only for "."
and "source".
In addition I propose some new '~' expansions which will give concise
expression of dirname+realpath without penalizing code that does not need
it.
The primary intention is to allow the "standard preamble" t
Conceptually this sounds useful, but how exactly would it work?
• Is any attempt made to terminate the other processes in the pipeline, or
to you just not delay by waiting for them immediately?
→ If attempting to terminate:
- using which signal?
- what happens if the process refuses to d
On Wed, 26 Jun 2024, 03:14 Chet Ramey, wrote:
> On 6/19/24 6:12 PM, konsolebox wrote:
>
> > Alternatively, have BASH_SOURCE always produce real physical paths
> > either by default or through a shopt.
>
> This is the best option. I don't think changing bash to do this by default
> would have nega
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
On Thu, 27 Jun 2024 at 06:30, Chet Ramey wrote:
> On 6/26/24 2:18 PM, Zachary Santer wrote:
>
> >> On Tue, Jun 11, 2024, 12:49 PM Zachary Santer
> wrote:
> >>>
> >>> $ array=( zero one two three four five six )
> >>> $ printf '%s\n' "${array[@]( 1 5 )}"
> >>> one
> >>> five
> >
> > This is diffe
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
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 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
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 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 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.
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 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
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
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
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 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
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
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
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
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 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
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
"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
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"
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
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
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 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 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 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,
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
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
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
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
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
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
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 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.
>
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
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"
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,
> | >
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, 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, 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
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-
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
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
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
101 - 200 of 254 matches
Mail list logo
