On Fri, Apr 26, 2024 at 4:57 AM Dan Shelton wrote:
> Could you do this for the next alpha release, please?
Run `find -name Makefile -exec sed -i 's/\$[({]MFLAGS[)}]//g' {} +'
and it'll work. What's the hurry?
On Fri, Apr 26, 2024 at 1:17 AM Grisha Levit wrote:
> Actually, I see this on Ubuntu 22.04 but not on macOS.
On Linux, O_EXCL and RX_EXPANDED (a flag used by bash to signal that
the redirection word is already expanded) has the same value. I don't
know why bash doesn't clear its internal flags
On Mon, Apr 22, 2024 at 10:24 AM Kerin Millar wrote:
> I cannot find anything in the manual that concretely explains why bash
> behaves as it does in this instance.
Me neither, but the current behavior is useful. Take `while false |
false; do :; done' for example, if bash reported the status of
flag from it?
--
Oğuz
bash.
>
Bash's behavior matches that of dash in POSIX mode. This is documented here
in the 8th item https://tiswww.case.edu/php/chet/bash/POSIX
--
Oğuz
On Tue, Apr 9, 2024 at 5:17 AM Robert Elz wrote:
> Sure, it is possible to make a useless program like this ...
> Almost all real commands use stdio to read stdin. Playing about
> any more with this absurd example isn't worth the bother. The relevant
> text should simply be deleted from
On Mon, Apr 8, 2024 at 5:32 PM Robert Elz wrote:
> The effect is that sharing stdin between the shell script, and other
> commands (than read), is almost certainly never going to work,
Why not? It works fine with other shells
$ cat tst.sh
cat
On Mon, Apr 8, 2024 at 5:58 AM Robert Elz wrote:
> Shells interpret their input in much the same way, regardless of
> from where it comes. Would you really want your login shell to
> just collect commands that you type (possibly objecting to those
> with syntax errors) but executing none of
why this non-stop nagging? If you want maintainership ask for it, or is
your plan boring us all to death first?
--
Oğuz
looks like a
> hyperlink back into a hyperlink, which is how you get clickable links in
> the footnote.
>
They don't actually type those brackets then. Thanks
--
Oğuz
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?
ell for small, embedded systems.
--
Oğuz
ve the trap set for
an event into a variable if `x=$(trap)' stops working?
--
Oğuz
On Sunday, March 24, 2024, Oğuz wrote:
>
> $ printf '%s\0' "${a[@]@k}" | xargs -0 jq --args -n '$ARGS.positional
> | _nwise(2) | {(.[0]): .[1]}' | jq -s add
>
On reflection, splitting by NULs in JQ is better; there is no guarantee
that xargs will always provide an ev
| {(.[0]): .[1]}' | jq -s add
{
"y": "2",
"x": "1"
}
--
Oğuz
ot;${a[@]@k}"
{
"y": "2",
"x": "1"
}
--
Oğuz
On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote:
> The command in the first shell will exit after a random number of
> iterations with "terminated with exit status 141".
That's what every other shell does.
> Regardless of the reason for the SIGPIPE, the reporter expects the loop
> to
On Sunday, March 17, 2024, tpeplt wrote:
>
>The texinfo version of the bash manual is missing a description of
> the ‘shopt’ option ‘syslog_history’.
>
That must be a vendor extension, bash doesn't have such an option.
--
Oğuz
fly, you may not always know which case is
going to be the last. You may not always know that at least one clause is
going to be generated either, but `case x in esac' is valid, so it's not a
problem. The syntax for the case command is neat as-is.
--
Oğuz
On Monday, February 19, 2024, Lawrence Velázquez wrote:
>
> On what system does this happen? The proposed changes might break the
> test suite on some older systems.
>
Agreed. Those egrep invocations can be replaced with `grep -v -e
BASH_VERSINFO -e PIPESTATUS -e GROUPS' though.
--
Oğuz
e command, recall it and
edit the first line to introduce a syntax error and hit enter. Does it look
right? Wouldn't it be much better if the entire command were discarded?
--
Oğuz
m *
' >z
> ^C
$ ls
$
After the second invocation of `ls' I add a single quote and hit enter
accidentally, and lose all my files. I wish it didn't happen
--
Oğuz
o point in having `wait -n' if it can't
distinguish a single job terminating from multiple jobs terminating between
subsequent calls.
--
Oğuz
f *directory* is an empty string, the results are unspecified.
This changes to the following in Issue 8 draft 4:
>If directory is an empty string, cd shall write a diagnostic message to
standard error and exit with non-zero status.
Sorry for the noise.
--
Oğuz
On Sun, Jan 28, 2024 at 5:10 PM wrote:
> POSIX Programmer's Manual (cd(1p) manpage) says this:
>
> [9 unrelated special cases]
>
> 10. The cd utility shall then perform actions equivalent to the
>chdir() function called with curpath as the path argument. If
>
On Mon, Jan 22, 2024 at 8:13 PM Steven Pelley wrote:
>
> Hello,
> I've encountered what I believe is a bug in bash's "wait -n". wait -n
> fails to return for processes that terminate due to a signal prior to
> calling wait -n. Instead, it returns 127 with an error that the
> process id cannot
On Mon, Jan 22, 2024 at 3:25 PM Greg Wooledge wrote:
> But in any case, writing a "script" without a shebang and then counting
> on the shell to work around the broken script is not ideal.
Unlike shebangs that behavior is standardized. Which is what I
consider ideal. Thanks for your input
h would take a hacky approach like that for implementing
this basic functionality. It must be something else
--
Oğuz
ght in the second case instead of showing the completion
options.
This is reproducible on both the devel branch and 5.1.16, I didn't test 5.2.
Oğuz
On Fri, Jan 12, 2024 at 7:05 PM Chet Ramey wrote:
> Nofork command substitution freezes the jobs list, because you don't
> want jobs appearing and disappearing in the list while you're running
> word expansion. If the jobs list is frozen, wait -n doesn't even try
> waiting, since you don't want
These bugs affect the development branch only.
1. `wait -n' doesn't work inside nofork command substitution. I think
it should, or wait without `-n' shouldn't work either, or what works
and what doesn't should be documented.
$ sleep 3 & sleep 1; echo ${| wait -n -p REPLY;}
[1] 433
$
don't think this should be a syntax error because the closing brace
is not in a place it can terminate the command substitution.
Oğuz
On Mon, Dec 18, 2023 at 7:39 AM Luke Tidd wrote:
>
> A very common thing I need to do when writing bash is to collect both
> the stdout and stderr of a command. This can be done relatively
> reasonably with files but it would be very attractive to be able to
> redirect these directly to a
On Sunday, December 10, 2023, Koichi Murase wrote:
>
> In that case, a question would be what would be the standard way to
> specify the Bash-specific variable,
>
There doesn't have to be a standard way; I'd set it in ~/.profile, you'd
set it wherever is convenient on your setup.
ariable like BASH_HOME when looking for rc
files instead of exploring a fixed path.
--
Oğuz
oo: -c: line 1: unexpected EOF while looking for matching `"'
$
You wouldn't want the entire script printed for every error.
--
Oğuz
children won't receive the death
signal when the shell dies. It doesn't make any sense.
Unless there is a way to make it stick and affect all descendants of the
shell process, I don't think this would be very useful as a loadable
builtin either.
--
Oğuz
various events (udev events, window manager events,
> etc) often leave orphan processes behind when terminated forcefully.
>
> I've attached a proof-of-concept patch.
I think it'd make more sense to implement this as a loadable builtin.
--
Oğuz
bout it.
>
Can't you abuse jobs -x somehow? Like this perhaps
jobs -x printf '%s\n' %{1..100} | awk '!/%/{print "%"NR}'
--
Oğuz
On Tuesday, November 7, 2023, Chet Ramey wrote:
>
> It's interesting that musl supports brk but not sbrk
It doesn't support locales either. I always assumed it's someone's toy
project but looks like there are Linux distros shipping it instead of
glibc. Huh
--
Oğuz
On Sun, Oct 29, 2023 at 8:49 AM Paul Eggert wrote:
> My understanding is that Bash was intended to allow both leading and
> trailing whitespace. This is compatible with ksh and with Dash. If
> that's the intent, Bash should be consistent about it, just as ksh and
> Dash are. There seems little
On Saturday, October 28, 2023, Paul Eggert wrote:
> Bash should treat trailing whitespace the same way it treats leading
> whitespace,
Why? The same commands fail on bosh, yash, and zsh too.
--
Oğuz
ng SGR before the \n it is wise to have a closing sequence
> \n[m\n
>
I can reproduce this behavior on all the terminals I have access to except
xterm on Solaris 10, it never paints the background of a tab, which is at
least consistent. I wonder what changed...
--
Oğuz
On Wed, Sep 6, 2023 at 9:38 AM Robert Elz wrote:
> Adding a different %b to printf(1) wasn't currently even proposed, just
> deprecating the current one so it wouldn't conflict with the usage of
> %b in printf(3) (which is being defined in C23, and is apparently already
> firmly entrenched, even
On Tuesday, September 5, 2023, Chet Ramey wrote:
> to print binary literals
>
What's the point? Does anyone need this feature in their shell scripts (and
can't afford to use bc for it)?
--
Oğuz
On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> My vote is for posix_printf %B mapping to libc_printf %b
In the shell we already have bc for base conversion. Does POSIX really
have to support C2x %b in the first place?
On 6/2/23 4:01 AM, rpaufin1 wrote:
However, the result should be the same.
The manual says otherwise:
The shell does not exit if the command that fails is [...] part of any
command executed in a && or || list except the command following the
final && or ||
t see why anyone would either.
--
Oğuz
On 5/17/23 3:27 PM, Martin D Kealey wrote:
On Wed, 17 May 2023 at 20:20, Oğuz İsmail Uysal
wrote:
On 5/16/23 8:35 PM, Aleksey Covacevice wrote:
[original code elided as it's been mangled by line-wrapping]
This boils down to the following
true &
f
On 5/16/23 8:35 PM, Aleksey Covacevice wrote:
waitjobs() { local status=0 while true; do local code=0; wait -n ||
code=$? ((code == 127)) && break ((!code)) || status=$code done return
$status } # Eventually finishes: while true; do ( true & false &
waitjobs ) && break; done
This boils down
On 5/15/23 9:51 PM, Chet Ramey wrote:
Everything is shared between the comsub and its caller, with a
couple of documented exceptions. So it's just like calling `fg' in the
current execution environment, but capturing the output.
Oh, okay then. Thanks.
How about this?
$ declare -i x
$
On 5/15/23 8:35 PM, Chet Ramey wrote:
Please test it out
$ cat
^Z
[1]+ Stopped cat
$ x=${ fg;}
foo
foo
<^C or ^D here>
$ declare -p x
declare -- x="cat"
$
Is this intended?
not a syntax error when `()' is though.
--
Oğuz
On 3/30/23 7:51 PM, Felipe Contreras wrote:
So? This is argumentum ad populum. The fact that most shells do X
doesn't imply that POSIX says X.
POSIX documents existing practice. If what it says differs from what the
majority of shells do, then it's POSIX that is wrong. And this mailing
list
On 3/30/23 2:12 PM, Felipe Contreras wrote:
IFS=,
str='foo,bar,,roo,'
printf '"%s"\n' $str
zsh is the only shell that generates an empty last field, no other shell
exhibits this behavior.
Besides your link says:
>The shell shall treat each character of the IFS as a delimiter
On 3/24/23 4:49 AM, Paul Eggert wrote:
a strict C23 compiler
Does such a compiler exist? Is C23 even published yet?
On 2/18/23 2:05 AM, Chet Ramey wrote:
If the shell reads an unquoted word in the right position, it checks
the word to see if it matches an alias name. If it matches, the shell
replaces the word [in the input] with the alias value, and reads that
value as if it had been read [from the input]
On 2/15/23 2:52 AM, Koichi Murase wrote:
two or three command substitutions are generally not considered "so
many command substitutions".
I can't reproduce a great deal of unresponsiveness with five or six
either, and my computer is very old too. I think this "delay" you
mentioned has more to
benefits at all, ksh didn't
> have the feature.
>
Ksh has many features no one ever uses; some of them don't make any sense,
some don't even work. Check out <https://github.com/ksh93/ksh>, it's a mess
compared to bash.
--
Oğuz
to write it in.
> and also can
> affect the parent shell context when it wants to.
This doesn't sound like an upside to me, I can't think of any use case
where it wouldn't make the code more confusing.
--
Oğuz
On 2/13/23 2:43 PM, Koichi Murase wrote:
I guess just the support for ksh's ${ list; } [1] would make
everything simple and clear. One can simply call ${ jobs; }, ${ trap
-p; }, etc. without thinking about subshells.
I don't see what difference that'd make. A subshell inherits its
parent's job
4 Şubat 2023 Cumartesi tarihinde Koichi Murase
yazdı:
>
> I understand. But I think both bash and zsh should change their behavior
to disallow the functions in question at least in posix mode, and the
standard shouldn't allow it, that's what I'm saying
--
Oğuz
On 2/4/23 12:23 PM, Koichi Murase wrote:
Changing the behavior related to the function names wouldn't make the
behavior of the shell entirely unspecified
I see, but that's not what you're suggesting. You're suggesting that how
command search and execution works be changed to allow functions
rsonal reason to support or not support what you
propose, but that names of functions and pathnames of executables can clash
even under POSIX mode doesn't feel right. I'm not against periods and
colons in function names though.
--
Oğuz
ell shall execute
a non-built-in utility
I think he meant he'll change that for POSIX mode only though
--
Oğuz
sub1"
>echo 'echo "2nd script starting" && ${THIS_SH} '"$sub3" >"$sub2"
>echo 'echo "3rd script starting"' >"$sub3"
>
>. "$sub1"
>
> "1st script still executing" will never be printed.
>
Or
$ bash -c '(. <(echo ": && uname"); echo x)'
Linux
$
x is never printed. Looks like another bug caused by aggressive subshell
optimizations
--
Oğuz
On 10/31/22 2:20 PM, Greg Wooledge wrote:
Bash already uses the POSIX regex functions (regcomp(3) et al.) to do
[[ =~ ]] using POSIX ERE.
Yeah, and offers no more than what your libc's regex engine has. For
example, you can't tell what `[[ x =~ .{256} ]]' (or even `[[ x =~ ""
]]') would
.stackexchange.com/questions/167582/why-zsh-
> ends-a-line-with-a-highlighted-percent-symbol#answer-302710
>
Thanks for the link. The hack is clever but the result is ugly. I'd much
prefer the current behavior of bash.
--
Oğuz
ugh
in my previous email.
The problem is that it DOESN'T work fine. In practice people encounter
> abysmally slow extglob matching.
>
*when matching against a huge string. Which is rare in my experience, but
of course should be taken into consideration if there are multiple bug
reports; I didn't say anything against that.
--
Oğuz
a newline or not then?
> Option B: Fix the line editor to take into account when the
> prompt doesn't start at column 0.
>
>
Yeah, or add a new prompt sequence (e.g. \N) that prints a newline only if
the cursor is not at column 0.
--
Oğuz
On 10/30/22 3:25 PM, Martin D Kealey wrote:
How much faster do you think it can be made?
I don't know, irrelevant though.
The problem is not that individual steps are slow, but rather that it
takes at least a higher-order-polynomial number of steps, possibly
more (such as exponential or
e shell.
Which, in my opinion, is the easiest and most realistic option.
--
Oğuz
tion definition
>
> This results in an effective masking of the error from the debugging
> support.
This sounds like a misuse of the debug trap. The error can be caught using
the err trap, why don't you use that instead?
--
Oğuz
27 Ekim 2022 Perşembe tarihinde Chet Ramey yazdı:
>
> Yep, this is a problem. I'll have a fix in the next devel branch push.
>
Thanks
--
Oğuz
ect command, every arithmetic
> for command, and before the first command executes in a
> shell function [...]
--
Oğuz
nly the
last-executed one, it waits for all of them:
$ ( : & wait ) > >(sleep 3) > >(:)
*hangs for 3 seconds*
--
Oğuz
t; >(cat)
>
> Or, in your specific case, use "$!" to only wait for the most recent
> background job.
>
> (: & wait -- "$!") > >(cat)
>
Thanks, I'm not looking for a workaround.
--
Oğuz
To reproduce:
$ echo $BASH_VERSION
5.2.2(3)-release
$ ( : & wait ) > >(cat)
*hangs*
It should return immediately, but hangs instead.
13 Ekim 2022 Perşembe tarihinde Chet Ramey yazdı:
>
> You know that referencing an array variable without a subscript is
> equivalent to referencing element 0 (or "0").
>
Yes, but I didn't know that it applied to test -v as well.
Thanks for the reply
--
Oğuz
e -a bar=(42)
$ test -v foo; echo $?
1
$ test -v bar; echo $?
0
--
Oğuz
9 Ekim 2022 Pazar tarihinde Phi Debian yazdı:
>
> $ [[ $(printf '%010d' 0) == +(0) ]]
>
> I see 3 way of fixing this
>
I'm not familiar with how extended globs are implemented in either shell
but this doesn't look like something that'd involve recursion.
--
Oğuz
't get me wrong, I just like it when new features align with the old
ones and work together nicely.
--
Oğuz
On 10/8/22 6:03 AM, Cynthia Coan wrote:
Otherwise, I think we can perhaps reword this into two smaller
features: "function local trap signals", and
I don't think this would be a feature worth the time to implement and
the complexity it would introduce. Is there any other use case for this
On 8/29/22 5:48 AM, Martin D Kealey wrote:
The Shell persists because it has one killer feature: it does double duty
as a scripting language and as an interactive command language. But we're
kidding ourselves if we think that no other language could fill that gap:
Python has a respectable
the case where /new/file1 does not
> exists, which is critical error.
> * Without errfail, an error message will be sent to script stderr, but the
> script will continue to copy the 2nd file, and to perform the
> important-job, even though the data is not ready.
How is this any better than doing `cp ... && cp ... && important-job ...'?
--
Oğuz
24 Nisan 2022 Pazar tarihinde Ángel yazdı:
>
> I think a shopt makes more sense. Forcing heredocs to be files although
> something legit to request, is more a caller workaround to bugs in
> called programs.
>
https://lists.gnu.org/archive/html/bug-bash/2020-12/msg00084.html
--
Oğuz
d anyone use $'' in a
here-document other than for embedding escape sequences?
--
Oğuz
f allowing dollar-quotes
inside here documents then?
--
Oğuz
On Fri, Jan 21, 2022 at 6:28 PM Chet Ramey wrote:
> a. Fixed a bug that assigned a value to the variable name supplied as an
>argument to `wait -p' when there were no jobs.
This doesn't seem like it's fixed
$ bash -c 'echo $BASH_VERSION; unset foo; for i in 1 2 3; do wait -p
foo; declare -p
make it a special case? What's wrong with prepending all of them with
`:;'?
--
Oğuz
On Mon, Dec 13, 2021 at 8:31 AM Mallika wrote:
> "An interactive shell is one started without non-option arguments, unles*s*
> -s is specified, without specifying the -c option, and whose input and
> error output are both connected to terminals (as determined by isatty(3)), or
> one started with
To reproduce:
$ a=()
$ echo ${a[42]=foo}
Desktop Documents Downloads mpv-shot0001.jpg Music Pictures Public
Videos VirtualBox VMs
$ declare -p a
declare -a a=([42]="foo")
or
$ declare -A a
$ echo ${a[foo]=bar}
P�ϝU
$ declare -p a
declare -A a=([foo]="bar" )
Oğuz
> I agree that the `mtime >= atime' behavior should be restored; ``file
> is newly created or was accessed since last modified'' is not a useful
> information, nor is the opposite.
Or, -N can be split into -A (atime > mtime) and -M (mtime > atime),
and everyone would be happy :D
On Fri, Nov 12, 2021 at 12:44 PM Mischa Baars
wrote:
> Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash
> 5.1.8) this returns a false:
> touch test; if [[ -N test ]]; then echo true; else echo false; fi;
This seems to have changed as a result of this bug report:
On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote:
> Temporarily using a default value of PATH is akin to modifying it.
But they are not the same thing, and you know this. The standard is
neither on your side nor mine.
On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote:
> This wording does not cover it wholly, in my opinion.
> Because when the utility's hashed path is not in $PATH,
> then the utility should not have been searched for at all.
> It should not be found, even if it is remembered.
Is the rest of
On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans wrote:
> POSIX is also silent on this.
I think ``Once a utility has been searched for and found [...], an
implementation may remember its location and need not search for the
utility again unless the PATH variable has been the subject of an
On Sun, Oct 31, 2021 at 7:07 PM Mike Jonkmans wrote:
>
> On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> > 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> > >
> > > Using the hash as alias for commands, that are not in your PATH,
> > > see
31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
>
> Using the hash as alias for commands, that are not in your PATH,
> seems risky though.
Why? Risky how?
--
Oğuz
On Sun, Oct 31, 2021 at 2:15 PM Mike Jonkmans wrote:
> PATH=/dev/null
> command -p hostname
> hostname # executes /bin/hostname via the hash table
>
> I agree with OP that the behaviour is a bug, or at least unwanted behaviour.
I'd say it's a feature, and a good one too.
1 - 100 of 270 matches
Mail list logo
