On Thu, Nov 9, 2023, 10:56 PM Greg Wooledge <g...@wooledge.org> wrote:
> On Thu, Nov 09, 2023 at 10:17:35PM +0100, Andreas Schwab wrote:
> > On Nov 09 2023, Greg Wooledge wrote:
> >
> > > re='^\[([0-9]+)\]'
> > > jobspecs=()
> > > while IFS= read -r line; do
> > > if [[ $line =~ $re ]]; then
> > > jobspecs+=( "%${BASH_REMATCH[1]}" )
> > > fi
> > > done < <(jobs -l)
> >
> > That fails for multi-line commands that happen to contain matches for
> > re.
> >
> > $ (sleep 100; printf $'\n[100]\n') &
>
> Fair enough. I believe *nothing* would work in that case; the output of
> "jobs -l" cannot be safely parsed in its current form.
>
> Adding a NUL-delimited output option might work around that, but if we're
> modifying the jobs builtin, we might as well just add the -i or -j option
> instead.
>
ther'd be few different values for seps , i think ifs is nearly none , so ,
one is per element , one per record
others may also exist
so just two constant opts to align extend usage
>
