upt or where the last successful read command left it?
--
Oğuz
See:
$ while read; do :; done
POSIX Issue 8 will require that this feature is supported, see
https://www.austingroupbugs.net/view.php?id=1592
Perhaps a future version of Bash will have it.
--
Oğuz
While you're at it take a look at this too:
true; for (( ; $? == 0; ${ ! break;} )); do uname; done
Once you run this command bash gets stuck in a state where it prints
the prompt string and reads commands but doesn't execute anything. If
you press Ctrl+C it returns to normal.
Oğuz
See:
$ bash -c 'for (( $(case x in x) esac);; )); do :; done'
bash: -c: line 1: syntax error: `;' unexpected
bash: -c: line 1: syntax error: `(( $(case x in x)
;;
esac);; ))'
This is reproducible on 5.3 alpha too.
Oğuz
On Thu, May 23, 2024 at 2:49 AM Steffen Nurpmeso wrote:
> Only to note that this is not portable.
> The FreeBSD shell will not assign "b" to "c" for this one!
Nor will NetBSD sh. This lets you swap values of two variables without
using a third
$ x=1 y=2
$ x=$y y=$x
$ echo $x $y
2 1
And some
hey don't clash and source with
`${BASH_SOURCE%/*}' prepended to PATH and it'll work fine.
This feature request sounded promising at first, it feels like
bike-shedding now.
--
Oğuz
On Monday, May 13, 2024, Chet Ramey wrote:
> performs the setpgid in the process forked
> to run the process substitution).
>
Yes, this sounds like the easy way. I don't know how else to prevent the
race in OP. Close stdin/stdout? Direct it from /dev/null?
--
Oğuz
On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote:
> Since the redirection fails and the cat command is never started, bash
> doesn't switch the terminal process group
It does on my computer:
554 ioctl(255, TIOCSPGRP, [554]) = 0
553 execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10
On Sun, May 5, 2024 at 7:36 AM Matheus Afonso Martins Moreira
wrote:
> I certainly intend to use it as one should it be merged.
If it's not you should try turning this into a loadable builtin. An
`include' command that lets you selectively import variables/functions
from a larger collection and
On Fri, May 3, 2024 at 6:41 PM Chet Ramey wrote:
> We're only talking about interactive shells here. Non-interactive shells
> have printed something like this, but including the pid, for forever:
>
> ./x1: line 2: 65124 Killed: 9 ( kill -9 $BASHPID )
Never seen this and it's ugly
r scripts
started printing that though, take more people's opinions on that please.
--
Oğuz
On Thu, May 2, 2024 at 8:44 PM Chet Ramey wrote:
> I'm not planning to change the text. The point is whether or not this
> counts as `notification' for the purposes of the jobs list, which allows
> the shell to remove the job from the list.
And what change of behavior discernible by the average
ent when a foreground job is killed is useful when the shell is
non-interactive too, the other not so much. I don't know why the standard
doesn't cover it, but if you plan to follow zsh in this I don't think
that's a good idea. It's ugly and confusing.
--
Oğuz
On Thu, May 2, 2024 at 6:10 PM Chet Ramey wrote:
> There's no real difference between the two statements; there is a
> clarification for consistency with the language in the new "Job
> Control" section in Issue 8.
Yeah it doesn't clarify anything and the new job control section is
pointlessly
On Thu, May 2, 2024 at 3:55 PM Chet Ramey wrote:
> A paraphrase of what?
Issue 7 says this:
By default, the jobs utility shall display the status of all stopped
jobs, running background jobs and all jobs whose status has changed
and have not been reported by the shell.
And Issue 8 draft, this:
On Wed, May 1, 2024 at 10:36 PM Chet Ramey wrote:
> Sure. Then you wonder why POSIX bothered to include "and all jobs whose
> status has changed and have not been reported by the shell" in the
> standard.
No, I think it's a botched paraphrase. Issue 7 says "By default, the
jobs utility shall
On Tuesday, April 30, 2024, Chet Ramey wrote:
>
> comsubs). I can work around this case, but I'm still interested in what
> people think the general rule should be.
>
I don't think anyone would expect to run `jobs' and see anything but
asynchronous and stopped jobs.
--
Oğuz
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
1 - 100 of 288 matches
Mail list logo
