zsh: Strange feature with 'jobs' commmand

zsh: Strange feature with 'jobs' commmand

[Björn Johannesson]

Hi.

If you start a few jobs in the background and do:
zsh% jobs
[1]  - running    xmixer
[2]  + running    gtcd
zsh% _

ok, this is expected but this is not...
zsh% jobs | less
(END)
zsh% _

Why? This is quite annoying. You do not get any output if you pipe the
results from the "jobs" command. (jobs 2>&1|less doesn't work either)

(zsh is v4.0.4 and the same result on Linux-2.4(i386) and Solaris
 8(sparc))

-- 
Nej, jag är inte glad. Varför är du?

Re: zsh: Strange feature with 'jobs' commmand

[Oliver Kiddle]

On 30 May, you wrote:
> 
> If you start a few jobs in the background and do:
> zsh% jobs
> [1]  - running    xmixer
> [2]  + running    gtcd
> zsh% _
> 
> ok, this is expected but this is not...
> zsh% jobs | less
> (END)
> zsh% _
> 
> Why? This is quite annoying. You do not get any output if you pipe the
> results from the "jobs" command. (jobs 2>&1|less doesn't work either)

What is happening is that jobs is being run in a subshell. The subshell
doesn't inherit the child processes (i.e. the jobs) so when jobs runs it
doesn't find any to list.

We could do with a mention of this in the FAQ (unless it is there
already and my quick grep missed it).

Incidentally, I think bash special cases the jobs builtin and would
run less in a subshell in this case instead. Could we do something like
this in zsh?

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

$jobstates (Re: zsh: Strange feature with 'jobs' commmand)

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

Hi,

Björn Johannesson wrote [020530 14:12]:
> Hi.
> 
> If you start a few jobs in the background and do:
> zsh% jobs
> [1]  - running    xmixer
> [2]  + running    gtcd
> zsh% _
> 
> ok, this is expected but this is not...
> zsh% jobs | less
> (END)
> zsh% _
> 
> Why? This is quite annoying. You do not get any output if you pipe the
> results from the "jobs" command. (jobs 2>&1|less doesn't work either)

I don't remember exactly why this is the case (you might find
something in the archives), but you can get the information via
the $jobstates associative array.

echo $jobstates | less

What I don't understand from "man zshparam":

       k      If  used  in  a  subscript on an associative array,
              this flag causes the keys to be interpreted as pat­
              terns,  and  returns  the  value  for the first key
              found where exp is matched by the key.   This  flag
              does  not work on the left side of an assignment to
              an associative array element.  If used  on  another
              type of parameter, this behaves like `r'.

       K      On  an  associative  array  this  is  like  `k' but
              returns all values where  exp  is  matched  by  the
              keys.   On  other  types of parameters this has the
              same effect as `R'.

Why doesn't
   ~> echo $jobstates[(K)*]
return anything when
   ~> echo $jobstates[*]
   running::6179=running running:-:6193=running running:+:6207=running
returns a few jobs?
   ~> echo $jobstates[1]
   running::6179=running
also works fine. I would suppose
   ~> echo $jobstates[(K)*]
   1 2 3
or something similar...

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: zsh: Strange feature with 'jobs' commmand

[Borsenkow Andrej]

On Thu, 30 May 2002, Oliver Kiddle wrote:

>
> Incidentally, I think bash special cases the jobs builtin and would
> run less in a subshell in this case instead. Could we do something like
> this in zsh?
>

IIRC bash runs right part of every pipe in subshell. We run left pipe.
This makes it possible to do something like

foo | read FOO_RESULT

that assigns return value of foo to FOO_RESULT. It does not work in bash.
Just how useful (often used) this feature is is different qustion :-)

Anyway, I am afraid, changing it requires quite a major rewrite. And in
current zsh you have jobstates and jobtexts arrays that make 'jobs | less'
hardly ever needed.

-andrej

Re: $jobstates (Re: zsh: Strange feature with 'jobs' commmand)

[Sven Wischnowsky]

Thomas Köhler wrote:

> ...
> 
> What I don't understand from "man zshparam":
> 
>        k      If  used  in  a  subscript on an associative array,
>               this flag causes the keys to be interpreted as pat­
>               terns,  and  returns  the  value  for the first key
>               found where exp is matched by the key.   This  flag
>               does  not work on the left side of an assignment to
>               an associative array element.  If used  on  another
>               type of parameter, this behaves like `r'.
> 
>        K      On  an  associative  array  this  is  like  `k' but
>               returns all values where  exp  is  matched  by  the
>               keys.   On  other  types of parameters this has the
>               same effect as `R'.
> 
> Why doesn't
>    ~> echo $jobstates[(K)*]
> return anything when [...]

You want (i):

  % echo $jobstates[(i)*]
  1 2 ...

With k and K the *keys* stored in the assoc (as opposed to the *exp*
given in the subscript) are used as patterns:

  % typeset -A type
  % type=('[a-zA-Z]' alpha '[0-9]' digit '[^a-zA-Z0-9]' other)
  % echo $type[(k)x] $type[(k)4] $type[(k).]
  alpha digit other


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: $jobstates (Re: zsh: Strange feature with 'jobs' commmand)

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Sven Wischnowsky wrote [020530 14:49]:
> Thomas Köhler wrote:
> 
> > ...
> > What I don't understand from "man zshparam":
[...]
> > Why doesn't
> >    ~> echo $jobstates[(K)*]
> > return anything when [...]
> 
> You want (i):
> 
>   % echo $jobstates[(i)*]
>   1 2 ...
> 
> With k and K the *keys* stored in the assoc (as opposed to the *exp*
> given in the subscript) are used as patterns:
> 
>   % typeset -A type
>   % type=('[a-zA-Z]' alpha '[0-9]' digit '[^a-zA-Z0-9]' other)
>   % echo $type[(k)x] $type[(k)4] $type[(k).]
>   alpha digit other

Aaaaahh, silly me. Now I understand :-)

Now, for the original problem... Uhm. Tricky. any better ideas?

jless() {
   typeset -x -A tmpstates
   for i in $jobstates[(I)*] 
   do
      tmpstates[$i]=$jobstates[$i]
   done
   for i in $tmpstates[(I)*]
   do
      echo "[$i]\t$tmpstates[$i]"
   done  | sort -n |  less
   unset tmpstates
}

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: zsh: Strange feature with 'jobs' commmand

[Phil Pennock]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On 2002-05-30 at 16:37 +0400, Borsenkow Andrej wrote:
> IIRC bash runs right part of every pipe in subshell. We run left pipe.
> This makes it possible to do something like
> 
> foo | read FOO_RESULT
> 
> that assigns return value of foo to FOO_RESULT. It does not work in bash.
> Just how useful (often used) this feature is is different qustion :-)

Useful, and I use it more often than I'd like, given the sort of things
I end up having to use it for -- killing recalcitrant processes.

Constructs for getting PID listings and storing them in an array, for
later iteration, etc.

Since my employer doesn't have zsh installed by default, except on
machines installed within the last few months (*ahem* guess who wrote
the new installation procedure?), I often end up having to move to Perl.

Some tasks _can_ be done in bash, messing around with extra subshells,
but it gets grotty fast.

zsh keeping the RHS as the parent lets me do a lot of sysadmin tasks
more fluently than using bash or dropping to Perl.
-- 
Compounding the problem are people who insist on confusing "problems with
executable MIME attachments" with "problems with all MIME attachments because
one vendor ships a product that will execute anything that resembles ones and
zeros more than my goldfish does".  -- Valdis Kletnieks

[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]