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

[Peter Stephenson]

On Sat, 19 Nov 2016 21:54:05 +
Daniel Shahaf  wrote:
> If we do keep space and tab then we should document them.  

I'm inclined to get rid of them.  They've been undocumented
and not even mentioned in the prompt for a quarter century.
If this hasn't been causing mayhem that's just luck.  We
are not running a service for people who like guessing
features (though this may come as a surprise).

pws

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

[Peter Stephenson]

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 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.

pws


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654225: PATCH: Restore `LC_ALL' when setting `LANG'

[Peter Stephenson]

On 2012-01-03 16:26:44 +0100, Frank Terbeck wrote:
 I think the patch below fixes the issue correctly, by restoring LC_ALL
 from its parameter along the way with all the other LC_* values zsh
 cares about.

Looks plausible, without following through all the implications.

On Wed, 4 Jan 2012 03:16:41 +0100
Vincent Lefevre vinc...@vinc17.net wrote:
 I don't understand why zsh has anything to do with environment
 variables to detect the charset (if I understood correctly).
 Why not using nl_langinfo(CODESET)?

Intercepting the setting of environment variables is mostly to ensure
setlocale() gets run when necessary.

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
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 uboTab - endless loop

[Peter Stephenson]

On Wed, 23 Feb 2011 11:30:04 +
Peter Stephenson p.w.stephen...@ntlworld.com wrote:
 On Wed, 23 Feb 2011 11:50:18 +0100
 Michael Prokop n...@michael-prokop.at wrote:
  in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353863
  Sebastien Desreux reported a bug about zsh with its
  completion system in a specific situation.
  
  To trigger the bug (at least 4.3.10 and 4.3.11 in Debian are
  known to be affected by this bug):
  
zsh -f
autoload -Uz compinit; compinit; alias ubox=ls
ubotab
  
  Then the zsh process is hanging in an endless loop, eating CPU.
 
 I think the answer might be never to expand aliases when the x would
 be added to the command word.  That might be easier said than done.

Looks like this is my fault.  There's code to stop lexical processing
when we've got to the cursor position, which means the alias never gets
expanded, but when I upgraded the interface I missed the fact that it
was doing a test of lexflags against 1 and now needs to look for the bit
LEXFLAGS_ZLE.

Index: Src/lex.c
===
RCS file: /cvsroot/zsh/zsh/Src/lex.c,v
retrieving revision 1.64
diff -p -u -r1.64 lex.c
--- Src/lex.c   21 Feb 2011 11:32:47 -  1.64
+++ Src/lex.c   24 Feb 2011 12:36:41 -
@@ -1825,7 +1825,7 @@ exalias(void)
int zp = lexflags;
 
gotword();
-   if (zp == 1  !lexflags) {
+   if ((zp  LEXFLAGS_ZLE)  !lexflags) {
if (zshlextext == copy)
zshlextext = tokstr;
return 0;

-- 
Peter Stephenson p...@csr.comSoftware Engineer
Tel: +44 (0)1223 692070   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom



-- 
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 uboTab - endless loop

[Peter Stephenson]

On Wed, 23 Feb 2011 11:50:18 +0100
Michael Prokop n...@michael-prokop.at wrote:
 in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353863
 Sebastien Desreux reported a bug about zsh with its
 completion system in a specific situation.
 
 To trigger the bug (at least 4.3.10 and 4.3.11 in Debian are
 known to be affected by this bug):
 
   zsh -f
   autoload -Uz compinit; compinit; alias ubox=ls
   ubotab
 
 Then the zsh process is hanging in an endless loop, eating CPU.

Tee hee.  This is what happens when your interface between the
completion system and the main shell is a complete hack.

If the option COMPLETE_ALIASES is off, the shell tries to expand
aliases, so it can do completion for aliased commands without the
completion system needing to understand the alias.

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.  It removes the non-existent x to get l which it
thinks is three characters long.  It then loops for ever reading the
null byte at the end of the string waiting to get to the third
character.

I think the answer might be never to expand aliases when the x would
be added to the command word.  That might be easier said than done.

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
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

[Peter Stephenson]

On Wed, 18 Aug 2010 18:29:59 +
Clint Adams sch...@debian.org wrote:
 On Wed, Aug 18, 2010 at 02:51:48PM +1200, Victor Villa wrote:
  After running a process in the background (by putting  at the end
  of the command line) the output of jobs correctly shows the
  process as running. If I send the process a STOP signal with kill
  -STOP, the process stops and jobs shows the process as suspended
  (signal).  The problem is that after sending a CONT signal to the
  process (with kill -CONT), jobs still shows the process as
  suspended, even though the process resumes (if it's a media file I
  can hear it playing, for example.

Part of the problem is that we don't update the process status properly
when sending a SIGCONT.  That's fairly easy to fix, and it sounds like
it addresses the immediate issue.

However, we ought to be cleverer, since we don't get a signal when a
child gets a SIGCONT from outside the shell, which is perfectly
possible.  To handle that we'd need to use wait3() or waitpid() with
WNOHANG to see if the job was still stopped.  That's still fairly
straightforward, the problem is that if the job has just exited we then
need to update the job status as if we were in the SIGCHLD handler, and
that needs more thought to do it properly.  Probably not *that*
difficult.  I don't suppose anyone has an urge to learn about the signal
code?

Index: Src/jobs.c
===
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.77
diff -p -u -r1.77 jobs.c
--- Src/jobs.c  31 Jul 2010 22:03:41 -  1.77
+++ Src/jobs.c  18 Aug 2010 19:58:50 -
@@ -2217,7 +2217,7 @@ bin_kill(char *nam, char **argv, UNUSED(
signal. */
if (jobtab[p].stat  STAT_STOPPED) {
if (sig == SIGCONT)
-   jobtab[p].stat = ~STAT_STOPPED;
+   makerunning(jobtab + p);
if (sig != SIGKILL  sig != SIGCONT  sig != SIGTSTP
 sig != SIGTTOU  sig != SIGTTIN  sig != SIGSTOP)
killjb(jobtab + p, SIGCONT);
@@ -2225,9 +2225,19 @@ bin_kill(char *nam, char **argv, UNUSED(
} else if (!isanum(*argv)) {
zwarnnam(kill, illegal pid: %s, *argv);
returnval++;
-   } else if (kill(atoi(*argv), sig) == -1) {
-   zwarnnam(kill, kill %s failed: %e, *argv, errno);
-   returnval++;
+   } else {
+   int pid = atoi(*argv);
+   if (kill(pid, sig) == -1) {
+   zwarnnam(kill, kill %s failed: %e, *argv, errno);
+   returnval++;
+   } else if (sig == SIGCONT) {
+   Job jn;
+   Process pn;
+   if (findproc(pid, jn, pn, 0)) {
+   if (WIFSTOPPED(pn-status))
+   pn-status = SP_RUNNING;
+   }
+   }
}
 }
 unqueue_signals();

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#582258: zsh-mime-setup disables usual completions

[Peter Stephenson]

 no_bg
+local handler flags no_sh no_bg arg
+integer i
 local -a exec_asis hand_nonex
 
 # Set to a list of patterns which are ignored and executed as they are,
@@ -94,7 +117,20 @@ fi
 for pattern in $exec_asis; do
   files=(${dirpref}${~pattern})
   if [[ -n ${files[(r)$1]} ]]; then
-$@
+if (( list )); then
+  for (( i = 1; i = $#; i++ )); do
+   (( i == 1 )) || print -n  
+   arg=${argv[i]}
+   if [[ -n $arg ]]; then
+ print -rn -- ${(q)arg}
+   else
+ print ''
+   fi
+  done
+  print
+else
+  $@
+fi
 return
   fi
 done
@@ -152,12 +188,13 @@ if [[ $handler = *%s* ]]; then
   # Probably we ought not even to handle multiple
   # arguments, but at least the error message ought
   # to make it obvious what's going on.
-  zformat -f command $handler s:$argv
+  zformat -f command $handler s:$argv[0]
 else
-  files=(${(q)argv})
-  zformat -f command $handler s:$files
+  zformat -f command $handler s:${(q)argv[0]}
 fi
-if [[ $no_sh = yes ]]; then
+if (( list )); then
+  execargs=(${(Q)${(z)command}} ${argv[1,-1]})
+elif [[ $no_sh = yes ]]; then
   execargs=(eval $command)
 else
   execargs=(sh -c $command)
@@ -174,13 +211,27 @@ if [[ $handler = *%s* ]]; then
 else
   # If there's no %s, the input is supposed to come from stdin.
   stdin=1
-  if [[ -n $hasmeta  $no_sh != yes ]]; then
+  if [[ -n $hasmeta  $no_sh != yes  list -eq 0 ]]; then
 execargs=(sh -c $handler)
   else
 execargs=(${=handler})
   fi
 fi
 
+if (( list )); then
+  for (( i = 1; i = ${#execargs}; i++ )); do
+(( i == 1 )) || print -n  
+arg=${execargs[i]}
+if [[ -n $arg ]]; then
+  print -rn -- ${(q)arg}
+else
+  print -n ''
+fi
+  done
+  print
+  return 0
+fi
+
 # Now execute the command in the appropriate fashion.
 if [[ $flags = *copiousoutput* ]]; then
   # We need to page the output.


-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579209: zsh: insert-last-word problem after completion

[Peter Stephenson]

On Mon, 26 Apr 2010 12:53:31 +0200
Vincent Lefevre vinc...@vinc17.net wrote:
 After a zsh -f:
 
 % alias my_echo=echo
 % false
 % true 
 % my_ech[TAB]
 
 A succession of [ESC] . (bound to insert-last-word) gives:
 
   my_echo
   my_echo
   my_echofalse
 
 while I would expect:
 
   my_echo 
   my_echo false

That's a bug:  can you get it to happen with the new completion system (I
tried briefly and failed)?  I presume there's a gap in the suffix-fixing
logic for completion.

 or even better:
 
   my_echo true
   my_echo false
 
 i.e. the  should be ignored by insert-last-word.

That's not a bug.  As Mikael suggested, you need to use something that's
smart about syntax; that's not the job of insert-last-word, which only
knows about the division into editing words.

-- 
Peter Stephenson p...@csr.comSoftware Engineer
Tel: +44 (0)1223 692070   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579209: zsh: insert-last-word problem after completion

[Peter Stephenson]

On Mon, 26 Apr 2010 17:42:10 +0200
Vincent Lefevre vinc...@vinc17.net wrote:
 On 2010-04-26 13:11:39 +0100, Peter Stephenson wrote:
  On Mon, 26 Apr 2010 12:53:31 +0200
  Vincent Lefevre vinc...@vinc17.net wrote:
   After a zsh -f:
   
   % alias my_echo=echo
   % false
   % true 
   % my_ech[TAB]
   
   A succession of [ESC] . (bound to insert-last-word) gives:
   
 my_echo
 my_echo
 my_echofalse
 
 Actually I noticed the bug with the new completion system.

I've got there, too, eventually.

There are two ways to approach this: either have the  inserted as
now, with the space removed, which is the same as if the  was typed;
or fix the suffix when inserting the last word.  The drawback with the
former (which is what it's currently trying to do, but failing) is that
replacing the  with earlier words would leave the space before it
removed, and in most cases that won't be the right thing to do (you'd
get my_echofalse in this case).  So I think the latter is the right
answer---we know that what we're inserting always functions as a
complete word, hence fixing the space or whatever makes more sense even
if in the case of the first last word you happen not to need it.
This happens to be the simpler fix (though I have an implementation of
the other one, too).

By the way, as an alternative to smart-insert-last-word, what I do is
have the widget copy-earlier-word bound to ESC = so that I can get
earlier words from the line to which ESC . has taken me.

Index: Src/Zle/zle_hist.c
===
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_hist.c,v
retrieving revision 1.64
diff -p -u -r1.64 zle_hist.c
--- Src/Zle/zle_hist.c  18 Mar 2010 16:03:20 -  1.64
+++ Src/Zle/zle_hist.c  26 Apr 2010 22:29:11 -
@@ -634,6 +634,7 @@ insertlastword(char **args)
}
 }
 
+fixsuffix();
 metafy_line();
 if (lastinsert  lastlen 
lastpos = zlemetacs 

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537283: homing in

[Peter Stephenson]

Clint Adams wrote:
 On Wed, Sep 02, 2009 at 09:09:12AM +0200, martin f krafft wrote:
  % precmd_test() { set -x; test -d .  echo . is a directory; set +x; }
  % precmd_functions=(precmd_test)
  +precmd_test:0 test -d .
  +precmd_test:0 echo . is a directory
  . is a directory
  +precmd_test:0 set +x
  % [PRESS CTRL-C]
  +precmd_test:0 test -d .
  precmd_test:test: argument expected
  +precmd_test:0 set +x

Incomplete previous patch (27079).

Index: Src/builtin.c
===
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.234
diff -u -r1.234 builtin.c
--- Src/builtin.c   24 Jul 2009 18:35:53 -  1.234
+++ Src/builtin.c   2 Sep 2009 15:18:03 -
@@ -5818,17 +5818,19 @@
 testlex();
 prog = parse_cond();
 condlex = zshlex;
-lexrestore();
 
 if (errflag) {
errflag = 0;
+   lexrestore();
return 1;
 }
 
 if (!prog || tok == LEXERR) {
zwarnnam(name, tokstr ? parse error : argument expected);
+   lexrestore();
return 1;
 }
+lexrestore();
 
 if (*curtestarg) {
zwarnnam(name, too many arguments);

-- 
Peter Stephenson p...@csr.comSoftware Engineer
Tel: +44 (0)1223 692070   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#544528: zsh-beta: FTBFS on GNU/kFreeBSD (hang in testsuite)

[Peter Stephenson]

Clint Adams wrote:
 On Tue, Sep 01, 2009 at 12:17:31PM +0200, Petr Salinger wrote:
  the build of zsh-beta currently hangs in testsuite.
  The problematic test is Test/B04read.ztst.
 
  In the head of the file is written:
 
  # Not tested:
  #  -c/-l/-n (options for compctl functions)
  #  -q/-s (needs a tty)
 
  But a few lines latter, the -q is used.

-q doesn't need a terminal since 27188, the documentation needs changing
too.

  0:read specified number of chars
  foo
 
   for char in y Y n N X $'\n'; do
 read -q -u0 $char
 print $?
   done
 
 
  The test hangs in nohup dpkg-buildpackage -b -uc build,
  but passes in dpkg-buildpackage -b -uc interactive build.

Please find out where it's hanging, and if it does so with -k instead of
-q (the test will fail in that case unless rewritten).

-- 
Peter Stephenson p...@csr.comSoftware Engineer
Tel: +44 (0)1223 692070   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#535232: zsh: segfaults while trying to free in hend

[Peter Stephenson]

On Sun, 9 Aug 2009 18:47:21 +
Clint Adams sch...@debian.org wrote:
 On Tue, Jun 30, 2009 at 06:21:33PM -0400, Alec Berryman wrote:
 Recently (one or two weeks, probably when I upgraded to the current
 version of zsh), I've been seeing intermittent segfaults - I'll run a
 command like less or cd and my terminal will die on me.  I've never
 seen it happen in a long-running shell; if it makes it through the
 first few commands, everything works.

The following is at least safe and good practice, but it's impossible to
tell if it's the root of the problem.

Index: Src/hist.c
===
RCS file: /cvsroot/zsh/zsh/Src/hist.c,v
retrieving revision 1.94
diff -u -r1.94 hist.c
--- Src/hist.c  23 Mar 2009 12:17:33 -  1.94
+++ Src/hist.c  16 Aug 2009 18:59:10 -
@@ -1156,6 +1156,7 @@
zfree(chline, hlinesz);
zfree(chwords, chwordlen*sizeof(short));
chline = NULL;
+   chwords = NULL;
histactive = 0;
unqueue_signals();
return 1;
@@ -1270,6 +1271,7 @@
 zfree(chline, hlinesz);
 zfree(chwords, chwordlen*sizeof(short));
 chline = NULL;
+chwords = NULL;
 histactive = 0;
 if (isset(SHAREHISTORY)? histfileIsLocked() : isset(INCAPPENDHISTORY))
savehistfile(hf, 0, HFILE_USE_OPTIONS | HFILE_FAST);


-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537596: regression: parse error near `()' in function definition

[Peter Stephenson]

On Sun, 19 Jul 2009 23:20:41 +
Clint Adams sch...@debian.org wrote:
 On Sun, Jul 19, 2009 at 07:16:51PM +0200, martin f krafft wrote:
  % eval 'lt() { (_lt-en $*; _en-lt $*) | more }'
  zsh: parse error near `()'
  
  Alright, so lt is special:
  
  % which lt
  lt: aliased to ls -lt

Assuming lt was defined as an alias first, this has always been the wrong
thing to do:

% alias lt=one two
% eval 'lt() { (_lt-en $*; _en-lt $*) | more }'
% which one two
one () {
(
_lt-en $*
_en-lt $*
) | more
}
two () {
(
_lt-en $*
_en-lt $*
) | more
}

This is not a new feature; it's been mentioned in the FAQ for many years.


2.3: Why do my csh aliases not work?  (Plus other alias pitfalls.)

...

  There is one other serious problem with aliases: consider

alias l='/bin/ls -F'
l() { /bin/ls -la $@ | more }

  `l' in the function definition is in command position and is expanded
  as an alias, defining `/bin/ls' and `-F' as functions which call
  `/bin/ls', which gets a bit recursive.  This can be avoided if you use
  `function' to define a function, which doesn't expand aliases.  It is
  possible to argue for extra warnings somewhere in this mess.

  Bart Schaefer's rule is:  Define first those aliases you expect to
  use in the body of a function, but define the function first if the
  alias has the same name as the function.

-- 
Peter Stephenson p...@csr.comSoftware Engineer
Tel: +44 (0)1223 692070   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


'member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#527171: [zsh] segfaults on long environment variables

[Peter Stephenson]

On Wed, 6 May 2009 01:38:28 +
Clint Adams sch...@debian.org wrote:
 On Wed, May 06, 2009 at 02:35:05AM +0200, Nico Golde wrote:
  export BLA=$(perl -e print 'A' x 1;)
  
  results in zsh segfaulting:
  [335969.515454] zsh[29005]: segfault at 7fff1b357858 ip 7fb5184a5855 sp 
  7fff1b357860 error 6 in libc-2.9.so[7fb518471000+149000]
 
 The segfault is not in the assignment but in the export (zputenv).

This appears to be failing within setenv() which (as far as I can tell)
is being passed a perfectly valid string.  setenv() is supposed to fail
gracefully and set errno to ENOMEM if it doesn't fit in the environment
but apparently isn't.  I believe the environment size is limited by
ARG_MAX on POSIX-like systems, but it's not usually tested by the caller
(which doesn't know how much space is left).

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
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

[Peter Stephenson]

On Wed, 25 Mar 2009 17:14:31 -0700
Bart Schaefer schae...@brasslantern.com wrote:
 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?

From what I've heard, it doesn't sound like it's worth more than a
warning.

Index: Doc/Zsh/options.yo
===
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.78
diff -u -r1.78 options.yo
--- Doc/Zsh/options.yo  3 Mar 2009 17:35:29 -   1.78
+++ Doc/Zsh/options.yo  26 Mar 2009 09:49:05 -
@@ -1721,7 +1721,12 @@
 
 Alias expansion takes place while text is being read; hence when this
 option is set it does not take effect until the end of any function or
-other piece of shell code evaluated as one unit.
+other piece of shell code evaluated as one unit.  Note this may
+cause differences from other shells even when the option is in
+effect.  For example, when running a command with `tt(zsh -c)' the
+entire command argument is parsed in one go, so aliases defined within
+the argument are not available even in later lines.  If in doubt, avoid use
+of aliases in non-interactive code.
 )
 pindex(POSIX_BUILTINS)
 pindex(NO_POSIX_BUILTINS)


-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#516998: zsh regards reserved word as candidate for alias substitution

[Peter Stephenson]

Clint Adams wrote:
 On Wed, Feb 25, 2009 at 12:18:46AM +0100, Vincent Lefevre wrote:
  POSIX.1-2008 says[*]:
  
2.3.1 Alias Substitution
[...] However, reserved words in correct grammatical context
shall not be candidates for alias substitution.
  
  [*] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
 #tag_18_03_01
  
  but zsh gives:
  
  vin% emulate sh
  vin% alias !=echo OK
  vin% ! foo
  OK foo
  vin% 
  
  instead of running command foo. ksh93, pdksh, dash and bash
  in POSIX mode all behave correctly.
 
 Where it seems that correctly means that setting the alias
 succeeds, but ! is never substituted.

This was fixed in 26675.

-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519571: Bug#514857: zsh -c 'set -e; ! true; echo OK' fails

[Peter Stephenson]

Clint Adams wrote:
 A trio regarding set -e:

I am not going anywhere near this until the clarification in the
standard gets through.

-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
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

[Peter Stephenson]

Clint Adams wrote:
 On Wed, Feb 25, 2009 at 03:28:50AM +0100, Vincent Lefevre wrote:
  Aliases are not expanded with the -c option, as shown below.
  
  vin% cmd=$(printf emulate sh\nalias a='echo OK 2'\na)
  vin% printf %s\n $cmd
  emulate sh
  alias a='echo OK 2'
  a
  vin% printf %s $cmd | zsh -f
  OK
  vin% zsh -fc $cmd
  zsh:3: command not found: a
  vin% 
  
  There's no such problem with ksh93, bash in POSIX mode, and dash
  (pdksh has the same bug).
 
 That does appear to be the behavior.

Yes, at least as far as native zsh mode goes this isn't a bug.  The
command passed is treated as a single piece of text that's parsed in one
go, so the alias isn't available until afterwards (by which time the
shell has exited).  This is the same behaviour as other chunks of code
read in one go.  To get script-like behaviour, don't use -c, use a
script argument.

-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
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

[Peter Stephenson]

On Wed, 25 Mar 2009 16:30:08 +
Peter Stephenson p...@csr.com wrote:
Clint Adams wrote:
On Wed, Feb 25, 2009 at 03:28:50AM +0100, Vincent Lefevre wrote:
 Aliases are not expanded with the -c option, as shown below.

 vin% cmd=$(printf emulate sh\nalias a='echo OK 2'\na)
 vin% printf %s\n $cmd
 emulate sh
 alias a='echo OK 2'
 a
 vin% printf %s $cmd | zsh -f
 OK
 vin% zsh -fc $cmd
 zsh:3: command not found: a
 vin% 

 There's no such problem with ksh93, bash in POSIX mode, and dash
 (pdksh has the same bug).

 That does appear to be the behavior.

 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.
You would need to start the shell in the appropriate mode.  I don't think
that's an unreasonable requirement.

Is the fix as simple as the following?  This is not a trick question, I
could very easily have missed something.

Index: Src/init.c
===
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.100
diff -u -r1.100 init.c
--- Src/init.c  9 Mar 2009 15:57:59 -   1.100
+++ Src/init.c  25 Mar 2009 17:19:57 -
@@ -1038,9 +1038,32 @@
 if (cmd) {
if (SHIN = 10)
fclose(bshin);
-   SHIN = movefd(open(/dev/null, O_RDONLY | O_NOCTTY));
-   bshin = fdopen(SHIN, r);
-   execstring(cmd, 0, 1);
+   if (isset(POSIXALIASES)) {
+   /*
+* We need to process input one line at a time to
+* ensure aliases are available.
+*/
+   char *fil;
+   int tempfd = gettempfile(NULL, 1, fil);
+
+   if (tempfd  0) {
+   zerr(fc, can't open temp file: %e, errno);
+   lastval = 1;
+   } else {
+   int cmdlen;
+   unmetafy(cmd, cmdlen);
+   write(tempfd, cmd, cmdlen);
+   lseek(tempfd, 0, SEEK_SET);
+   SHIN = tempfd;
+   bshin = fdopen(SHIN, r);
+   loop(1, 0);
+   }
+   unlink(fil);
+   } else {
+   SHIN = movefd(open(/dev/null, O_RDONLY | O_NOCTTY));
+   bshin = fdopen(SHIN, r);
+   execstring(cmd, 0, 1);
+   }
stopmsg = 1;
zexit(lastval, 0);
 }
Index: Doc/Zsh/options.yo
===
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.78
diff -u -r1.78 options.yo
--- Doc/Zsh/options.yo  3 Mar 2009 17:35:29 -   1.78
+++ Doc/Zsh/options.yo  25 Mar 2009 17:19:57 -
@@ -1719,6 +1719,20 @@
 ifnzman(noderef(Reserved Words))\
 ifzman(the section RESERVED WORDS in zmanref(zshmisc)).
 
+Another effect of this option, provided it is set at shell start up,
+is to cause the shell's tt(-c) option to save commands to a temporary file
+and read them line by line to ensure aliases are expanded.  For example,
+
+example(zsh -fc 'alias o=echo Hello
+o')
+
+reports a `command not found' error, while
+
+example(zsh -o posixaliases -fc 'alias o=echo Hello
+o')
+
+outputs `Hello'.
+
 Alias expansion takes place while text is being read; hence when this
 option is set it does not take effect until the end of any function or
 other piece of shell code evaluated as one unit.


-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
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

[Peter Stephenson]

Bart Schaefer wrote:
 } 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?

If you mean cover it in the sense that the option is turned on before
any code is parsed---yes, but that's not changed by this patch.  It
won't cover the case where emulate -c is followed by multiple lines of
code that define aliases that are expected to be available in following
lines.  I'm not sure it needs to: there's no question of that being
standardised and we are at liberty to define the rule as being what it
is by default, i.e. code is parsed and aliases expanded before any code
is executed; although I can see you might expect it to be the same
as the shell's own -c option.

 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.).

I think it's accepted that this will not work with any current shell
implementation, not just zsh.

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.

-- 
Peter Stephenson p...@csr.com  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519535: history expansion: modifier completion missing

[Peter Stephenson]

On Sun, 15 Mar 2009 06:22:53 +
Clint Adams sch...@debian.org wrote:
 On Fri, Mar 13, 2009 at 11:55:55AM +0100, martin f krafft wrote:
  I tried to show off zsh to a sceptic today and had to find out the
  hard way that it does not (yet) provide completion for history
  expansion modifiers, e.g.
  
echo !$:TAB

I thought this was going to be harder than it turned out to be; as you can
see it's really quite simple, particularly since I already wrote modifer
completion and it would appear had the foresight to make it handle the
history case.

It's in _normal which is where we handle normal command arguments.  I think
this is both the first and last place where get to massage command line
arguments generically---we don't just want this in default completion since
history expansion, if active, trumps everything else.

It probably needs to go in _value for assignments; is right at the top the
appropriate place?  Or should it actually go higher, in _complete itself,
outside the if that decides whether it's _normal or otherwise?  I don't
think so, because that screws up vared.  Hmmm... I think that's true of
putting it in _value, which _in_vared uses.  Maybe leaving it discretely
alone might work well.

The rum thing is the way $PREFIX acquires quoted !'s.  I thought $PREFIX
was fairly raw, so you could handle special characters?  Obviously I'm
misremembering, because I traced the quoting to some completely general
code for all special characters.  Anyway, that has two effects:  first you
have to check $words, because that does have the raw form, and secondly you
have to update $PREFIX so that you get the raw !'s inserted into the
command line.  (But you don't usually have to do that even if you're
inserting special characters, do you?  You just need to make sure compadd
has the argument -Q, which it does here, except that's not good enough.
Baaa.)

I think -z $compstate[quote] ensures we're not already doing something
clever inside nested quotes, which would mean the expression couldn't be a
history expansion.  I think.

So it seems to work fine (possibly depending on your options and
completers---there are other things around that will do other things to
!'s), but I'm still a bit confused.

Index: Completion/Base/Core/_normal
===
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_normal,v
retrieving revision 1.4
diff -u -r1.4 _normal
--- Completion/Base/Core/_normal13 Mar 2002 09:28:05 -  1.4
+++ Completion/Base/Core/_normal16 Mar 2009 18:05:48 -
@@ -9,6 +9,19 @@
   _compskip=''
 fi
 
+# Check for a history reference to complete modifiers.
+# $PREFIX has a quoted form of the !, so we can't test that
+# (it might the start of a real argument), but words has the
+# raw McCoy.
+if [[ -o BANG_HIST  $words[CURRENT] = \!*:  -z $compstate[quote] ]]; then
+  # This looks like a real history expansion; in that case
+  # we'd better put the !'s back the way pfalstad intended.
+  PREFIX=${PREFIX//\\!/!}
+  compset -P '*:'
+  _history_modifiers h
+  return
+fi
+
 # Completing in command position?
 
 if [[ CURRENT -eq 1 ]]; then





-- 
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

[Peter Stephenson]

Bart Schaefer wrote:
 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.

I don't think that can be it, since this feature is only in the command
hashing.  If you type the command name in full it will still be
executed.  So this has virtually no effect on non-interactive use.

Since the path is still absolute I don't see how this could effect
security, either, except maybe at second hand... if you sanitized the
early part of the path but didn't look for .., so the component could
end up pointing out of that area, for example.  But that doesn't seem to
me to be the shell's problem.

-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#418199: Segfault on really long paths

[Peter Stephenson]

On Tue, 30 Dec 2008 01:19:51 +0100
Richard Hartmann richih.mailingl...@gmail.com wrote:
 ric...@adamantium ~ % for i in {1..1000}; do mkdir 0123456789; cd
 0123456789; done
 [1]24398 segmentation fault  zsh
 ric...@adamantium ~ %
 
 It would be better to throw an error than to segfault.

This is one major culprit, there may be others.  If we've *really* run
out of memory there are far too many cases to trap, but there was
an arbitrary limit here that I really don't like.  This is reasonably well
optimized in the case of no metafied characters (unless I've screwed up).

Index: Src/utils.c
===
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.207
diff -u -r1.207 utils.c
--- Src/utils.c 27 Nov 2008 17:05:42 -  1.207
+++ Src/utils.c 5 Jan 2009 21:50:46 -
@@ -3704,26 +3704,67 @@
 return mlen;
 }
 
-/* This function converts a zsh internal string to a form which can be *
- * passed to a system call as a filename.  The result is stored in a   *
- * single static area.  NULL returned if the result is longer than *
- * 4 * PATH_MAX.   */
+/*
+ * This function converts a zsh internal string to a form which can be
+ * passed to a system call as a filename.  The result is stored in a
+ * single static area, sized to fit.  If there is no Meta character
+ * the original string is returned.
+ */
 
 /**/
 mod_export char *
 unmeta(const char *file_name)
 {
-static char fn[4 * PATH_MAX];
+static char *fn;
+static int sz;
 char *p;
 const char *t;
+int newsz, meta;
+
+meta = 0;
+for (t = file_name; *t; t++) {
+   if (*t == Meta)
+   meta = 1;
+}
+if (!meta) {
+   /*
+* don't need allocation... free if it's long, see below
+*/
+   if (sz  4 * PATH_MAX) {
+   zfree(fn, sz);
+   fn = NULL;
+   sz = 0;
+   }
+   return (char *) file_name;
+}
+
+newsz = (t - file_name) + 1;
+/*
+ * Optimisation: don't resize if we don't have to.
+ * We need a new allocation if
+ * - nothing was allocated before
+ * - the new string is larger than the old one
+ * - the old string was larger than an arbitrary limit but the
+ *   new string isn't so that we free up significant space by resizing.
+ */
+if (!fn || newsz  sz || (sz  4 * PATH_MAX  newsz = 4 * PATH_MAX))
+{
+   if (fn)
+   zfree(fn, sz);
+   sz = newsz;
+   fn = (char *)zalloc(sz);
+   if (!fn) {
+   sz = 0;
+   /*
+* will quite likely crash in the caller anyway...
+*/
+   return NULL;
+   }
+}
 
-for (t = file_name, p = fn; *t  p  fn + 4 * PATH_MAX - 1; p++)
+for (t = file_name, p = fn; *t; p++)
if ((*p = *t++) == Meta)
*p = *t++ ^ 32;
-if (*t)
-   return NULL;
-if (p - fn == t - file_name)
-   return (char *) file_name;
 *p = '\0';
 return fn;
 }


-- 
Peter Stephenson p.w.stephen...@ntlworld.com
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#501851: zsh: Completion fails if a directory name contains '(', ')' and 'Ą '.

[Peter Stephenson]

) {
*p++ = Meta;
-   *p++ = *add ^ 32;
+   *p++ = add[1];
} else
*p++ = *add;
} else
-   len += imeta(*add) ? 3 : 2;
-   if (PATMATCHRANGE(m-line-u.str, CONVCAST(*add),
+   len += (*add == Meta) ? 3 : 2;
+   if (PATMATCHRANGE(m-line-u.str, CONVCAST(chr),
  ind, mt)) {
/*
 * Find the equivalent match for ind in the
 * word pattern.
 */
if ((ind = pattern_match_equivalence
-(m-word, ind, mt, CONVCAST(*add))) != -1) {
+(m-word, ind, mt, CONVCAST(chr))) != -1) {
if (ret) {
if (imeta(ind)) {
*p++ = Meta;
@@ -4158,7 +4159,7 @@
 * if *add is ] and ] is also the first
 * character in the range.
 */
-   addadd = !pattern_match1(m-word, CONVCAST(*add), mt);
+   addadd = !pattern_match1(m-word, CONVCAST(chr), mt);
if (addadd  *add == ']') {
if (ret)
*p++ = *add;
@@ -4218,6 +4219,13 @@
}
}
}
+   if (*add == Meta) {
+   add += 2;
+   mp += 2;
+   } else {
+   add++;
+   mp++;
+   }
}
if (ret) {
*p = '\0';
@@ -4236,19 +4244,19 @@
 
 if (m  m != pcm_err) {
char *tmp;
-   int al = strlen(add), tl;
-   VARARR(Cmatcher, ms, al);
+   int al = strlen(add), zl = ztrlen(add), tl, cl;
+   VARARR(Cmatcher, ms, zl);
Cmatcher *mp;
Cpattern stopp;
int stopl = 0;
 
-   memset(ms, 0, al * sizeof(Cmatcher));
+   memset(ms, 0, zl * sizeof(Cmatcher));
 
for (; m  *add; m = m-next) {
stopp = NULL;
if (!(m-flags  (CMF_LEFT|CMF_RIGHT))) {
if (m-llen == 1  m-wlen == 1) {
-   for (tmp = add, tl = al, mp = ms; tl; tl--, tmp++, mp++) {
+   for (tmp = add, tl = al, mp = ms; tl; ) {
if (pattern_match(m-line, tmp, NULL, NULL)) {
if (*mp) {
*tmp = '\0';
@@ -4257,6 +4265,10 @@
} else
*mp = m;
}
+   cl = (*tmp == Meta) ? 2 : 1;
+   tl -= cl;
+   tmp += cl;
+   mp += cl;
}
} else {
stopp = m-line;
@@ -4264,7 +4276,7 @@
}
} else if (m-flags  CMF_RIGHT) {
if (m-wlen  0  !m-llen  m-ralen == 1) {
-   for (tmp = add, tl = al, mp = ms; tl; tl--, tmp++, mp++) {
+   for (tmp = add, tl = al, mp = ms; tl; ) {
if (pattern_match(m-right, tmp, NULL, NULL)) {
if (*mp || (tmp == add  *tmp == '.')) {
*tmp = '\0';
@@ -4273,6 +4285,10 @@
} else
*mp = m;
}
+   cl = (*tmp == Meta) ? 2 : 1;
+   tl -= cl;
+   tmp += cl;
+   mp += cl;
}
} else if (m-llen) {
stopp = m-line;
@@ -4289,12 +4305,16 @@
stopl = m-lalen;
}
if (stopp)
-   for (tmp = add, tl = al; tl = stopl; tl--, tmp++)
+   for (tmp = add, tl = al; tl = stopl; ) {
if (pattern_match(stopp, tmp, NULL, NULL)) {
*tmp = '\0';
al = tmp - add;
break;
}
+   cl = (*tmp == Meta) ? 2 : 1;
+   tl -= cl;
+   tmp += cl;
+   }
}
if (*add)
return cfp_matcher_range(ms, add);


-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501851: zsh: Completion fails if a directory name contains '(', ')' and 'Ą '.

[Peter Stephenson]

On Tue, 14 Oct 2008 10:46:29 +0900
Morita Sho [EMAIL PROTECTED] wrote:
   zstyle ':completion:*' matcher-list 'm:{[:lower:]}={[:upper:]}'
 
 After removing the above line, the completion Ą/[TAB] works again.

Thanks for narrowing it down...  I'm aware that that syntax still needs
some work on it, it's only half-converted to supporting non-ASCII
characters, so it's probably not surprising this sort of thing happens.
The problem is the way characters are stored is quite specific to a
single-byte representation; I've made it so that it can be extended to
multibyte/wide characters, but it hasn't been.

I'm not going to get it properly converted before the next release since
it's a big job (I started it once back in June and got bogged down).  When
I get a chance, I'll look and see if there's any thing obvious I can do
with Meta-encoded characters that will work round the problem for now.

Until then you should be able to get away with the old syntax,

zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'

since before I finish the job it won't actually handle non-ASCII character
conversions properly anyway.

I will document my way round this as follows...

Index: Doc/Zsh/compwid.yo
===
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compwid.yo,v
retrieving revision 1.43
diff -u -r1.43 compwid.yo
--- Doc/Zsh/compwid.yo  14 Jul 2008 17:39:26 -  1.43
+++ Doc/Zsh/compwid.yo  14 Oct 2008 12:01:54 -
@@ -942,14 +942,16 @@
 completion you can use `tt(m:{[:lower:]}={[:upper:]})'.  Although the
 matching system does not yet handle multibyte characters, this is likely
 to be a future extension, at which point this syntax will handle
-arbitrary alphabets; hence this form, rather than the use of explicit
-ranges, is the recommended form.  In other cases
-`tt([:)var(name)tt(:])' forms are allowed.  If the two forms on the left
-and right are the same, the characters must match exactly.  In remaining
-cases, the corresponding tests are applied to both characters, but they
-are not otherwise constrained; any matching character in one set goes
-with any matching character in the other set:  this is equivalent to the
-behaviour of ordinary character classes.
+arbitrary alphabets; until then it is safer to use the older syntax
+that only handles ASCII characters, `tt(m:{a-z}={A-Z}) as this does
+not have side effects in the case of multibyte characters.
+
+In other cases `tt([:)var(name)tt(:])' forms are allowed.  If the two forms
+on the left and right are the same, the characters must match exactly.  In
+remaining cases, the corresponding tests are applied to both characters,
+but they are not otherwise constrained; any matching character in one set
+goes with any matching character in the other set:  this is equivalent to
+the behaviour of ordinary character classes.
 
 The pattern var(tpat) may also be one or two stars, `tt(*)' or
 `tt(**)'. This means that the pattern on the command line can match


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501851: zsh: Completion fails if a directory name contains '(', ')' and 'Ą '.

[Peter Stephenson]

On Mon, 13 Oct 2008 10:32:05 +0900
Morita Sho [EMAIL PROTECTED] wrote:
 Additionally, Ą/[TAB] completion doesn't work on cvs head. (It was working on
 zsh 4.3.6)
 
   % mkdir Ą
   % touch Ą/foo
   % ls Ą/[TAB]
= Nothing completes.

This works fine for me (as does the version with () after the previous
fix).  Does the same still happen after zsh -f; autoload -U compinit;
compinit?  Is the character the composed version, i.e. Unicode 0x0104,
which is 0xc4 0x84 in UTF-8, or could it be some decomposed version with
combining characters?

Please send the output from running ^X? if there no obvious difference.

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501851: zsh: Completion fails if a directory name contains '(', ')' and 'Ą '.

[Peter Stephenson]

On Sat, 11 Oct 2008 22:47:52 +0900
Morita Sho [EMAIL PROTECTED] wrote:
 $~tmp1 expansion seems not working correctly for a pattern '\(\)Ą/*'.

Thanks for the clear analysis.

The pattern gets divided up into chunks because of the backslashed
characters, but we don't report that it wasn't a pure string on that
basis, so the directory trise to match the wrong string.  This was triggered
in this case because of the character in a range that zsh has to quote
internally to avoid clashing with tokens, which is why it occurred with
some forms of accent but not others.

I could optimise this better but this is a simple change for now.

Index: Src/pattern.c
===
RCS file: /cvsroot/zsh/zsh/Src/pattern.c,v
retrieving revision 1.47
diff -u -r1.47 pattern.c
--- Src/pattern.c   8 Jun 2008 17:53:55 -   1.47
+++ Src/pattern.c   11 Oct 2008 21:44:35 -
@@ -1446,7 +1446,13 @@
 * Marker for restoring a backslash in output:
 * does not match a character.
 */
-   return patcomppiece(flagp);
+   next = patcomppiece(flagp);
+   /*
+* Can't match a pure string since we need to do this
+* as multiple chunks.
+*/
+   *flagp = ~P_PURESTR;
+   return next;
break;
 #ifdef DEBUG
default:
Index: Test/D07multibyte.ztst
===
RCS file: /cvsroot/zsh/zsh/Test/D07multibyte.ztst,v
retrieving revision 1.25
diff -u -r1.25 D07multibyte.ztst
--- Test/D07multibyte.ztst  26 Mar 2008 15:26:20 -  1.25
+++ Test/D07multibyte.ztst  11 Oct 2008 21:44:35 -
@@ -395,3 +395,14 @@
 OK
 OK
 OK
+
+  mkdir glob
+  mkdir glob/'()Ą' glob/'()Ā'
+  mkdir glob/'()Ą'/foo glob/'()Ā'/bar
+  tmp1=('glob/\(\)Ą/*')
+  print $~tmp1
+  tmp1=('glob/\(\)Ā/*')
+  print $~tmp1
+0:Backslashes and metafied characters in patterns
+glob/()Ą/foo
+glob/()Ā/bar



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#497663: Tab completion for vim is broken

[Peter Stephenson]

Clint Adams wrote:
 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 '
   
   Commenting out lines 31-40 in
   /usr/share/zsh/functions/Completion/Unix/_vim fixes the problem. Should
   be trivial to fix properly for someone who understands zsh's compeltion
   syntax (I don't).
  
   I can't reproduce this and I don't see what the problem might be.
   Is this consistent for you?
  
  Hmm. Apparently it depends on emulate csh being used. I can't
  reproduce with a .zshrc of only
  
  autoload -U compinit
  compinit
  
  But can after adding emulate csh above those lines.
 
 Anyone know which option might be the culprit here?

csh_junkie_quotes

--- ../zsh-debug/zsh/Completion/compinit2008-06-06 17:43:35.0 
+0100
+++ Completion/compinit 2008-09-04 13:34:21.0 +0100
@@ -139,6 +139,7 @@
 NO_allexport
 NO_aliases
 NO_cshnullglob
+NO_cshjunkiequotes
 NO_errexit
 NO_globsubst
 NO_histsubstpattern


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486785: tab completion broken

[Peter Stephenson]

On Mon, 30 Jun 2008 21:35:22 +0100
Peter Stephenson [EMAIL PROTECTED] wrote:
 I'm now a little worried it should be going into menu completion at this
 point even without the option being set; the documentation for
 _approximate says the completer will normally start menu completion
 but in the test case above it doesn't.

Comparing with 4.3.4 confirms this problem.

 I'm not clear how it starts menu
 completion, since _approximate only mentions menu completion in a
 comment at the top, implying it is done somewhere within that function
 that I can't find.

It comes from the combination of

  compstate[pattern_match]='*'

in _approximate and something I haven't bothered to track down setting

  compstate[insert]=menu

somewhere else.  The need for the combination, which I don't really
understand, also underlies what's going on in the code.

See the comment in the fix.  I think I've said quite enough there.

Please do report any remaining problems, since I've at least half
convinced myself I've fixed it, however unlikely that seems.

Index: Src/Zle/compcore.c
===
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.94
diff -u -r1.94 compcore.c
--- Src/Zle/compcore.c  6 May 2008 16:01:19 -   1.94
+++ Src/Zle/compcore.c  6 Jul 2008 19:38:17 -
@@ -2277,6 +2277,45 @@
haspattern = 1;
}
}
+   } else {
+   /*
+* (This is called a comment.  Given you've been
+* spending your time reading the completion time, you
+* may have forgotten what one is.  It's used to deconfuse
+* the poor so-and-so who's landed up having to maintain
+* the code.)
+*
+* So what's going on here then?  I'm glad you asked.  To test
+* whether we should start menu completion, we test whether
+* compstate[insert] has been set to menu, but only if we found
+* patterns in the code.  It's not clear to me from the
+* documentation why the second condition would apply, but sure
+* enough if I remove it the test suite falls over.  (Testing
+* comppatmatch at the later point doesn't work because compstate
+* is likely to have been reset by the point we actually insert
+* the completions, after all functions have exited; this is at
+* least part of the problem.)  In the present case, we are not
+* doing matching on the code because all the clever stuff has
+* been done over our heads and we've simply between told to
+* insert it.  However, we still need to take account of ambiguous
+* completions properly.  To do this, we rely on the caller to
+* pass down the same prefix/suffix with the patterns that we
+* would get if we were doing matching, and test those for
+* patterns.  This gets us out of the hole apparently without
+* breaking anything.  The particular case where this is needed is
+* approximate file completion: this does its own matching but
+* _approximate still sets the prefix to include the pattern.
+*/
+   if (comppatmatch  *comppatmatch) {
+   int pflen = strlen(compprefix);
+   char *tmp = zhalloc(pflen + strlen(compsuffix) + 1);
+   strcpy(tmp, compprefix);
+   strcpy(tmp + pflen, compsuffix);
+   tokenize(tmp);
+   remnulargs(tmp);
+   if (haswilds(tmp))
+   haspattern = 1;
+   }
}
if (*argv) {
if (dat-pre)


-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486785: tab completion broken

[Peter Stephenson]

On Sun, 22 Jun 2008 23:23:42 +0100
Peter Stephenson [EMAIL PROTECTED] wrote:
 On Thu, 19 Jun 2008 21:15:39 +
 Clint Adams [EMAIL PROTECTED] wrote:
  Using only the following zshrc, ls /tmp/.X2tab results in the entire
  argument being elided (/tmp/.X* exists but /tmp/.X2* does not).
  
  --8--zshrc--8--
  autoload -U compinit
  compinit
  
  zstyle ':completion:*' completer _approximate
  
  --8--zshrc--8--
 
 It's something to do with using the -U argument to compadd when you've
 got ambiguous completions: it works fine when there's only a single
 completion.  It was triggered by adding the -U's to do approximation in
 non-final path segments (even before the compmatch change).

Slight cop out, but the -M matcher option is not documented as doing
anything useful with the -U option and removing that wherever it occurs
together with -U makes it better.  (In case you're worried, this is not
the matcher from the matcher list, which is passed down to compfiles
earlier on to generate the list of trial completions rather than to
compadd; the matcher here appears to be some kind of it works better
that way kludge, I think to help path completion by allowing anything
that matches completions of partial path prefixes.)  Strictly I think
the -M argument should be ignored, and it isn't, which is probably a
bug, but I don't have time to investigate bugs that can be easily worked
around, and I think given the -U the new code is more correct anyway.
I've only removed the -M where there is a -U option.

This improves things to the point where the unambiguous prefix is kept
and the trial completions are available.  I think the main difference in
my own set-up was having menucomplete set, but my experiences are a bit
ambiguous.

I'm now a little worried it should be going into menu completion at this
point even without the option being set; the documentation for
_approximate says the completer will normally start menu completion
but in the test case above it doesn't.  I'm not clear how it starts menu
completion, since _approximate only mentions menu completion in a
comment at the top, implying it is done somewhere within that function
that I can't find.  If someone who doesn't usually have menu completion
set can confirm that it's still not doing the right thing, I will see if
I can find any further clues to how this should be happening.

I couldn't find anything this change broke and I don't think it's
supposed to have any negative effect.

The reason this happens with _approximate, by the way, seems to be due
to addition of the default completion:
  compadd -V -default- -U -Q - /tmp/.X2 
to the array of normal matches (despite the fact there is no -M argument
here---possibly the discrepancy between the two is confusing it).  I
traced the bug down to the function (assuming you've got /tmp/.X2 on
the command line---the tmp1 contents aren't important, they're just what
I happen to have):

  local -a tmp1

  tmp1=( .X0-lock .X11-unix .Xfoo )
  compadd -J -default- -U -Qf -J -default- -p /tmp/ -s '' \
-W /tmp/ -M 'r:|/=* r:|=*' -a tmp1
  compadd -V -default- -U -Q - /tmp/.X2

However, I don't think that helps us with the remaining problem
because that extra compadd can't explain how we get into menu
completion.

(I have kept this mail short by expunging phrases like in an obscure
fashion and undocumented and incomprehensible, as well as sarcastic
asides like of course and as I'm sure you'd guessed, and
long-suffering comments like spending weeks of my life, from wherever
they naturally occur.  You can have fun reinserting them.  You can have
even more fun writing a lex programme to fill out a completion system
bug fix posting with the appropriate comments.)

Index: Completion/Unix/Type/_path_files
===
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.31
diff -u -r1.31 _path_files
--- Completion/Unix/Type/_path_files21 Jun 2008 21:36:01 -  1.31
+++ Completion/Unix/Type/_path_files30 Jun 2008 19:55:41 -
@@ -598,7 +598,7 @@
compadd -U -Qf [EMAIL PROTECTED] -p $IPREFIX$linepath$tmp2 \
-s /${tmp3#*/}$ISUFFIX \
-W $prepath$realpath$testpath \
-   [EMAIL PROTECTED] -M r:|/=* r:|=* \
+   [EMAIL PROTECTED] \
$listopts \
-a tmp1
   else
@@ -608,7 +608,7 @@
compadd -U -Qf [EMAIL PROTECTED] -p $IPREFIX$linepath$tmp2 \
-s $ISUFFIX \
-W $prepath$realpath$testpath \
-   [EMAIL PROTECTED] -M r:|/=* r:|=* \
+   [EMAIL PROTECTED] \
$listopts \
-a tmp1
   fi
@@ -617,7 +617,7 @@
  compadd -U -Qf [EMAIL PROTECTED] -p $IPREFIX$linepath$tmp2 \
  -s $ISUFFIX \
  -W $prepath$realpath$testpath \
-  [EMAIL

Bug#486785: tab completion broken

[Peter Stephenson]

On Thu, 19 Jun 2008 21:15:39 +
Clint Adams [EMAIL PROTECTED] wrote:
 Using only the following zshrc, ls /tmp/.X2tab results in the entire
 argument being elided (/tmp/.X* exists but /tmp/.X2* does not).
 
 --8--zshrc--8--
 autoload -U compinit
 compinit
 
 zstyle ':completion:*' completer _approximate
 
 --8--zshrc--8--

It's something to do with using the -U argument to compadd when you've
got ambiguous completions: it works fine when there's only a single
completion.  It was triggered by adding the -U's to do approximation in
non-final path segments (even before the compmatch change).  The initial
. is a red herring.  However, I don't know where it's going wrong
since when I do approximation after normal completion (but lots of other
options set, too) it works fine.  This triggers a different part of
_path_files which has compadd -U but slight differences in the other
arguments.  Internally the Cline struct that's used for generating the
command line looks a bit spartan in the failed case.  Needless to say I
haven't the faintest clue where this is leading.

pws



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482662: zsh: completion with locate gives extra output

[Peter Stephenson]

On Sat, 24 May 2008 20:21:35 +
Clint Adams [EMAIL PROTECTED] wrote:
 On Sat, May 24, 2008 at 10:16:56PM +0530, Sykora wrote:
  I just typed locate at the prompt and pressed space, followed by tab. 
  
  
  $ locate Usage: locate [-d path | --database=path] [-e | -E | 
  --[non-]existing]
[-i | --ignore-case] [-w | --wholename] [-b | --basename] 
[--limit=N | -l N] [-S | --statistics] [-0 | --null] [-c | --count]
[-P | -H | --nofollow] [-L | --follow] [-m | --mmap ] [ -s | --stdio ]
[-A | --all] [-p | --print] [-r | --regex ] [--regextype=TYPE]
[--max-database-age D] [--version] [--help]
pattern...
  
  Report bugs to [EMAIL PROTECTED].
  CURSOR HERE
 
 Ah, okay. You are using GNU locate and I am using mlocate.
 
 So _locate is trying to match *(#i)gnu locate*, which does not appear in the
 `locate -V` output (nor does it appear in the `locate --version` output).
 Does anyone have an older version of findutils handy? Would matching for
 *findutils* or (#i)*findutils*gnu* cover all possibilities?

Presumably also copying stderr to stdout.

Index: Completion/Unix/Command/_locate
===
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_locate,v
retrieving revision 1.2
diff -u -r1.2 _locate
--- Completion/Unix/Command/_locate 11 Feb 2008 16:28:30 -  1.2
+++ Completion/Unix/Command/_locate 25 May 2008 14:50:52 -
@@ -11,7 +11,7 @@
   ;;
 
   (locate)
-  input=$(_call_program locate $words[1] -V)
+  input=$(_call_program locate $words[1] -V 21)
   case $input in
 (*mlocate*)
 ltype=mlocate
@@ -21,7 +21,7 @@
 ltype=slocate
 ;;
 
-(*(#i)gnu locate*)
+(*(#i)gnu locate*|*findutils*gnu*)
 ltype=gnu
 ;;
 

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
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)

[Peter Stephenson]

On Sat, 24 May 2008 14:44:45 +0200
Vincent Lefevre [EMAIL PROTECTED] wrote:
 This is 100% reproducible with both zsh and zsh-beta.

If it's just a matter of starting vlc and trying to kill it for you,
then there's something more to track down since this doesn't happen for
me (Fedora 9).

There must be more to it than simply zsh not waiting for children:  that
has no effect on whether vlc is executing code.  The propagation of the
signal to the programme seems to me a likely suspect.  Of course these
could be related to the same fundamental problem.  vlc does appear to do
some fairly odd things with signals which may be interacting in
unexpected ways with the shell.

It would be useful to know whether the vlc job is listed in the shell's
job table at this point, and to see what else is there.  The array
jobtab contains the jobs, which contain linked lists of process
structures.  One of the jobs (it should be the one indexed
by curjob) should include the vlc process.  The previous bug
happened because some other job (marked as defunct) had
a process with the same number.

pws



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#480889: zcompiling messes with alias-in-function expansion

[Peter Stephenson]

Clint Adams wrote:
 I imagine that this is somehow related to
 
 alias foo='echo bar'; foo

Right, it's the same problem.  Aliases are expanded early on, during
input, and so you can't use an alias within the same chunk of shell code
as where it's defined.  This isn't going to change; you need to find a
workaround.  The standard approach is to use functions in such chunks of
code.  Aliases tend to be regarded as largely an interactive feature.

This ought to be documented somewhere, if it isn't.

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#479576: incorrect interpretation of LS_COLORS link=target by compsys

[Peter Stephenson]

;
+
 /* Combined length of LC and RC, maximum length of capability strings. */
 
 static int lr_caplen, max_caplen;
@@ -428,24 +436,33 @@
for (i = 0, nn = colnames; *nn; i++, nn++)
if (!strcmp(n, *nn))
break;
-   p = getcolval(s, 0);
-   if (*nn) {
-   Filecol fc, fo;
-
-   fc = (Filecol) zhalloc(sizeof(*fc));
-   fc-prog = (i == COL_EC || i == COL_LC || i == COL_RC ?
-   NULL : gprog);
-   fc-col = s;
-   fc-next = NULL;
-   if ((fo = mcolors.files[i])) {
-   while (fo-next)
-   fo = fo-next;
-   fo-next = fc;
-   } else
-   mcolors.files[i] = fc;
+   /*
+* special case:  highlighting link targets
+*/
+   if (i == COL_LN  strpfx(target, s) 
+   (s[6] == ':' || !s[6])) {
+   mcolors.flags |= LC_FOLLOW_SYMLINKS;
+   p = s + 6;
+   } else {
+   p = getcolval(s, 0);
+   if (*nn) {
+   Filecol fc, fo;
+
+   fc = (Filecol) zhalloc(sizeof(*fc));
+   fc-prog = (i == COL_EC || i == COL_LC || i == COL_RC ?
+   NULL : gprog);
+   fc-col = s;
+   fc-next = NULL;
+   if ((fo = mcolors.files[i])) {
+   while (fo-next)
+   fo = fo-next;
+   fo-next = fc;
+   } else
+   mcolors.files[i] = fc;
+   }
+   if (*p)
+   *p++ = '\0';
}
-   if (*p)
-   *p++ = '\0';
return p;
 }
 }
@@ -474,6 +491,7 @@
 int i, l;
 
 max_caplen = lr_caplen = 0;
+mcolors.flags = 0;
 queue_signals();
 if (!(s = getsparam(ZLS_COLORS)) 
!(s = getsparam(ZLS_COLOURS))) {
@@ -1685,7 +1703,7 @@
}
zcoff();
 } else {
-   int mx;
+   int mx, modec;
 
if (g-widths) {
int i;
@@ -1733,8 +1751,13 @@
zcputs(g-name, COL_HI);
else if (mselect = 0  (m-flags  (CMF_MULT | CMF_FMULT)))
zcputs(g-name, COL_DU);
-   else if (m-mode)
-   subcols = putfilecol(g-name, m-str, m-mode);
+   else if (m-mode) {
+   if (mcolors.flags  LC_FOLLOW_SYMLINKS) {
+   subcols = putfilecol(g-name, m-str, m-fmode);
+   } else {
+   subcols = putfilecol(g-name, m-str, m-mode);
+   }
+   }
else
subcols = putmatchcol(g-name, (m-disp ? m-disp : m-str));
 
@@ -1747,12 +1770,13 @@
len = ZMB_nicewidth(m-disp ? m-disp : m-str);
mlprinted = len ? (len-1) / columns : 0;
 
-   if ((g-flags  CGF_FILES)  m-modec) {
+   modec = (mcolors.flags  LC_FOLLOW_SYMLINKS) ? m-fmodec : m-modec;
+   if ((g-flags  CGF_FILES)  modec) {
if (m-gnum != mselect) {
zcoff();
zcputs(g-name, COL_TC);
}
-   putc(m-modec, shout);
+   putc(modec, shout);
len++;
 }
if ((len = width - len - 2)  0) {
@@ -2556,6 +2580,15 @@
s-origcs = origcs;
s-origll = origll;
 s-status = dupstring(status);
+   /*
+* with just the slightest hint of a note of infuriation:
+* mode here is the menu mode, not the file mode, despite
+* the fact we're in a file dealing with file highlighting;
+* but that's OK, because s is a menu stack entry, despite
+* the fact we're in a function declaring s as char *.
+* anyway, in functions we really mean *mode* it's
+* called m, to be clear.
+*/
 s-mode = mode;
menucmp = menuacc = hasoldlist = 0;
minfo.cur = NULL;
@@ -2674,6 +2707,7 @@
s-origcs = origcs;
s-origll = origll;
 s-status = dupstring(status);
+   /* see above */
 s-mode = mode;
accept_last();
handleundo();



-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
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

[Peter Stephenson]

On Tue, 6 May 2008 17:55:55 +0100
martin f krafft [EMAIL PROTECTED] wrote:
 also sprach Bart Schaefer [EMAIL PROTECTED] [2008.05.06.1645 +0100]:
  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.
 
 What, if I may ask, is the purpose of zsh/files?

Its primary purpose has been as a fallback on a system where the shell
is working but nothing much else is.  Hence it provides the limited,
easy-to-implement things you're likely to need to fix what needs
fixing.  Moving things between file systems typically isn't something
you need (though in any given case it may be, as well as a whole load of
other stuff the shell doesn't provide).

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#478019: zsh: Should handle non-breaking space as word separator

[Peter Stephenson]

On Sat, 26 Apr 2008 16:05:48 +0100
Clint Adams [EMAIL PROTECTED] wrote:
 On Sat, Apr 26, 2008 at 12:00:03PM +0100, Samuel Thibault wrote:
  On a french keyboard, '|' is typed by using alt-gr, and the non-breaking
  space is often typed by using alt-gr space. That often leads to this:
  
  € echo a | grep a
  zsh: command not found:  grep
  
  Because zsh looks for a  grep command, with leading non-breaking space
  because my thumb remained a bit too long on the alt-gr key.
  
  This doesn't happen with bash, because bash treats non-breaking space as
  a word separator.  Could zsh do the same? (currently, I have defined
  alias  grep=grep
  alias  vi=vi
  ...)
 
 Having locale-based (and multibyte) word separators sounds like a nightmare
 to me, but maybe someone has some ideas.

I tend to agree with this.  It's doable, and the standard (SUS 2004)
supports the idea (see under LC_CTYPE) although it's a little bit
two-faced (only ASCII space characters are listed as requiring quoting,
for example).  However,

- I've been resisting having to convert the byte stream into anything
  else for basic shell parsing.  I've got far better things to do
  than make the shell slower and buggier for a feature of doubtful
  general utility.
- Having basic syntactic elements depending on the locale is really
  nasty.  We have one such kludge ourselves, (NO_)POSIX_IDENTIFIERS,
  which is mostly a sop to traditional pre-multibyte zsh behaviour.  I
  would actively discourage people from assuming this sort of behaviour.
- It seems to me somewhat ludicrous making a change specifically so
  that arguments can be separated by a non-breaking space.  Is it
  or isn't it breakable?
- This isn't a general solution to mistyping anyway.  You might be able
  to fix alt-gr space with xmodmap or the terminal emulator translation
  table.

(Yes, I know a little bit two-faced is meaningless, strictly
speaking.  I stopped speaking strictly years ago now.)

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#369305: zsh: failed to write history file /home/sven/.zsh-history: no such file or directory

[Peter Stephenson]

On Wed, 5 Mar 2008 14:41:58 -0800
Wayne Davison [EMAIL PROTECTED] wrote:
 On Wed, Mar 05, 2008 at 03:29:36PM -0500, Clint Adams wrote:
  As Sven notes, any history added before exiting will make it into the
  history file despite the error message.
 
 The history being added is the appending going on due to SHARE_HISTORY.
 The error is referring to the inability to rewrite the history file on
 exit, and it is actually failing (because the write-new, then rename
 steps would cause the file to change ownership).  If incremental history
 updating was not happening, the failed rewrite would indeed not save
 anything new.  The no such file or directory error string is
 presumably a left-over errno that Peter noticed.

Yes, I've found where... at this point we've already handled the error in
the manner you say by simply not trying to write the history, so there's no
system error we haven't dealt with and we should reset errno.

We could fix both problems by not printing an error if there's no errno,
as below.  That's OK in the specific circumstances, but probably not right
in all cases.  Could we, for example, pass down a flag when savehistfile()
is called from itself to do the rewriting and suppress the error message,
or make it more anodyne, in that case?

If we decide a warning message is still appropriate, given that we've
detected exactly what's going on it should probably be more specific than
just a vague failed to write history.

I won't commit this until we've resolved the TODO, but you might want to
check it does remove the error message.

Index: Src/hist.c
===
RCS file: /cvsroot/zsh/zsh/Src/hist.c,v
retrieving revision 1.70
diff -u -r1.70 hist.c
--- Src/hist.c  31 Dec 2007 23:14:17 -  1.70
+++ Src/hist.c  6 Mar 2008 10:16:08 -
@@ -2207,7 +2207,13 @@
struct stat sb;
int old_exists = stat(unmeta(fn), sb) == 0;
 
+   errno = 0;
if (old_exists  sb.st_uid != geteuid()) {
+   /*
+* TODO: do we want an error message about changed ownership
+* here?  Do we want a lesser error message, or none,
+* if this call to savehistfile() was just a rewrite?
+*/
free(tmpfile);
tmpfile = NULL; /* Avoid an error about HISTFILE.new */
out = NULL;
@@ -2302,7 +2308,7 @@
 } else
ret = -1;
 
-if (ret  0  err) {
+if (ret  0  err  errno) {
if (tmpfile) {
zerr(failed to write history file %s.new: %e, fn, errno);
free(tmpfile);

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#468386: zsh-beta: Slow command completion

[Peter Stephenson]

Clint Adams wrote:
 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?

Limit the extra information for commands to people who *really* want it,
by using another style (extra_verbose) with an appropriate warning
in the doc that this level of verbosity has speed implications.  The
style is then reusable if this crops up elsewhere.

Bart may have more drastic suggestions...

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466655: the expression {x=(); echo ${+x[(r)blah]}} changes meaning between 4.3.2 and current version

[Peter Stephenson]

On Wed, 27 Feb 2008 09:35:40 -0500
Clint Adams [EMAIL PROTECTED] wrote:
 On Wed, Feb 20, 2008 at 07:09:05AM +, Frederik Eaton wrote:
  Hello, one of my scripts has broken because of the following change:
  
  $ zsh --version
  zsh 4.3.2 (i686-pc-linux-gnu)
  $ x=(); echo ${+x[(r)blah]}
  0
  
  $ zsh --version
  zsh 4.3.5 (i686-pc-linux-gnu)
  $ x=(); echo ${+x[(r)blah]}
  1
  
  Is the behaviour of zsh's parameter expansion supposed to be stable?
 
 I think this is related to 23273*

No, this is unexpected fallout from the changes to make zero subscripts
behave in a more rational fashion, 23562.  I hadn't even remembered this
form worked with subscripts, but the the manual certainly suggests it
should (and it's definitely useful).  I've added a test that should keep it
working.

Index: Src/subst.c
===
RCS file: /cvsroot/zsh/zsh/Src/subst.c,v
retrieving revision 1.82
diff -u -r1.82 subst.c
--- Src/subst.c 16 Dec 2007 14:05:16 -  1.82
+++ Src/subst.c 27 Feb 2008 15:28:41 -
@@ -1915,7 +1915,8 @@
 hkeys|hvals|
 (arrasg ? SCANPM_ASSIGNING : 0)|
 (qt ? SCANPM_DQUOTED : 0))) ||
-   (v-pm  (v-pm-node.flags  PM_UNSET)))
+   (v-pm  (v-pm-node.flags  PM_UNSET)) ||
+   (v-flags  VALFLAG_EMPTY))
vunset = 1;
 
if (wantt) {
Index: Test/D04parameter.ztst
===
RCS file: /cvsroot/zsh/zsh/Test/D04parameter.ztst,v
retrieving revision 1.29
diff -u -r1.29 D04parameter.ztst
--- Test/D04parameter.ztst  30 Oct 2007 14:01:35 -  1.29
+++ Test/D04parameter.ztst  27 Feb 2008 15:28:41 -
@@ -52,6 +52,14 @@
 0:$+...
 1 1 0 0
 
+  x=()
+  print ${+x} ${+x[1]} ${+x[(r)foo]} ${+x[(r)bar]}
+  x=(foo)
+  print ${+x} ${+x[1]} ${+x[(r)foo]} ${+x[(r)bar]}
+0:$+... with arrays
+1 0 0 0
+1 1 1 0
+
   set1=set1v
   null1=
   print ${set1:-set1d} ${set1-set2d} ${null1:-null1d} ${null1-null2d} x

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
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

[Peter Stephenson]

On Sun, Jul 10, 2005 at 12:57:47AM +, Bart Schaefer wrote:
 I just noticed 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.

There are two completely separate parts of the shell that restore
parameters.  There is one I wrote for function scope, and there is a second
one that someone else wrote without taking any notice of the first one that
restores parameters in this case.  (Good job I never get bitter, eh?)  This
second one doesn't take account of restoring a special parameter when the
local value is exported and the old value isn't.  For specials there is
always an entry in the table, so this applies even if LC_ALL isn't actually
set.

It should just be a case of removing stuff from the environment if we know
it shouldn't be there.  I can't see any cases when this would be wrong,
anyway.  (There are POSIX exceptions, which I don't think cover LC_ALL
anyway, where the value is preserved after the function call, but none that
would force an export to be inconsistent with the local value.)

Index: Src/exec.c
===
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.128
diff -u -r1.128 exec.c
--- Src/exec.c  9 Dec 2007 23:53:33 -   1.128
+++ Src/exec.c  21 Feb 2008 18:14:41 -
@@ -3113,6 +3113,8 @@
DPUTS(!tpm || PM_TYPE(pm-node.flags) != 
PM_TYPE(tpm-node.flags) ||
  !(pm-node.flags  PM_SPECIAL),
  BUG: in restoring special parameters);
+   if (!pm-env  tpm-env)
+   delenv(tpm);
tpm-node.flags = pm-node.flags;
switch (PM_TYPE(pm-node.flags)) {
case PM_SCALAR:


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#463507: zsh: Completion fails with: _main_complete:161: permission denied:

[Peter Stephenson]

Clint Adams wrote:
 On Tue, Feb 05, 2008 at 02:46:51AM -0500, A. Costa wrote:
  'zsh-newuser-install' gave me:
 
  % zstyle -L | grep completer
  zstyle ':completion:*' completer ''

 I think maybe it should prevent that from ever happening.

 You probably want

 zstyle ':completion:*' completer _complete

I presume the problem is that it's not set by default, rather than that
the user explicitly unset the completions?  I think this should fix it.

Index: Completion/compinstall
===
RCS file: /cvsroot/zsh/zsh/Completion/compinstall,v
retrieving revision 1.10
diff -u -r1.10 compinstall
--- Completion/compinstall  21 Aug 2006 19:40:34 -  1.10
+++ Completion/compinstall  5 Feb 2008 14:38:01 -
@@ -506,7 +506,7 @@
  ;;
[sS]) olist=
  tmparr=(_complete _approximate _correct _match _expand)
- while true; do
+ while true; do
clear
print \
  *** compinstall:  choosing completers to have _oldlist behaviour ***
@@ -839,7 +839,10 @@
   for c in ${=newc}; do
 completers[$c]=1
   done
-  clist=(_list _oldlist _menu _expand _complete _ignored
+  if (( ${#completers} == 0 )); then
+completers[_complete]=1
+  fi
+  clist=(_list _oldlist _menu _expand _complete _ignored
  _match _correct _approximate _prefix)

   # TODO: these are a bit brief, so could provide some more detailed help.

--
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#463507: zsh: Completion fails with: _main_complete:161: permission denied:

[Peter Stephenson]

Peter Stephenson wrote:
 +  if (( ${#completers} == 0 )); then
 +completers[_complete]=1
 +  fi

Come to think of it, the default should almost certainly be the same as
what the completion system uses if the style isn't set, i.e. with
_ignored, too.  I'll commit it with that added.

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457076: zsh: is-at-least does not work properly

[Peter Stephenson]

On Wed, 19 Dec 2007 14:19:34 -0500
Clint Adams [EMAIL PROTECTED] wrote:
 On Wed, Dec 19, 2007 at 05:15:09PM +0200, Tonguc Yumruk wrote:
  The is-at-least function in zsh (which is used in some other functions)
  uses setopt LOCAL_OPTIONS which is only available in ksh emulation mode.
  Instead it should use emulate -L zsh to use LOCAL_OPTIONS in zsh mode.
  Patch is attached.

setopt LOCAL_OPTIONS should work fine in all modes.  If there are places
where it doesn't that's a bug.

It would be more consistent to use emulate -L zsh here but it's
exactly equivalent to what's there already.

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457076: zsh: is-at-least does not work properly

[Peter Stephenson]

On Wed, 19 Dec 2007 22:41:07 +0200
Tonguc Yumruk [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED]:~% setopt LOCAL_OPTIONS
 setopt: no such option: LOCAL_OPTIONS
 
 On the other hand this works fine:
 
 [EMAIL PROTECTED]:~% setopt localoptions

I wonder if that's a function of your locale ($LANG setting)?  It's
possible it's not translating upper case characters to lower case
properly.  Ah, in fact it probably is...

2007-03-15  Peter Stephenson  [EMAIL PROTECTED]

* 23219: Src/options.c: Ismail Dönmez reported that lower
casing of I to dotless i in tr_TR.UTF-8 broke option handling.

I would guess you'll find that any option with an upper case I in it
won't work properly.

Now I look, I've found I've missed a place that needs this fix (although
it doesn't apply here).

Index: Src/options.c
===
RCS file: /cvsroot/zsh/zsh/Src/options.c,v
retrieving revision 1.37
diff -u -r1.37 options.c
--- Src/options.c   18 Jun 2007 13:25:05 -  1.37
+++ Src/options.c   19 Dec 2007 21:46:08 -
@@ -571,7 +571,9 @@
if (*t == '_')
chuck(t);
else {
-   *t = tulower(*t);
+   /* See comment in optlookup() */
+   if (*t = 'A'  *t = 'Z')
+   *t = (*t - 'A') + 'a';
t++;
}
 


-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#455376: tab completion following mutt -f = no longer works

[Peter Stephenson]

On Thu, 13 Dec 2007 17:12:33 -0500
Paul Kimoto [EMAIL PROTECTED] wrote:
  unsetopt equals
  autoload -U compinit  compinit
  zstyle ':completion:*' mail-directory $HOME/email
  zstyle ':completion:*:warnings' format 'No matches for: %d'
  
  I see errors like
  
  $ mutt -f =de[TAB]
  No matches for: `mailbox', `mailbox specification', `mailbox file', or 
  `file'
 
  I don't recall this ever working.  Can you narrow it down to when it
  did?
 
 On a different machine, zsh 4.3.2-25 (Debian stable), using the above
 four-line .zshrc, works as I'd like.

Looking at _mailboxes suggests it should work, but I don't use mutt so
can't follow this.  Can someone find out what change did this?

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#377765: zsh: completion of configure script does not handle underscore properly

[Peter Stephenson]

On Thu, 13 Dec 2007 14:09:09 -0500
Clint Adams [EMAIL PROTECTED] wrote:
 This still seems to be an issue and that patch no longer applies to
 current _arguments.

I would imagine something simple-minded like the following would do this
consistently.  Please commit it if it works.

Index: Completion/Base/Utility/_arguments
===
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.20
diff -u -r1.20 _arguments
--- Completion/Base/Utility/_arguments  16 Feb 2007 15:02:03 -  1.20
+++ Completion/Base/Utility/_arguments  13 Dec 2007 20:56:36 -
@@ -97,7 +97,7 @@
# present.  Maybe the problem was that the intervening code
# didn't.  If it's buggy without removing them, the problem
# probably is later, not here.
-   if [[ -z ${tmp[(r)${match[1]%%[^a-zA-Z0-9-]#}]} ]]; then
+   if [[ -z ${tmp[(r)${match[1]%%[^a-zA-Z0-9_-]#}]} ]]; then
 tmp+=($match[1])
fi
opt=$match[2]
@@ -218,9 +218,9 @@
odescr=
  fi
  if [[ $opt = (#b)(*)\[\=* ]]; then
-   opt2=${${match[1]}//[^a-zA-Z0-9-]}=-${dir}${odescr}
+   opt2=${${match[1]}//[^a-zA-Z0-9_-]}=-${dir}${odescr}
  else
-   opt2=${${opt}//[^a-zA-Z0-9-]}=${dir}${odescr}
+   opt2=${${opt}//[^a-zA-Z0-9_-]}=${dir}${odescr}
  fi
  if [[ $descr = :\=* ]]; then
cache+=( ${opt2}::${(L)${opt%\]}#*\=}:  )
@@ -247,7 +247,7 @@
  else
odescr=
  fi
- opt2=${${opt%%\=*}//[^a-zA-Z0-9-]}=${dir}${odescr}
+ opt2=${${opt%%\=*}//[^a-zA-Z0-9_-]}=${dir}${odescr}
  if [[ $descr = :\=* ]]; then
cache+=( ${opt2}:${(L)${opt%\]}#*\=}:  )
  else
@@ -268,7 +268,7 @@
  # I discovered after about half an hour, so don't do that.
  ${(@)^${(@)tmp:#^*:*}//:/[}]
  # commands with no description
- ${(@)${(@)tmp:#*:*}//[^a-zA-Z0-9-]})
+ ${(@)${(@)tmp:#*:*}//[^a-zA-Z0-9_-]})
 if [[ -n $descr  $descr != ': :  ' ]]; then
  cache+=( ${(@)^tmp}${descr} )
 else

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#185228: [EMAIL PROTECTED]: Bug#185228: zsh: Incorrect filename generation with glob qualifier mh+]

[Peter Stephenson]

);
+}
+return (g_range  0 ? div  days :
+   g_range  0 ? div  days :
+   div == days);
 }
 
 /* evaluate a string */
Index: Src/lex.c
===
RCS file: /cvsroot/zsh/zsh/Src/lex.c,v
retrieving revision 1.41
diff -u -r1.41 lex.c
--- Src/lex.c   23 Aug 2007 22:04:25 -  1.41
+++ Src/lex.c   13 Dec 2007 22:33:51 -
@@ -1099,7 +1099,7 @@
break;
case LX2_OUTANG:
if (!intpos) {
-   if (in_brace_param || sub)
+   if (in_brace_param || pct || sub)
break;
else
goto brk;


-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451382: i18n is NOT so easy!

[Peter Stephenson]

On Fri, 07 Dec 2007 17:26:57 +
Peter Stephenson [EMAIL PROTECTED] wrote:
 Clint Adams wrote:
  On Fri, Dec 07, 2007 at 02:11:41PM +, Peter Stephenson wrote:
   Found it: see thread around
   
   http://www.zsh.org/mla/workers/2006/msg00753.html
  
  I think it would be easier to do something like bash's $ interface to
  gettext and co-opt that for completion translations.
 
 As far as I understood it (it doesn't seem to be well documented) that
 only does translations which are pre-compiled into the shell (or rather
 its libraries).  We need something which can be updated with completion
 functions.  It's OK if the definitions are in another file (though we
 could presumably have an interface which adds translations from the
 completion function itself) but it needs to be added at run time.
 
 Possibly we can still do this with $..., but I don't like the idea
 that if you change the original message you can no longer find the
 translation, which seems to me to be asking for trouble.

Further thoughts after groping through the gettext documentation for a
bit... this is not a definitive answer (though rather closer to one than
when I originally wrote that two hours and counting ago) but unless I post
it now I'll forget it.  A summary is that I believe we can use the
internationalization functions in the library behind gettext(), to avoid
reinventing the wheel and maintain some compatibility, but it'll take a
bit more care to get this right than simply $msgid plus
gettext(msgid).

I think we have two basic problems with the simplest $... / gettext()
interface.


1.

The problem in the last paragraph quoted.  I'm convinced this is a real
problem:  unlike with C programmes, the urge to tinker with strings in
shell functions is strong and if there's no visual cue that this has bad
side effects then the interface is, in my view, fundamentally broken.
To put it another way, only programmers tinker with C programmes while
users are actively encouraged to tinker with shell functions, so the
whole nature of the interface needs to be rethought to make it clear and
robust rather than minimal.

However, this isn't insuperable.  The msgid is only by convention the
original string and could be anything; it was designed to be simple in
the case of having many calls to gettext() throughout a programme.  As
we essentially have only one point of entry for translations in shell
functions (the shell's C code is a separate and much simpler problem
since this isn't fundamentally different from any other C programme), we
can do it how we like.  We can, for example, have translation strings
like:

$_mount_nfs_access_acregmin:specify cached file attributes minimum hold time

and have the following rule:

- If the string is in the form
identifer_character * : . *
  (we might need to make this more complicated eventually), first
  attempt look-up with the identifier characters.  If the lookup doesn't
  return the original string, this is the text we want.
- Otherwise look up with the whole string.  This is for compatibility.  Use
  of this in zsh functions would be deprecated.
- If it still returns the original string but there is an identifier
  part, return the string after the :.
- Maybe we want some rule about aliasing, it's not clear (we can leave
  it until a use becomes obvious). 

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.


2.

Unfortunately there's also the problem of finding message catalogues.
For the same reason that it's designed for simplicity with pre-compiled
programmes, gettext() itself appears to require them to be in a
particular hierarchy the top of which is determined at compile time.

This isn't good enough in our case.  We have functions that are
installed at different places in the function path.  The path can change
and the only clean way of finding message catalogues is using the same
path.  We *could* collect all translations at shell installation and
simply shrug our shoulders saying that's your lot, but in my view this
is too botched to consider.  (As far as I can tell this is what happens
in bash.)  It's a key part of the way the completion system works that
people can customize it themselves just by writing functions, and even
if adding translations to your own functions is unusual I still don't
think being limited to a predefined set is acceptable.  I don't mind
users (which includes administrators) having to run some utility to add,
or add to, a message catalogue, but I do mind them having to modify the
shell configuration and reinstall; even updating the shell libraries
with something like one of Clint's out-of-tree modules seems a bit over
the top.

However, it seems like we can get something better

Bug#451382: i18n is NOT so easy!

[Peter Stephenson]

Bart Schaefer wrote:
 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.

Fine, that gives us an easier test for whether there's a special msgid
anyway.  (I would still propose that msgid has to consist only of shell
identifier characters for simplicity.)

-- 
Peter Stephenson [EMAIL PROTECTED]
Web page now at http://homepage.ntlworld.com/p.w.stephenson/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451382: i18n is NOT so easy!

[Peter Stephenson]

On Thu, 6 Dec 2007 11:10:22 -0500
Clint Adams [EMAIL PROTECTED] wrote:
 On Thu, Dec 06, 2007 at 06:08:55PM +0200, Ismail Dönmez wrote:
  nothing as in it wouldn't be useful? Imho it would be useful for warning 
  messages like do you want to delete all files etc.
 
 Certainly it would be useful.

We need a completion framework for translation which might or might not use
gettext in the back end.  There were some discussions about this a while
ago, I think about the time we first got the line editor to use multibyte
characters, but I can't find them now.  This is a big project somebody will
have to volunteer for.

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070

Bug#451382: i18n is NOT so easy!

[Peter Stephenson]

Peter Stephenson wrote:
 On Thu, 6 Dec 2007 11:10:22 -0500
 Clint Adams [EMAIL PROTECTED] wrote:
 We need a completion framework for translation which might or might not use
 gettext in the back end.  There were some discussions about this a while
 ago, I think about the time we first got the line editor to use multibyte
 characters, but I can't find them now.

Found it: see thread around

http://www.zsh.org/mla/workers/2006/msg00753.html

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451382: i18n is NOT so easy!

[Peter Stephenson]

Clint Adams wrote:
 On Fri, Dec 07, 2007 at 02:11:41PM +, Peter Stephenson wrote:
  Found it: see thread around
  
  http://www.zsh.org/mla/workers/2006/msg00753.html
 
 I think it would be easier to do something like bash's $ interface to
 gettext and co-opt that for completion translations.

As far as I understood it (it doesn't seem to be well documented) that
only does translations which are pre-compiled into the shell (or rather
its libraries).  We need something which can be updated with completion
functions.  It's OK if the definitions are in another file (though we
could presumably have an interface which adds translations from the
completion function itself) but it needs to be added at run time.

Possibly we can still do this with $..., but I don't like the idea
that if you change the original message you can no longer find the
translation, which seems to me to be asking for trouble.

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#353607: Related problem?

[Peter Stephenson]

On Fri, 19 Oct 2007 15:52:45 -0400
Clint Adams [EMAIL PROTECTED] wrote:
 On Fri, Oct 19, 2007 at 09:18:22PM +0200, Georg Neis wrote:
  traal% ls -a
  ./  ../
  traal% mkdir a b
  traal% touch a/1 b/1
  traal% print -l *(F)
  a
  b
  traal% mv a à
  traal% print -l *(F)
  b

We don't unmetafy strings passed down to glob qualifier functions.
This appears to be correct in some cases (where the name is passed into
shell code for further processing), so it seems we need to do this within
qualnonemptydir().  (I left the first hunk in as it's a little neater
but it has no effect.)

Index: Src/glob.c
===
RCS file: /cvsroot/zsh/zsh/Src/glob.c,v
retrieving revision 1.59
diff -u -r1.59 glob.c
--- Src/glob.c  18 Jun 2007 13:25:05 -  1.59
+++ Src/glob.c  22 Oct 2007 09:15:07 -
@@ -326,7 +326,8 @@
/* Reject the file if the function returned zero *
 * and the sense was positive (sense1 == 0), or *
 * vice versa.   */
-   if ((!((qn-func) (news, bp, qn-data, qn-sdata)) ^ qn-sense)  
1) {
+   if ((!((qn-func) (news, bp, qn-data, qn-sdata))
+^ qn-sense)  1) {
/* Try next alternative, or return if there are no more */
if (!(qo = qo-or)) {
unqueue_signals();
@@ -3254,6 +3255,8 @@
 {
 DIR *dirh;
 struct dirent *de;
+int unamelen;
+char *uname = unmetafy(dupstring(name), unamelen);
 
 if (!S_ISDIR(buf-st_mode))
return 0;
@@ -3261,7 +3264,7 @@
 if (buf-st_nlink  2)
return 1;
 
-if (!(dirh = opendir(name)))
+if (!(dirh = opendir(uname)))
return 0;
 
 while ((de = readdir(dirh))) {


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070

Bug#416970: reverse-menu-complete crashes

[Peter Stephenson]

Clint Adams wrote:
 On Wed, Jun 06, 2007 at 05:46:32PM +0200, Vincent Lefevre wrote:
  This is quite simple in fact:
  
  vin:~ zsh -f
  vin% bindkey '\e\t' reverse-menu-complete
  vin% aaa
  
  At this time, I type Esc-Tab.
  
  vin% aaazsh: segmentation fault (core dumped)  zsh -f
  vin:~[139]
 
 Now that I can reproduce.

Should be fixed by 23478 (2007-05-28).

-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070



To access the latest news from CSR copy this link into a web browser:  
http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations 
page at http://ir.csr.com/csr/about/overview


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#411050: zsh: configure completion doesn't work after --enable-shared

[Peter Stephenson]

Clint Adams [EMAIL PROTECTED] wrote:
--enable-shared[=PKGS]  build shared libraries [default=yes]
  
  Same problem with --enable-static, where one has:
  
--enable-static[=PKGS]  build static libraries [default=yes]
 
 I haven't looked at _arguments, but presumably it doesn't understand
 this convention.

This seems to help.

I notice that automatically generated --without-* and --disable-*
option specifiers offer to add an argument, too.  Presumably this is
wrong?

Index: Completion/Base/Utility/_arguments
===
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.19
diff -u -r1.19 _arguments
--- Completion/Base/Utility/_arguments  10 Oct 2006 21:26:52 -  1.19
+++ Completion/Base/Utility/_arguments  16 Feb 2007 14:52:30 -
@@ -217,7 +217,11 @@
  else
odescr=
  fi
- opt2=${${opt%%\[\=*}//[^a-zA-Z0-9-]}=${dir}${odescr}
+ if [[ $opt = (#b)(*)\[\=* ]]; then
+   opt2=${${match[1]}//[^a-zA-Z0-9-]}=-${dir}${odescr}
+ else
+   opt2=${${opt}//[^a-zA-Z0-9-]}=${dir}${odescr}
+ fi
  if [[ $descr = :\=* ]]; then
cache+=( ${opt2}::${(L)${opt%\]}#*\=}:  )
  elif [[ $descr = ::* ]]; then


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  
http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations 
page at http://ir.csr.com/csr/about/overview


-- 
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).

[Peter Stephenson]

) {
int i;
 
@@ -1890,7 +1883,6 @@
break;
}
}
-#endif
if (sig  SIGCOUNT) {
zwarnnam(nam, unknown signal: SIG%s,
 signame, 0);
@@ -1953,7 +1945,6 @@
break;
if (*signame == '0'  !signame[1])
sig = 0;
-#ifdef ALT_SIGS
if (sig  SIGCOUNT) {
int i;
 
@@ -1964,7 +1955,6 @@
break;
}
}
-#endif
if (sig  SIGCOUNT) {
zwarnnam(nam, unknown signal: SIG%s, signame, 0);
zwarnnam(nam, type kill -l for a List of signals, NULL, 
0);
@@ -2042,18 +2032,40 @@
if (!strcmp(s, sigs[i]))
return i;
 
-#ifdef ALT_SIGS
 for (i = 0; alt_sigs[i].name; i++)
 {
if (!strcmp(s, alt_sigs[i].name))
return alt_sigs[i].num;
 }
-#endif
 
 /* no matching signal */
 return -1;
 }
 
+/* Get the name for a signal. */
+
+/**/
+mod_export const char *
+getsigname(int sig)
+{
+if (sigtrapped[sig]  ZSIG_ALIAS)
+{
+   int i;
+   for (i = 0; alt_sigs[i].name; i++)
+   if (sig == alt_sigs[i].num)
+   return alt_sigs[i].name;
+}
+else
+   return sigs[sig];
+
+/* shouldn't reach here */
+#ifdef DEBUG
+dputs(Bad alias flag for signal);
+#endif
+return ;
+}
+
+
 /* Get the function node for a trap, taking care about alternative names */
 /**/
 HashNode
@@ -2062,9 +2074,7 @@
 char fname[20];
 HashNode hn;
 HashNode (*getptr)(HashTable ht, char *name);
-#ifdef ALT_SIGS
 int i;
-#endif
 if (ignoredisable)
getptr = shfunctab-getnode2;
 else
@@ -2074,7 +2084,6 @@
 if ((hn = getptr(shfunctab, fname)))
return hn;
 
-#ifdef ALT_SIGS
 for (i = 0; alt_sigs[i].name; i++) {
if (alt_sigs[i].num == sig) {
sprintf(fname, TRAP%s, alt_sigs[i].name);
@@ -2082,7 +2091,6 @@
return hn;
}
 }
-#endif
 
 return NULL;
 }
Index: Src/zsh.h
===
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.73
diff -u -r1.73 zsh.h
--- Src/zsh.h   12 Apr 2005 15:11:12 -  1.73
+++ Src/zsh.h   1 Jun 2005 10:26:00 -
@@ -1852,7 +1852,8 @@
 /* Mask to get the above flags */
 #define ZSIG_MASK  (ZSIG_TRAPPED|ZSIG_IGNORED|ZSIG_FUNC)
 /* No. of bits to shift local level when storing in sigtrapped */
-#define ZSIG_SHIFT 3
+#define ZSIG_ALIAS (13)  /* Trap is stored under an alias */
+#define ZSIG_SHIFT 4
 
 /**/
 /* Flags to third argument of zle */


-- 
Peter Stephenson [EMAIL PROTECTED]  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK  Tel: +44 (0)1223 692070


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]