Preliminary release of 3.0.8 - please test

Preliminary release of 3.0.8 - please test

[Bart Schaefer]

I realize most people on this list are now using 3.1.6-dev-19, but it'd
be helpful to me if a few people could grab this and at least report any
build-time errors.  Several of the changes are to the configure scripts,
and I have only Linux to test on.

	ftp://ftp.brasslantern.com/pub/zsh/zsh-3.0.8.tar.gz

Note that I haven't updated the doc.tar yet, but there's only one minor
change to that.  I'll update everything and make an official announcement
after I either hear that it looks OK, or a few days pass with no response
at all ...

Here are the new ChangeLog entries since the 3.0.7 release:

2000-02-27  Bart Schaefer  <schaefer@zsh.org>

	* Src/version.h: Version 3.0.8 released.
	
	* Src/builtin.c: Fixes to `vared', particularly when run from a
	subshell; adapted from PWS, 7308, and Sven, 8591.

	* configure.in, configure, acconfig.h, config.h.in,
	Src/prototypes.h: Add test for mknod() prototype, per bug report
	from Olivier Delemar.

	* Src/exec.c, Src/globals.h, Src/init.c, Src/builtin.c: Fix
	improper redirection of xtrace output; unlock terminal device on
	Solaris as per zsh-workers/5118; misc. insignificant typos.

2000-02-23  Bart Schaefer  <schaefer@zsh.org>

	* config.sub: Handle the latest Alpha hardware type; Sven, 9840.

2000-02-16  Bart Schaefer  <schaefer@zsh.org>

	* Src/subst.c: Better quoting behavior for ${(e)...}
	substitutions; from Sven, 9763.

2000-02-15  Bart Schaefer  <schaefer@zsh.org>

	* Src/signames.awk: Missing newline.

	* Src/jobs.c, Src/signames.awk: Wrap signal message array derefs
	in a macro to avoid segfaults in the event we recieve an
	unrecognized signal.

2000-02-13  Bart Schaefer  <schaefer@zsh.org>

	* configure.in, configure: Import the 3.1.6 signal.h (or
	equivalent) detection code.

	* Etc/MACHINES: Mention potential resource.h problem on Linux.

2000-02-12  Bart Schaefer  <schaefer@zsh.org>

	* Src/init.c: Redo the way we attach to the tty in init_io() to
	avoid competing with our parent on systems that don't prevent TTY
	ioctl()s from background jobs.

2000-02-06  Bart Schaefer  <schaefer@zsh.org>

	* Src/builtin.c: Clear the PM_UNSET flag from the `pm' structure
	before setting the parameter; PWS, 9582.

2000-02-03  Bart Schaefer  <schaefer@zsh.org>

	* Src/utils.c: Interrupt read1char() when any of the usual shell
	loop control flags becomes set (e.g. by a trap handler); Sven,
	9522.

	* Src/exec.c: A different reformulation of 9345; based on Sven,
	9503 and 9521.

2000-01-29  Bart Schaefer  <schaefer@zsh.org>

	* Src/globals.h: Add a missing EXTERN.

	* Src/globals.h, Src/jobs.c, Src/zsh.h, Src/builtin.c, Src/exec.c:
	Fixes for suspending/restarting subshells; adapted from Sven, 9345.

2000-01-12  Bart Schaefer  <schaefer@zsh.org>

	* Src/loop.c: Fix behavior of "select" loops with respect to
	reading stdin; adapted from PWS, 9295.

2000-01-08  Bart Schaefer  <schaefer@zsh.org>

	* Src/loop.c: Using a negative count with the "repeat" construct
	should not loop.  Adapted from Sven, 9188.

1999-12-12  Bart Schaefer  <schaefer@zsh.org>

	* Src/exec.c: Don't try to suspend/resume loops and other shell
	constructs as separate processes when the parent shell is not
	doing job control in the first place.

1999-11-25  Bart Schaefer  <schaefer@zsh.org>

	* Src/lex.c: Fix off-by-one line number when reporting unmatched
	cshjunkiequote errors.

1999-11-24  Bart Schaefer  <schaefer@zsh.org>

	* Src/signals.c: Just for sanity, be sure not to SIGHUP ourself
	when already exiting.

1999-10-25  Bart Schaefer  <schaefer@zsh.org>

	* Src/system.h, Src/hashtable.h, Src/init.c, Src/params.c,
	INSTALL, acconfig.h, configure.in, configure, config.h.in:
	Configure option to disable setlocale() support, and also do a
	linkage test for it rather than simply test for the LC_ALL
	constant; adapted from Zefram, 8372, by Tatsuo Furukawa.

1999-10-24  Bart Schaefer  <schaefer@zsh.org>

	* Makefile.in: Don't bother trying to enumerate all the files in
	the ftp-dist tar, just pack up the whole zsh-$(VERSION) directory.
	The enumeration caused files in subdirectories to be included
	twice by tar.

1999-10-23  Bart Schaefer  <schaefer@zsh.org>

	* Src/zle_misc.c, Doc/zshparam.man: Add the %L prompt token, for
	the value of SHLVL, as in 3.1.6; thanks to Phil Pennock
	<phil@PsiDev.net> for pointing out this inconsistency.

1999-10-22  Bart Schaefer  <schaefer@zsh.org>

	* Src/mem.c: Fix a couple of typos in comments.

1999-10-19  Bart Schaefer  <schaefer@zsh.org>

	* Src/utils.c: Remove redundant variable decls; noted by Albert
	Chin in 8327.

	* Src/builtin.c: Tweak whitespace in string constant.

	* Src/builtin.c: Recognize "maxpthreads" limit as noted by Albert
	Chin in private mail; also arrange to print the "sockbufsize"
	limit in "ulimit -a".

	* Src/rlimits.awk: Recognize "maxpthreads" limit as noted by
	Albert Chin in private mail.


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Preliminary release of 3.0.8 - please test

[Geoff Wing]

Bart Schaefer <schaefer@candle.brasslantern.com> typed:
:I realize most people on this list are now using 3.1.6-dev-19, but it'd
:be helpful to me if a few people could grab this and at least report any
:build-time errors.  Several of the changes are to the configure scripts,
:and I have only Linux to test on.

Builds OK on NetBSD 1.4T (i386).  Haven't done much testing yet.

If you feel the urge, you might want to update
    Etc/NEWS		(if appropriate)
    Etc/CONTRIBUTORS	(which would also need to be updated in 3.1.6-dev*)

Also, last section of Etc/BUGS says:
    ------------------------------------------------------------------------
    Numeric ranges are still too greedy with using characters; for example,
    <1-1000>33 will not match 633 because the 633 matches the range.  Some
    backtracking will be necessary.
    ------------------------------------------------------------------------
Maybe make a note that this is fixed (according to some basic testing I did)
in the current development version (even though it still appears in the BUGS
file there).  I suspect it's a big change which isn't appropriate to roll
into 3.0.* but don't know for sure.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Preliminary release of 3.0.8 - please test

[Jos Backus]

On FreeBSD -current, I dropped the tarfile in the distfiles dir, changed the
port Makefile and checksum file and did a make. This gave

utils.o: In function `gettempname':
utils.o(.text+0x1bfa): warning: mktemp() possibly used unsafely; consider
using mkstemp()

and

./zsh.texi:1069: warning: unlikely character [ in @var.
./zsh.texi:1069: warning: unlikely character ] in @var.
./zsh.texi:1573: warning: `.' or `,' must follow cross reference, not ).

I'm running it as my shell now. Seems to work just fine so far.

Thanks,
-- 
Jos Backus                          _/ _/_/_/  "Reliability means never
                                   _/ _/   _/   having to say you're sorry."
                                  _/ _/_/_/             -- D. J. Bernstein
                             _/  _/ _/    _/
Jos.Backus@nl.origin-it.com  _/_/  _/_/_/      use Std::Disclaimer;

Re: Preliminary release of 3.0.8 - please test

[Geoff Wing]

Geoff Wing <mason@primenet.com.au> typed:
:Bart Schaefer <schaefer@candle.brasslantern.com> typed:
::I realize most people on this list are now using 3.1.6-dev-19, but it'd
::be helpful to me if a few people could grab this and at least report any
::build-time errors.  Several of the changes are to the configure scripts,
::and I have only Linux to test on.
:Builds OK on NetBSD 1.4T (i386).  Haven't done much testing yet.

After some initial usage, got it into a state of:
% %
fg: no such job: 3
% %%
fg: no such job: 3
% fg
fg: no current job
% jobs
%

Will see if I can reproduce.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Preliminary release of 3.0.8 - please test

[Bart Schaefer]

On Feb 29, 10:33am, Geoff Wing wrote:
} Subject: Re: Preliminary release of 3.0.8 - please test
}
} After some initial usage, got it into a state of:
} % %
} fg: no such job: 3
} % %%
} fg: no such job: 3
} % fg
} fg: no current job
} % jobs
} %

Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
can get 3.0.8 into that state theres a problem for 3.1.6 as well.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Preliminary release of 3.0.8 - please test

[Geoff Wing]

Bart Schaefer <schaefer@candle.brasslantern.com> typed:
:On Feb 29, 10:33am, Geoff Wing wrote:
:} Subject: Re: Preliminary release of 3.0.8 - please test
:} After some initial usage, got it into a state of:
:} % %
:} fg: no such job: 3
:} % %%
:} fg: no such job: 3
:} % fg
:} fg: no current job
:} % jobs
:} %
:Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
:can get 3.0.8 into that state theres a problem for 3.1.6 as well.

I'm thinking that getjob() may need a setcurjob() before it checks curjob.

builtin.c:bin_fg() has
    ....
    /* If necessary, update job table. */
        if (unset(NOTIFY))
            scanjobs();
        setcurjob();
    ....
    if (!*argv) {
        if (func == BIN_FG || func == BIN_BG || func == BIN_DISOWN) {
            if (curjob == -1 || (jobtab[curjob].stat & STAT_NOPRINT)) {
                zwarnnam(name, "no current job", NULL, 0);                
    ....

builtin.c:getjob() has
    ....
    if (*s == '%' || *s == '+' || !*s) {
        if (curjob == -1) {
            zwarnnam(prog, "no current job", NULL, 0);
    ....

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

[Bart Schaefer]

On Mar 3,  2:55am, Geoff Wing wrote:
} Subject: Re: Preliminary release of 3.0.8 - please test
}
} Bart Schaefer <schaefer@candle.brasslantern.com> typed:
} :On Feb 29, 10:33am, Geoff Wing wrote:
} :} Subject: Re: Preliminary release of 3.0.8 - please test
} :} After some initial usage, got it into a state of:
} :} % %
} :} fg: no such job: 3
} :} % %%
} :} fg: no such job: 3
} :} % fg
} :} fg: no current job
} :} % jobs
} :} %
} :Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
} :can get 3.0.8 into that state theres a problem for 3.1.6 as well.
} 
} I'm thinking that getjob() may need a setcurjob() before it checks curjob.

Since Sven has been incommunicado for a couple of days, I tried to look
into this myself in more detail.  The only two places where getjob() is
called are from bin_kill(), and from bin_fg() *after* the setcurjob()
that you noted.

I can believe that a race condition might cause "no such job: 3" once,
but twice in a row is impossible.  So the only possible answer is that
the one and only job has STAT_NOPRINT set but *not* STAT_SUBJOB, which
in turn happens only at exec.c:768 and 806 (in 3.0.8; in 3.1.6-dev-19,
exec.c:993 and 1031), both in execpline().  See jobs.c:setprevjob(),
which is called from setcurjob().

Now, it may be that the right solution is to have setprevjob() ignore
jobs that have STAT_NOPRINT set, but I wouldn't want that to mask some
more serious job-state problem.  If you have any insights, share 'em.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Preliminary release of 3.0.8 - please test

[Brian Boonstra]

Hi Bart

	I know it's been a while since you asked, but 3.0.8 seems to build  
and run fine on OpenStep 4.2 using gcc.
	
	
		- Brian

You wrote:
> I realize most people on this list are now using 3.1.6-dev-19, but it'd
> be helpful to me if a few people could grab this and at least report any
> build-time errors.  Several of the changes are to the configure scripts,
> and I have only Linux to test on.
>
> <ftp://ftp.brasslantern.com/pub/zsh/zsh-3.0.8.tar.gz
>

Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

[Geoff Wing]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
:Geoff, do you remember what you did before you got that message? Did
:you kill some job/process? What (kind of) commands did you suspend?
:Pipes with lists in them, commands that do some kind of signal
:handling? (Yes, I'm guessing wildly...)

Job 2 was vim; job 1 was make (BSD make ~= pmake) or maybe another
vim job.  I've got no memory of running a third job, though it may
have been something like ``cvs log <somefile> | less'' or
``cvs status |& fgrep Status | fgrep -v Up-to''.  I'm sure I never
had four jobs going.  Unfortunately I didn't attach a debugger or
core dump it so I have no ability to query values from it in that
state.  It's very rare (obviously) though I've either got deja vu
or I've seen it before at least once (and it would have been quite
a while ago (a year? more maybe) so I suspect it's not from any
recent changes).

Regards,
-- 
Geoff Wing : <gcw@pobox.com>     Work URL: http://www.primenet.com.au/
Rxvt Stuff : <gcw@rxvt.org>      Ego URL : http://pobox.com/~gcw/
Zsh Stuff  : <gcw@zsh.org>       Phone   : (Australia) 0413 431 874

Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

[Sven Wischnowsky]

I wrote:

> Bart Schaefer wrote:
> 
> ...
> > 
> > I can believe that a race condition might cause "no such job: 3" once,
> > but twice in a row is impossible.  So the only possible answer is that
> > the one and only job has STAT_NOPRINT set but *not* STAT_SUBJOB, which
> > in turn happens only at exec.c:768 and 806 (in 3.0.8; in 3.1.6-dev-19,
> > exec.c:993 and 1031), both in execpline().  See jobs.c:setprevjob(),
> > which is called from setcurjob().
> 
> The one in 1031 isn't interesting here, it only makes the sub-shells
> created for stopped lists not report their jobs (list_pipe_child is
> non-zero only in those sub-shells). Leaves us with the one in 993.
> This is used to make sure that jobs started for commands which are
> not the first one in a pipeline and jobs started from some kind of 
> pipeline nesting (e.g. in a loop in a pipeline) are not shown.
> 
> Given that, your suggestion:
> 
> > Now, it may be that the right solution is to have setprevjob() ignore
> > jobs that have STAT_NOPRINT set, but I wouldn't want that to mask some
> > more serious job-state problem.  If you have any insights, share 'em.
> 
> seems sensible. But... how can such a job survive when the super-job
> of the (main) pipeline is dead? I wished I could find a way to
> reproduce it.

I've played some more yesterday evening/night but still couldn't get
it to happen (with dev-19, that is).

Geoff, do you remember what you did before you got that message? Did
you kill some job/process? What (kind of) commands did you suspend?
Pipes with lists in them, commands that do some kind of signal
handling? (Yes, I'm guessing wildly...)


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Bogus "no such job" (Re: Preliminary release of 3.0.8 - please test)

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 3,  2:55am, Geoff Wing wrote:
> } Subject: Re: Preliminary release of 3.0.8 - please test
> }
> } Bart Schaefer <schaefer@candle.brasslantern.com> typed:
> } :On Feb 29, 10:33am, Geoff Wing wrote:
> } :} Subject: Re: Preliminary release of 3.0.8 - please test
> } :} After some initial usage, got it into a state of:
> } :} % %
> } :} fg: no such job: 3
> } :} % %%
> } :} fg: no such job: 3
> } :} % fg
> } :} fg: no current job
> } :} % jobs
> } :} %
> } :Hrm.  The job handling code is now identical to 3.1.6-dev-19, so if you
> } :can get 3.0.8 into that state theres a problem for 3.1.6 as well.
> } 
> } I'm thinking that getjob() may need a setcurjob() before it checks curjob.
> 
> Since Sven has been incommunicado for a couple of days, I tried to look
> into this myself in more detail.  The only two places where getjob() is
> called are from bin_kill(), and from bin_fg() *after* the setcurjob()
> that you noted.
> 
> I can believe that a race condition might cause "no such job: 3" once,
> but twice in a row is impossible.  So the only possible answer is that
> the one and only job has STAT_NOPRINT set but *not* STAT_SUBJOB, which
> in turn happens only at exec.c:768 and 806 (in 3.0.8; in 3.1.6-dev-19,
> exec.c:993 and 1031), both in execpline().  See jobs.c:setprevjob(),
> which is called from setcurjob().

The one in 1031 isn't interesting here, it only makes the sub-shells
created for stopped lists not report their jobs (list_pipe_child is
non-zero only in those sub-shells). Leaves us with the one in 993.
This is used to make sure that jobs started for commands which are
not the first one in a pipeline and jobs started from some kind of 
pipeline nesting (e.g. in a loop in a pipeline) are not shown.

Given that, your suggestion:

> Now, it may be that the right solution is to have setprevjob() ignore
> jobs that have STAT_NOPRINT set, but I wouldn't want that to mask some
> more serious job-state problem.  If you have any insights, share 'em.

seems sensible. But... how can such a job survive when the super-job
of the (main) pipeline is dead? I wished I could find a way to
reproduce it.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de