Re: New array_expand_once option
On 6/14/23 5:18 PM, alex xmb ratchev wrote: [[ -v a["$subscript"] ]] is already an arithmetic expansion error in bash-5.2, but not in bash-5.1. hello there .. i dont get much it d be an arith err if array wasnt -A .. ? Yes, because only one expansion is performed, and so the subscript is the command substitution, which is not a valid arithmetic expression. so i shopt -s array_expand_once and [[ -v foo["$var"] ]] .. is the right way ? ( for the change , the future ) It's not as important for compound commands like [[, but for builtins like test/[, yes, this is the way to use it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: New array_expand_once option
On Thu, Jun 15, 2023, 15:06 Chet Ramey wrote: > On 6/14/23 5:18 PM, alex xmb ratchev wrote: > > > [[ -v a["$subscript"] ]] > > > > is already an arithmetic expansion error in bash-5.2, but not in > bash-5.1. > > > > > > hello there .. > > > > i dont get much > > it d be an arith err if array wasnt -A > > .. ? > > Yes, because only one expansion is performed, and so the subscript is the > command substitution, which is not a valid arithmetic expression. > very good i like now it works like this , . the old was bugged > > > so i shopt -s array_expand_once > > and [[ -v foo["$var"] ]] > > .. is the right way ? ( for the change , the future ) > > It's not as important for compound commands like [[, but for builtins like > test/[, yes, this is the way to use it. > alright , thanks greets -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: `jobs` shows output even when nothing has been started in the background
On Thu, Jun 15, 2023, 00:13 Ajeet D'Souza <98aj...@gmail.com> wrote:
> Hey Chet,
>
> Thanks for the quick reply. I have some follow-up questions:
>
>- Is there an elegant way I can start an external process without it
>showing up under jobs, even on affected versions? My current best idea
>is: (_="$(/bin/echo)"; jobs -l)
>- Is there an elegant way I can get the correct number of jobs, even on
>affected versions? My current best idea is to run jobs once before doing
>the count: (jobs &> /dev/null; jobs | wc -l)
>
small .. speed up
p=( $( jobs -p ) ) # here new code will come , with new feature
pcount=${#p[*]}
I'm trying to keep the behaviour consistent across all versions of Bash.
>
> Thanks,
> Ajeet
>
> On Wed, Jun 14, 2023 at 8:17 PM Chet Ramey wrote:
>
> > On 6/14/23 4:47 AM, Ajeet D'Souza wrote:
> >
> > > Bash Version: 5.2
> > > Patch Level: 15
> > > Release Status: release
> > >
> > > *Description:*
> > > I apologize if this is not a bug, but I couldn't find any documentation
> > > around this behaviour.
> > >
> > > In Bash, this does not produce any output:
> > > /bin/echo; jobs -l
> > >
> > > But if you run it in a subshell, it does:
> > > (/bin/echo; jobs -l) # output: [1] 42135 Done
> > /bin/echo
> > >
> > > Similar problem if you put this into $PROMPT_COMMAND, although it does
> > not
> > > run in a subshell AFAIK:
> > > PROMPT_COMMAND='/bin/echo; jobs -l' # output on every prompt: [1]
> 42135
> > > Done/bin/echo
> > >
> > > This happens only for external processes, if you were to use the
> builtin
> > > echo, it would not show any background process.
> >
> > Thanks for the report. I changed this back in late September, 2022 after
> > a bug-bash discussion:
> >
> > https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00067.html
> >
> > The original report was
> >
> > https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00117.html
> >
> > The original (through bash-5.2) behavior was due to the subshell not
> > notifying the user about the status of the completed foreground job,
> > even though not running it in a subshell ignored foreground jobs. The
> > fix was to remove terminated foreground jobs the shell would never notify
> > the user about (foreground jobs not killed by a signal) from the jobs
> list.
> >
> > Chet
> > --
> > ``The lyf so short, the craft so long to lerne.'' - Chaucer
> > ``Ars longa, vita brevis'' - Hippocrates
> > Chet Ramey, UTech, CWRUc...@case.edu
> http://tiswww.cwru.edu/~chet/
> >
> >
>
posix_spawn (or vfork) support?
Hi, Sorry if this has come up before - I did take a look and couldn't find anything. Could bash use posix_spawn/vfork instead of the rather heavyweight fork? I'm aware of the work in `devel` to add nofork comsubs which is very intriguing, but I do wonder about another suggestion: could bash use posix_spawn (or maybe vfork directly) in some cases? Recently, we've been optimising a lot of our global-scope (commonly used bash "libraries") used for packages in Gentoo and unsurprisingly, a lot of the cost has been down to forks, so this came up. (It also came up a few years ago in https://trofi.github.io/posts/215-perf-and-dwarf-and-fork.html). Some prior art: * fish used to do it, but stopped because it didn't make as much sense for them (fish is for interactive use AFAIK so I guess the environment size is never big enough for this to pay off): https://github.com/fish-shell/fish-shell/issues/3149. * ksh does it (https://github.com/ksh93/ksh/issues/79). * The `posixspawn` utility (https://github.com/AlexanderOMara/posixspawn) aims to make this available as a tool to call rather than something builtin. * https://blog.famzah.net/tag/benchmark-fork/ has an interesting set of benchmarks. * https://metacpan.org/pod/Proc::FastSpawn implements this in Perl with some interesting discussion on the performance benefits. best, sam signature.asc Description: PGP signature
5.2 fails to treat a missing conditional expression as an error of syntax
As below. $ bash -c 'declare -p BASH_VERSION' declare -- BASH_VERSION="5.2.15(1)-release" $ bash -c '[[ ]]; echo fin'; echo $? 0 $ bash -c 'declare -p BASH_VERSION' declare -- BASH_VERSION="5.1.16(1)-release" $ bash -c '[[ ]]; echo fin'; echo $? bash: -c: line 1: syntax error near `;' bash: -c: line 1: `[[ ]]; echo fin' 2 The development branch behaves as 5.1 does. Being uncertain as to whether this is a result of the issue having been identified prior, I determined that it was worth reporting. -- Kerin Millar
`verb=(--) declare -ax verb` causes an ENOTSOCK segfault
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer uname output: Linux localhost-live 6.2.9-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Mar 30 22:32:58 UTC 2023 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.2 Patch Level: 15 Release Status: release Description: `verb=(--) declare -ax verb` causes bash to crash and closes the active terminal tab. strace output includes this error: "getpeername(0, 0x7ffc74d185d0, [16])= -1 ENOTSOCK (Socket operation on non-socket)" Repeat-By: Occurs every time. xfce4-terminal 1.0.4 on Fedora 38 Thank you, you wizards, Wiley
