fg call in function: bug?

fg call in function: bug?

[Matt Wozniski]

If I run 'fg %n' with a job number that doesn't exist, it has
different (and worse) effects in a function than at a prompt.  (Sorry
if this has been fixed in CVS... Ubuntu Dapper doesn't have a package
past 4.2.5 yet.. ;) )

SpyderByte%   zsh -f
SpyderByte%   jobs

SpyderByte%   fg %1
fg: %1: no such job

SpyderByte%   test() { fg %1 }
SpyderByte%   test
test: can't set tty pgrp: operation not permitted

SpyderByte%   fg %1
fg: no job control in this shell.

SpyderByte%   zsh --version
zsh 4.2.5 (i686-pc-linux-gnu)

~Matt

fg call in function: bug?

[Matt Wozniski]

Ok, I have an even weirder test case for the "job control in cursh
construct" bug... No arguments, %-, %+, and even %2 work as expected,
but %1 doesn't?

~>{ jobs }
~>jobs
~>
~>{ jobs %- }
jobs: no previous job
~>jobs %-
jobs: no previous job
~>
~>{ jobs %+ }
jobs: no current job
~>jobs %+
jobs: no current job
~>
~>{ jobs %1 }
~>jobs %1
jobs: %1: no such job
~>
~>{ jobs %2 }
jobs: %2: no such job

~Matt
~>jobs %2
jobs: %2: no such job

Re: fg call in function: bug?

[Bart Schaefer]

On Nov 3,  4:39pm, Matt Wozniski wrote:
}
} SpyderByte%   test() { fg %1 }
} SpyderByte%   test
} test: can't set tty pgrp: operation not permitted

On Nov 3,  5:15pm, Matt Wozniski wrote:
} Subject: fg call in function: bug?
}
} ~>{ jobs %1 }
} ~>jobs %1
} jobs: %1: no such job

I believe both of these are happening because the { } construct creates
a job table entry, which (in the first case) is attempting to put itself
into the foreground when it already is, and (in the second case) is
reporting nothing about itself.

Re: fg call in function: bug?

[Matt Wozniski]

Crap.  I sent this to Bart at first.  My apologies, Bart.

If that were the case, wouldn't you expect to see different output
between "jobs" and "{ jobs }"?

~Matt

On 11/3/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 3,  4:39pm, Matt Wozniski wrote:
> }
> } SpyderByte%   test() { fg %1 }
> } SpyderByte%   test
> } test: can't set tty pgrp: operation not permitted
>
> On Nov 3,  5:15pm, Matt Wozniski wrote:
> } Subject: fg call in function: bug?
> }
> } ~>{ jobs %1 }
> } ~>jobs %1
> } jobs: %1: no such job
>
> I believe both of these are happening because the { } construct creates
> a job table entry, which (in the first case) is attempting to put itself
> into the foreground when it already is, and (in the second case) is
> reporting nothing about itself.
>

Re: fg call in function: bug?

[Bart Schaefer]

On Nov 3,  6:58pm, Matt Wozniski wrote:
}
} If that were the case, wouldn't you expect to see different output
} between "jobs" and "{ jobs }"?

No ... I believe the code takes a different branch when there is a
job number specified as opposed to when it's asked to list all jobs.

Re: fg call in function: bug?

[Peter Stephenson]

"Matt Wozniski" <godlygeek@gmail.com> wrote:
> Ok, I have an even weirder test case for the "job control in cursh
> construct" bug... No arguments, %-, %+, and even %2 work as expected,
> but %1 doesn't?
> 
> ~>{ jobs %1 }
> ~>jobs %1
> jobs: %1: no such job

Just to complete the story...  "jobs" on its own is simply a builtin and
doesn't cause the special logic to create a pseudojob, while in braces it
becomes a construct that gets special handling.  It's usually job 1 because that's
the first that's free; as it's special it doesn't cause %- or %+ to be set.

This is fixed by the patch that I just posted, but I noticed that the form
of error is different for no good reason, so I'll put that right, too.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.104
diff -u -r1.104 exec.c
--- Src/exec.c	17 Sep 2006 19:28:46 -0000	1.104
+++ Src/exec.c	6 Nov 2006 12:24:04 -0000
@@ -2265,7 +2265,7 @@
 	/* This is a current shell procedure that didn't need to fork.    *
 	 * This includes current shell procedures that are being exec'ed, *
 	 * as well as null execs.                                         */
-	jobtab[thisjob].stat |= STAT_CURSH;
+	jobtab[thisjob].stat |= STAT_CURSH|STAT_NOPRINT;
     } else {
 	/* This is an exec (real or fake) for an external command.    *
 	 * Note that any form of exec means that the subshell is fake *
Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.49
diff -u -r1.49 jobs.c
--- Src/jobs.c	3 Nov 2006 19:44:47 -0000	1.49
+++ Src/jobs.c	6 Nov 2006 12:24:05 -0000
@@ -1771,7 +1771,7 @@
 	}
 	if (!(jobtab[job].stat & STAT_INUSE) ||
 	    (jobtab[job].stat & STAT_NOPRINT)) {
-	    zwarnnam(name, "no such job: %d", job);
+	    zwarnnam(name, "%%%d: no such job", job);
 	    unqueue_signals();
 	    return 1;
 	}

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


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

Re: fg call in function: bug?

[Peter Stephenson]

"Matt Wozniski" <mjw452@drexel.edu> wrote:
> If I run 'fg %n' with a job number that doesn't exist, it has
> different (and worse) effects in a function than at a prompt.  (Sorry
> if this has been fixed in CVS... Ubuntu Dapper doesn't have a package
> past 4.2.5 yet.. ;) )

I think this is most easily fixed by telling the code to ignore jobs in the
current shell for the purpose of job control; they're fictions to make
special effects easier.  I can't offhand see this is going to cause any
problems, but we'll just have to see.  Certainly you wouldn't expect to
be able to do job control on them.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.104
diff -u -r1.104 exec.c
--- Src/exec.c	17 Sep 2006 19:28:46 -0000	1.104
+++ Src/exec.c	6 Nov 2006 12:18:31 -0000
@@ -2265,7 +2265,7 @@
 	/* This is a current shell procedure that didn't need to fork.    *
 	 * This includes current shell procedures that are being exec'ed, *
 	 * as well as null execs.                                         */
-	jobtab[thisjob].stat |= STAT_CURSH;
+	jobtab[thisjob].stat |= STAT_CURSH|STAT_NOPRINT;
     } else {
 	/* This is an exec (real or fake) for an external command.    *
 	 * Note that any form of exec means that the subshell is fake *



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