Re: `jobs' builtin does not work with pipe in scripts

[ZyX <zyx.vim@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 2139 bytes --]

Reply to message «Re: `jobs' builtin does not work with pipe in scripts», 
sent 04:37:18 28 November 2010, Sunday
by Bart Schaefer:

> Hmm, previously you reported yours as "zsh-4.3.10-r2" but I can't find
> evidence that this was ever an official zsh version number.  There were
> a bunch of changes to the handling of MONITOR in July 2009, which is a
> bit after 4.3.10 was released.  That's also around the time that the
> POSIX_JOBS option was added, and is the last time job control was being
> changed in any noticeable way.

-r2 in gentoo means that maintainer(s) had two times done something that 
requires package update, but have not changed mainstream version they are using. 
So zsh-4.3.10-r2 is zsh-4.3.10 with two ebuild updates. More information can be 
found here: http://devmanual.gentoo.org/general-concepts/ebuild-revisions/. 
Quote:
> Ebuilds may have a Gentoo revision number associated with them. This is a -rX
> suffix, where X is an integer — see File Naming Rules. This component must
> only be used for Gentoo changes, not upstream releases. By default, -r0 is
> implied. 
>
> Ebuilds should have their -rX incremented whenever a change is made which will
> make a substantial difference to what gets installed by the package — by
> substantial, we generally mean "something for which many users would want to
> upgrade". This is usually for bugfixes.
>
> Simple compile fixes do not warrant a revision bump; this is because they do
> not affect the installed package for users who already managed to compile it.
> Small documentation fixes are also usually not grounds for a new revision.


> However, depending on what you want to do with the output, there are
> two other ways to go about this.  One is to use the $jobstates hash
> from the zsh/parameter module, which maps job numbers to strings that
> describe the state.  Another is to use "jobs -p >>(...)" to keep the
> jobs command in the foreground shell and manipulate its output in a
> subshell.  An third is to direct output from jobs into a file, then
> read the file.
Thanks, jobstates works just fine.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]