* zsh-3.1.2-zefram3
@ 1998-01-12 11:27 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
0 siblings, 2 replies; 17+ messages in thread
From: Andrew Main @ 1998-01-12 11:27 UTC (permalink / raw)
To: zsh-workers
-----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-----
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3 on Solaris
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
@ 1998-01-13 9:29 ` Andrei Tcherepanov
1998-01-13 11:46 ` Andrew Main
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
1 sibling, 1 reply; 17+ messages in thread
From: Andrei Tcherepanov @ 1998-01-13 9:29 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
Hi!
Does somebody built on Solaris 2.5.1 ???
configure pass well, but on make it will explose in scripts.
It looks like scripts not work with solaris /bin/sh --
it have another translation for ' and " in echos
--
Thanks,
Andrei ( tandr@ptc.com )
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3 on Solaris
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
@ 1998-01-13 11:46 ` Andrew Main
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Main @ 1998-01-13 11:46 UTC (permalink / raw)
To: Andrei Tcherepanov; +Cc: zefram, zsh-workers
Andrei Tcherepanov wrote:
>Does somebody built on Solaris 2.5.1 ???
>
>configure pass well, but on make it will explose in scripts.
>
>It looks like scripts not work with solaris /bin/sh --
>it have another translation for ' and " in echos
Where does it fall over? Can you determine what part of which script
is at fault?
-zefram
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
@ 1998-01-18 15:14 ` Anthony Heading
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1 sibling, 1 reply; 17+ messages in thread
From: Anthony Heading @ 1998-01-18 15:14 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
@ 1998-01-18 17:38 ` Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
0 siblings, 2 replies; 17+ messages in thread
From: Bart Schaefer @ 1998-01-18 17:38 UTC (permalink / raw)
To: Anthony Heading, Andrew Main, zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
@ 1998-01-19 8:58 ` Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
1 sibling, 0 replies; 17+ messages in thread
From: Peter Stephenson @ 1998-01-19 8:58 UTC (permalink / raw)
To: Zsh hackers list
"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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
@ 1998-01-21 18:37 ` Anthony Heading
1 sibling, 0 replies; 17+ messages in thread
From: Anthony Heading @ 1998-01-21 18:37 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
@ 1998-01-20 0:46 Gene Cohler
0 siblings, 0 replies; 17+ messages in thread
From: Gene Cohler @ 1998-01-20 0:46 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 13:36 ` zsh-3.1.2-zefram3 Peter Stephenson
@ 1998-01-13 15:04 ` Bruce Stephens
0 siblings, 0 replies; 17+ messages in thread
From: Bruce Stephens @ 1998-01-13 15:04 UTC (permalink / raw)
To: Zsh hackers list
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 12:19 ` zsh-3.1.2-zefram3 Andrew Main
1998-01-13 12:49 ` zsh-3.1.2-zefram3 Bruce Stephens
@ 1998-01-13 13:36 ` Peter Stephenson
1998-01-13 15:04 ` zsh-3.1.2-zefram3 Bruce Stephens
1 sibling, 1 reply; 17+ messages in thread
From: Peter Stephenson @ 1998-01-13 13:36 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 12:19 ` zsh-3.1.2-zefram3 Andrew Main
@ 1998-01-13 12:49 ` Bruce Stephens
1998-01-13 13:36 ` zsh-3.1.2-zefram3 Peter Stephenson
1 sibling, 0 replies; 17+ messages in thread
From: Bruce Stephens @ 1998-01-13 12:49 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 12:24 ` zsh-3.1.2-zefram3 Andrew Main
@ 1998-01-13 12:44 ` Bruce Stephens
0 siblings, 0 replies; 17+ messages in thread
From: Bruce Stephens @ 1998-01-13 12:44 UTC (permalink / raw)
To: Andrew Main; +Cc: zsh-workers
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!
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 11:59 zsh-3.1.2-zefram3 Bruce Stephens
@ 1998-01-13 12:24 ` Andrew Main
1998-01-13 12:44 ` zsh-3.1.2-zefram3 Bruce Stephens
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Main @ 1998-01-13 12:24 UTC (permalink / raw)
To: Bruce Stephens; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
1998-01-13 11:44 zsh-3.1.2-zefram3 Bruce Stephens
@ 1998-01-13 12:19 ` Andrew Main
1998-01-13 12:49 ` zsh-3.1.2-zefram3 Bruce Stephens
1998-01-13 13:36 ` zsh-3.1.2-zefram3 Peter Stephenson
0 siblings, 2 replies; 17+ messages in thread
From: Andrew Main @ 1998-01-13 12:19 UTC (permalink / raw)
To: Bruce Stephens; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
@ 1998-01-13 11:59 Bruce Stephens
1998-01-13 12:24 ` zsh-3.1.2-zefram3 Andrew Main
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Stephens @ 1998-01-13 11:59 UTC (permalink / raw)
To: zsh-workers
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!
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
@ 1998-01-13 11:56 Sven Wischnowsky
0 siblings, 0 replies; 17+ messages in thread
From: Sven Wischnowsky @ 1998-01-13 11:56 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: zsh-3.1.2-zefram3
@ 1998-01-13 11:44 Bruce Stephens
1998-01-13 12:19 ` zsh-3.1.2-zefram3 Andrew Main
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Stephens @ 1998-01-13 11:44 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1998-01-21 18:59 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-01-12 11:27 zsh-3.1.2-zefram3 Andrew Main
1998-01-13 9:29 ` zsh-3.1.2-zefram3 on Solaris Andrei Tcherepanov
1998-01-13 11:46 ` Andrew Main
1998-01-18 15:14 ` zsh-3.1.2-zefram3 Anthony Heading
1998-01-18 17:38 ` zsh-3.1.2-zefram3 Bart Schaefer
1998-01-19 8:58 ` zsh-3.1.2-zefram3 Peter Stephenson
1998-01-21 18:37 ` zsh-3.1.2-zefram3 Anthony Heading
1998-01-13 11:44 zsh-3.1.2-zefram3 Bruce Stephens
1998-01-13 12:19 ` zsh-3.1.2-zefram3 Andrew Main
1998-01-13 12:49 ` zsh-3.1.2-zefram3 Bruce Stephens
1998-01-13 13:36 ` zsh-3.1.2-zefram3 Peter Stephenson
1998-01-13 15:04 ` zsh-3.1.2-zefram3 Bruce Stephens
1998-01-13 11:56 zsh-3.1.2-zefram3 Sven Wischnowsky
1998-01-13 11:59 zsh-3.1.2-zefram3 Bruce Stephens
1998-01-13 12:24 ` zsh-3.1.2-zefram3 Andrew Main
1998-01-13 12:44 ` zsh-3.1.2-zefram3 Bruce Stephens
1998-01-20 0:46 zsh-3.1.2-zefram3 Gene Cohler
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).