jobs -d &>/dev/null still produces output?

jobs -d &>/dev/null still produces output?

[Matt Wozniski]

I'm a bit confused by something zsh is doing.

Test case:

sleep 1000 &
jobs -d &>/dev/null

Why does this still produce output?  Is there any way to redirect the
line that's still appearing on screen?  And what on earth is the
'shout' file descriptor tied to?   :)

Thanks!

~Matt

Re: jobs -d &>/dev/null still produces output?

[Michael Hernandez]

On Nov 3, 2006, at 1:48 PM, Matt Wozniski wrote:

> I'm a bit confused by something zsh is doing.
>
> Test case:
>
> sleep 1000 &
> jobs -d &>/dev/null
>
> Why does this still produce output?  Is there any way to redirect the
> line that's still appearing on screen?  And what on earth is the
> 'shout' file descriptor tied to?   :)
>
> Thanks!
>
> ~Matt

Could be that jobs is using STERR not just STDOUT

Try redirecting STDERR, for example

lskdjf 2&>/dev/null

Produces no output (it should say "command not found" or something  
similar)

--
Mike

Fwd: jobs -d &>/dev/null still produces output?

[Matt Wozniski]

Crap, I sent this to Michael instead of the group accidentally...
Sorry Michael!

'1>' or just '>' redirects STDOUT, '2>' redirects STDERR, and '&>'
redirects both.  My test case should redirect both.  Try getting rid of the
'2' in your example and it will still give the behavior that you
described.  jobs is doing something special, and the source code just
confused me more.  :)

~Matt

On 11/3/06, Michael Hernandez <sequethin@gmail.com> wrote:
>
> On Nov 3, 2006, at 1:48 PM, Matt Wozniski wrote:
>
> > I'm a bit confused by something zsh is doing.
> >
> > Test case:
> >
> > sleep 1000 &
> > jobs -d &>/dev/null
> >
> > Why does this still produce output?  Is there any way to redirect the
> > line that's still appearing on screen?  And what on earth is the
> > 'shout' file descriptor tied to?   :)
> >
> > Thanks!
> >
> > ~Matt
>
> Could be that jobs is using STERR not just STDOUT
>
> Try redirecting STDERR, for example
>
> lskdjf 2&>/dev/null
>
> Produces no output (it should say "command not found" or something
> similar)
>
> --
> Mike
>

Re: jobs -d &>/dev/null still produces output?

[Peter Stephenson]

"Matt Wozniski" <godlygeek@gmail.com> wrote:
> I'm a bit confused by something zsh is doing.
> 
> Test case:
> 
> sleep 1000 &
> jobs -d &>/dev/null
> 
> Why does this still produce output?

The line you're seeing is the same line that would usually be produced
when, for example, you run "fg" and the process that's brought to the
foreground is running in a different directory.  Since this is purely an
interactive informational message it's directed straight to the terminal.

It's less useful when this happens in the "jobs" command, however, since in
that case the above doesn't apply and you'd expect the output to appear in
one place.  I think it would be more consistent to do what we already
do with other output and send it to stdout rather than the terminal if
it's run from "jobs".

Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.48
diff -u -r1.48 jobs.c
--- Src/jobs.c	30 Oct 2006 10:37:18 -0000	1.48
+++ Src/jobs.c	3 Nov 2006 19:41:31 -0000
@@ -954,10 +954,10 @@
 
     if ((lng & 4) || (interact && job == thisjob &&
 		      jn->pwd && strcmp(jn->pwd, pwd))) {
-	fprintf(shout, "(pwd %s: ", (lng & 4) ? "" : "now");
-	fprintdir(((lng & 4) && jn->pwd) ? jn->pwd : pwd, shout);
-	fprintf(shout, ")\n");
-	fflush(shout);
+	fprintf(fout, "(pwd %s: ", (lng & 4) ? "" : "now");
+	fprintdir(((lng & 4) && jn->pwd) ? jn->pwd : pwd, fout);
+	fprintf(fout, ")\n");
+	fflush(fout);
     }
 /* delete job if done */
 
@@ -1827,11 +1827,12 @@
 		printjob(jobtab + job, (stopped) ? -1 : lng, 1);
 	    if (func != BIN_BG) {		/* fg or wait */
 		if (jobtab[job].pwd && strcmp(jobtab[job].pwd, pwd)) {
-		    fprintf(shout, "(pwd : ");
-		    fprintdir(jobtab[job].pwd, shout);
-		    fprintf(shout, ")\n");
+		    FILE *fout = (func == BIN_JOBS) ? stdout : shout;
+		    fprintf(fout, "(pwd : ");
+		    fprintdir(jobtab[job].pwd, fout);
+		    fprintf(fout, ")\n");
+		    fflush(fout);
 		}
-		fflush(shout);
 		if (func != BIN_WAIT) {		/* fg */
 		    thisjob = job;
 		    if ((jobtab[job].stat & STAT_SUPERJOB) &&


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: jobs -d &>/dev/null still produces output?

[Matt Wozniski]

On a machine that I can't use the latest cvs on:  Is there any sort of
file descriptor magic that I can use to work around this and get it to
send that to somewhere other than the terminal, or am I just stuck
with its current behavior?

On 11/3/06, Peter Stephenson <pws@csr.com> wrote:
> "Matt Wozniski" <godlygeek@gmail.com> wrote:
> > I'm a bit confused by something zsh is doing.
> >
> > Test case:
> >
> > sleep 1000 &
> > jobs -d &>/dev/null
> >
> > Why does this still produce output?
>
> The line you're seeing is the same line that would usually be produced
> when, for example, you run "fg" and the process that's brought to the
> foreground is running in a different directory.  Since this is purely an
> interactive informational message it's directed straight to the terminal.
>
> It's less useful when this happens in the "jobs" command, however, since in
> that case the above doesn't apply and you'd expect the output to appear in
> one place.  I think it would be more consistent to do what we already
> do with other output and send it to stdout rather than the terminal if
> it's run from "jobs".
>
> Index: Src/jobs.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
> retrieving revision 1.48
> diff -u -r1.48 jobs.c
> --- Src/jobs.c  30 Oct 2006 10:37:18 -0000      1.48
> +++ Src/jobs.c  3 Nov 2006 19:41:31 -0000
> @@ -954,10 +954,10 @@
>
>      if ((lng & 4) || (interact && job == thisjob &&
>                       jn->pwd && strcmp(jn->pwd, pwd))) {
> -       fprintf(shout, "(pwd %s: ", (lng & 4) ? "" : "now");
> -       fprintdir(((lng & 4) && jn->pwd) ? jn->pwd : pwd, shout);
> -       fprintf(shout, ")\n");
> -       fflush(shout);
> +       fprintf(fout, "(pwd %s: ", (lng & 4) ? "" : "now");
> +       fprintdir(((lng & 4) && jn->pwd) ? jn->pwd : pwd, fout);
> +       fprintf(fout, ")\n");
> +       fflush(fout);
>      }
>  /* delete job if done */
>
> @@ -1827,11 +1827,12 @@
>                 printjob(jobtab + job, (stopped) ? -1 : lng, 1);
>             if (func != BIN_BG) {               /* fg or wait */
>                 if (jobtab[job].pwd && strcmp(jobtab[job].pwd, pwd)) {
> -                   fprintf(shout, "(pwd : ");
> -                   fprintdir(jobtab[job].pwd, shout);
> -                   fprintf(shout, ")\n");
> +                   FILE *fout = (func == BIN_JOBS) ? stdout : shout;
> +                   fprintf(fout, "(pwd : ");
> +                   fprintdir(jobtab[job].pwd, fout);
> +                   fprintf(fout, ")\n");
> +                   fflush(fout);
>                 }
> -               fflush(shout);
>                 if (func != BIN_WAIT) {         /* fg */
>                     thisjob = job;
>                     if ((jobtab[job].stat & STAT_SUPERJOB) &&
>
>
> To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php
>

Re: jobs -d &>/dev/null still produces output?

[Peter Stephenson]

On Fri, 3 Nov 2006 14:59:07 -0500
"Matt Wozniski" <godlygeek@gmail.com> wrote:
> On 11/3/06, Peter Stephenson <pws@csr.com> wrote:
> > "Matt Wozniski" <godlygeek@gmail.com> wrote:
> > > sleep 1000 &
> > > jobs -d &>/dev/null
> > >
> > > Why does this still produce output?
> >
> > The line you're seeing is the same line that would usually be produced
> > when, for example, you run "fg" and the process that's brought to the
> > foreground is running in a different directory.  Since this is purely an
> > interactive informational message it's directed straight to the terminal.
>
> On a machine that I can't use the latest cvs on:  Is there any sort of
> file descriptor magic that I can use to work around this and get it to
> send that to somewhere other than the terminal, or am I just stuck
> with its current behavior?

I can't think of anything you can do in the shell:  it's hard-wired to
the terminal so you would somehow have to persuade the output to come back
from it.  There's no use using a pseudoterminal since you can't change
the terminal of the shell that's actually running... unless there's some
fiendishly clever trick using the zsh/clone module of cloning the shell
into a new pseudoterminal.  I couldn't get this to work with zsh/zpty since
(I think) clone doesn't get passed the new terminal early enough.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/