Bug#993843: [BUG] With --disable-dynamic-nss, not all functions calls are protected

2021-09-15 Thread Bart Schaefer
On Wed, Sep 15, 2021 at 7:32 AM Axel Beckert wrote: > > But copying zsh-static on a system with a different libc6 version > still segfaults, so this patch might be necessary but not sufficient. > > Last line is: > > zsh-static: dl-call-libc-early-init.c:37: _dl_call_libc_early_init: >

Bug#875460: Fwd: `rm *` count is incorrect with `setopt GLOB_DOTS`

2018-04-16 Thread Bart Schaefer
The below patch (with mangled whitespace corrected) should be in the zsh 5.5.1 release. -- Forwarded message -- From: Bart Schaefer <schae...@brasslantern.com> Date: Fri, Apr 13, 2018 at 6:48 PM Subject: Re: `rm *` count is incorrect with `setopt GLOB_DOTS` To: zs

Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"

2016-11-19 Thread Bart Schaefer
On Nov 19, 7:55am, Daniel Shahaf wrote: } Subject: Re: Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrecti } } Martin Steigerwald wrote on Fri, Nov 18, 2016 at 14:15:51 +0100: } > So two fixes to consider: } > } > 1) Don't confirm on space, as thats to easy to trigger accidentally. :)

Bug#765410: ulimit broken as root if it fails once [origin: goswin-...@web.de]

2014-10-22 Thread Bart Schaefer
On Oct 16, 9:22am, Peter Stephenson wrote: } Subject: Re: Bug#765410: ulimit broken as root if it fails once [origin: g } } On Wed, 15 Oct 2014 19:49:13 -0700 } Bart Schaefer schae...@brasslantern.com wrote: } This could also be fixed by having bin_ulimit read back the actual limit } after

Bug#765410: Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-...@web.de]

2014-10-15 Thread Bart Schaefer
On Oct 16, 12:33am, Axel Beckert wrote: } } the following has been reported in Debian at } http://bugs.debian.org/765410 and I can reprodcue it with 4.3.10, } 4.3.17, 5.0.6 and 5.0.7. } } The issue seems to only appear if ulimit is run as root user. I was } not able to reproduce it as non-root

Bug#760061: [Pkg-zsh-devel] Bug#760061: 5 seconds to fail

2014-10-01 Thread Bart Schaefer
On Sep 30, 7:40pm, Axel Beckert wrote: } } But I have a slight hope that enabling verbose output avoids some race } condition which is triggering this issue occasionally. That's quite likely. Also the patch in zsh-workers/33298 may resolve some deadlocks caused by signals interrupting memory

Bug#760061: [Pkg-zsh-devel] Bug#760061: 5 seconds to fail

2014-09-29 Thread Bart Schaefer
On Sep 29, 3:51am, Axel Beckert wrote: } } 1) Hangs in the static build at } } ../../Test/A04redirect.ztst: starting. This doesn't mean very much; none of the tests in A04 produce any output (unless they fail) so it could be stuck anywhere. To refine, the make check need to be run with

Bug#733075: Bug#733075: zsh: command completion not working after semicolon

2013-12-25 Thread Bart Schaefer
On Dec 25, 12:01pm, Frank Terbeck wrote: } } I git-bisected this to: } } [568e0db7a964feefa45061967d0c7079a0e59c1e] } 31611: attempt to fix crash completing redirection in do loop } } This is in zle_tricky.c, so naturally I'm afraid to touch it. :) I think this is the right thing, but it

Bug#353863: Bugreport: completion hanging at uboTab - endless loop

2011-02-23 Thread Bart Schaefer
On Wednesday, February 23, 2011, Peter Stephenson p.w.stephen...@ntlworld.com wrote: To analyse a command line to find the current context, completion adds an x at the cursor position which it later removes.  In this case, the x completes the word ubox, which is then expanded to ls.  The

Bug#593426: zsh: Status of background jobs not updated

2010-08-19 Thread Bart Schaefer
On Aug 20, 12:14am, Jilles Tjoelker wrote: } } [continuing a stopped background job using kill is not reflected in the } output of jobs] } } I think hooking into the kill builtin is the wrong way to fix this. } Instead, use the facilities provided by modern systems which can notify } you if a

Bug#593426: zsh: Status of background jobs not updated

2010-08-19 Thread Bart Schaefer
On Aug 18, 9:09pm, Peter Stephenson wrote: } } + } else if (sig == SIGCONT) { } + Job jn; } + Process pn; } + if (findproc(pid, jn, pn, 0)) { } + if (WIFSTOPPED(pn-status)) } + pn-status = SP_RUNNING; } +

Bug#526924: zparseopts: should use lists as values in assoc array

2009-05-05 Thread Bart Schaefer
On May 5, 4:05pm, Clint Adams wrote: } } set -- -a1 -a2; zparseopts 'a+:=arr'; print -l $arr } } although this seems to set arr=(1 -a 2), which is not what I } expected to happen. The parameter is set to (-a 1 -a 2), but print -l $arr is consuming the first -a as an option to print. -- To

Bug#517008: alias not expanded with zsh -c

2009-03-25 Thread Bart Schaefer
On Mar 25, 5:25pm, Peter Stephenson wrote: } Subject: Re: Bug#517008: alias not expanded with zsh -c } } Yes, at least as far as native zsh mode goes this isn't a bug. } } I should also have pointed out that the emulate sh doesn't make any } difference, it only takes effect after the string for

Bug#517008: alias not expanded with zsh -c

2009-03-25 Thread Bart Schaefer
On Mar 25, 6:20pm, Peter Stephenson wrote: } } But yes, I share your feeling that this isn't a particularly vital } addition, it just looked easy to do like other shells in compatability } mode, which is the point of that. It just seems to me that we're potentially penalizing a script that does

Bug#162291: Bug in executable completion: unable to handle .. it $PATH

2009-01-07 Thread Bart Schaefer
On Jan 7, 8:09pm, Peter Stephenson wrote: } } This is done explicitly in the code, but I have no idea why; it precedes } the CVS archive. The function isrelative() is only used by hashdir(). I believe it's a security thing, so that an inherited $PATH can't fool someone into executing code from

Bug#497663: Tab completion for vim is broken

2008-09-04 Thread Bart Schaefer
On Sep 4, 10:03am, Clint Adams wrote: } Subject: Re: Bug#497663: Tab completion for vim is broken } } On Thu, Sep 04, 2008 at 12:05:05PM +0300, Arto Jantunen wrote: } Typing vim and pressing tab produces the following output: } } _vim:31: unmatched ' } } Hmm. Apparently it depends on

Bug#494098: zsh: Prompt expansion of %~ seems broken.

2008-08-11 Thread Bart Schaefer
On Aug 11, 1:31pm, Clint Adams wrote: } Subject: Re: Bug#494098: zsh: Prompt expansion of %~ seems broken. } } On Mon, Aug 11, 2008 at 09:19:37AM +0100, Magnus Therning wrote: } } ~: cd Desktop } /home/magnus/Desktop: print -P %~ } /home/magnus/Desktop } /home/magnus/Desktop: cd

Bug#482346: zsh doesn't always wait for its children (- zombie)

2008-05-25 Thread Bart Schaefer
On May 26, 1:34am, Vincent Lefevre wrote: } } Now, I could reproduce the problem with both bash and pdksh. } I don't know why I couldn't reproduce it the first times while it is } 100% reproducible under zsh (perhaps timings are a bit different). It's possible that zsh is passing a larger *envp

Bug#482346: zsh doesn't always wait for its children (- zombie)

2008-05-24 Thread Bart Schaefer
On May 24, 4:27pm, Stephane Chazelas wrote: } } From the straces, we see that zsh is not receiving any SIGCHLD. If that were the only problem, then opening another shell window and performing kill -CHLD ... on the original shell should clear it all up. But as PWS pointed out, the spiking load

Bug#482346: zsh doesn't always wait for its children (- zombie)

2008-05-23 Thread Bart Schaefer
On May 22, 11:33pm, Clint Adams wrote: } } Any ideas what might be going on? Race condition? What version of the shell are we dealing with here? Does it have PWS's patch from users/12815? I've been a little worried that that is too simple. On the other hand, if it does not have users/12815,

Bug#479764: shell builtin mv fails to move files across devices

2008-05-06 Thread Bart Schaefer
On May 6, 4:03pm, Clint Adams wrote: } } Anyone up for changing this in a future version? } } Note that this mv will not move files across devices. Historical } versions of mv, when actual renaming is impossible, fall back on copying } and removing files; if this behaviour is

Bug#468386: zsh-beta: Slow command completion

2008-03-02 Thread Bart Schaefer
On Mar 2, 4:07pm, Romain Francoise wrote: } } Which suggests that most of the time is spent building the arrays } fed to compadd and/or formatting $descs w/ zformat. AIUI, before } your change for 24570 most of the contents of $commands were being } thrown away, and it's no longer the case.

Bug#468386: zsh-beta: Slow command completion

2008-02-28 Thread Bart Schaefer
On Feb 28, 12:27pm, Clint Adams wrote: } Subject: Re: Bug#468386: zsh-beta: Slow command completion } } On Thu, Feb 28, 2008 at 06:03:41PM +0100, Romain Francoise wrote: } zsh-beta's command cache is apparently broken: completing a command } twice takes the same amount of time both times,

Bug#458397: zsh: completion does not succeed with a function named the same as a command

2007-12-31 Thread Bart Schaefer
On Dec 31, 11:11am, Clint Adams wrote: } Subject: Re: Bug#458397: zsh: completion does not succeed with a function } } On Sun, Dec 30, 2007 at 11:48:45PM +0100, Adeodato Simó wrote: } dato Clint: if I have a zsh function with the same name as a binary in } PATH, completion does not work

Bug#451382: i18n is NOT so easy!

2007-12-09 Thread Bart Schaefer
On Dec 9, 6:01pm, Peter Stephenson wrote: } Subject: Re: Bug#451382: i18n is NOT so easy! } } This scheme has various merits: (i) it is robust about changes to } the English text (ii) the explicit msgid serves as a visual cue that } there's something here that shouldn't be monkeyed with without

Bug#428110: zsh: endless loop in command fc

2007-06-09 Thread Bart Schaefer
On Jun 9, 11:56am, Clint Adams wrote: } Subject: Re: Bug#428110: zsh: endless loop in command fc } } On Sat, Jun 09, 2007 at 05:17:13AM +0200, komar wrote: } } If I enter this 4 command: } === } echo 1 } echo 2 } r -2 -1 } r -2 -1 } === } endless loop I think you want setopt

Bug#317773: LC_ALL=C foo, where foo is a shell function

2007-04-14 Thread Bart Schaefer
On Apr 14, 3:38pm, Clint Adams wrote: } } On Sun, Jul 10, 2005 at 12:57:47AM +, Bart Schaefer wrote: } I just noticed Nearly two years ago. Phrases like just now certainly take on a different flavor in the face of permanent archival ... } that, even in the latest build, if LC_ALL starts

Bug#416441: Patch

2007-03-31 Thread Bart Schaefer
On Mar 31, 1:01pm, Clint Adams wrote: } Subject: Re: Bug#416441: Patch } } On Sat, Mar 31, 2007 at 06:41:27PM +0200, Erik Johansson wrote: } The attached patch fixes the problem for me. } } Thanks. } } --- _module.ORG 2007-03-31 17:47:42.0 +0200 } +++ _module 2007-03-31

Bug#355430: zsh: acroread completion prints debugging information

2006-03-25 Thread Bart Schaefer
On Mar 25, 1:34pm, Clint Adams wrote: } } No, it happens for me too, and I don't have acroread installed. } Somehow the caret is Plan9-ing away the ver= outside the ${} } or something. That doesn't seem to be it either. E.g.: schaefer502 print -R ver=${${${(f)$(/dev/null)}:#^ver=*}##ver=} ver=

Bug#315255: zsh: cvs commit completion breaks on spaces

2005-06-22 Thread Bart Schaefer
On Jun 21, 9:30pm, Clint Adams wrote: } Subject: Re: Bug#315255: zsh: cvs commit completion breaks on spaces } } Adding the parens makes it do the right thing in this particular case. I'm concerned that the parens will be confused for a glob qualifier if there is only one possible match. If

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-06-01 Thread Bart Schaefer
On Jun 1, 11:31am, Peter Stephenson wrote: } Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR). } } Adding SIGERR as an alias where there's no system signal is trivial. } Now it should show up in the trap lists under ERR, too. I've removed } the ALT_SIGS definition because

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-06-01 Thread Bart Schaefer
On Jun 1, 11:31am, Peter Stephenson wrote: } Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR). } } Bart Schaefer wrote: } I note in passing that trap in zsh doesn't understand all the same } signals that kill does. For example, when the OS defines both, kill

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-06-01 Thread Bart Schaefer
On Jun 1, 1:57pm, Bart Schaefer wrote: } } I just discovered another reason why we use ZERR: Urk, never mind that; I'm not awake yet. Unrelated ERR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-05-30 Thread Bart Schaefer
On May 30, 10:06am, Clint Adams wrote: } Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR). } } If the wise people on zsh-workers think that not understanding ERR is } acceptable for ksh emulation, I'm inclined to do nothing. Please note that I was not making any sort of

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-05-27 Thread Bart Schaefer
On May 27, 2:50pm, Christophe Martin wrote: } Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR). } } Bart Schaefer a écrit : } } A possible workaround would be } } (( $signals[(I)ERR] )) || alias -g ERR=ZERR } } But, If i keep zsh as ksh } I have to rewrite every

Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

2005-05-26 Thread Bart Schaefer
On May 26, 3:15pm, Clint Adams wrote: } Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR). } } This simple command fails using zsh as ksh (I did update-alternatives) : } } trap 'echo alert-an-error-occured' ERR Zsh does not provide an ERR trap because some