On Saturday, October 12, 2024, Zachary Santer wrote:
>
> Backwards compatibility with people's expectations
No one expects children of the same parent to be able to wait for
eachother. It's common sense.
--
Oğuz
On Saturday, October 12, 2024, David Moberg wrote:
> This link shows a big commit to bash. Is it merged to main/release? Can I
> try it out?
>
You can clone the devel branch to try it out. The master branch is only
updated for releases and important patches.
--
Oğuz
The first letter I type after running this command won't show up on
the terminal:
: < <(cat)
This is reproducible on 5.3 beta too.
Oğuz
On Saturday, September 21, 2024, Koichi Murase
wrote:
>
> Emacs has `auto-mode-alist'. VS Code has `files.associations'.
>
I think he meant a command line option. Like something you can put in FCEDIT
--
Oğuz
On Fri, Sep 20, 2024 at 12:00 PM shynur . wrote:
> Editors needn't give "bash-fc.NN" special handling, IMO.
A good editor would.
On Fri, Sep 20, 2024 at 11:20 AM shynur . wrote:
> - When Emacs opens a file named "bash-fc.NN.bash",
> it'll enable sh-mode automatically
Vim does that without the .bash extension. What stops Emacs from doing the same?
On Friday, September 20, 2024, shynur . wrote:
>
> editors that use *suffixes* to infer what syntax
> highlighting should be enabled.
>
For example?
--
Oğuz
On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso wrote:
>
It boils down to this:
f(){ echo $#;}; set "" "" ""; IFS=x; f $*
bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh
prints 3 but mksh and oksh print 1. dash, ksh93, yash, and zsh print
0.
On Monday, September 9, 2024, Zachary Santer wrote:
> Slightly improved wait-n-failure attached.
It's >100 lines and your replies are too long. Summarize what you want so
others can contribute too without having to waste time reading the whole
thread.
--
Oğuz
ut changing how Bash is
built.
--
Oğuz
On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote:
> However, as ksh93 makes "" from this
> expansion, and so probably ksh88 might have done as well
No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.
roduce an empty field, except that if the other parts are all within the
same double-quotes as the '@', it is unspecified whether the result is zero
fields or one empty field.
--
Oğuz
On Saturday, August 10, 2024, Martin D Kealey
wrote:
> Sorry, that was supposed to be a personal reply off-list.
>
Do you always harass foreigners like that or was it an exception?
--
Oğuz
lity that makes setting up FIFOs easier, I
don't know.
--
Oğuz
noise as how many procsubs you expand on the command line.
>
And that's too many. Much more than async jobs.
--
Oğuz
On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer wrote:
> I can not think of a time when I called 'wait' from the command line
> that wasn't just for testing something. Even using process
> substitutions on the command line is a relative rarity for me. If
> we're balancing behavior on the command lin
unction or sourced script" and completion returns to
normal.
Oğuz
it' waiting for a
procsub that I forgot about and that won't be listed by `jobs' is not.
Procsubs occupying one slot in the shell's internal list of job statuses is
acceptable, them filling up that list and causing data loss/oom errors is
not.
--
Oğuz
n. Didn't we already discuss this and
agree that `wait -n' should wait jobs one by one without skipping any? Did
it not make it to 5.3?
--
Oğuz
On Mon, Jul 8, 2024 at 11:16 AM Martin D Kealey wrote:
> The only things that the shell has going for it is that it's widely deployed
> and stable over the long term.
> Otherwise it's a terrible language, and any sane programmer should avoid it
> entirely:
> This has already been happening, and
-s compat52' should suffice to opt out of the new default. No point
in making it more complicated than that.
--
Oğuz
ing else?
--
Oğuz
On Saturday, June 29, 2024, Zachary Santer wrote:
>
> Couldn't you do the exact same thing with regular background processes
> forked with &?
>
But the shell notifies me when they terminate and reap them.
--
Oğuz
On Sat, Jun 29, 2024 at 3:47 PM Zachary Santer wrote:
> Why not just wait for all process substitutions?
What if I substitute thousands of processes and never call wait?
y changing it. Bash is too good to ruin like that.
--
Oğuz
',
`${a[1..10..3]}', etc. These would expand like `$@' when in double quotes
and like `$*' when being assigned to a variable.
--
Oğuz
On Tue, Jun 25, 2024 at 3:32 PM Emanuele Torre wrote:
> There are actually ways to call them:
>
> $ %f(){ echo hi;}
> $ compgen -F %f
> bash: compgen: warning: -F option may not work as you expect
> hi
Neat
precedence over jobspecs?
Oğuz
On Mon, Jun 24, 2024 at 2:37 PM Gioele Barabucci wrote:
> $ printf -v b "\xc3\xbf\xbe"
>
> $ printf "$b" | { while LC_ALL=C read -N1 c; do \
> LC_ALL=C.UTF-8 printf "%d %q\n" "'$c" "$c"; done; }
> 195 $'\303'
> 255 $'\277'
> 190 $'\276'
Can't reproduce this on Ubuntu 22.04 with Bash 5.3-alph
On Thursday, June 20, 2024, Léa Gris wrote:
>
> Would it be a valid option, then to make BASH_SOURCE contain the real path
> in all circumstances?
>
Sounds good to me.
--
Oğuz
ory of the source script, I just don't need it and it wasn't what we
were discussing.
--
Oğuz
On Sat, Jun 15, 2024 at 4:59 PM Koichi Murase wrote:
> Sorry, I think I misunderstood the part "behind the user's back". Now I
> guess you were talking about the behavior of `checkwinsize' when `set
> -a' is enabled?
Yes. All I'm saying is, a variable that affects how certain programs
behave when
env | grep COLUMNS
$ env | grep COLUMNS
COLUMNS=64
This is true for non-interactive shells where job control is enabled as
well.
If Bash didn't export COLUMNS implicitly but you wanted it to take effect,
you'd export it yourself once and it'd work fine. Clean and straightforward.
--
Oğuz
esented in OP,
wouldn't you think something was broken? What keeps Bash from exempting
LINES and COLUMNS from `set -a' other than "it's been like this forever"?
--
Oğuz
aviour do not get impacted by the
> shell used to call them.
>
> Even more reason to use `ps axww' instead of `ps ax'.
> What do you think ?
>
> I think there's at least one Bash bug involved here.
--
Oğuz
S
$ env | grep COLUMNS
COLUMNS=64
You should call ps with the option -w if you want wide output though. On
some implementations you can disable truncation completely by specifying it
twice like `ps axww'.
--
Oğuz
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 Bou
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 n
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 to
ct if their 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 u
ns though;
the one sent 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 det
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 disp
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 bef
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
j 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 POSIX
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 them
And why this non-stop nagging? If you want maintainership ask for it, or is
your plan boring us all to death first?
--
Oğuz
ooks 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?
a
bare-bones shell for small, embedded systems.
--
Oğuz
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
nal |
_nwise(2) | {(.[0]): .[1]}' | jq -s add
{
"y": "2",
"x": "1"
}
--
Oğuz
'
"${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 carr
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
ating case clauses on the 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
tiline 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
$ echo ''
rm *
' >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
is no point in having `wait -n' if it can't
distinguish a single job terminating from multiple jobs terminating between
subsequent calls.
--
Oğuz
>If *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
>the
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 be
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
bash would take a hacky approach like that for implementing
this basic functionality. It must be something else
--
Oğuz
he right 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 jo
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
$
x
$
I 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 variable
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
#x27; foo
foo: -c: line 1: unexpected EOF while looking for matching `"'
$
You wouldn't want the entire script printed for every error.
--
Oğuz
command forks, its 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
listen to 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 poi
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
when emitting 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 t
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?
1 - 100 of 324 matches
Mail list logo
