Re: zsh-3.1.2-zefram3

Re: zsh-3.1.2-zefram3

[Gene Cohler]

I failed to compile this under hpux 10.20

------------------------------------------
% make
        ( cd .. && /bin/sh Src/mkmodindex.sh Src ) \
            > modules.index.tmp
WARNING: illegally named module `zsh' in Src
         (ignoring it)
`modules.index' is up to date.
cd .. && /bin/sh $top_srcdir/Src/mkmakemod.sh Src Makemod
Src/../Src/mkmakemod.sh[85]: Syntax error at line 273 : `(' is not expected.
*** Error exit code 2
------------------------------------------

This appears to stem from the file modules.index which contains:
modules_list="". The script mkmakemod.sh seems to need a non-blank modules list. 
Are modules supposed to work under hpux 10.20 ? 


--
  Gene
  gene@sapience.com

Re: zsh-3.1.2-zefram3

[Anthony Heading]

Bart wrote:
> This is true, but seems clumsy especially because the EOF char is normally
> overloaded as delete-char-or-list.  You'd be forced to write a user-defined
> widget that implemented `delete-char-or-list-or-eof' to make it work right.

Indeed.

> On the other hand, I don't believe that vared *should* behave the way that
> typing text into `cat` would.  Vared is not a streaming editor; I expect
> it to behave like an editor that controls my terminal, not like a process
> blindly reading from standard input.

OK. I suppose I was thinking that vared could easily be a streaming editor,
and read standard input slightly less blindly.

> How exactly does this change the behavior, again?  EOF on any empty line
> is EOF, even in a multiline edit?  Yes, I object to that.  I want EOF to
> be EOF when typed on an empty line at a PS1 prompt, and nowhere else.

Fair.  But I want EOF to be EOF also in my vared-based `cat' emulator.

So at most, then, this should be an option for vared, and not a default.

I shall revamp my patch to be less intrusive, and not change any of the
current behaviour.

Cheers

A

Re: zsh-3.1.2-zefram3

[Peter Stephenson]

"Bart Schaefer" wrote:
> On Jan 18,  3:14pm, Anthony Heading wrote:
> } In zleread()
> } 
> } -           if (!ll && isfirstln && c == eofchar) {
> } +           if (c == eofchar && cs == ll && cs == findbol()) {
> }                 eofsent = 1;
> }                 break;
> }             }
> } 
> 
> The condition changed from 3.0.2 to 3.0.3, adding the "&& isfirstln".
> That was sometime before 27 June 1997.  I don't know exactly what that
> accomplished.

I think it was I (all right, me) that changed it, so that if you type
\<RETURN> then typing a ^D acted as list-choices instead of eof.  This
seemed logical since lexically you are in the middle of a line.

> } This is probably the point where I become unhinged.  At least in the
> } environment where I work, flexibility in user-space configuration is
> } absolutely no substitute for a satisfactory default.
> 
> I agree completely.

Actually, if we have a mission statement ("...proactively integrate
synergetic industry metaphors into a dynamic system-invariant
state-of-the-art user interface..." ???), I vote for inclusion of the
phrase "flexibility in user-space configuration is absolutely no
substitute for a satisfactory default" (suitably disguised, of course).

> } Nu chto zh.
> 
> What?

Hmm, I don't think that one came out of the mission statement
generator.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 911239
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: zsh-3.1.2-zefram3

[Bart Schaefer]

On Jan 18,  3:14pm, Anthony Heading wrote:
} Subject: Re: zsh-3.1.2-zefram3
}
} On Mon, Jan 12, 1998 at 11:27:05AM +0000, Andrew Main wrote:
} > I'd particularly like to discuss the recent ZLE-related feature patches:
} > [...]
} > N  3554 ajrh     allow vared to succeed on EOF
} > 	This can be done by temporarily rebinding ^D to accept-line, or
} > 	to a user-defined widget that conditionally calls accept-line.

This is true, but seems clumsy especially because the EOF char is normally
overloaded as delete-char-or-list.  You'd be forced to write a user-defined
widget that implemented `delete-char-or-list-or-eof' to make it work right.

On the other hand, I don't believe that vared *should* behave the way that
typing text into `cat` would.  Vared is not a streaming editor; I expect
it to behave like an editor that controls my terminal, not like a process
blindly reading from standard input.

} PREMISE:
} I would aver that the EOF char acting as accept-line is a natural
} default (viz my original desire to emulate the RCS check-in input).

I would aver that there shouldn't *be* any recognized EOF char in vared,
just as there is no EOF in vi or emacs.  That is, as best I can tell, the
current behavior.

} PRIMARY HANDLING OF EOF:
} In zleread()
} 
} -           if (!ll && isfirstln && c == eofchar) {
} +           if (c == eofchar && cs == ll && cs == findbol()) {
}                 eofsent = 1;
}                 break;
}             }
} 
} I think that this is an improvement.

How exactly does this change the behavior, again?  EOF on any empty line
is EOF, even in a multiline edit?  Yes, I object to that.  I want EOF to
be EOF when typed on an empty line at a PS1 prompt, and nowhere else.

} I think the condition has been
} changed at least once already in the past year, but nobody discussed
} it and nobody complained, so preservation of the status-quo may have
} been demonstrated de-facto not to be an overriding imperative.

The condition changed from 3.0.2 to 3.0.3, adding the "&& isfirstln".
That was sometime before 27 June 1997.  I don't know exactly what that
accomplished.

} VARED HANDLING OF -c:
} 
} Perhaps Zefram missed the fact that the patch retained the -c flag as
} a null op?  The balance as always is cost (incompatibility) against
} benefit (here simplicity).  I still suspect that the incompatibilty
} is minimal: that no-one relies on that error condition in scripts.

Scripts are not the only case to consider; I dislike having my interactive
habits disrupted, too.  In this case, this wouldn't bother *me*, but ....

} VARED HANDLING OF EOF:
} 
} If you like, we could swap the sense of the -e flag and keep the
} current behaviour as the default.  

That would be preferable.

} USE OF ZLE WIDGETS:
} 
} This is probably the point where I become unhinged.  At least in the
} environment where I work, flexibility in user-space configuration is
} absolutely no substitute for a satisfactory default.

I agree completely.

} Nu chto zh.

What?

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

Re: zsh-3.1.2-zefram3

[Anthony Heading]

On Mon, Jan 12, 1998 at 11:27:05AM +0000, Andrew Main wrote:
> I'd particularly like to discuss the recent ZLE-related feature patches:
> [...]
> N  3554 ajrh     allow vared to succeed on EOF
> 	This can be done by temporarily rebinding ^D to accept-line, or
> 	to a user-defined widget that conditionally calls accept-line.
> 	(See Functions/zed for an example of how to temporarily change
> 	bindings.)  Also, while I agree that vared -c is not much
> 	use, removing the option entirely will cause problems with
> 	some scripts.  Changing the default EOF behavior would cause
> 	similar problems.  While I would like the whole area of EOF
> 	handling in ZLE to be re-examined, this patch does not do a
> 	proper job of that.

Hmmm.  I'm not sure I understand quite what this means in practice.
Can we break it down?

PREMISE:
I would aver that the EOF char acting as accept-line is a natural
default (viz my original desire to emulate the RCS check-in input).

PRIMARY HANDLING OF EOF:
In zleread()

-           if (!ll && isfirstln && c == eofchar) {
+           if (c == eofchar && cs == ll && cs == findbol()) {
                eofsent = 1;
                break;
            }

I think that this is an improvement.  I think the condition has been
changed at least once already in the past year, but nobody discussed
it and nobody complained, so preservation of the status-quo may have
been demonstrated de-facto not to be an overriding imperative.

Does anyone find this problematic?  It's not difficult to make it
conditional on a vared flag, but Occam's razor advises not playing
silly buggers unless you need to.

VARED HANDLING OF -c:

Perhaps Zefram missed the fact that the patch retained the -c flag as
a null op?  The balance as always is cost (incompatibility) against
benefit (here simplicity).  I still suspect that the incompatibilty
is minimal: that no-one relies on that error condition in scripts.
But others may know better.  Not important - it was just a cleanup.

VARED HANDLING OF EOF:

If you like, we could swap the sense of the -e flag and keep the
current behaviour as the default.  

RE-EXAMINATION OF WHOLE OF ZLE EOF HANDLING:

I'd agree completely that this patch doesn't make a proper job of
anything like that.  I'm not sure what all the issues are.  It was
simply intended as a small step in the right direction

USE OF ZLE WIDGETS:

This is probably the point where I become unhinged.  At least in the
environment where I work, flexibility in user-space configuration is
absolutely no substitute for a satisfactory default.  And in the area
of multi-line zsh editing, zsh has a little tweaking still to do
before that default is reasonable.


Nu chto zh.  Zefram: I think the only necessarily incompatible change
is the tweak to zleread().  Is that objectionable?  All the others
can be reworked to preserve the current behaviour as default, if that
what you think is appropriate.  If the problem is more that you don't
want to see eof handling touched until it's radically overhauled, I
think you'll need to clarify what needs done.

Anthony

Re: zsh-3.1.2-zefram3

[Bruce Stephens]

pws@ifh.de said:
> I got this to compile by altering SHELL in both Src/Makefile and Src/
> Makemod.in.in to point to a version of zsh running as ksh.  This seems
> to be OK (I have zle compiled in). 

Ah, that works better.  I hadn't changed Makemod.in.in before.  Line 94 of 
Src/makepro.awk causes a problem with Solaris2.5.1's nawk:

        sub(/=.*$/, "", dcltor)

Quoting the = seems to fix it.

        sub(/\=.*$/, "", dcltor)

After that it seems to compile OK.

Re: zsh-3.1.2-zefram3

[Peter Stephenson]

For cisatlantic users, I put Zefram's version on the web at

http://www.ifh.de./~pws/computing/zsh-3.1.2-3.1.2-zefram3.diff.gz

(just the diff file).

I got this to compile by altering SHELL in both Src/Makefile and
Src/Makemod.in.in to point to a version of zsh running as ksh.  This
seems to be OK (I have zle compiled in).

One thing I've noticed is that the strftime sequences in the prompt
now print hours 1 to 9 with a space in front.  I don't know how that came
about.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +39 50 911239
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: zsh-3.1.2-zefram3

[Bruce Stephens]

zefram@tao.co.uk said:
>> Src/../Src/mkmakemod.sh: syntax error at line 238: `(' unexpected

> That's clever -- the ( is quoted.  There must have been a quoting
> confusion earlier.

Possibly.  I was confused by this one too.  Changing the double quotes to 
single quotes in that echo seemed to enable it to get further, so I thought 
that perhaps there was some strange rules about quoting.  You're probably 
right though, I suspect I was being misled.

Re: zsh-3.1.2-zefram3

[Bruce Stephens]

zefram@tao.co.uk said:
> Works for me with bash-1.14.6(1).  Are you sure you're actually using
> bash there?  You need to change the SHELL= lines in the Makefiles; for
> safety you should probably just change everything. 

Yes, this is what I did.  I didn't change the scripts themselves, so I guess 
it's possible something got it wrong.

The bash is 1.14.4(1), which may be a bit old.  The zsh I tried is 3.1.2 with 
some patches (mostly Peter's compctl extensions).

In any case, it needs fixing, so I'll stop fiddling with it and wait!

Re: zsh-3.1.2-zefram3

[Andrew Main]

Bruce Stephens wrote:
>Doesn't seem to work if I replace /bin/sh with /tmp/sh linked to bash either.  
>So I suspect this isn't going to be a widely used release!

Works for me with bash-1.14.6(1).  Are you sure you're actually using
bash there?  You need to change the SHELL= lines in the Makefiles;
for safety you should probably just change everything.

-zefram

Re: zsh-3.1.2-zefram3

[Andrew Main]

Bruce Stephens wrote:
>And indeed, the line is illegal:
>
>            *[^_0-9A-Za-z]*@*)

Damn.  I'm usually pretty good at writing portable sh code; I didn't
realise this construct would be a problem.

>Presumably it should be *[!_0-9A-Za-z]*@*)

That won't work everywhere either.

>Correcting this leads to numerous errors in Src/mkmakemod.sh, starting with
>Src/../Src/mkmakemod.sh: syntax error at line 238: `(' unexpected

That's clever -- the ( is quoted.  There must have been a quoting
confusion earlier.

>Nor does zsh seem happy to run the scripts.  I tried changing SHELL to 
>/tmp/sh, and creating a symbolic link to an older zsh, but that gave much the 
>same errors.

The scripts were actually developed on a system using zsh-3.1.2 as sh,
and it also works for me using zsh-3.0.5.  Which version did it fail on?

>          It needs fixing up for a proper release.

That it does.  I'll have another go at the scripts, but unfortunately
my choice of shells is limited to zsh, bash, pdksh and ash, so more wide
testing will be required.  But that's what the 3.1 branch is for.

-zefram

Re: zsh-3.1.2-zefram3

[Bruce Stephens]

Doesn't seem to work if I replace /bin/sh with /tmp/sh linked to bash either.  
So I suspect this isn't going to be a widely used release!

Re: zsh-3.1.2-zefram3

[Sven Wischnowsky]

Andrew Main wrote:

>...
>
> N  3503 wischnow lots of nifty completion options
> 	This I did not include.  AUTO_GLOB_COMPLETE really has very
> 	little to do with GLOB_COMPLETE -- all it does is complete from
> 	the beginning of the word as well as the end.  This is the sort
> 	of thing that multicomp is for.  COMPLETE_FOLD_CASE I would
> 	have used had it been separate from the rest of the patch; it
> 	does something useful that can't easily be done in user space.
> 	The other compctl options (-. and -:) I do not like.  They seem
> 	to require an awful lot of code for something that, again,
> 	should really be part of a completion function.
> 

I'm all for doing this in shell functions, but zsh isn't strong enough
for that (yet). The problem is that things like multicomp only work
with menu-completion.

Question is, what excatly do we need to allow building arbitrary
completion lists in shell functions and have the code make them
conveniently accessible with normal completion. Maybe something like
`replace the current word with the prefix <a> and the suffix <b>,
placing the cursor between them'. But we would also need to be able to
return the whole completion list for automenu. Taking multicomp
(i.e. path) completion as an example that would mean to present either
the list of full paths or only the list of ambiguous path name
components.
Thinking about the latter leads to the suggestion that such functions
may return: `we split the current word into <prefix><ambig><suffix>
at positions <p0> and <p1> and want <prefix> be replaced by <a>,
suffix by <b>, and for <ambig> we offer the list of possible
completions in $reply, now present that to the user'. But that sounds
pretty complex (in fact this is near to what the compctl code does
internally), so does anyone see a simpler solution?


Bye
 Sven


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

Re: zsh-3.1.2-zefram3

[Bruce Stephens]

Working on Solaris2.5.1, I get:

if test D = N; then \
    cat ./xmods.conf > modules-bltin; \
elif test yes != yes; then \
    echo comp1 > modules-bltin; \
else \
    echo > modules-bltin; \
fi
( cd .. && /bin/sh Src/mkmodindex.sh Src ) \
    > modules.index.tmp
Src/mkmodindex.sh: syntax error at line 19: `^' unexpected
*** Error code 2
make: Fatal error: Command failed for target `Makemod'
Current working directory /ic/dev/users/brs/zsh-3.1.2-zefram3/Src
*** Error code 1
make: Fatal error: Command failed for target `Src'

And indeed, the line is illegal:

            *[^_0-9A-Za-z]*@*)
 
Presumably it should be *[!_0-9A-Za-z]*@*)

Correcting this leads to numerous errors in Src/mkmakemod.sh, starting with
Src/../Src/mkmakemod.sh: syntax error at line 238: `(' unexpected

and moving on to complain about "do", "then" and so on.

Nor does zsh seem happy to run the scripts.  I tried changing SHELL to 
/tmp/sh, and creating a symbolic link to an older zsh, but that gave much the 
same errors.

I'm guessing this was developed on Linux, or some other machine where /bin/sh 
is bash.  It needs fixing up for a proper release.

zsh-3.1.2-zefram3

[Andrew Main]

-----BEGIN PGP SIGNED MESSAGE-----

I've put together an unofficial release, version 3.1.2-zefram3.  I'm not
up to doing a full release like Zoltan's -- his scripts in the top-level
Makefile don't suit my setup -- so, as was previously my custom with
unofficial releases, the only generated files in the tar are the
autoconf ones.  You'd better have yodl.

Sizes:

117257 zsh-3.1.2-3.1.2-zefram3.diff.gz
669945 zsh-3.1.2-zefram3.tar.gz

MD5 checksums:

03be8fa383b7137f6c91963dbb00b541  zsh-3.1.2-3.1.2-zefram3.diff.gz
028b7c4e6fb9d9866e5ab44f23d0454d  zsh-3.1.2-zefram3.tar.gz

As I'm on a relatively slow link here, that isn't intended to support
an ftp server, someone else will have to host this release.  Offers of
ftp space would be appreciated.  Until these files are ftpable, I am
prepared to send copies to developers by email.

A complete list of patches considered for this release is included below.
I'd particularly like to discuss the recent ZLE-related feature patches:

y  3492 pws      compctl -/ for directory completion like -f
	I like this a lot.  I've really missed this capability in the
	past, and the way it is done here is impressively neat.  I also
	updated the compctl-examples script to use -/ where appropriate,
	which was quite a lot of places.

y  3498 pws      compctl -W to complete under a directory
	I suspect that this could be mostly achieved by -K functions.
	However, it doesn't seem to be possible to precisely duplicate
	the directory behaviour (-/), and this is reasonably neat.

N  3503 wischnow lots of nifty completion options
	This I did not include.  AUTO_GLOB_COMPLETE really has very
	little to do with GLOB_COMPLETE -- all it does is complete from
	the beginning of the word as well as the end.  This is the sort
	of thing that multicomp is for.  COMPLETE_FOLD_CASE I would
	have used had it been separate from the rest of the patch; it
	does something useful that can't easily be done in user space.
	The other compctl options (-. and -:) I do not like.  They seem
	to require an awful lot of code for something that, again,
	should really be part of a completion function.

N  3554 ajrh     allow vared to succeed on EOF
	This can be done by temporarily rebinding ^D to accept-line, or
	to a user-defined widget that conditionally calls accept-line.
	(See Functions/zed for an example of how to temporarily change
	bindings.)  Also, while I agree that vared -c is not much
	use, removing the option entirely will cause problems with
	some scripts.  Changing the default EOF behavior would cause
	similar problems.  While I would like the whole area of EOF
	handling in ZLE to be re-examined, this patch does not do a
	proper job of that.

N  3581 pws      keyboard macros for ZLE
	The functionality is good, but this should be done by *calling*
	the input function, not by modifying it.  Once input is done
	via widgets, this will be implementable in user space.

y  3636 pws      compctl -y and -Y
	compctl -y is good.  It does something that's been on my wish list
	for a long time.  Considering the way variables and functions
	can both be specified with -y, maybe this should be extended to
	-K for consistency.  compctl -Y is pretty useful and neat, but
	I include it with a reservation: perhaps it would be better to
	have the explanation *always* be expanded.  It wouldn't affect
	any scripts, and we could use $_ instead of that icky %n thing.


Patch list:

y  2999 zefram   RM_STAR_WAIT
y  3004 zefram   emulate sh's default prompt
y  3050 zefram   HIST_NO_FUNCTIONS
y  3052 zefram   NO_PROMPT_PERCENT
N  3196 pws      stty settings and background jobs [superseded by 3297]
y  3239 zefram   prompt formatting
y  3240 zefram   always build rlimits module
y  3241 zefram   have static struct builtin objects in modules
y  3242 zefram   makepro.awk handles all types of declaration
y  3243 zefram   move global object declarations into source files
y  3244 zefram   move documentation for bindkey et al into zshmodules(1)
y  3246 hzoli    filter out garbage when importing environment variables
y  3247 hzoli    AUTO_PARAM_KEYS bugfix
y  3249 pws      end-of-pattern markers in globbing
y  3250 zefram   paramsubst() fix for `set "$@"'
y  3251 pws      removed memory leak in disown
y  3252 zefram   automatic Makefile and header generation for module building
N  3253 suzuki   stty settings and background jobs [superseded by 3297]
N  3257 suzuki   stty settings and background jobs [superseded by 3297]
N  3258 hzoli    stty settings and background jobs [superseded by 3297]
y  3260 gcw      crash bug fix in ZLE refresh code
N  3261 pws      3.0 version of patch 3249 [3.0]
N  3263 suzuki   stty settings and background jobs [superseded by 3297]
N  3264 hzoli    stty settings and background jobs [superseded by 3297]
y  3285 pws      in `*(-M)' the (-) should affect interpretation of (M)
y  3293 hzoli    keep original environment around when initialising environment
y  3297 hzoli    stty settings and background jobs
y  3301 pws      fixing a couple of memory leaks
y  3302 suzuki   set STAT_NOSTTY if a job is ever backgrounded
y  3308 pws      avoid unwanted space addition in menu completion
y  3318 pws      PRINT_EIGHT_BIT
y  3353 zefram   ZLE suffix mechanism rewrite
y  3360 pws      Prefer -lcurses to -ltermcap on HP-UX 10.*
y  3368 hzoli    restrict use of leaf optimisation in recursive globs
y  3369 kunihiro rlimits.awk handles GNU-style <resourcebits.h>
N  3380 hzoli    RC_EXPAND_PARAM general weirdness fix [superseded by 3403]
N  3381 hzoli    `wrong character in hungetc()' fix [superseded by 3383]
y  3383 hzoli    `wrong character in hungetc()' fix, fixed
y  3403 hzoli    RC_EXPAND_PARAM, braces, and other widgets, consistentified
y  3417 pws      documentation for 3403 (markup not quite right)
N  3418 pws      print explanation iff there *are* matches [superseded by 3423]
y  3423 hzoli    print explanation iff there are !=1 matches
y  3424 pws      documentation for 3423
y  3438 pws      completion in braces (clashes with 3353)
N  3441 harres   zgetcwd() fix for automounted directories [redundant]
N  3446 pws      makepro.sed fix for HP-UX [redundant with 3242]
N  3456 hzoli    3.0.4: avoid double scan in zgetcwd() [3.0.4]
N  3478 mrb      zrealloc() performs the same checks as zalloc() [in 3522]
y  3484 schaefer c2z updates
y  3492 pws      compctl -/ for directory completion like -f
y  3493 pws      typo fix in documentation of 3492
y  3495 pws      compctl display fix for 3492
N  3496 pws      duplicate of 3495 [duplicate]
y  3498 pws      compctl -W to complete under a directory
y  3502 pws      typo fixes in new compctl options
N  3503 wischnow lots of nifty completion options [can be done in user space]
N  3507 wischnow #if 0 removal for 3503 [not using 3503]
y  3511 schaefer ZLE refresh bugfix
y  3513 pws      fix for globbing [[ fofo == (fo#)# ]], etc.
y  3514 pws      more glob fixes based on 3513
y  3515 pws      yet more glob closure fixes
y  3522 hzoli    3478; rlimits.awk portability; some parameter fiddling
y  3525 pws      cunning performance improvement for glob closures
y  3526 pws      $(r)
y  3531 pws      history suppression improvement
N  3547 pws      RC_EXPAND_PARAM fix for empty arrays [superseded by 3548]
y  3548 hzoli    better RC_EXPAND_PARAM fix for empty arrays
y  3549 pws      better documentation of history expansion modifiers
N  3554 ajrh     allow vared to succeed on EOF [can be done with widgets]
N  3558 wischnow fix for duplicating struct autofn [done a better way]
N  3565 wischnow fixes to 3503 [not using 3503]
N  3581 pws      keyboard macros for ZLE [should be done more cleanly]
N  3582 pws      fixes to 3581 [not using 3581]
N  3586 AIF      go interactive if sourcing a tty [awkward behaviour]
N  3590 pws      getopts fix [causes other buggy behaviour]
y  3598 pws      New version of helpfiles script
N  3621 pws      compctl -Y to display non-default list [superseded by 3636]
y  3625 eggink   ZLE startup shuffle to avoid problems with vared and subshells
N  3626 pws      compctl -Y with scalars [superseded by 3636]
y  3636 pws      compctl -y and -Y
N  3638 schizo   import $HISTCHARS [undesirable behaviour]
N  3644 wischnow duplicate of patch 3558 [duplicate]
N  3649 schaefer 3.0.5: do not adjust window size in zsh -c [3.0.5]
y u1068 pws      preexec shell function

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: ascii

iQEVAwUBNLkoLZmk9GeOHh7BAQFInQf9FDsiKIqNsuGsevrgkHxNwYoDItqcubtO
3cAgO4BNt89bOTTEoBP/1PSYHQdSxr1HPuNwhgljHLerAKp3yvEU10LKTQU/JhCu
fwiqzdACIGLbzuFCfba9rUBpyBqjSgMJ3gHBBh6EsjwLEFD2PIk1SSsK4InkE0Ll
ieSTDOqNNKIioi6X+r4GBBwPxBXRCTC5tH0ZLcPZBjdD4Ra5Uz2tJKrsieGI8vah
Z7UOKQUkM0lf3puejUkGy5Ib8Q/kEFtuh2g5HFRaIT3yFwDtiAGyyoFo8frByPGX
u4ntlc7xcrEotPLrUwSrEcGkS1ru5zaqM5G/Hj3rDhI2zkkVMzFSgQ==
=TzVC
-----END PGP SIGNATURE-----