3.1.6-pws-3

3.1.6-pws-3

[Peter Stephenson]

I've uploaded
  http://www.ifh.de/~pws/computing/zsh-3.1.6-pws-3.tar.gz

This omits what are currently the last three patches from Sven
(i.e. about an hour's worth), and is supposed to be complete up to 7651.

There were some minor typo fixes in the completion functions which I didn't
post.  The last change to compsys.yo from Sven had quite a large offset, so
I may have missed something.  I've deleted Completion/Rpm since we now have
Completion/Linux/_rpm (this is going to make for great fun if we start
using CVS).  Ideally people introducing such subdirectories should find
some configure test (e.g. $host_os) for whether to include it, add it in
the obvious place in configure.in where Zftp is added, and document this in
INSTALL.  (This is all somewhere a good package mechanism could make a
difference.)


1999-09-06  Peter Stephenson  <pws@ibmth.df.unipi.it>

	* pws: Config/version.mk: 3.1.6-pws-3

	* pws: 7651: Doc/Zsh/options.yo: document HIST_FIND_NO_DUPS.

	* Sven: 7650: Doc/Zsh/compsys.yo, Completion/Base/_arguments,
	  Completion/Core/_display, Completion/Core/compinit,
	  Completion/Linux/_rpm, Completion/User/_urls,
	  Completion/X/_x_color, Etc/completion-style-guide:
	  urls_dir -> urls_path, colors_path allow paths for URLs and X
	  colours; funcall; _arguments changes: options assoc, states
	  available using '->name', option descriptions for mutually
	  incompatible options, descriptions of individual options,
	  option_prefix allows ~command; _display for compadd -y;
	  new _rpm; style guide additions.

	* pws: 7649: Src/pattern.c: bug with excluding multiple
	  directories with ~ in 7611, 7626.

	* Adam Spiers: 7647: Completion/User/_perl_basepods,
	  Completion/User/_perl_builtin_funcs,
	  Completion/User/_perl_modules, Completion/User/_perldoc:
	  completion for perldoc.

	* Tanaka Akira: 7641, 7646: Completion/Debian/_apt-get,
	  Completion/Debian/_deb_packages: handle different apt-get
	  keywords.

1999-09-03  Peter Stephenson  <pws@ibmth.df.unipi.it>

	* pws: 7639: Doc/Zsh/expn.yo, Src/glob.c: remember that
	  (foo/)# is a special case for file globbing; fix bug that
	  that pattern generated a null string.

	* pws: 7637: Doc/Zsh/expn.yo: clarify some glob descriptions
	  including change that / inside parentheses is error (rather than
	  just screwing up pattern) for file globbing.

	* Bart: zsh-users/2567: Doc/Zsh/options.yo: new improved
	  GLOB_COMPLETE description.

	* pws: 7636: Doc/Zsh/builtins.yo, Doc/Zsh/params.yo,
	  Src/builtin.c, Src/zsh.h, Src/Modules/mapfile.c,
	  Src/Modules/parameter.c: typeset -h allows locals to hide
	  specials; turned on automatically for specials in mapfile and
	  parameter modules.

	* Sven: 7635: Completion/User/_urls: change configuration key to
	  urls_dir.

	* Tanaka Akira: 7634: Completion/Debian/_apt-get,
	  Completion/Debian/_deb_packages: completion for apt-get.

	* Tanaka Akira: 7633: Completion/User/_lynx,
	  Completion/User/_urls: completion for lynx and general URL
	  completion.	

1999-09-02  Peter Stephenson  <pws@ibmth.df.unipi.it>

	* pws: 7632: Doc/Zsh/zftpsys.yo, Functions/Zftp/zfautocheck,
	  Functions/Zftp/zfinit, Functions/Zftp/zfrglob,
	  Functions/Zftp/zftp_progress: bar-style progress meter, zfconfig
	  associative array for configuration.

	* Sven: 7631: Completion/User/_pbm: comment about overriding
	  definitions.

	* Sven: 7630: Src/zle_tricky.c: when using a matcher spec
	  generating matches with missing characters, position on last set
	  of missing characters instead of first.

	* Sven: 7628: Src/params.c, Src/Modules/parameter.c,
	  Completion/Core/_parameters, Completion/Core/_path_files:
	  parameters gives `undefined' message; _parameters doesn't
	  load undefined parameters; do partial path expansion after
	  parameters.

	* pws: 7627: Src/params.c: don't autoload parameter just to
	  unset it (replaces 7616).

	* Sven: 7625: Completion/Base/_arguments: expansion fix.

	* Tanaka Akira: 7623: Completion/X/_xv: complete .jpg and .png
	  files.

	* Bart: 7618: Config/installfns.sh, Config/uninstallfns.sh:
	  space required in $sdir substitution.

	* Bart: 7617: Src/signals.c: set err to -1.

1999-09-01  Peter Stephenson  <pws@ibmth.df.unipi.it>

	* pws: 7613: Completion/User/_gv: typos

	* pws: 7611, 7626: Src/pattern.c, Src/parse.c, Doc/Zsh/expn.yo:
	  strip parentheses from case label with open and close
	  parentheses; use unions for pattern alignment, optimize lowest
	  level character reading routine, optimize ...*string pattern,
	  optimize search for characters terminating processing, document
	  some more existing pattern features.
	
	* Sven: 7607: Completion/Base/_arguments: behaviour after a
	  non-option when using `*::'.

	* Sven: 7605: Src/exec.c, Src/jobs.c: use killpg instead of
	  altering process group when leader exits, fix fg test to use
	  killpg.

	* Sven: 7598: Src/Zle/zle_tricky.c: REC_EXACT behaviour.

	* Sven: 7596, 7601: Completion/Base/_arguments: interaction of option
	  arguments with default.

	* pws: 7591: Src/utils.c: cap_free should take caps (not pointer
	  to it) as arg.

	* Bart: 7584: Src/jobs.c, Src/signals.c, Src/system.h: handle
	  broken ESRCH by redefining ESRCH to EINVAL.

	* Tanaka Akira: 7580: Completion/Cvs/_cvs,
	  Completion/Cvs/_cvs_diff, Completion/Cvs/_cvs?history_x:
	  arguments for options; cvs diff description.

	* Sven: 7574, 7577, 7597: Src/subst.c, Doc/Zsh/expn.yo: modify
	  7539 so that the % flag just does % expansion, while %% does
	  full prompt expansion.
	
	* Sven: 7573: Src/signals.c, Src/exec.c, Src/utils.c: fix return
	  value of killjb(); pipelines which lose their leader get a new
	  one.

1999-08-31  Peter Stephenson  <pws@ibmth.df.unipi.it>

	* Will Day: 7362: Src/Makefile.in, Src/hist.c, Src/jobs.c,
	  Src/signals.c, Src/system.h, acconfig.h: support for BeOS: test
	  more capabilities.  This was present in 6-pws-1, but without
	  a Changelog entry.

	* Sven: -7540: withdrawn, use ${${${(M)name#pattern}:+then}:-else}.
	
	* Tanaka Akira: 7436: Src/exec.c: exec last command in sequence
	  properly; don't increment SHLVL when exec'ing.

	* Sven: 7564: Completion/X/_xterm, Completion/Pbmplus/_pgmtoppm,
	  Completion/Pbmplus/_pnmalias, Completion/Pbmplus/_pnmmargin,
	  Completion/Pbmplus/_ppmchange, Completion/Pbmplus/_ppmmake,
	  Completion/Pbmplus/_ppmtoacad, Completion/User/_gs,
	  Completion/X/_xdvi, Completion/X/_xfig, Completion/X/_xsetroot,
	  Completion/X/_xt_arguments, Completion/X/_xterm,
	  Completion/X/_xv: change some names.
	
	* Bart: 7562: corresponding fix for Config/uninstallfns.sh

	* Tanaka Akira: 7561: Config/installfns.sh: administrative files
	  from Functions and Completion were installed by mistake.

	* Bart: 7414: Doc/ztexi.yo: @'@' breaks texinfo; use '@:'.

	* Bart: 7557: Src/Makefile.in: typo adding $(DESTDIR) patch by
	  hand.  (Also from Ollivier Robert, 7558, and Oliver Kiddle).

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: 3.1.6-pws-3

[Andrej Borsenkow]

> 
> This omits what are currently the last three patches from Sven
> (i.e. about an hour's worth), and is supposed to be complete up to 7651.
> 

Looks, like 7652 is included.

/andrej

Re: 3.1.6-pws-3

[Bart Schaefer]

On Sep 6, 12:19pm, Peter Stephenson wrote:
} Subject: 3.1.6-pws-3
}
} I've deleted Completion/Rpm since we now have Completion/Linux/_rpm
} (this is going to make for great fun if we start using CVS).

The rpm tools aren'tnecessarily limited to linux, either, although I
suppose they're not used very often elsewhere at the moment.  Certainly
they're not limited to RedHat; I think there are at least three linux
distributions using RPM installers now.

It is true that adding and removing directories is not the cleanest part
of CVS, so it would be good to establish some file-structure guidelines
before we deploy an "official" CVS server.  Just how great the fun will
be depends on the write-access policy we choose; what were your thoughts?

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

CVS

[Peter Stephenson]

"Bart Schaefer" wrote:
> It is true that adding and removing directories is not the cleanest part
> of CVS, so it would be good to establish some file-structure guidelines
> before we deploy an "official" CVS server.  Just how great the fun will
> be depends on the write-access policy we choose; what were your thoughts?

We shouldn't any more need to add directories unless they going to
hold distinct sets of completions for a particular command set.  I
don't believe it's worth deciding for an individual completion file
whether the command or suite of commands it supports is present or not
--- we could provide an extra script for pruning the installed
functions, if anyone wants to write one --- and hence I don't think
directories like Gnu etc. are particularly useful.  In fact, I can't
currently think of a good example of an extra subdirectory that's
necessary; if the Debian and Linux directories stay fairly empty, I
may put the commands back in User.

To summarise,
- choosing the set of completions appropriate to a local environment
  is more to do with individual mix-and-match on commands than an
  operation en bloc;
- where blocks of commands are concerned, we are now in any case more
  able to provide support in a single file, making new directories
  irrelevant;
- consequently, having extra directories for external commands doesn't
  do the only thing it usefully could do, i.e. help the user with
  organisation.

One thing that might help users through the minefield is a way of
showing what completion will actually be executed in a given context.
To begin with, just being able to find that out for a given command
would be useful.

As far as organizing a CVS archive goes, we could arrange it so that,
for example, Sven made changes to the completion code, and I did it
for the rest, or Bart did in the case of my absence or total
incapacity due to huge volume of patches.  Changes wouldn't appear in
the archive until after they'd been seen on the list --- though at the
present rate of change, how much after is difficult to judge.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56100 Pisa, Italy

Re: CVS (slightly off-topic)

[Adam Spiers]

Peter Stephenson (pws@ifh.de) wrote:
> As far as organizing a CVS archive goes, we could arrange it so that,
> for example, Sven made changes to the completion code, and I did it
> for the rest, or Bart did in the case of my absence or total
> incapacity due to huge volume of patches.  Changes wouldn't appear in
> the archive until after they'd been seen on the list --- though at the
> present rate of change, how much after is difficult to judge.

On the subject of CVS, I've been trying to get my head around (vendor)
branches and have been wondering what the best strategy would be for
using CVS to track changes.  I know that several of you are already
doing this; would you mind briefly detailing what strategy you use?
In particular, do you use a vendor branch?  Several, even?  Do you
make your own changes to the main branch, or to a branch of your own?

It also struck me that even if an official anonymous CVS facility were
to be set up, this still wouldn't be a complete solution (correct me
if I'm wrong) for anyone who wanted to actively develop, since to
develop you ideally need your own repository.  If you wanted to merge
in changes from the anon CVS to your own repository, would you have to
update your working copy of the anon CVS and then `cvs import' your
working copy into your own development repository, or is there a
better way?

Apologies for the off-topicness, but once I get this sorted I'll find
it much easier to contribute (cvs rdiff with tags is a real joy).

Adam

Re: CVS (slightly off-topic)

[Ollivier Robert]

According to Adam Spiers:
> doing this; would you mind briefly detailing what strategy you use?
> In particular, do you use a vendor branch?  Several, even?  Do you
> make your own changes to the main branch, or to a branch of your own?

There is only one vendor branch. What I do (with Perforce and not CVS but
the principle is more or less the same) is to import each  pws (and
release) on the vendor branch and apply the patches on the main trunk.

Tanaka-san uses the vendor branch for all releases/patches which is another 
approach.

> in changes from the anon CVS to your own repository, would you have to
> update your working copy of the anon CVS and then `cvs import' your
> working copy into your own development repository, or is there a
> better way?

Importing what you get from anoncvs in your repository is more or less the
only way to do that.

The way I generally use anoncvs, is that I modify the source locally, make
a 'cvs diff' and it.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.

Re: CVS (slightly off-topic)

[Bart Schaefer]

On Sep 8, 11:40am, Adam Spiers wrote:
} Subject: Re: CVS (slightly off-topic)
}
} On the subject of CVS, I've been trying to get my head around (vendor)
} branches and have been wondering what the best strategy would be for
} using CVS to track changes.  I know that several of you are already
} doing this; would you mind briefly detailing what strategy you use?

I have two repositories, one for zsh-3.0 and one for zsh-3.1.

I import full releases (e.g. 3.0.5, 3.0.6, 3.1.5, 3.1.6) on the standard
vendor branch with vendor tag "zsh-workers".

I import the pws-XX releases onto a second vendor branch with vendor tag
"pws".  I wrote a zsh function wrapper around the cvs command that checks
the vendor tag name and inserts the appropriate -b option so that I can't
accidentally import onto the standard vendor branch, which is the primary
problem with using more than one vendor branch.

(That wrapper function does other things like execute "rm -i" if I try to
"cvs remove" a file that still exists, and always use "cvs -n" with the
"diff" subcommand, and so forth.)

I apply patches to the main trunk as they appear on zsh-workers, and make
any changes of my own there as well.  Immediately after importing, I merge
in the pws-XX changes with e.g.

	cvs update -d
	cvs update -jzsh-3-1-6-pws-2 -jzsh-3-1-6-pws-3

The first update is to pick up any completely new files/directories,
which merging doesn't always accomplish.  Using explicit revision tags
in the update -j -j produces *much* better merges than does the stupid
"yesterday" suggestion that's spat out at the end of the import.

Then I resolve conflicts reported by the merge (ignore conflicts reported
by import, they're mostly useless) and run e.g.

	cvs diff -u -rzsh-3-1-6-pws-3

to check whether I have patches that Peter may have missed or that should
not have been included.  I resolve anything reported by the diff, then
"cvs commit", and now I'm ready to start applying patches off the list
again.

} If you wanted to merge in changes from the anon CVS to your own
} repository, would you have to update your working copy of the anon
} CVS and then `cvs import' your working copy into your own development
} repository, or is there a better way?

There are assorted tools for keeping two repositories in sync, but none
of them do much more than help you automate the process.  You don't have
to import, of course; you can check out two sandboxes (one from the anon
repository, one from your own), and "cp" files back and forth between
the sandboxes, doing updates and/or commits on whichever side is out of
date.  In that case it's good to make some helper scripts to prevent you
from copying a file over the top of one you've changed but not committed.

(You can't "cvs import" your own working copy; I believe cvs refuses to do
an import in a directory that has CVS/ subdirectories.  What you'd do is
"cvs export" from the anon server to a clean tree, then "cvs import" that,
and finally merge into your sandbox with update -j -j as I described.)

On Sep 8,  3:44pm, Ollivier Robert wrote:
} Subject: Re: CVS (slightly off-topic)
}
} There is only one vendor branch.

I don't want turn zsh-workers into the info-cvs list, but:

	cvs import -b 1.1.N ...

for any odd number N greater than 1, creates another vendor branch.  As
I said, you then have to remember to explicitly add that -b option every
time you want to import to that branch; the vendor tag name is not used
by cvs itself, though you're required to provide one.

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

Re: BK & CVS (slightly off-topic)

[Wayne Davison]

One thing we may wish to do is to hold off on a decision to use CVS for the
public archive until the BitKeeper 1.0 release occurs (currently estimated
to happen on either September 22nd or October 1st).  I don't yet have any
experience with BitKeeper, but from what I've read, it sounds very nice.  It
will be free to use for Open Source development.

Some of the things that BK proportedly improves are the proper versioning of
moved files (which CVS handles very badly), and better support for
distributed development.

For instance, BK supposedly makes it easy to have several different "lines
of development" in the same archive, e.g. the stable release, the test
release, the up-to-the-moment patch release, and each developer's own
private work area (which is local to their machine).  This is purported to
be much easier to manage than using CVS.

Their website is http://www.bitkeeper.com/ .

I'd be interested in hearing any comments people have on the software.

..wayne..

Re: BK & CVS (slightly off-topic)

[Bart Schaefer]

On Sep 8,  1:03pm, Wayne Davison wrote:
> Subject: Re: BK & CVS (slightly off-topic)
> One thing we may wish to do is to hold off on a decision to use CVS for the
> public archive until the BitKeeper 1.0 release occurs

I had been meaning to mention BK myself, but I also have no direct experience
with it.

> It will be free to use for Open Source development.

Last I heard, it was to be free for any kind of development as long as you
are willing to publish your commit logs.

I'm not entirely thrilled with BK's license, but it seems it'd be OK for
zsh work.

Re: BK & CVS (slightly off-topic)

[Wayne Davison]

On Wed, 8 Sep 1999, Bart Schaefer wrote:
> I had been meaning to mention BK myself, but I also have no direct
> experience with it.

I'm tempted to contact sales@bitmover.com and ask to be put on the
beta test list, but I'm currently too short on time.  Anyone else
have the time to check it out before it gets released?

> On Sep 8,  1:03pm, Wayne Davison wrote:
> > It will be free to use for Open Source development.

> Last I heard, it was to be free for any kind of development as
> long as you are willing to publish your commit logs.

Yes, that's my understanding as well (you'll notice that my
statement is still true, just not complete :-) ).  I was trying to
indicate that zsh development could use it for free without getting
into the details of their license, but it didn't come out that way.

..wayne..

Re: BK & CVS (slightly off-topic)

[Ollivier Robert]

According to Wayne Davison:
> private work area (which is local to their machine).  This is purported to
> be much easier to manage than using CVS.

But it uses SCCS (albeit modified). I'm not sure but I don't think there is 
the equivalent of anoncvs.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.

Re: BK & CVS (slightly off-topic)

[Wayne Davison]

On Thu, 9 Sep 1999, Ollivier Robert wrote:
> But it uses SCCS (albeit modified). I'm not sure but I don't think
> there is the equivalent of anoncvs.

In my understanding of how BK works, this is not required.  I'm
fuzzy on some details (not having used it yet), but the web page
makes it clear that everyone has their own copy of the archive and
works locally on that, so there is no need for direct remote archive
access.  Combine this with an extended "patch" format (called a
changeset) and the ability to merge archives together, and
everyone's local archive can be synchronized to reflect the same
(essential) version control information.  Note also that each user
has control over how much "detail" gets put into a patch, so it
should be possible for someone to check a whole bunch of incremental
changes into their local archive and then just release the patch as
one incremental change (if desired).  (Yes, I believe that this means
that the SCCS version numbers on various machines are not identical,
but BK appears to use names to work around this.)

What I think this means in practice is that you start things going by
distributing a tarred/gzipped archive snapshot (a collection of SCCS
files that was perhaps created via some kind of export command) and
making it available for download.  Someone could keep up to date by
periodically re-downloading a new archive and merging it into their
local version, but the better way to go would be to apply one or
more patch files (which _does_ update all the appropriate version-
control info such as change-log comments, symbols, etc).  It is my
understanding that PK makes it easy to apply as many or as few
incremental patches from the development contributors as you like,
and it will sort out the whole mess when you apply an incremental
collection of changes (in our case, a new pws patch) that may already
contain the changes you've applied.

So, if I understand things correctly, this means that there is not
instant access to every little twiddle that someone might make to an
anonCVS archive, but instead you have to use "commit" and "makepatch"
to share your changes.  I think this will be a good thing, since you
can't accidentally check out a partial commit.  However, I'll reserve
final judgement until I can actually use it to see for sure.

..wayne..

Re: CVS (slightly off-topic)

[Adam Spiers]

Thanks to all who replied to my CVS questions.  After much fighting
with CVS, I've managed to set up a repository with all the necessary
branches and tags, so this will hopefully make it much easier for me
to contribute patches.  I'm taking the approach of putting all
official and pws releases in the standard vendor branch, and making my
own changes and those from zsh-workers on the main branch.  I'm
planning to only /commit/ my changes on the main branch after I've
saved a copy of the output of a `cvs diff' which can be sent to this
list, rather than messing around with tags for before and after my own
changes.

For reference, in case anyone in the future who hasn't already is
thinking of going down the CVS route, and is reading this thread,
something to be wary of is that if you do more than one import onto a
vendor branch, you have to check for any files present in the first
import but not the second.  Do a `find . -print | sort' in both
directories, and then do a

  cvs remove -f `comm -23 filelist_a filelist_b`

on the respective outputs.

I also had one weird conflict error reported in Completion/User/_cvs
when I imported 3.1.6-pws-4 which I had to deal with manually.  No
idea why.

Right, enough noise; on with the patches! :-)

Adam

Re: CVS (slightly off-topic)

[Bart Schaefer]

On Sep 16,  4:46pm, Adam Spiers wrote:
} Subject: Re: CVS (slightly off-topic)
}
} For reference, in case anyone in the future who hasn't already is
} thinking of going down the CVS route, and is reading this thread,
} something to be wary of is that if you do more than one import onto a
} vendor branch, you have to check for any files present in the first
} import but not the second.  Do a `find . -print | sort' in both
} directories, and then do a
} 
}   cvs remove -f `comm -23 filelist_a filelist_b`
} 
} on the respective outputs.

If you found that you needed to do this, then you've done something else
wrong, or you have a really old version of CVS.  This should be handled
for you by the import and merge process.

(The first thing you did wrong was "find . -print | sort" instead of
"print -l **/*(D)", but that has nothing to do with CVS.)

I'm assuming you did something like this:

    import vendor-rev-A
		    checkout trunk
    import vendor-rev-B
    import vendor-rev-C
		    update trunk

The correct way to update the trunk sandbox in that instance is to do BOTH:

	cvs update
	cvs update -jvendor-rev-A -jvendor-rev-C

The plain "cvs update" will add any new files from rev-B or rev-C that
are not in rev-A.  The "cvs update -j... -j..." will merge changes to
any other files since rev-A, including removing any files no longer
present at rev-C.

The import of rev-C should itself have removed any files new at rev-B
but that are no longer present in rev-C.

The one case where this might fail is when you have modified (but not
committed) a rev-A file in your sandbox that is one of those removed at
either rev-B or rev-C.  In that case you should get a conflict report
at the "cvs update -j... -j..." stage, which you will have to resolve
(possibly by using "cvs remove").  It's best to commit everything you
possibly can *before* doing the merge.

I'd actually update, resolve conflicts, and commit after EACH import,
rather than doing two imports in a row; but that's just to minimize the
size of the conflicts I might have to resolve.

} I also had one weird conflict error reported in Completion/User/_cvs
} when I imported 3.1.6-pws-4 which I had to deal with manually.  No
} idea why.

If you've applied any patches from the list to your trunk sandbox,
"cvs import" may report conflicts.  They're not real conflicts unless
they're also reported by "cvs update -j... -j...", in which case they
might mean that PWS tweaked something without posting it, or that you
missed a patch, or that PWS missed one.

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