jobs not listing all commands

jobs not listing all commands

[Felix Rosencrantz]

The jobs command seems to have a problem if there is a gap in job numbers. 
I've started noticing this recently, though it could be more because  I've
added "%j" to my prompt.  I'm running from the latest CVS.   Also, when
configuring zsh I use "--enable-max-jobtable-size=100 --enable-zsh-debug". 
Output below shows that %4 command exists, but the jobs command doesn't list it
when there is a gap in the job table...  The 

-FR.
ps also note another "bug" with "%j" and the prompt.  when the sleep finishes,
the prompt doesn't update. 

Part of my configuration:
prompt="j=%j felix@ "
alias j="jobs -l"

j=3 felix@ sleep 10 &
j=4 felix@ alias j='jobs -l'
j=4 felix@ j
[1]    28730 suspended  vim script.sh
[2]  + 29134 suspended  vim text
[3]    29443 running    sleep 10
[4]  - 29439 suspended  vim settings.sh
j=4 felix@
[3]    done       sleep 10
j=4 felix@ jobs
[1]    suspended  vim script.sh
[2]  + suspended  vim text
j=3 felix@


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Re: jobs not listing all commands

[Peter Stephenson]

Felix Rosencrantz wrote:
> The jobs command seems to have a problem if there is a gap in job numbers. 

Thanks, it was a simple off-by-one error from the last time I `improved'
the job table (with a slight recount to avoid `jobs' in a subshell from
crashing).  The actual bug was it wouldn't report the last job in the
list.  However, if the table was full that was the job running `jobs',
so you wouldn't notice.  If the table wasn't full, the `jobs' job would
go in the middle and the last one would be missing.

Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.24
diff -u -r1.24 jobs.c
--- Src/jobs.c	13 Nov 2003 14:34:38 -0000	1.24
+++ Src/jobs.c	17 Feb 2004 10:36:07 -0000
@@ -1488,14 +1488,14 @@
 	    int curmaxjob, ignorejob;
 	    if (unset(MONITOR) && oldmaxjob) {
 		jobptr = oldjobtab;
-		curmaxjob = oldmaxjob;
+		curmaxjob = oldmaxjob ? oldmaxjob - 1 : 0;
 		ignorejob = 0;
 	    } else {
 		jobptr = jobtab;
 		curmaxjob = maxjob;
 		ignorejob = thisjob;
 	    }
-	    for (job = 0; job != curmaxjob; job++, jobptr++)
+	    for (job = 0; job <= curmaxjob; job++, jobptr++)
 		if (job != ignorejob && jobptr->stat) {
 		    if ((!OPT_ISSET(ops,'r') && !OPT_ISSET(ops,'s')) ||
 			(OPT_ISSET(ops,'r') && OPT_ISSET(ops,'s')) ||

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: jobs not listing all commands

[Bart Schaefer]

Peter already patched this, but I wanted to comment on ...

On Feb 16, 11:58pm, Felix Rosencrantz wrote:
}
} ps also note another "bug" with "%j" and the prompt. when the sleep
} finishes, the prompt doesn't update.

Prompts don't update between two interactive commands, ever, no matter
what the reason.  The prompt string is computed when ZLE initializes
(just before it is first printed) and is thereafter used verbatim until
the next re-initialize.

The PS2 prompt is recomputed after each accept-line, but not while the
current line is still being edited.  So if you put %j in PS2 you can see
it change every time you hit enter with an unclosed quote or brace, but
it still doesn't change when the job status notification is printed.

Also, with respect to Peter's patch, I now get:

../../../zsh-4.0/Src/Modules/zpty.c: In function `get_pty':
../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of function `grantpt'
../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of function `unlockpt'
../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of function `ptsname'
../../../zsh-4.0/Src/Modules/zpty.c:176: warning: assignment makes pointer from integer without a cast

And during "make test", the completion tests hang forever in comptestinit.
I have to manually #undef HAVE_DEV_PTMX in config.h (I have the device but
not the library routines for manipulating it, apparently).

Re: jobs not listing all commands

[James Devenish]

In message <1040217221439.ZM12330@candle.brasslantern.com>
on Tue, Feb 17, 2004 at 10:14:39PM +0000, Bart Schaefer wrote:
> On Feb 16, 11:58pm, Felix Rosencrantz wrote:
> } ps also note another "bug" with "%j" and the prompt. when the sleep
> } finishes, the prompt doesn't update.
> Prompts don't update between two interactive commands, ever, no matter
> what the reason.  The prompt string is computed when ZLE initializes
> (just before it is first printed) and is thereafter used verbatim until
> the next re-initialize.

I'm a bit confused by both of the both comments. Firstly, %j works "as a
user would expect" for me in zsh v4.1.1 (i.e. I get the behaviour that
Felix expects). Secondly, %t, %@, %T, %*, %? (etc.) work as expected in
PS1, so why should we not expect %j to work? Thirdly, Felix demonstrated
that %j could could /up/ (i.e. the prompt *did* get updated between
interactive commands) and he was questioning why it didn't also count
/down/.

Re: jobs not listing all commands

[Wayne Davison]

On Wed, Feb 18, 2004 at 08:25:53AM +0800, James Devenish wrote:
> (i.e. the prompt *did* get updated between interactive commands) and
> he was questioning why it didn't also count /down/.

In this case the value didn't count down because the prompt just got
re-drawn after the job message.  When a redraw happens, the prompt does
not get regenerated -- it just gets sent to the screen again.  The user
has to hit return to have the prompt take on a new value that would
reflect the new number of jobs.

..wayne..

Re: jobs not listing all commands

[Bart Schaefer]

On Feb 18,  8:25am, James Devenish wrote:
} Subject: Re: jobs not listing all commands
}
} > Prompts don't update between two interactive commands, ever, no matter
} > what the reason.  The prompt string is computed when ZLE initializes
} > (just before it is first printed) and is thereafter used verbatim until
} > the next re-initialize.
} 
} I'm a bit confused by both of the both comments.

What I mean by "between two interactive commands" is "after one command
finishes (and the prompt is printed) but before the next one _begins_
(i.e. when accept-line is executed)."

The empty command is still a command for this purpose.

} Firstly, %j works "as a user would expect" for me in zsh v4.1.1 (i.e.
} I get the behaviour that Felix expects).

I suspect you really don't.  Try this:

zsh -f
% PS1='njobs:%j %'
njobs:0 % sleep 60 &
njobs:1 % sleep 10 &
njobs:2 % 

Now wait 10 seconds.  You should see:

[2]  + done       sleep 10
njobs:2 %

Note that the prompt has not changed.  If you now hit return, it should
change to:

njobs:1 %

} Secondly, %t, %@, %T, %*, %? (etc.) work as expected in PS1

I think you'll find they work the same as %j in the example above.

Re: jobs not listing all commands

[Peter Stephenson]

Bart Schaefer wrote:
> Also, with respect to Peter's patch, I now get:
> 
> ../../../zsh-4.0/Src/Modules/zpty.c: In function `get_pty':
> ../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of fun
> ction `grantpt'
> ../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of fun
> ction `unlockpt'
> ../../../zsh-4.0/Src/Modules/zpty.c:176: warning: implicit declaration of fun
> ction `ptsname'
> ../../../zsh-4.0/Src/Modules/zpty.c:176: warning: assignment makes pointer fr
> om integer without a cast
> 
> And during "make test", the completion tests hang forever in comptestinit.
> I have to manually #undef HAVE_DEV_PTMX in config.h (I have the device but
> not the library routines for manipulating it, apparently).

It's probably a case of missing headers.  It wouldn't link, or would fail
to load with an error message, if you didn't have the functions; there's
no obvious way it could hang.  In RedHat 9 and Solaris 8 the headers are
in stdlib.h (and they're certainly to hand in the other two Linux systems
I tried at home).

I'm not sure how to test for this.  Maybe it would be enough to try
compiling and linking a programme with grantpt etc., since I think
configure is sensitive to compiler warnings.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: jobs not listing all commands

[Bart Schaefer]

On Feb 18, 10:24am, Peter Stephenson wrote:
}
} It's probably a case of missing headers.  It wouldn't link, or would fail
} to load with an error message, if you didn't have the functions; there's
} no obvious way it could hang.  In RedHat 9 and Solaris 8 the headers are
} in stdlib.h (and they're certainly to hand in the other two Linux systems
} I tried at home).

Aha.  They're in <stdlib.h> but they're inside #ifdef __USE_XOPEN ... which
is defined by <features.h> only when _XOPEN_SOURCE is defined ... which is
meant to be defined directly by the user, or is defined when _GNU_SOURCE is
defined.

} I'm not sure how to test for this.  Maybe it would be enough to try
} compiling and linking a programme with grantpt etc., since I think
} configure is sensitive to compiler warnings.

While a missing-header test is probably appropriate, in this case I think
the issue is whether zsh wants to define _XOPEN_SOURCE, and if not, then
it shouldn't use /dev/ptmx even when the device exists.

Re: jobs not listing all commands

[Peter Stephenson]

Bart Schaefer wrote:
> } I'm not sure how to test for this.  Maybe it would be enough to try
> } compiling and linking a programme with grantpt etc., since I think
> } configure is sensitive to compiler warnings.
> 
> While a missing-header test is probably appropriate, in this case I think
> the issue is whether zsh wants to define _XOPEN_SOURCE, and if not, then
> it shouldn't use /dev/ptmx even when the device exists.

Some more results...

1. Defining _GNU_SOURCE seems to work OK, except there is a function
which clashes with the getline in zle_hist.c.  However, that function
doesn't seem to be used anyway.

2. That doesn't fix the problem.  It seems that the problem is the
streams modules --- I was too optimistic about them not causing problems
if they weren't needed.  We need to find out where they are needed.
I'm tempted just to limit that chunk of code to Solaris.  Does anyone
know of another system (with /dev/ptmx) which is keen on ttcompat and
friends?

One course of action:

- Define _GNU_SOURCE for Linux only --- we've got enough testers to make
it fairly painless to find out if this causes compilation problems.
(Defining _XOPEN_SOURCE directly is harder since you've got to work
out the version number.)
- Check for the function definitions, particularly ptsname(), to make
sure.
- Only let the streams stuff cause havoc on Solaris.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: jobs not listing all commands

[Felix Rosencrantz]

--- Bart Schaefer <scschaeferrbrasslanternom> wrote:
> On Feb 16, 11:58pm, Felix RoRosencrantzrote:
> } pspslso note another "bug" with "%j" and the prompt. when the sleep
> } finishes, the prompt doesn't update. 
> Prompts don't update between two interactive commands, ever, no matter
> what the reason.  The prompt string is computed when ZLZLEnitializes
> (just before it is first printed) and is thereafter used verbatim until
> the next re-initialize.

What I read is that is how it works now. I'm wondering if zszshould be changed
so that it does regenerate the prompt between commands?
-  Is there some standard that this behavior matches?
-  Do people believe this is the best/most useful behavior?
-  Would it be difficult to change zszsho regenerate the prompt when it is
redrawn (such as when job status is printed)?
- Could a redraw be forced by events such as typing through a "zlzleedraw
prompt" command within a zlzleidget?


I ask since I think it would be useful to have the prompt update on demand and
as it is redrawn.  Some examples:
- asasynchronousvents (such as jobs completing)
- ability to report on zlzletatus that could change due to typing (current vi
mode/kekeymapprediction on/off, last completer used)
-ability to do things like change directory from zlzleidgets and have the
prompt reflect a new cwcwd

-FR.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

PATCH: ptmx part 2

[Peter Stephenson]

Peter Stephenson wrote:
> One course of action:
> 
> - Define _GNU_SOURCE for Linux only --- we've got enough testers to make
> it fairly painless to find out if this causes compilation problems.
> (Defining _XOPEN_SOURCE directly is harder since you've got to work
> out the version number.)
> - Check for the function definitions, particularly ptsname(), to make
> sure.
> - Only let the streams stuff cause havoc on Solaris.

This works on RedHat 9 and Solaris 8.

The check for the ptsname() prototype is a bit of a hack, since I don't
know how to do this properly.  I declare it as int ptsname(), i.e. the
same as the implicit definition, and if that causes an error I assume it
was properly prototyped.

Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.7
diff -u -r1.7 configure.ac
--- configure.ac	18 Feb 2004 13:33:08 -0000	1.7
+++ configure.ac	20 Feb 2004 14:47:48 -0000
@@ -1802,8 +1802,6 @@
 dnl We need to open it read/write, so make sure it is writeable.
 dnl Yet another test which won't work when cross-compiling.
 dnl ---------------
-AH_TEMPLATE([HAVE_DEV_PTMX],
-[Define to 1 if your system can use /dev/ptmx for creating ptys.])
 AC_CACHE_CHECK(if your system has /dev/ptmx,
 ac_cv_have_dev_ptmx,
 [if test -w /dev/ptmx; then
@@ -1811,10 +1809,38 @@
 else
   ac_cv_have_dev_ptmx=no
 fi])
-if test $ac_cv_have_dev_ptmx = yes; then
-  AC_DEFINE(HAVE_DEV_PTMX)
+
+dnl --------
+dnl Check if the ptmx functions are usable.
+dnl We need to be able to find the prototypes, which may
+dnl require non-POSIX source definitions.  So test to see
+dnl if ptsname is correctly recognised as returning a char *.
+dnl We do this by making sure a program where ptsname() is declared
+dnl as returning int does *not* compile.
+dnl On Linux we need the XOPEN extensions.  The easiest way to get
+dnl these is by defining _GNU_SOURCE.
+dnl -------
+AH_TEMPLATE([USE_DEV_PTMX],
+[Define to 1 if all the kit for using /dev/ptmx for ptys is available.])
+if test $ac_cv_have_dev_ptmx = yes && \
+   test $ac_cv_func_grantpt = yes && \
+   test $ac_cv_func_unlockpt = yes && \
+   test $ac_cv_func_ptsname = yes; then
+   AC_CACHE_CHECK([if /dev/ptmx is usable],
+   ac_cv_use_dev_ptmx,
+   [AC_TRY_COMPILE([#ifdef __linux
+#define _GNU_SOURCE 1
+#endif
+#include <stdlib.h>
+int ptsname();], ,
+   ac_cv_use_dev_ptmx=no,
+   ac_cv_use_dev_ptmx=yes)])
+   if test $ac_cv_use_dev_ptmx = yes; then
+     AC_DEFINE(USE_DEV_PTMX)
+   fi
 fi
 
+
 dnl ---------------
 dnl dynamic loading
 dnl ---------------
Index: Src/system.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/system.h,v
retrieving revision 1.17
diff -u -r1.17 system.h
--- Src/system.h	25 Jun 2003 14:48:38 -0000	1.17
+++ Src/system.h	20 Feb 2004 14:47:49 -0000
@@ -37,6 +37,14 @@
 #endif
 #endif
 
+#ifdef __linux
+/*
+ * Turn on numerous extensions.
+ * This is in order to get the functions for manipulating /dev/ptmx.
+ */
+#define _GNU_SOURCE 1
+#endif
+
 /* NeXT has half-implemented POSIX support *
  * which currently fools configure         */
 #ifdef __NeXT__
Index: Src/Modules/zpty.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zpty.c,v
retrieving revision 1.28
diff -u -r1.28 zpty.c
--- Src/Modules/zpty.c	17 Feb 2004 13:53:40 -0000	1.28
+++ Src/Modules/zpty.c	20 Feb 2004 14:47:49 -0000
@@ -154,8 +154,7 @@
     return NULL;
 }
 
-#if defined(HAVE_DEV_PTMX) && defined(HAVE_GRANTPT) && \
-    defined(HAVE_PTSNAME) && defined(HAVE_UNLOCKPT)
+#ifdef USE_DEV_PTMX
 
 #ifdef HAVE_SYS_STROPTS_H
 #include <sys/stropts.h>
@@ -190,7 +189,7 @@
 	close(mfd);
 	return 1;
     }
-#if defined(I_FIND) && defined(I_PUSH)
+#if defined(I_FIND) && defined(I_PUSH) && defined(__SVR4)
     /*
      * Use if STREAMS is available.  The test is probably OK,
      * but we could use e.g. the sys/stropts.h test.
Index: Src/Zle/iwidgets.list
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/iwidgets.list,v
retrieving revision 1.4
diff -u -r1.4 iwidgets.list
--- Src/Zle/iwidgets.list	1 Jul 2002 09:54:48 -0000	1.4
+++ Src/Zle/iwidgets.list	20 Feb 2004 14:47:49 -0000
@@ -56,7 +56,7 @@
 "expand-word", expandword, 0
 "forward-char", forwardchar, 0
 "forward-word", forwardword, 0
-"get-line", getline, 0
+"get-line", zgetline, 0
 "gosmacs-transpose-chars", gosmacstransposechars, 0
 "history-beginning-search-backward", historybeginningsearchbackward, 0
 "history-beginning-search-forward", historybeginningsearchforward, 0
Index: Src/Zle/zle_hist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_hist.c,v
retrieving revision 1.9
diff -u -r1.9 zle_hist.c
--- Src/Zle/zle_hist.c	6 Dec 2002 23:24:07 -0000	1.9
+++ Src/Zle/zle_hist.c	20 Feb 2004 14:47:49 -0000
@@ -660,9 +660,10 @@
     return ret;
 }
 
+/* Renamed to avoid clash with library function */
 /**/
 int
-getline(char **args)
+zgetline(char **args)
 {
     char *s = (char *)getlinknode(bufstack);
 

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************