Chet Ramey wrote in
<7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
|On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
|> The "problem" with the current way bash is doing it is that bash's
|> job handling does not recognize jobs die under the hood:
|>
|>$ jobs
|>[1]- Stopped
On Fri, Nov 10, 2023 at 01:09:29PM -0600, G. Branden Robinson wrote:
> At 2023-11-10T10:54:52-0800, Eric Pruitt wrote:
> > From _seq(1)_ on FreeBSD:
> >
> > > The seq command first appeared in Version 8 AT UNIX. A seq command
> > > appeared in NetBSD 3.0, and was ported to FreeBSD 9.0. This
At 2023-11-10T10:54:52-0800, Eric Pruitt wrote:
> On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote:
> > It most definitely is *not* everywhere. It's part of GNU coreutils,
> > and is generally not present on any system that does't use those
> > (BSDs and commercial Unixes for
On Fri, Nov 10, 2023 at 10:54:52AM -0800, Eric Pruitt wrote:
> > A seq command appeared in Version 8 AT UNIX. This version of seq
> > appeared in NetBSD 3.0 and was ported to OpenBSD 7.1.
Ah, I'm a year and a half behind. OpenBSD 7.1 was released April 2022.
On Fri, Nov 10, 2023 at 01:22:54PM -0500, Greg Wooledge wrote:
> It most definitely is *not* everywhere. It's part of GNU coreutils,
> and is generally not present on any system that does't use those (BSDs
> and commercial Unixes for example).
>From _seq(1)_ on FreeBSD:
> The seq command first
Greg Wooledge wrote in
:
|On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote:
|> Sequences are also bash-only (though seq(1) is
|> everywhere).
|
|It most definitely is *not* everywhere. It's part of GNU coreutils,
|and is generally not present on any system that does't use
On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote:
> Sequences are also bash-only (though seq(1) is
> everywhere).
It most definitely is *not* everywhere. It's part of GNU coreutils,
and is generally not present on any system that does't use those (BSDs
and commercial Unixes for
Chet Ramey wrote in
<7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
|On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
|> The "problem" with the current way bash is doing it is that bash's
|> job handling does not recognize jobs die under the hood:
|>
|>$ jobs
|>[1]- Stopped
Hello.
Oğuz wrote in
:
|On Thursday, November 9, 2023, Steffen Nurpmeso wrote:
|> I mean some scripting on "jobs | wc -l" would do that, though. :(
|> Maybe i should just write a function that builds the string
|> necessary to do what i wanted with %* or "%1-2 %4" etc.
|> Eh. Forget about
On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
The "problem" with the current way bash is doing it is that bash's
job handling does not recognize jobs die under the hood:
$ jobs
[1]- Stopped LESS= less -RIFe README
[2]+ Stopped LESS= less -RIFe TODO
$
On Thursday, November 9, 2023, Steffen Nurpmeso wrote:
>
> I mean some scripting on "jobs | wc -l" would do that, though. :(
> Maybe i should just write a function that builds the string
> necessary to do what i wanted with %* or "%1-2 %4" etc.
> Eh. Forget about it.
>
Can't you abuse jobs -x
Greg Wooledge wrote in
:
|On Thu, Nov 09, 2023 at 10:17:35PM +0100, Andreas Schwab wrote:
|> On Nov 09 2023, Greg Wooledge wrote:
|>> re='^\[([0-9]+)\]'
..
|>> while IFS= read -r line; do
|>> if [[ $line =~ $re ]]; then
...
|> That fails for multi-line commands that happen
Robert Elz wrote in
<15529.1699569...@jacaranda.noi.kre.to>:
|Date:Thu, 9 Nov 2023 16:55:50 -0500
|From:Greg Wooledge
|Message-ID:
|
|| I believe *nothing* would work in that case;
|
|There's no requirement (in fact, it is probably not a good idea) for
Robert Elz wrote in
<7989.1699564...@jacaranda.noi.kre.to>:
|Date:Thu, 09 Nov 2023 21:04:28 +0100
|From:Steffen Nurpmeso
|Message-ID: <20231109200428.8g9lz%stef...@sdaoden.eu>
|
|| ash(1) and busybox ash(1) do not even support jobs -l in a function \
|| (yet).
Andreas Schwab wrote in
<87h6lueids@igel.home>:
|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
Date:Thu, 9 Nov 2023 16:55:50 -0500
From:Greg Wooledge
Message-ID:
| I believe *nothing* would work in that case;
There's no requirement (in fact, it is probably not a good idea) for
newlines in the output to be printed literally - whether entered literally
or
On Thu, Nov 9, 2023, 11:08 PM alex xmb sw ratchev wrote:
>
>
> On Thu, Nov 9, 2023, 10:56 PM Greg Wooledge 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=()
>> > >
On Thu, Nov 9, 2023, 10:56 PM Greg Wooledge 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
> >
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
>
On Thu, Nov 9, 2023, 10:18 PM 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
Date:Thu, 09 Nov 2023 21:04:28 +0100
From:Steffen Nurpmeso
Message-ID: <20231109200428.8g9lz%stef...@sdaoden.eu>
| ash(1) and busybox ash(1) do not even support jobs -l in a function (yet).
That seems unlikely, ash based shells mostly don't care whether the
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
Greg Wooledge wrote in
:
|On Thu, Nov 09, 2023 at 08:09:23PM +0100, Steffen Nurpmeso wrote:
|> j() {
|> local j= a=${AWK:-awk}
|> [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')( \
|> |$)/'
|> j=$(jobs -l | $a -F '[][]' '/^[[]/'"$j"'{print "%" $2}{next}')
On Thu, Nov 9, 2023, 8:24 PM Greg Wooledge wrote:
> On Thu, Nov 09, 2023 at 08:09:23PM +0100, Steffen Nurpmeso wrote:
> > j() {
> > local j= a=${AWK:-awk}
> > [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')(
> |$)/'
> > j=$(jobs -l | $a -F '[][]' '/^[[]/'"$j"'{print
On Thu, Nov 9, 2023, 8:41 PM alex xmb sw ratchev wrote:
>
>
> On Thu, Nov 9, 2023, 8:36 PM Steffen Nurpmeso wrote:
>
>> alex xmb sw ratchev wrote in
>> :
>> ...
>> |> So i did that (what a mess -- does anyone know how i can create an
>> |> awk regular expression where parts of the
On Thu, Nov 9, 2023, 8:36 PM Steffen Nurpmeso wrote:
> alex xmb sw ratchev wrote in
> :
> ...
> |> So i did that (what a mess -- does anyone know how i can create an
> |> awk regular expression where parts of the expression is a variable
> |> that should be expanded? ugh! what do i
alex xmb sw ratchev wrote in
:
...
|> So i did that (what a mess -- does anyone know how i can create an
|> awk regular expression where parts of the expression is a variable
|> that should be expanded? ugh! what do i know??):
|
|awk -v var1='cont ent' -vv2="$other' ' { code } '
|
|keep
On Thu, Nov 9, 2023, 8:10 PM Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
> <20231109181645.bocyg%stef...@sdaoden.eu>:
> |Steffen Nurpmeso wrote in
> | <20231109181107.bj0wl%stef...@sdaoden.eu>:
> ||Steffen Nurpmeso wrote in
> || <20231109011212.tc9hj%stef...@sdaoden.eu>:
> || ...
>
On Thu, Nov 09, 2023 at 08:09:23PM +0100, Steffen Nurpmeso wrote:
> j() {
> local j= a=${AWK:-awk}
> [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')( |$)/'
> j=$(jobs -l | $a -F '[][]' '/^[[]/'"$j"'{print "%" $2}{next}')
> echo $j
> }
Classic code injection
Steffen Nurpmeso wrote in
<20231109181645.bocyg%stef...@sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20231109181107.bj0wl%stef...@sdaoden.eu>:
||Steffen Nurpmeso wrote in
|| <20231109011212.tc9hj%stef...@sdaoden.eu>:
|| ...
||Something like this that would be, adding JLIST_SPEC_ONLY and
On Thu, Nov 9, 2023, 7:21 PM alex xmb sw ratchev wrote:
>
>
> On Thu, Nov 9, 2023, 7:17 PM Steffen Nurpmeso wrote:
>
>> Steffen Nurpmeso wrote in
>> <20231109181107.bj0wl%stef...@sdaoden.eu>:
>> |Steffen Nurpmeso wrote in
>> | <20231109011212.tc9hj%stef...@sdaoden.eu>:
>> | ...
>>
On Thu, Nov 9, 2023, 7:17 PM Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
> <20231109181107.bj0wl%stef...@sdaoden.eu>:
> |Steffen Nurpmeso wrote in
> | <20231109011212.tc9hj%stef...@sdaoden.eu>:
> | ...
> |Something like this that would be, adding JLIST_SPEC_ONLY and
> |jobs(1) -j.
Steffen Nurpmeso wrote in
<20231109181107.bj0wl%stef...@sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20231109011212.tc9hj%stef...@sdaoden.eu>:
| ...
|Something like this that would be, adding JLIST_SPEC_ONLY and
|jobs(1) -j. Just in case of interest.
I mean some scripting on "jobs | wc -l"
Steffen Nurpmeso wrote in
<20231109011212.tc9hj%stef...@sdaoden.eu>:
...
Something like this that would be, adding JLIST_SPEC_ONLY and
jobs(1) -j. Just in case of interest.
diff --git a/builtins/jobs.def b/builtins/jobs.def
index 1ce098d08b..989a78079e 100644
--- a/builtins/jobs.def
+++
Hello.
Well first i was thinking of a "%*" special so i can say
"kill %*", but get_job_spec() and usage does not look promising.
The task: close all jobs at once (and dreaming of
%ID1-%ID2,ID3-ID4, etc). Ie i often (really) am doing things that
require many instances of less(1), or git(1) log,
35 matches
Mail list logo
