Bug#993843: [BUG] With --disable-dynamic-nss, not all functions calls are protected
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: > Assertion `sym != NULL' failed. Based on the strace, my guess would be that getrlimit() is what's attempting to link to the dynamic library. This is based on the success of the uname() call and on what does NOT appear in the subsequent trace output. If getrlimit() does have this effect, it's possible that getrusage() will as well.
Bug#875460: Fwd: `rm *` count is incorrect with `setopt GLOB_DOTS`
The below patch (with mangled whitespace corrected) should be in the
zsh 5.5.1 release.
-- Forwarded message --
From: Bart Schaefer
Date: Fri, Apr 13, 2018 at 6:48 PM
Subject: Re: `rm *` count is incorrect with `setopt GLOB_DOTS`
To: zsh-work...@plast.id.au
Cc: "zsh-work...@zsh.org"
On Fri, Apr 13, 2018 at 5:23 PM, wrote:
>
> When I run `rm *`, zsh asks if I "want to delete all x files", where x
> is the number of files to be deleted. However, with `setopt GOB_DOTS`,
> this number appears to be two more than the actual number of files.
It's counting "." and ".." because, well, they begin with a dot.
It's actually wrong any time the directory contains files beginning
with ".", it's just LESS wrong when GLOB_DOTS.
Apologies if this gets line-folded badly:
diff --git a/Src/utils.c b/Src/utils.c
index 180693d..2a006b4 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2775,10 +2775,11 @@ checkrmall(char *s)
const int max_count = 100;
if ((rmd = opendir(unmeta(s {
int ignoredots = !isset(GLOBDOTS);
-/* ### TODO: Passing ignoredots here is wrong. See workers/41672
- aka <https://bugs.debian.org/875460>.
- */
-while (zreaddir(rmd, ignoredots)) {
+char *fname;
+
+while ((fname = zreaddir(rmd, 1))) {
+if (ignoredots && *fname == '.')
+continue;
count++;
if (count > max_count)
break;
Bug#844710: Fwd: Re: [Pkg-zsh-devel] Bug#844710: autocorrection suggested rm for typing mr without typing "y"
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. :) } } The code confirms on both tabs (since commit 7f1ce570) and spaces (since } before CVS). Does anyone know a reason for doing this? If you have a look at the zsh-workers article referenced by 7f1ce570, you'll see that both space and tab date from time immemorial; the patch in 7f1ce570 actually REMOVES the interpretation of tab as "yes" from the NO_RM_STAR_SILENT option, it didn't change CORRECT handling. Why it's this way probably has more to do with Paul Falstad's typing habits than anything else. If you're used to hitting space or tab at a completion, and most of the time you believe the correction, then you probably want space and tab to mean "go ahead" anytime the shell is waiting for something. Notice the RM_STAR_WAIT option for a similar situation. While I don't use CORRECT and therefore personally don't much care what this prompt does, I question whether one person remarking about this after 25+ years of it being the way it has been, is a sufficient reason for us to immediately change it.
Bug#765410: ulimit broken as root if it fails once [origin: goswin-...@web.de]
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 wrote:
} > This could also be fixed by having bin_ulimit read back the actual limit
} > after a failure to set the hard limit and store that instead of keeping
} > the "desired" hard limit around and trying to change it again.
}
} I think that would be preferable --- I noted after the last ulimit query
} (zsh-workers/33363, about a different implementation oddity) that this
} looked potentially confusing.
Patch below fixes the command name in the warning message as well.
diff --git a/Src/Builtins/rlimits.c b/Src/Builtins/rlimits.c
index 9da3183..85ec181 100644
--- a/Src/Builtins/rlimits.c
+++ b/Src/Builtins/rlimits.c
@@ -518,7 +518,7 @@ do_limit(char *nam, int lim, rlim_t val, int hard, int
soft, int set)
}
} else
limits[lim].rlim_cur = val;
- if (set && zsetlimit(lim, "limit"))
+ if (set && zsetlimit(lim, nam))
return 1;
}
}
diff --git a/Src/exec.c b/Src/exec.c
index d0fadd6..2f896d8 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -250,6 +250,7 @@ zsetlimit(int limnum, char *nam)
if (setrlimit(limnum, limits + limnum)) {
if (nam)
zwarnnam(nam, "setrlimit failed: %e", errno);
+ limits[limnum] = current_limits[limnum];
return -1;
}
current_limits[limnum] = limits[limnum];
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765410: Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-...@web.de]
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 user. (I was also unable to } reproduce it on any of Debian's kfreebsd-* architectures, so it may be } a linux-only issue, too.) This is primarily a documentation issue. As root, "ulimit" by default attempts to raise both the hard and soft limits, but only lowers the soft ones. Each time you try to lower the soft limit, it attempts to re-assert the previously specified hard limit, and generates the error -- but the soft limit is in fact been correctly changed, as you can see by examining the output of the "limit" command (without the leading "u"). To lower the hard limit again and make the error message go away, one simply has to use "ulimit -H ...". This could also be fixed by having bin_ulimit read back the actual limit after a failure to set the hard limit and store that instead of keeping the "desired" hard limit around and trying to change it again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760061: [Pkg-zsh-devel] Bug#760061: "5 seconds to fail"
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 management. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760061: [Pkg-zsh-devel] Bug#760061: "5 seconds to fail"
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 ZTST_verbose=1 in the environment. See Test/ztst.zsh for more. } 2) Hangs in the static build at } } This test takes 5 seconds to fail... This is the only one to which my previous discussions apply. I've since reproducesd this several times, never intentionally but it always happens immediately after recompiling the binaries. } 3) Hangs in the static build at } } ../../Test/A05execution.ztst: starting. Again this could be in any test, if possible retry with ZTST_verbose=1 } 4) Hangs in the non-static build at } } ../../Test/X02zlevi.ztst: starting. Once more, anywhere. X02 manipulates zpty terminals to emulate an interactive session, so is a likely place for race conditions. } 5) Hangs in the non-static build at } } This test takes 5 seconds to fail... See (2). } 6) Hangs in the non-static build at } } ../../Test/A05execution.ztst: starting. See (3). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733075: Bug#733075: zsh: command completion not working after semicolon
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 would be helpful if someone
can also check that the redirection issue has not regressed. (There
are no tests of command completion in Y01, so I'm not sure how to
add a regression test for these.)
diff --git a/Src/Zle/zle_tricky.c b/Src/Zle/zle_tricky.c
index 25f09c4..9d163ad 100644
--- a/Src/Zle/zle_tricky.c
+++ b/Src/Zle/zle_tricky.c
@@ -1071,7 +1071,7 @@ has_real_token(const char *s)
static char *
get_comp_string(void)
{
-enum lextok t0, tt0;
+enum lextok t0, tt0, cmdtok;
int i, j, k, cp, rd, sl, ocs, ins, oins, ia, parct, varq = 0;
int ona = noaliases;
/*
@@ -1146,6 +1146,7 @@ get_comp_string(void)
linredir = inredir;
zsfree(cmdstr);
cmdstr = NULL;
+cmdtok = NULLTOK;
zsfree(varname);
varname = NULL;
insubscr = 0;
@@ -1264,6 +1265,7 @@ get_comp_string(void)
ins = (tok == REPEAT ? 2 : (tok != STRING));
zsfree(cmdstr);
cmdstr = ztrdup(tokstr);
+ cmdtok = tok;
/* If everything before is a redirection, don't reset the index */
if (wordpos != redirpos)
wordpos = redirpos = 0;
@@ -1271,10 +1273,11 @@ get_comp_string(void)
/*
* A following DOLOOP should cause us to reset to the start
* of the command line. For some reason we only recognise
-* DOLOOP for this purpose (above) if ins is set. Why?
-* Don't ask pointless questions.
+* DOLOOP for this purpose (above) if ins is set. Why? To
+* handle completing multiple SEPER-ated command positions on
+* the same command line, e.g., pipelines.
*/
- ins = 1;
+ ins = (cmdtok != STRING);
}
if (!lexflags && tt0 == NULLTOK) {
/* This is done when the lexer reached the word the cursor is on. */
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#353863: Bugreport: completion hanging at ubo - endless loop
On Wednesday, February 23, 2011, Peter Stephenson 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 > completion system doesn't notice and assumes it still has the original > command line. Maybe the right thing to do here is insert something other than an "x" -- a metafied character, for example, something that can't appear in normal input. Unfortunately I'm not able to look at the source at the moment so I don't know whether the string is already metafied at that point. At least pick something less likely to form part of an actual word. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593426: zsh: Status of background jobs not updated
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;
} + }
} + }
Hmm, are we really guaranteed that the job has started running again
just because we killed it with SIGCONT? E.g., if the reason it was
stopped is because it got a TTIN or TTOU, is there a possible race
here because it's just going to immediately stop again?
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593426: zsh: Status of background jobs not updated
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 child process continues. These are si_code CLD_CONTINUED for } SIGCHLD and the WCONTINUED flag and WIFCONTINUED() macro for waitpid(). Zsh *soes* use those facilities. The problem (if I understand the thread so far correctly) is, in order to use those facilities, zsh has to wait for the job, i.e., call one of waitpid() or the like. But the shell doesn't just sit around all day waiting for background jobs or polling the ones that are stopped to see if they spontaneously started again -- in fact the whole point is that it does NOT wait for background jobs. So unless the OS sends a SIGCHLD when the background job changes state, zsh isn't aware that it ought to check on the child status. There is a SIGCHLD sent to the parent when the background job stops, but that signal is NOT sent when the child resumes running again. You can even see this for yourself by installing a handler, e.g., trap "print CHILD" SIGCHLD Now run something in the background, kill it with -STOP/-CONT from some other shell, and watch when CHILD is printed (or isn't). -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526924: zparseopts: should use lists as values in assoc array
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 UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517008: alias not expanded with zsh -c
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 not use aliases in the can't-open-tempfile case in order to support a script that does not use aliases. Given potential security problems with using tempfiles and the likelyhood of a script using an alias vs. the likelyhood of file creation failing, which case ought we be catering too? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517008: alias not expanded with zsh -c
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 -c has already been } parsed---it's basically the same issue as the alias expansion one itself. It's my recollection that the discussion of this on the austin-group list led to the conclusion that zsh's native behavior in this case is within the allowed variation in the POSIX spec. Vincent, if you're reading this, do you disagree, and can you point out why? My personal feeling is that aliases are an interactive convenience that should never be used in scripts (including "sh -c") in the first place. } You would need to start the shell in the appropriate mode. I don't think } that's an unreasonable requirement. Especially considering that now you can do emulate sh -c "..." which is admittedly a little clumsy to use as in zsh -c 'emulate sh -c "..."' but nevertheless is available to get the desired effect. } Is the fix as simple as the following? This is not a trick question, I } could very easily have missed something. Will this cover "emulate -c"? I'm a bit leery of even starting down this road, because it still fails to make any difference if the alias definition and use are on the same line (separated with ";" or "&&" etc.). -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#162291: Bug in executable completion: unable to handle .. it $PATH
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 an unexpected place. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497663: Tab completion for vim is broken
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 "emulate csh" being used. } } Anyone know which option might be the culprit here? Line 31 of _vim is a single-quoted string that spans multiple lines. So CSH_JUNKIE_QUOTES is almost certainly at fault. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494098: zsh: Prompt expansion of %~ seems broken.
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 .. } > >> /home/magnus: print -P %~ } > >> /home/magnus } } Beats me. Anyone have ideas? It's the trailing slash in the value of the home directory in passwd: > ~ grep magnus /etc/passwd > magnus:x:1000:1000:Magnus Therning,,,:/home/magnus/:/bin/zsh [[ /home/magnus/ != /home/magnus ]] so $HOME is not being recognized as a prefix of any subdirectory. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482346: zsh doesn't always wait for its children (-> zombie)
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 or some similar difference, that makes it more likely the bug is tickled. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482346: zsh doesn't always wait for its children (-> zombie)
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 indicates that either
vlc or zsh is actively doing something, which may have to do with the
way zsh progates signals, or how it sets the signal masks before
forking vlc in the first place.
If it's zsh that's looping, then Vincent's stack trace indicates it
must be here in zwaitjob:
while (!errflag && jn->stat &&
!(jn->stat & STAT_DONE) &&
!(interact && (jn->stat & STAT_STOPPED))) {
signal_suspend(SIGCHLD);
/* job handling stuff elided */
child_block();
}
But if *that* were a tight loop, it would mean that signal_suspend()
isn't working. It'd be nice to know what process or processes send
the load so high; 100% CPU usage is one thing, but 26+ processes in
runnable state sounds like another thing entirely.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482346: zsh doesn't always wait for its children (-> zombie)
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, it's possible that zsh is actually waiting for some other job that doesn't exist any more, and interrupting vlc is a red herring. I note from the ps output that PIDs have rolled over since the shell was started, which is exactly the case where that patch would come into play. } On Thu, May 22, 2008 at 01:50:08AM +0200, Vincent Lefevre wrote: } > I started vlc from the zsh command line. Some time later, I decided } > to kill vlc with Ctrl-C. As I didn't get the prompt, I tried Ctrl-C } > a few more times, with no change. I can see that vlc is now a zombie: } > } > ay:~> ps -ft pts/5 } > UIDPID PPID C STIME TTY TIME CMD } > lefevre 4277 20147 1 01:16 pts/500:00:26 [vlc] } > lefevre 20147 20126 0 May06 pts/500:00:00 zsh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479764: shell builtin mv fails to move files across devices
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 desired, use cp and rm manually. } This may change in a future version. I'd rather we didn't. rename(2) is atomic, but there's no reasonable way to make cp+rm be so, and I think it's better if the user is forced to be aware of the issue. Also note that "cp" is (intentionally) NOT one of the commands supplied by the zsh/files module, so changing mv means implementing cp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468386: zsh-beta: Slow command completion
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.
That's correct. Before 24570 *all* of the contents of $commands were
being thrown away in some circumstances. You get a choice between
slow and correct or fast and worthless.
After Clint's 24650 you can also have fast and correct but less helpful
(if the command descriptions really were helpful to begin with).
It belatedly occurs to me that the following might work as a replacement
for ${(k)commands[(I)$PREFIX]} and speed things up, except on the very
first call when the cache is populating (which may take a very long time).
--- ../zsh-forge/current/Completion/Unix/Type/_path_commands2008-03-02
09:57:33.0 -0800
+++ Completion/Unix/Type/_path_commands 2008-03-02 10:10:54.0 -0800
@@ -50,9 +50,10 @@
fi
if [[ -n $need_desc ]]; then
- typeset -a dcmds descs cmds
+ typeset -a dcmds descs cmds matches
local desc cmd sep
- for cmd in ${(k)commands}; do
+ compadd "$@" -O matches -k commands
+ for cmd in $matches; do
desc=$_command_descriptions[$cmd]
if [[ -z $desc ]]; then
cmds+=$cmd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468386: zsh-beta: Slow command completion
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, whereas in zsh4 } > (from the zsh package) the first completion takes a few seconds and } > subsequent completions are much faster. } } This looks to be a side effect of 24570. Any ideas? Scrap the part of _path_commands that reads "whatis" output? As I said in 24570, I think that was a truly horrible idea in the first place. Or at least protect it with a style that is not generally set for any other purpose. The workaround for Romain is probably to enable caching of the output by creating a cache-policy style for :completion::complete:-command-:: context. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458397: zsh: completion does not succeed with a function named the same as a command
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: } > Clint: if I have a zsh function with the same name as a binary in } > PATH, completion does not work correctly: I can type up to the whole } > name and press , and a space won't be added, it'll still offer the } > two identical names for completion. } > } > I can reproduce with no zsh configuration files whatsoever. } } I could just be sleep-deprived, but this seems to be fine under 4.3.4 } and spaceless under 4.3.4-dev-6. I am unable to reproduce this with 4.3.4-dev-6 on CentOS 4.6. torch% whence -av gprof gprof is a shell function gprof is /usr/bin/gprof torch% gpr torch% gprof I get the trailing space, zsh -f both with and without compinit loaded. I've also tried it with a command for which there is an explicit entry in the $_comps hash; I still get the space added.
Bug#451382: i18n is NOT so easy!
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 good
} reason (and that even if you change the English text it should mean
} the same thing) (iii) the msgid in the catalogues is compact.
This is close to the same scheme that I [*] adopted for localization
of zmail twelve years ago. Except that we used a two-argument C
macro with the msgid and English text, rather than a delimited string.
We also had a number of tools that massaged the C source to add any new
msgid where a programmer had forgotten to use one, and to extract and
build the default English catalog file which could then be turned over
to translators. It'd be pretty easy, I expect, to write a perl script
to find $"..." strings in shell scripts and extract them.
I'd be cautious about treating everything up to the first colon in a
$"..." string as a msgid key, though. Error messages are going to
look like $"thing that failed: reason it failed" a lot of the time. Or
would that have to be written "thing that failed: "$"reason it failed"
for this to work in the first place? Anyway, it might be better to
adopt something like $"{msgid}original text" and treat both $"{message}"
and $"message" the same when only one of the two parts is found.
An additional issue that zsh may or may not have to address is that
you need entirely separate strings for things like plurals. You can't
localize something like:
There %s %d thing%s in the bucket
where the %s get replaced by "are" and "s" when the %d is not 1, and
"is" and "" otherwise. You must instead have two strings (sometimes
three for the zero case):
There are %d things in the bucket
There is 1 thing in the bucket
There is nothing in the bucket
There are gobs of other niggling details that I'm sure I've forgotten.
} However, it seems like we can get something better by interfacing to
} the library at a lower level, in particular to catopen() (strictly
} this is a different family of interfaces). That accepts an absolute
} path to a catalogue and also uses the environment variable NLSPATH to
} search for files.
This is also what I did back then in zmail -- gettext() didn't really
even exist yet at that point, at least not in a fully-developed form.
The POSIX cat*() interfaces work just fine, though NLSPATH searching
has some pretty nasty bugs on older operating systems.
[*] That's sort of the royal "I" as actually there was a whole team
of people working for me on it.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428110: zsh: endless loop in command fc
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 hist_no_store" ... (The shell is like any other programming language, it'll enter an infinite loop if you program it to do so.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317773: LC_ALL=C foo, where foo is a shell function
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 out set
} > (even to nothing), but not exported, then when "LC_ALL=C foo" is run
} > LC_ALL becomes and remains exported, even though its value gets reset
} > to the previous state.
}
} I'm think seeing the same behavior in current CVS.
I'm not able to reproduce it with the latest CVS on my RHEL4 machine, or
at least I can't do so with the most straightforward interpretation of
"LC_ALL starts out set".
If it is happening, it has to be related to this (params.c):
void
lc_allsetfn(Param pm, char *x)
{
strsetfn(pm, x);
if (!x) {
queue_signals();
setlang(getsparam("LANG"));
unqueue_signals();
}
else
setlocale(LC_ALL, x);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416441: Patch
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 17:55:08.0 +0200
} > @@ -83,7 +83,7 @@
} > # Fills the available modules cache
} > _module_available_modules()
} > {
} > - if (( [[ -n "$MODULEPATH" ]] && [[ ${+_available_modules} -eq 0 ]] ));
} > + if (( [[ -n $MODULEPATH ]] && [[ ${+_available_modules} -eq 0 ]] ));
} >then
} > _available_modules=($(find ${(e)=MODULEPATH//:/ } -xtype f -print
2>/dev/null | grep -v \.version | sed -e
's,\('${${(e)=MODULEPATH//:/\/\\\|}%\\\|}'\),,g' -e 's,^/*,,g'))
} >fi
}
} Why would this break zcompile?
What's up with the double parens?
if (( ... this is parsed as a math expression ... ))
I don't know why zcompile chokes on that when the regular interpreter
does not, but it almost certainly ought to be a syntax error long before
the unmatched double-quote error that zcompile coughs up.
if [[ -n $MODULEPATH ]] && [[ ${+_available_modules} -eq 0 ]]
without the excess parens and trailing semicolon, ought to be sufficient.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355430: zsh: acroread completion prints debugging information
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.:
schaefer<502> print -R ver=${${${(f)"$(
Bug#315255: zsh: cvs commit completion breaks on spaces
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 that doesn't happen, then this would be OK. } What's the correct fix? I would have expected _path_files to do the right thing, so maybe the fix is somewhere there. Or might it be _wanted ...? -- 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).
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).
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" } > understands SIGIO as a synonym for SIGPOLL and SIGCLD for SIGCHLD, but } > "trap" only knows CHLD and POLL. } } How did you work this out? I was basing it on an observation of the awk-generated list of trap names on my system and the lack of any explicit mention of CLD and IO elsewhere in the trap code, vs. the presence of alt_sigs in jobs.c. } 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 there isn't really any justification for } making the mechanism optional now. I can't tell by reading the patch: does this do as Oliver suggested and prefer the ZERR equivalent for ERR, requiring SIGERR to get the actual signal? If not -- that is, if SIGERR is preferred when available -- then we still don't have ksh compatibility. -- 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).
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 there isn't really any justification for } making the mechanism optional now. I just discovered another reason why we use ZERR: In file included from ../../../zsh-4.0/Src/Modules/terminfo.c:53: /usr/include/curses.h:195: warning: `ERR' redefined /usr/include/sys/ucontext.h:74: warning: this is the location of the previous definition -- 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).
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 judgement about whether zsh *ought* to treat ERR differently in ksh mode. I merely explained why zsh behaves the way it does. (Google indicates that ksh does run on UNICOS; I wonder what it does with ERR in that case.) 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" understands SIGIO as a synonym for SIGPOLL and SIGCLD for SIGCHLD, but "trap" only knows CHLD and POLL. Perhaps the "alt_sigs" code should be factored out of jobs.c [*] and extended to cover SIGERR as well. Whether that's enabled only in ksh emulation is a second question. [*] Or perhaps bin_trap() should be moved *to* jobs.c. -- 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).
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 script to put this workaround in. No, you just have to put the above in /etc/zshenv, which is read by all instances of zsh, whether script or interactive. } So, for this particular problem of trap ERR, there are only problems } in using zsh as a ksh That's not the only incompatibility, by a long shot. Don't try scripts using namerefs or discipline functions, for example. } (By the way, what are the platform with OS } SIGERR ? And do some ksh run on them ?) UNICOS, according to the Zsh FAQ. I have no idea whether ksh has been ported to that.
Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
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 platforms on which zsh can be compiled actually have SIGERR defined, which is a real OS-level signal and not interchangeable with the ksh et al. use of ERR as a magic trap. The zsh equivalent is trap 'echo alert-an-error-occured' ZERR A possible workaround would be (( $signals[(I)ERR] )) || alias -g ERR=ZERR } P.S., someone left conflict cruft in ChangeLog. "cvs annotate" is great for finding someones. I deleted the cruft. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
