On Thu, Nov 9, 2023, 11:08 PM alex xmb sw ratchev <fxmb...@gmail.com> wrote:
>
>
> 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
>
i d have a half example about such formatting for printf
( pre ) ( sep for 2+ elements ) ( elem pre ( also elem N pre ) ) $elem (
elem stu or and N th ) ( end )
missing some terms also ..
>
