3.1.6-dev-22

3.1.6-dev-22

[Peter Stephenson]

I have uploaded
  ftp://ftp.zsh.org/zsh/development/zsh-3.1.6-dev-22.tar.gz
which is also tagged in the CVS archive as zsh-3_1_6-dev-22 .
(At least, the message says it worked, although I can't see it there yet.)

The changes are as below.  There should be no files missing this time.

One change I haven't posted is for Completion/Core/compinstall, since
essentially the entire file has changed since the last posted version, and
it's quite long.  Most of the change was actually in dev-21.  This time, it
is now usable and consists of all I expect to do with styles before the
next release.  It should now be a painless way of getting your styles set
the way you want.  I would welcome any comments --- even quite picky ones,
since it's supposed to be reasonably idiot-resistant to a depth of about
5m, though sample patches for any suggested changes would be appreciated.

It's now time for anybody to suggest things which need doing (and which are
likely actually to get done) before 3.1.7, else I shall start producing
pre-releases.  The documentation will need reading through again, which can
be concurrent with the pre-release sequence.  The variable setting code
could do with a biggish overhaul after the release, so I don't plan to poke
around too much there.  I would appreciate any opinions on whether fixing
`export' to work locally in functions is a good idea.  We can now do export
-g to refer to the global variable --- but it's been the way it is for so
long that maybe a change would cause trouble.  It's not suitable to have an
option for this.

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

	* Config/version.mk: 3.1.6-dev-22.

	* Completion/Core/compinstall, Doc/Zsh/compsys.yo:  rewrite
	of compinstall to set styles.  Most of this was already in
	3.1.6-dev-21.

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

	* 10594: Functions/Prompts/prompt_bart_setup: Fix index into
	$history in prompt_bart_precmd.

	* 10591: Chmouel Boudjnah: Completion/User/_fakeroot: Completion
	for the fakeroot program.

	* 10590: Chmouel Boudjnah: Completion/Linux/_rpm: Signature
	checking completes only local package files.

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

	* 10584: Doc/Zsh/mod_stat.yo, Src/Modules/stat.c: -o shows
	numeric file modes in octal.

2000-04-07  Bart Schaefer <schaefer@zsh.org>

	* 10582: Src/exec.c: Apply STTY only to process group leaders.

	* 10581: Etc/BUGS, Src/Modules/zpty.c: Note a fixed bug; typo.

	* Chmouel Boudjnah: 10562: Completion/Linux/_rpm: Complete
	only .src.rpm files for "rpm --rebuild".

2000-04-07  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>

	* 10579: Completion/Base/_arguments, Completion/Base/_values,
 	Completion/Core/_alternative: make sure caller-supplied
 	explanation takes precedence
	
	* 10575: Completion/User/_make: complete make targets of the form
 	`foo bar:'
	
	* 10573: Src/Zle/compmatch.c: cursor placed on wrong word part
 	with ** match spec
	
	* 10571: Completion/Core/_main_complete,
 	Completion/Core/_path_files: missing initialisations, -W with
 	multiple directories didn't work

2000-04-06  Clint Adams  <schizo@debian.org>

	* Felix Rosencrantz: 10564: Completion/X/_x_display:
	typo in _wanted.

	* 10565: acconfig.h, configure.in, Src/exec.c:
	add configure option for function depth limit.

	* 10566: Src/glob.c: change invocation of patgetglobflags
	to use two arguments.

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

	* 10547: Doc/Zsh/expn.yo, Misc/globtests, Src/pattern.c,
	Src/subst.c, Test/11glob.ztst, Test/ztst.zsh: add
	(#s) and (#e) to match at start and end of string.

2000-04-06  Andrew Main  <zefram@zsh.org>

	* zefram2: Src/lex.c: Support "3&> foo" etc.

2000-04-06  Andrew Main  <zefram@zsh.org>

	* zefram1: configure.in, Etc/zsh-development-guide: List of tools
	required for development work, and a little more conspicuous
	explanation of the config.status hack.

2000-04-06  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>

	* 10543: Makefile.in: avoid distcleaning Test twice

	* 10542: Completion/Core/_files, Doc/Zsh/compsys.yo: tag in
	file-patterns optional, use `files' as default

	* 10531: Src/init.c: use `zsh' as command name in error messages
	even with -c

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

	* 10524: Util/mkdisttree.sh: always copy files to tarred tree;
	chmod g-s.

	* Oliver: 10519: Src/utils.c, Doc/Zsh/compsys.yo: AIX dependencies
	and minor typo in docs.

	* Alexandre: 10516: Completion/User/_prcs: diff options behaviour.
	
	* 10513: Src/glob.c, Doc/Zsh/expn.yo: glob order qualifier (od)
	implements depth-first ordering.

2000-04-05  Bart Schaefer  <schaefer@zsh.org>

	* 10499: Makefile.in: Dependencies relative to $(sdir).

2000-04-05  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>

	* 10514: Completion/Base/_arguments, Doc/Zsh/compsys.yo:
	support automatically inserted dummy in $words

	* 10511: Completion/Debian/_apt, Completion/Debian/_bug,
	Completion/Debian/_dpkg, Completion/User/_chown,
	Completion/User/_dvi, Completion/User/_imagemagick,
	Completion/User/_ispell, Completion/User/_lp,
	Completion/User/_mount, Completion/User/_mysql_utils,
	Completion/User/_pbm, Completion/User/_psutils,
	Completion/User/_rcs, Completion/User/_rlogin,
	Completion/User/_ssh, Completion/User/_tiff, Completion/User/_yp,:
	Completion/X/_xutils: use basename of commands instead of $words[1]

	* 10508: Completion/Builtins/_zstyle, Completion/Core/_path_files,
	Doc/Zsh/compsys.yo, Functions/Zle/incremental-complete-word: 
	renaming some styles

	* 10507: Completion/Core/_files, Completion/Core/_main_complete:
	two small fixes (-g in _files and menu style)

	* 10502: Src/parse.c: use magic number in zwc files as zwc-version,
	report zsh-version in error message.

	* 10500: Doc/Zsh/zle.yo, Functions/Zle/incremental-complete-word,
	Src/utils.c, Src/Zle/zle_params.c: add zle special parameter
	$PENDING, giving the number of un-read bytes.

	* 10498: Completion/Commands/_next_tags: fix for handling
	file-patterns.

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

	* Clint: 10477: Functions/Zftp/zfcd_match: some awks don't like
	index zero.

	* Clint: 10448: Completion/Debian/_dpkg: complete after -S.

	* Chmouel: 10440: Completion/Linux/_rpm: rpm tags should have %
	in front.

2000-04-04  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>

	* 10471: Completion/User/_imagemagick: new completion function

	* 10467: Src/builtin.c, Src/parse.c: better error handling for
	zwc files

	* 10465: Src/Zle/computil.c: fix for completion of options
	after option with rest-arguments

	* 10463: Src/builtin.c, Src/params.c, Src/zsh.h: PM_HASHELEM
	flag to keep association elements from being exported with
	ALL_EXPORT set

	* 10459: Completion/Commands/_next_tags, Doc/Zsh/compwid.yo,
	Src/Zle/compcore.c: _next_tags should be usable with menu-
	completion

	* 10456: Src/Zle/compcore.c: Copy QIPREFIX/QISUFFIX.

2000-04-04  Andrew Main  <zefram@zsh.org>

	* 10444: Src/lex.c, Src/pattern.c: Insist on proper syntax
	for numeric globbing (with the "-").  Also fix the bug whereby
	"echo 1<2-3>" would lose the "1".

2000-04-03  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>

	* 10408: Completion/Core/_path_files: better quoting

	* 10409: Completion/Core/_path_files: completion after ~+<num>

	* 10412: Src/Zle/compmatch.c: better partial word completion for
 	new parts

	* 10413: Completion/Commands/_complete_help, Doc/Zsh/compsys.yo:
	style list optional in _complete_help

	* 10416: Completion/Core/_main_complete, Doc/Zsh/compsys.yo:
 	default completer style contains _ignored

	* 10425: Completion/Core/_files, Completion/User/_gdb,
	Completion/User/_getconf, Completion/User/_mh,
	Completion/User/_netscape, Completion/User/_tiff,
	Completion/User/_urls, Completion/X/_xmodmap,
	Doc/Zsh/compsys.yo, Src/Zle/computil.c: Various completion fixes.

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

	* Clint: 10424: Completion/Debian/_dpkg: reported -i=irs failure.

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

Re: 3.1.6-dev-22

[Bart Schaefer]

On Apr 9,  7:54pm, Peter Stephenson wrote:
} Subject: 3.1.6-dev-22
}
} I have uploaded
}   ftp://ftp.zsh.org/zsh/development/zsh-3.1.6-dev-22.tar.gz
} which is also tagged in the CVS archive as zsh-3_1_6-dev-22 .
} (At least, the message says it worked, although I can't see it there yet.)

About an hour later now, and it still isn't there yet.

} It's now time for anybody to suggest things which need doing (and which are
} likely actually to get done) before 3.1.7, else I shall start producing
} pre-releases.

I've sent a number of messages asking about potential changes, to which
there have been no replies or at least no decision (e.g., 10346, users/3013,
users/2973, others).  Does Sven have any outstanding issues with completion?

} I would appreciate any opinions on whether fixing
} `export' to work locally in functions is a good idea.  We can now do export
} -g to refer to the global variable --- but it's been the way it is for so
} long that maybe a change would cause trouble.  It's not suitable to have an
} option for this.

I think it should work like ksh in sh/ksh emulation modes, but otherwise I
think the current behavior is OK.  That isn't exactly the same as having an
option; do you believe that also to be unsuitable?

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

Re: 3.1.6-dev-22

[Peter Stephenson]

"Bart Schaefer" wrote:
> I've sent a number of messages asking about potential changes, to which
> there have been no replies or at least no decision (e.g., 10346, 

If you don't see a problem with changing the way zshpaths.h is made (and I
presume you tried it out) then I certainly don't.

> users/3013,

Doesn't look that controversial to me.

> users/2973

Looks like we need some noalwayslastprompt guinea pigs for that one.

> others

Well, I came home today and there were 82 messages in my mailbox, so a
list wouldn't hurt.

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

Re: 3.1.6-dev-22

[Bart Schaefer]

On Apr 11,  9:18pm, Peter Stephenson wrote:
> Subject: Re: 3.1.6-dev-22
> "Bart Schaefer" wrote:
> > I've sent a number of messages asking about potential changes, to which
> > there have been no replies or at least no decision (e.g., 10346, 
> 
> If you don't see a problem with changing the way zshpaths.h is made (and I
> presume you tried it out) then I certainly don't.

Zefram?  I believe it's your test I'm proposing to delete ... or maybe it's
Zoltan's ...

> > users/3013,
> 
> Doesn't look that controversial to me.

That's good, because I already committed it (after fixing some things).

> Well, I came home today and there were 82 messages in my mailbox, so a
> list wouldn't hurt.

I'll try to generate one.

Re: 3.1.6-dev-22

[Zefram]

Bart Schaefer wrote:
>> If you don't see a problem with changing the way zshpaths.h is made (and I
>> presume you tried it out) then I certainly don't.
>
>Zefram?  I believe it's your test I'm proposing to delete ... or maybe it's
>Zoltan's ...

It's really a policy decision: when should zshpaths.h be rebuilt.
I've previously expressed my point of view on that -- that zshpaths.h
should always be made consistent with the parameter values effective in
the make in progress -- but there is a perfectly reasonable alternative
of making zshpaths.h from the originally configured values.  I have no
problem with either scheme.

-zefram

Re: 3.1.6-dev-22

[Bart Schaefer]

On Apr 12,  1:59pm, Zefram wrote:
} Subject: Re: 3.1.6-dev-22
}
} Bart Schaefer wrote:
} >> If you don't see a problem with changing the way zshpaths.h is made (and I
} >> presume you tried it out) then I certainly don't.
} >
} >Zefram?  I believe it's your test I'm proposing to delete ... or maybe it's
} >Zoltan's ...
} 
} It's really a policy decision: when should zshpaths.h be rebuilt.
} I've previously expressed my point of view on that -- that zshpaths.h
} should always be made consistent with the parameter values effective in
} the make in progress

That's a slightly different issue.  I'm proposing to have zshpaths.h built
*more* often, not less ... the test I want to remove *prevents* zshpaths.h
from being rebuilt in some circumstances.

Here's the (not committed to SourceForge) diff for reference:

--- zsh-forge/common/Src/zsh.mdd	Fri Jan 14 11:15:00 2000
+++ zsh-3.1.6/Src/zsh.mdd	Sat Apr  8 16:12:55 2000
@@ -49,13 +49,8 @@
 	    >>zshpaths.h.tmp; \
 	  fi; \
 	fi
-	@if cmp -s zshpaths.h zshpaths.h.tmp; then \
-	    rm -f zshpaths.h.tmp; \
-	    echo "\`zshpaths.h' is up to date." ; \
-	else \
-	    mv -f zshpaths.h.tmp zshpaths.h; \
-	    echo "Updated \`zshpaths.h'." ; \
-	fi
+	@mv -f zshpaths.h.tmp zshpaths.h; \
+	echo "Updated \`zshpaths.h'."
 
 bltinmods.list: modules.stamp modules-bltin xmods.conf mkbltnmlst.sh
 	srcdir='$(sdir)' MODBINS='modules-bltin' \

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

Re: 3.1.6-dev-22

[Zefram]

Bart Schaefer wrote:
>Here's the (not committed to SourceForge) diff for reference:

Oh, that one.  I passed over that one when it first appeared on the
grounds that it's fairly insignificant -- it doesn't affect what's in
any file, it can just cause unnecessary rebuilding.  I don't see a great
advantage in it, so I'm neutral on it.

-zefram

Re: 3.1.6-dev-22

[Geoff Wing]

Peter Stephenson <pws@pwstephenson.fsnet.co.uk> typed:
:"Bart Schaefer" wrote:
:> I've sent a number of messages asking about potential changes, to which
:> there have been no replies or at least no decision (e.g., 10346, 
:> users/2973
:Looks like we need some noalwayslastprompt guinea pigs for that one.

We differ from other shells in that we have a clear workspace
under the prompt line.  Apply the patch and try the following
with and without alwayslastprompt.

% clear; ls; echo "\e[0H"; ls

This depends slightly on the file listing but you should get an
idea.  My preference is for the current arrangement and I have
noalwayslastprompt - adding the patch may spawn another setopt
value: gimmeaclearworkspace :-)

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: 3.1.6-dev-22

[Bart Schaefer]

On Apr 12,  6:30am, Geoff Wing wrote:
} Subject: Re: 3.1.6-dev-22
}
} We differ from other shells in that we have a clear workspace
} under the prompt line.  Apply [users/2973] and [...]
} 
} My preference is for the current arrangement and I have
} noalwayslastprompt - adding the patch may spawn another setopt
} value: gimmeaclearworkspace :-)

I'll play with this a bit when I'm wider awake, but:

Can't you get the same effect with 2973 applied by having %E as the last
thing in $PS1 ?

And what's the point of having the %E escape if zsh is always going to
clear the screen unconditionally?  Just for "print -P"?

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

Re: 3.1.6-dev-22

[Geoff Wing]

Bart Schaefer wrote about Re: 3.1.6-dev-22:
:On Apr 12,  6:30am, Geoff Wing wrote:
:} Subject: Re: 3.1.6-dev-22
:} We differ from other shells in that we have a clear workspace
:} under the prompt line.  Apply [users/2973] and [...]
:} My preference is for the current arrangement and I have
:} noalwayslastprompt - adding the patch may spawn another setopt
:} value: gimmeaclearworkspace :-)
:I'll play with this a bit when I'm wider awake, but:

I've been waiting.  Are you wider awake yet?  :-)

:Can't you get the same effect with 2973 applied by having %E as the last
:thing in $PS1 ?

:And what's the point of having the %E escape if zsh is always going to
:clear the screen unconditionally?  Just for "print -P"?

OK.  Here are some starting points:
1) %E is CLEAREOL (erase to end of line)
2) The display code doesn't know about %E.  The prompt code handles
   that but doesn't pass that information through, leading to:
3) %E in prompts may be dangerous.  In certain (possibly contrived)
   situations the display code may have the cursor within the prompt
   and decide the quickest way to get past it is to output the prompt.
   However it won't know that you've CLEAREOL'd so you may end up
   missing text in the display.  The likelyhood of this happening to
   anyone is probably extremely low since, IIRC, you would need wierd
   termcap/terminfo settings to achieve it.
4) CLEAREOL only affects the directly managed display (the prompt lines)
   whereas the patch affects sending CLEAREOD which also affects text
   under the prompt lines.
5) You can't unconditionally put CLEAREOD in left or right prompt
   because of several situations including lists or extended lines,
   e.g. the right prompt can be removed or redrawn without affecting
   the following lines;  if it's redrawn and it has CLEAREOD, blam!

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: 3.1.6-dev-22

[Bart Schaefer]

On Apr 17, 10:58am, Geoff Wing wrote:
} Subject: Re: 3.1.6-dev-22
}
} Bart Schaefer wrote about Re: 3.1.6-dev-22:
} :On Apr 12,  6:30am, Geoff Wing wrote:
} :} Subject: Re: 3.1.6-dev-22
} :} We differ from other shells in that we have a clear workspace
} :} under the prompt line.  Apply [users/2973] and [...]
} :} My preference is for the current arrangement and I have
} :} noalwayslastprompt - adding the patch may spawn another setopt
} :} value: gimmeaclearworkspace :-)
} :I'll play with this a bit when I'm wider awake, but:
} 
} I've been waiting.  Are you wider awake yet?  :-)

I woke up and promptly left town.  (Pun?)

What I was supposed to try was:

% clear; ls; echo "\e[0H"; ls

If I replace those semicolons with RETs so that a new prompt is printed
between each pair of commands, then I begin to see what you mean.  (It
depends more than a little bit on the "ls" output -- if the output is
enough to scroll the screen, for example, no difference is discernable).

Nevertheless, this is only an issue if a command (the echo in the sample)
leaves the cursor above some portion of a screenful of output.  Does that
happen to you a lot?  The last time I can remember it happening to me, it
was because a curses-based program crashed.

I'm sure some test other than `&& isset(ALWAYSLASTPROMPT)' would be better;
if it's not clearing for the completion code's benefit then whether we've
returned to the previous prompt is irrelevant (e.g., if Geoff's arguments
aren't convincing then maybe we should remove that CLEAREOD entirely).

However, I don't feel very strongly about it either way; special-case code
for transparent terminals makes even less sense than for crashing commands.

} :Can't you get the same effect with 2973 applied by having %E as the last
} :thing in $PS1 ?
} 
} 1) %E is CLEAREOL (erase to end of line)

Oh, duh.

} :And what's the point of having the %E escape if zsh is always going to
} :clear the screen unconditionally?  Just for "print -P"?
} 
} 2) The display code doesn't know about %E.  The prompt code handles
}    that but doesn't pass that information through, leading to:
} 3) %E in prompts may be dangerous.

Maybe we should document this?

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

Re: 3.1.6-dev-22

[Geoff Wing]

Bart Schaefer wrote about Re: 3.1.6-dev-22:
:Nevertheless, this is only an issue if a command (the echo in the sample)
:leaves the cursor above some portion of a screenful of output.  Does that
:happen to you a lot? 

Yes.  Running multiple programs which use secondary screens, e.g. ``screen''
and something else which uses curses (or similar), and primary/secondary
screen independent cursor positions.  It _might_ not be a major handicap
without the latter.

:I'm sure some test other than `&& isset(ALWAYSLASTPROMPT)' would be better;
:if it's not clearing for the completion code's benefit then whether we've
:returned to the previous prompt is irrelevant (e.g., if Geoff's arguments
:aren't convincing then maybe we should remove that CLEAREOD entirely).

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: 3.1.6-dev-22

[Peter Stephenson]

I forgot about this...

"Bart Schaefer" wrote:
> } I would appreciate any opinions on whether fixing
> } `export' to work locally in functions is a good idea.  We can now do export
> } -g to refer to the global variable --- but it's been the way it is for so
> } long that maybe a change would cause trouble.  It's not suitable to have an
> } option for this.
> 
> I think it should work like ksh in sh/ksh emulation modes, but otherwise I
> think the current behavior is OK.  That isn't exactly the same as having an
> option; do you believe that also to be unsuitable?

Well, up to now every change in emulation has been mirrored in some
option.  It's not strictly necessary, but it does make things a lot
neater.  Sooner or later someone's going to want the feature and find they
can only do it by setting two gross of options.

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

dev-22 compile problem

[Jason Price]

I have been trying to compile dev-22 on Solaris 2.7 with both gcc 2.81, and
gcc 2.95.2, and failing in the same place on both.  

It's a strait gtar -xzf zsh*.gz ; cd zsh<tab> ; ./configure ; make.

The error I'm getting is:

gcc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -Wall -Wno-implicit -Wmissing-prototypes -O2  -o hashtable.o hashtable.c
hashtable.c: In function `add_userdir':
hashtable.c:1191: structure has no member named `en_cols'
make[2]: *** [hashtable.o] Error 1
make[2]: Leaving directory `/export/home/jprice/programs/zsh/zsh-3.1.6-dev-22/Src'
make[1]: *** [modobjs] Error 2
make[1]: Leaving directory `/export/home/jprice/programs/zsh/zsh-3.1.6-dev-22/Src'
make: *** [all] Error 1

If I need to give more info, please let me know.

Solaris 2.7, 128 m ram, ultra 1, 167 MHz.  To the best of my knowledge,
it's a strait 2.7 machine.  I havn't torched it, and re-installed to verify
it though...

Jason

-- 
Faith is not a matter of questions.      Jason Price
Faith is a matter of answers.            jprice@gatech.edu
More to the point, one answer:           Theta Xi, Beta Alpha, 449
"Yes, Lord."

Re: dev-22 compile problem

[Bart Schaefer]

On Apr 12,  4:29pm, Jason Price wrote:
> Subject: dev-22 compile problem
> 
> hashtable.c:1191: structure has no member named `en_cols'

Apparently no one else is building zsh with HAVE_NIS_PLUS.

Try deleting half of the .en_cols.en_cols on line 1191 of hashtable.c.

Re: dev-22 compile problem

[Jason Price]

On Wed, Apr 12, 2000 at 05:15:28PM -0700, Bart Schaefer wrote:
> On Apr 12,  4:29pm, Jason Price wrote:
> > Subject: dev-22 compile problem
> > hashtable.c:1191: structure has no member named `en_cols'
> Apparently no one else is building zsh with HAVE_NIS_PLUS.
> Try deleting half of the .en_cols.en_cols on line 1191 of hashtable.c.

The line now looks like:

    if (object->zo_data.objdata_u.en_data.en_cols >= 6) {

As opposed to:

    if (object->zo_data.objdata_u.en_data.en_cols.en_cols >= 6) {

And the error returned is:

gcc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -Wall
-Wno-implicit -Wmissing-prototypes -O2  -o hashtable.o hashtable.c
hashtable.c: In function `add_userdir':
hashtable.c:1191: invalid operands to binary >=
make[2]: *** [hashtable.o] Error 1
make[2]: Leaving directory `/export/home/jprice/programs/zsh/zsh-3.1.6-dev-22/Src'
make[1]: *** [modobjs] Error 2
make[1]: Leaving directory `/export/home/jprice/programs/zsh/zsh-3.1.6-dev-22/Src'
make: *** [all] Error 1

Thanks;
Jason

-- 
Faith is not a matter of questions.      Jason Price
Faith is a matter of answers.            jprice@gatech.edu
More to the point, one answer:           Theta Xi, Beta Alpha, 449
"Yes, Lord."

Re: dev-22 compile problem

[Geoff Wing]

Jason Price <jprice@cyberbuzz.gatech.edu> typed:
:On Wed, Apr 12, 2000 at 05:15:28PM -0700, Bart Schaefer wrote:
:> On Apr 12,  4:29pm, Jason Price wrote:
:> > Subject: dev-22 compile problem
:> > hashtable.c:1191: structure has no member named `en_cols'
:> Apparently no one else is building zsh with HAVE_NIS_PLUS.
:> Try deleting half of the .en_cols.en_cols on line 1191 of hashtable.c.
:The line now looks like:
:    if (object->zo_data.objdata_u.en_data.en_cols >= 6) {
:As opposed to:
:    if (object->zo_data.objdata_u.en_data.en_cols.en_cols >= 6) {
:And the error returned is:

I guess it should be something like:

 if (object->zo_data.objdata_u.en_data.en_cols.en_cols_len >= 6) {

The check with 6 to make sure there are 6+ columns because we later access
the 6th column.


Quick look a Sun docs (docs.sun.com):

union {
	struct directory_obj     di_data;
	struct group_obj         gr_data;
	struct table_obj         ta_data;
	struct entry_obj         en_data;
	struct link_obj          li_data;
	struct {
		u_int              po_data_len;
		char               * po_data_val;
	} po_data;
} objdata_u;

struct entry_col {
	u_long     ec_flags;
	struct {
		u_int      ec_value_len;
		char       * ec_value_val;
	} ec_value;
}
typedef struct entry_col entry_col;

struct entry_obj {
	char       * en_type;
	struct {
		u_int      en_cols_len;
		entry_col * en_cols_val;
	} en_cols;
}


-- 
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: 3.1.6-dev-22

[Bart Schaefer]

On Apr 12,  9:06pm, Peter Stephenson wrote:
> 
> > } I would appreciate any opinions on whether fixing
> > } `export' to work locally in functions is a good idea.
> > 
> > I think it should work like ksh in sh/ksh emulation modes, but otherwise
> > I think the current behavior is OK.
> 
> Well, up to now every change in emulation has been mirrored in some
> option.

That's not quite true ... although it may be my fault in both cases where
it isn't.  ${!foo} acts like ${(P)foo} only in ksh emulation, and ${assoc}
acts like ${assoc[0]} only in ksh emulation.  There's no option for either;
they're strictly for executing ksh scripts.

> Sooner or later someone's going to want the feature and find they
> can only do it by setting two gross of options.

This is as opposed to wanting the feature and finding they can't do it at
all?

RE: 3.1.6-dev-22

[Andrej Borsenkow]

>
> It's now time for anybody to suggest things which need doing
> (and which are
> likely actually to get done) before 3.1.7, else I shall start
> producing
> pre-releases.


One thing that I'd wish is easy way to sync wordcode file and
directories. Without all these fancy patterns etc. That would add new
functions, remove deleted functions and recompile changed ones.

-andrej

Re: 3.1.6-dev-22

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> } It's now time for anybody to suggest things which need doing (and which are
> } likely actually to get done) before 3.1.7, else I shall start producing
> } pre-releases.
> 
> I've sent a number of messages asking about potential changes, to which
> there have been no replies or at least no decision (e.g., 10346, users/3013,
> users/2973, others).  Does Sven have any outstanding issues with completion?

I didn't have any strong opinions about the things in those messages
or, for 1973, am not the person who can decide that (but Geoff sent a
reply).

As for my todo-list: only bug-fixing, the file-patterns stuff Peter
has just `suggested' (or complained about if you prefer) and the
function-moving-around which will happen before the final release, I
think. Oh, and removing compconf().


Bye
 Sven


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

RE: 3.1.6-dev-22

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > It's now time for anybody to suggest things which need doing
> > (and which are
> > likely actually to get done) before 3.1.7, else I shall start
> > producing
> > pre-releases.
> 
> One thing that I'd wish is easy way to sync wordcode file and
> directories. Without all these fancy patterns etc. That would add new
> functions, remove deleted functions and recompile changed ones.

I don't get it... what could be easier than zrecompile with -p?

Ok, we could also add an option that works like -p but gets directory
names instead of filenames, but is that worth it? Avoiding only the
need for `/*'?

Bye
 Sven


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

Re: 3.1.6-dev-22

[Sven Wischnowsky]

I wrote:

> ...
> 
> As for my todo-list: only bug-fixing, the file-patterns stuff Peter
> has just `suggested' (or complained about if you prefer) and the
> function-moving-around which will happen before the final release, I
> think. Oh, and removing compconf().

After reading a bit in the guide...

We might have to change _wanted so that it does the real tag-loop,
too, not only the label-loop. That would make

  zstyle ':completion:*:*:foo:*' tag-order bar:baz bar

work everywhere. But it would require changing some of the completion
functions that use `_wanted ... && ...' and the like, but the fact
that the above sometimes isn't possible is just too confusing. I just
hadn't though of such a tag-order value.

Sigh.

But then it should also be possible to make _next_tags work with it.


About the file-patterns style: maybe we should just allow multiple
patterns per tag. I.e.:

  ... file-patterns '*.o:object\ files *(-/)'

would be the same as `... *(-/):files', using the default tag. If one
want to give multiple patterns for the same tag, one could always use
`(...|...)', right? And giving the same tag for different patterns as
in :

  ... file-patterns '*.foo:foobar *.bar:foobar'

would work, too. Most if not all of the things possible with this are
already possible (or will become possible if the change to _wanted is
implemented), but allowing it with file-patterns is probably easier to 
understand.


Bye
 Sven


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