3.1.6-dev-17

3.1.6-dev-17

[Peter Stephenson]

I've uploaded
  ftp://ftp.zsh.org/pub/development/zsh-3.1.6-dev-17.tar.gz
Sorry about the delay, I've been quite busy.

This includes Bart's oldish suggestion to prevent zsh sending itself
SIGHUP, as just reposted.

It still does not include zpty.  I suspect I will simply have to add that
and rely on problems being reported, otherwise it will never appear at all.
It might in any case be convenient to have a mechanism for specifying
modules that are not to be compiled or installed --- doing it that way
round prevents the ignorant from leaving out important modules.  This would
protect us against uncompilable minor modules because we could say in
Etc/MACHINES that you should use --ignore-modules=zpty on a particular
architecture.  Other opinions?

2000-02-02  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* pws: Config/version.mk: version 3.1.6-dev-17

	* Bart: 9533: Src/signals.c: make sure shell doesn't send itself
	SIGHUP when exiting.

	* Sven: 9528: Completion/Core/_files: missing variable
	initialization.

	* Sven: 9527: Doc/Zsh/compsys.yo: extra description for styles.

	* Sven: 9526: Src/Zle/computil.c: missing tokenization in
	completion listing.

	* Sven: 9524: Src/text.c: wordcode bug outputting function
	definitions.

	* Sven: 9522: Src/utils.c: return on various conditions when
	reading a character from the terminal.

	* Sven: 9521: Src/exec.c: another job-waiting fix.

2000-02-01  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* pws: 9518: Test/.distfiles, Test/10prompt.ztst: test for prompt
	escapes.

	* Clint/Sven: 9500 rewritten as 9505: Src/mem.c: more graceful exit
	after mmap() failure when used for heap allocation.

	* Alexandre: 9504: Completion/Builtins/_zstyle: complete name of
	packageset style.

	* Sven: 9503: Src/exec.c: problem updating job entry without any
	processes.

	* Alexandre: 9502: Completion/User/_urls,
	Completion/Core/compinit, Completion/Core/_menu,
	Completion/Core/_match, Completion/Base/_combination: fix 9463
	to use ':completion:...' prefix with zstyle.

2000-01-31  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* Sven: 9496: Src/loop.c: failure to check for return status in
	for loop.

	* Bart: 9495: Src/exec.c: re-block after waiting for jobs.

	* Sven: 9494: Src/Zle/computil.c: extraneous space with option
	description.

	* Bart: 9493: Test/09funcdef.ztst: regression test for function
	definition.

	* Sven: 9489: Src/Zle/complist.c, Src/Zle/compresult.c: avoid menu
	selection with no list and asking whether to list twice.

	* Sven: 9488: Src/exec.c: remove unnecessary child_block().

	* Sven: 9487: Src/exec.c: wordcode fix: expand names in function
	definitions.

	* Sven: 9486: Doc/Zsh/compwid.yo: fix docs for compadd -1 with -J

2000-01-30  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* Tanaka Akira: 9476: Completion/User/_cvs,
	Completion/User/_patch: prefer LC_ALL to LANG as the former
	overrides the latter.

	* Tanaka Akira: 9475: Completion/User/_telnet: simplify by using
	(K) parameter flag.

	* Tanaka Akira: 9473: Completion/User/_patch: improved support for
	different versions of `patch'.

	* Bart: 9472: Doc/Makefile.in: dependencies on texinfo files when
	building out of source tree.

	* Tanaka Akira: 9470: Completion/Debian/_deb_packages: updage
	should be update throughout.

	* Clint: 9469: Completion/Debian/_deb_packages,
	Completion/Debian/_dpkg, Doc/Zsh/compsys.yo: new packageset style
	to select Debian package.

2000-01-29  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* Alexandre: 1684: Completion/User/.distfiles: add _diff and
	_diff_options.

	* Alexandre: 9463: Completion/User/_urls,
	Completion/Core/compinit, Completion/Core/_menu,
	Completion/Core/_match, Completion/Base/_combination: switch to
	using zstyle instead of compstyle in various functions.

	* Sven: 9458: Src/Zle/complete.c, Src/Zle/compresult.c: used freed
	memory in completion; should have been using heaps all along.

	* Sven: 9457: Src/params.c: tokenisation problem with patterns
	using parameter flag (K).

	* Sven: 9454: Completion/Core/_path_files: handling path prefixes
	with patterns more cleverly.

	* Sven: 9452: Completion/Base/_arguments: `--exclude=' shouldn't
	show both argument list and completions of --exclude....

	* Bart: 9448: Makefile.in: treat Test subdirectory along with
	others in make procedures (notably distclean).

	* Sven: 9442: Src/Zle/compresult.c: problems with suffixes when
	cursor style set.

	* Sven: 9441: Completion/Core/_files,
	Completion/User/_diff_options: _files sometimes didn't use
	ignored-patterns; use $(command diff) just in case, plus more
	verbose descriptions.

	* Alexandre: 9436: Completion/User/_prcs,
	Completion/User/_diff_options, Completion/User/_diff: prcs
	enhancements with builtin diff support, plus diff options for use
	directly with GNU diff.

2000-01-25  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* pws: Etc/FAQ.yo: updated from latest posted version.

	* Sven: 9424: Src/Modules/parameter.c: problems with 9421 with
	aliases and dir parameters.

2000-01-24  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* pws: 9421: Src/params.c: PM_REMOVABLE parameters are freeable
	since they were created by an ordinary createparam() (fixes
	memory leak).

	* Alexandre: 9419: Src/Zle/complist.c: more problems with
	backreferences in list-colors: aborts after failed backref,
	nested backrefs not handled.

	* Sven: 9417: Src/Zle/compcore.c: prefix code confused by matcher
	specifications.

	* Sven: 9416: Completion/Core/_setup, Src/Zle/complist.c: problems
	using backreferences in list-colors, check zsh/complist is loaded
	if needed.

	* Sven: 9415: Doc/Zsh/mod_complist.yo: typo in pattern example.

	* Sven: 9414: Completion/Core/_path_files: use _comp_ignore.

	* Sven: 9413: Functions/Zftp/zfinit, Src/Modules/zutil.c,
	Src/loop.c: cleanups for module name, new completion test,
	compilation warnings.

	* Sven: 9361: Src/exec.c: simplifty getoutput() test.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

RE: 3.1.6-dev-17

[Andrej Borsenkow]

gmake ->

...
gmake[1]: Entering directory `/tools/src/zsh-3.1.6-dev-17/Doc'
Makefile:217: target `zsh.texi' given more than once in the same rule.
...

bor@itsrm2% gmake --version
GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.

/andrej

Makefile target given more than once (Re: 3.1.6-dev-17)

[Bart Schaefer]

On Feb 3,  1:11pm, Andrej Borsenkow wrote:
} Subject: RE: 3.1.6-dev-17
}
} gmake[1]: Entering directory `/tools/src/zsh-3.1.6-dev-17/Doc'
} Makefile:217: target `zsh.texi' given more than once in the same rule.

Hrm.  This would appear to be gmake cleverly discovering that when $(sdir)
is ".", zsh.texi and $(sdir)/zsh.texi are the same target.

Does that actually cause the build to fail, or is it just noise?

Can we count on other "make" implementations being that clever?  I didn't
think so, but ...

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

RE: Makefile target given more than once (Re: 3.1.6-dev-17)

[Andrej Borsenkow]

> }
> } gmake[1]: Entering directory `/tools/src/zsh-3.1.6-dev-17/Doc'
> } Makefile:217: target `zsh.texi' given more than once in the same rule.
>
> Hrm.  This would appear to be gmake cleverly discovering that when $(sdir)
> is ".", zsh.texi and $(sdir)/zsh.texi are the same target.
>
> Does that actually cause the build to fail, or is it just noise?
>

So far it is just noise. But why we need two targets? One is obviously
redundant.

> Can we count on other "make" implementations being that clever?  I didn't
> think so, but ...
>

I stopped trying native make long ago. I'm even not sure, that it is
possible at all with current makefiles.

/andrej

Re: Makefile target given more than once (Re: 3.1.6-dev-17)

[Bart Schaefer]

On Feb 7, 10:34am, Andrej Borsenkow wrote:
} Subject: RE: Makefile target given more than once (Re: 3.1.6-dev-17)
}
} > } gmake[1]: Entering directory `/tools/src/zsh-3.1.6-dev-17/Doc'
} > } Makefile:217: target `zsh.texi' given more than once in the same rule.
} >
} > Hrm.  This would appear to be gmake cleverly discovering that when $(sdir)
} > is ".", zsh.texi and $(sdir)/zsh.texi are the same target.
} 
} So far it is just noise. But why we need two targets? One is obviously
} redundant.

No, that's not true.

The $(sdir)/zsh.texi target is used in dependencies elsewhere in the
Makefile.

The zsh.texi target is for (cd Doc; make zsh.texi) which is executed by
the top-level Makefile and also may be typed by a user.

When $(sdir) is not "." (e.g., when building in a platform-specific
parallel tree) one or the other of those targets will fail if they are
not both present.  "make zsh.texi" doesn't actually create ./zsh.texi
when $(sdir) is not ".", but if you don't know what $(sdir) is it's
bothersome to figure out what you should type to get zsh.texi created.

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

RE: Makefile target given more than once (Re: 3.1.6-dev-17)

[Andrej Borsenkow]

> } > Hrm.  This would appear to be gmake cleverly discovering that
> when $(sdir)
> } > is ".", zsh.texi and $(sdir)/zsh.texi are the same target.
> }
> } So far it is just noise. But why we need two targets? One is obviously
> } redundant.
>
> No, that's not true.
>
> The $(sdir)/zsh.texi target is used in dependencies elsewhere in the
> Makefile.
>
> The zsh.texi target is for (cd Doc; make zsh.texi) which is executed by
> the top-level Makefile and also may be typed by a user.
>

Here I'm confused. Top-level Makefile never does (cd Doc; make zsh.texi); it
does all, install, clean ... but never subdir-specific targets.

So, we need zsh.texi in source dir to include it with distribution (for
users without yodl). Right?

I suggest to use placeholder like texi, dvi, html etc as main targets and
make them depend on actual files. Like

all: man texi

man: $(MAN)

texi: $(sdir)/zsh.texi

That is what e.g. bash does.

/andrej

Re: 3.1.6-dev-17

[Sven Wischnowsky]

Peter Stephenson wrote:

> It still does not include zpty.  I suspect I will simply have to add that
> and rely on problems being reported, otherwise it will never appear at all.
> It might in any case be convenient to have a mechanism for specifying
> modules that are not to be compiled or installed --- doing it that way
> round prevents the ignorant from leaving out important modules.  This would
> protect us against uncompilable minor modules because we could say in
> Etc/MACHINES that you should use --ignore-modules=zpty on a particular
> architecture.  Other opinions?

No, sounds good.

Bye
 Sven


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