Buffered stderr on Linux

Buffered stderr on Linux

[Zoltan Hidvegi]

[-- Attachment #1: Type: application/pgp, Size: 2092 bytes --]

Re: Buffered stderr on Linux

[Bart Schaefer]

On Mar 12,  8:03pm, Zoltan Hidvegi wrote:
} Subject: Buffered stderr on Linux
}
} Now I wander why is it
} necessary to use malloc to allocate these buffers.  Is there anything
} against using static char[BUFSIZ] buffers?

Stdio will call free() on the buffer at fclose().  That means you should
always pass malloc'd buffers, and never call free() yourself on a buffer
that's been passed to any of the setbuf() variants!

-- 
Bart Schaefer
http://www.well.com/user/barts

Re: Buffered stderr on Linux

[Zoltan Hidvegi]

Bart Schaefer wrote:
> On Mar 12,  8:03pm, Zoltan Hidvegi wrote:
> } Subject: Buffered stderr on Linux
> }
> } Now I wander why is it
> } necessary to use malloc to allocate these buffers.  Is there anything
> } against using static char[BUFSIZ] buffers?
> 
> Stdio will call free() on the buffer at fclose().  That means you should
> always pass malloc'd buffers, and never call free() yourself on a buffer
> that's been passed to any of the setbuf() variants!

As far as I know zsh never closes stdout and stderr explicitely.  Of course
there is an implicit close on exit() (but not on _exit() which zsh use when
it forked) and a free may fail here but it is probably harmless.  Anyway it
is probably better to stay clean and use malloc.

Zoltan

Re: Buffered stderr on Linux

[Zoltan Hidvegi]

Bart Schaefer wrote:
> On Mar 12,  8:03pm, Zoltan Hidvegi wrote:
> } Subject: Buffered stderr on Linux
> }
> } Now I wander why is it
> } necessary to use malloc to allocate these buffers.  Is there anything
> } against using static char[BUFSIZ] buffers?
> 
> Stdio will call free() on the buffer at fclose().  That means you should
> always pass malloc'd buffers, and never call free() yourself on a buffer
> that's been passed to any of the setbuf() variants!

Well I've just checked it on Solaris and Linux and it seems that you are
wrong.

Try this:

#include <stdio.h>
#include <stdlib.h>

void
main(void)
{
    FILE *fp;
    char *buf;

    for (;;) {
	fp = fopen("/tmp/test_setvbuf", "w");
	buf = malloc(BUFSIZ);
	setvbuf(fp, buf, _IOFBF, BUFSIZ);
	fclose(fp);
    }
}

It will eat all memory you have.  But if you insert a free(buf); after the
fclose() it will run happily.

It means that static buffer can be used with setvbuf.

Zoltan

Re: Buffered stderr on Linux

[Steven L Baur]

>>>>> "Zoltan" == Zoltan Hidvegi <hzoli@cs.elte.hu> writes:

Zoltan> Bart Schaefer wrote:
>> 
>> Stdio will call free() on the buffer at fclose().  That means you should
>> always pass malloc'd buffers, and never call free() yourself on a buffer
>> that's been passed to any of the setbuf() variants!

Zoltan> Well I've just checked it on Solaris and Linux and it seems
Zoltan> that you are wrong.
 ...
Zoltan> It means that static buffer can be used with setvbuf.

I checked the source code to Linux libc 5.2.18 && libc 5.3.5 and
Zoltan is correct -- a buffer set by setvbuf is not freed upon fclose().

What does the standard say?  My copy of IEEE 1003.1 mentions setvbuf
but doesn't assign any specific details to it.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Buffered stderr on Linux

[Bart Schaefer]

On Mar 13, 12:17am, Zoltan Hidvegi wrote:
} Subject: Re: Buffered stderr on Linux
}
} Bart Schaefer wrote:
} > Stdio will call free() on the buffer at fclose().
}
} Well I've just checked it on Solaris and Linux and it seems that you are
} wrong.

Hm.  I was sure that I remembered running into a multiple-free problem at
one point with this.  However, the only notes I can find are about a case
where we avoided setbuf because we couldn't readily track the buffer pointer
all the way from setbuf to the fclose, and hence didn't know whether/when
to free it.  So either I've got some cruft from a really obscure platform
floating around in my head, which is entirely possible, or I was confused.

Sorry about the false alarm.


-- 
Bart Schaefer
http://www.well.com/user/barts

History file locking?

[Russell Senior]

In order to keep Zsh from trashing its history file, I have
implemented the following local patch.  Perhaps this can be worked
into the source tree?  This patch uses the fcntl() function to lock
the entire contents of the history file during read and write
operations, using the corresponding blocking read and write locks. 

-- 
Russell Senior                                seniorr@teleport.com



*** hist.c-orig	Thu Dec 21 14:44:16 1995
--- hist.c	Wed Apr 10 03:22:35 1996
***************
*** 30,35 ****
--- 30,36 ----
   */
  
  #include "zsh.h"
+ #include <fcntl.h>
  
  extern int cs, ll;
  
***************
*** 1250,1255 ****
--- 1251,1262 ----
      time_t tim = time(NULL);
      short *wordlist;
      int nwordpos, nwordlist;
+     struct flock lk;
+ 
+     lk.l_type = F_RDLCK;
+     lk.l_whence = SEEK_SET;
+     lk.l_start = 0;
+     lk.l_len = 0;
  
      if (!s)
  	return;
***************
*** 1257,1262 ****
--- 1264,1271 ----
  	nwordlist = 16;
  	wordlist = (short *)zalloc(nwordlist*sizeof(short));
  
+         fcntl(fileno(in),F_SETLKW,&lk);
+         
  	while (fgets(buf, sizeof(buf), in)) {
  	    int l = strlen(buf);
  	    char *pt, *start;
***************
*** 1326,1333 ****
  	    } else
  		ent->words = (short *)NULL;
  	}
  	fclose(in);
! 
  	zfree(wordlist, nwordlist*sizeof(short));
      } else if (err)
  	zerr("can't read history file", s, 0);
--- 1335,1345 ----
  	    } else
  		ent->words = (short *)NULL;
  	}
+         
+         lk.l_type = F_UNLCK;
+         fcntl(fileno(in),F_SETLKW,&lk);
  	fclose(in);
!         
  	zfree(wordlist, nwordlist*sizeof(short));
      } else if (err)
  	zerr("can't read history file", s, 0);
***************
*** 1341,1347 ****
--- 1353,1364 ----
      FILE *out;
      int ev;
      Histent ent;
+     struct flock lk;
  
+     lk.l_whence = SEEK_SET;
+     lk.l_start = 0;
+     lk.l_len = 0;
+     
      if (!s || !interact || savehist == 0)
  	return;
      ev = curhist - savehist + 1;
***************
*** 1352,1357 ****
--- 1369,1376 ----
      else
  	out = fdopen(open(s, O_CREAT | O_WRONLY | O_TRUNC, 0600), "w");
      if (out) {
+         lk.l_type = F_WRLCK;
+         fcntl(fileno(out),F_SETLKW,&lk);
  	for (; ev <= curhist; ev++) {
  	    ent = gethistent(ev);
  	    if (app & 2) {
***************
*** 1374,1385 ****
--- 1393,1410 ----
  	    }
  	    fputc('\n', out);
  	}
+         
+         lk.l_type = F_UNLCK;
+         fcntl(fileno(out),F_SETLKW,&lk);
  	fclose(out);
  
  	if (app & 2 && (out = fopen(s, "r"))) {
  	    char **store, buf[1024], **ptr;
  	    int i, l, histnum = 0;
  
+             lk.l_type = F_WRLCK;
+             fcntl(fileno(out),F_SETLKW,&lk);
+ 
  	    store = (char **)zcalloc((savehist + 1) * sizeof *store);
  	    while (fgets(buf, sizeof(buf), out)) {
  		l = strlen(buf);
***************
*** 1394,1407 ****
--- 1419,1439 ----
  		strcpy(store[i], buf);
  		histnum++;
  	    }
+             lk.l_type = F_UNLCK;
+             fcntl(fileno(out),F_SETLKW,&lk);
  	    fclose(out);
  	    if ((out = fdopen(open(s, O_WRONLY | O_TRUNC, 0600), "w"))) {
+                 lk.l_type = F_WRLCK;
+                 fcntl(fileno(out),F_SETLKW,&lk);
+ 
  		if (histnum < savehist)
  		    for (i = 0; i < histnum; i++)
  			fprintf(out, "%s", store[i]);
  		else
  		    for (i = histnum; i < histnum + savehist; i++)
  			fprintf(out, "%s", store[i % savehist]);
+                 lk.l_type = F_UNLCK;
+                 fcntl(fileno(out),F_SETLKW,&lk);
  		fclose(out);
  	    }
  	    for (ptr = store; *ptr; ptr++)

Re: History file locking?

[Zefram]

>In order to keep Zsh from trashing its history file, I have
>implemented the following local patch.  Perhaps this can be worked
>into the source tree?  This patch uses the fcntl() function to lock
>the entire contents of the history file during read and write
>operations, using the corresponding blocking read and write locks. 

I think it's a good idea, but the patch can't be included as-is.  There
needs to be a configure test to check if this type of locking is
available, and perhaps to try using flock() as a backup mechanism, if
available.

-zefram

Re: History file locking?

[Zoltan Hidvegi]

> >In order to keep Zsh from trashing its history file, I have
> >implemented the following local patch.  Perhaps this can be worked
> >into the source tree?  This patch uses the fcntl() function to lock
> >the entire contents of the history file during read and write
> >operations, using the corresponding blocking read and write locks. 
> 
> I think it's a good idea, but the patch can't be included as-is.  There
> needs to be a configure test to check if this type of locking is
> available, and perhaps to try using flock() as a backup mechanism, if
> available.

Also things get quite complicated when the history file is on an NFS volume.
Probaly some dot-locking method similar to the one used by sendmail & co
should be used.

Bye,

Zoltan

Re: History file locking?

[Zefram]

>Also things get quite complicated when the history file is on an NFS volume.
>Probaly some dot-locking method similar to the one used by sendmail & co
>should be used.

I wouldn't bother -- it's only a history file.  lockf() (and fcntl())
locking work over NFS anyway; it's only flock() that doesn't.  O_EXCL
isn't reliable over NFS, which makes .lock locking rather pointless.

-zefram

Re: History file locking?

[Barton E. Schaefer]

On Apr 10,  1:50pm, Zefram wrote:
} Subject: Re: History file locking?
}
} >Also things get quite complicated when the history file is on an NFS volume.
} >Probaly some dot-locking method similar to the one used by sendmail & co
} >should be used.
} 
} I wouldn't bother -- it's only a history file.  lockf() (and fcntl())
} locking work over NFS anyway; it's only flock() that doesn't.  O_EXCL
} isn't reliable over NFS, which makes .lock locking rather pointless.

Unfortunately, lockf() and fcntl() locking over NFS are very unreliable
in heterogenous networks, because they depend on all of nfsd, lockd, and
statd to be both running and compatible on every machine.  (Believe me,
I *know* about this.  Z-Mail has to do extremely reliable file locking
in all sorts of circumstances.)

And one of the failure modes for lockf/fcntl is to hang the process, so
you may want to avoid that.

It's actually possible to do .lock locking *more* reliably than lockf
if you follow some special rules.  Take a look at the file xcreat.c in
the mush (mail users's shell) sources, or at the file locking routines
in procmail.  Essentially, you create a file with a psuedo-random name
to avoid the O_EXCL problems, then you use link() to create the file
you really want, and then you stat() to check whether the link and the
psuedo-random file really are the same (in case of link races).

However, Zefram is right that it's probably more effort than it's worth.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: History file locking?

[Anthony Heading]

> It's actually possible to do .lock locking *more* reliably than lockf
> if you follow some special rules. [...]
> 
> However, Zefram is right that it's probably more effort than it's worth.

More than it's worth for the history.  But wouldn't it make a rather nice
general-purpose builtin?  `lockfile' from procmail is a pretty useful
utility - to have equivalent functionality in zsh would be great.

Anthony

Re: History file locking?

[Barton E. Schaefer]

On Apr 10,  6:08pm, Anthony Heading wrote:
} Subject: Re: History file locking?
}
} More than it's worth for the history.  But wouldn't it make a rather nice
} general-purpose builtin?  `lockfile' from procmail is a pretty useful
} utility - to have equivalent functionality in zsh would be great.

I think this one falls in the category of "if you can do it with an
external process, it doesn't belong in the shell".

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: History file locking?

[Anthony Heading]

Bart wrote:
> I think this one falls in the category of "if you can do it with an
> external process, it doesn't belong in the shell".

I understand the principle. And maybe you're right.  But zsh doesn't
rely much on /bin/[ for example.  Defence to the charge of featuritis:
  o  Not very much code
  o  Merely providing public access to a feature motivated by internal need
  o  Internalising would often allow more reliable/easier lock release.
  o  Lockfiles are a natural adjunct to shell programming
  o  Resulting portability of lockfile-utilising user scripts

One could bundle a separate implementation of 'lockfile' with zsh, I
guess.  But that feels a bit extreme.  Just because zsh is maybe biased
toward the 'bloated' end of the shell market doesn't mean we need to
become reactionary neo-minimalists to compensate.  Who uses rc anyhow?

I dunno. Just thought I'd flag the idea, no more than that.

Anthony

Re: History file locking?

[Zoltan Hidvegi]

> >Also things get quite complicated when the history file is on an NFS volume.
> >Probaly some dot-locking method similar to the one used by sendmail & co
> >should be used.
> 
> I wouldn't bother -- it's only a history file.  lockf() (and fcntl())
> locking work over NFS anyway; it's only flock() that doesn't.  O_EXCL
> isn't reliable over NFS, which makes .lock locking rather pointless.

lockf() should work on NFS, but on many systems it doesn't.  But properly
implemented .lock works:

1. create a temporary lock file
2. link the temporary lock to the real lock.

   If the link succeeds, stat the temporary lock file.  It its link count
   is 2 the locking really succeded, so remove the temp lock.  This stat
   trick should work even on NFS.

   If the link fails, check the validity of the lock (the lock file should
   contain the PID of the locking process) using kill(0, lock_pid).  If the
   lock is invalid, remove it and repeat step 2.

That works on all systems without configure checks.  Configure check for a
working lock method is not simple.  The checks should be done using all of
the possible filesystems which zsh may use.  Procmail has a test for that,
but I one managed to crach a Solaris machine with it running is as an
ordinal user.

Bye,

Zoltan

Re: History file locking?

[Barton E. Schaefer]

On Apr 10, 11:21pm, Zoltan Hidvegi wrote:
} Subject: Re: History file locking?
}
}    If the link fails, check the validity of the lock (the lock file should
}    contain the PID of the locking process) using kill(0, lock_pid).  If the
}    lock is invalid, remove it and repeat step 2.

That doesn't work when the competing processes are on two different
machines.  You can only reliably remove lock files by timing them out
based on the date of the file.  A process that wants to hang onto a
lock has to touch the lock file periodically to keep its date current.


-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts

Re: History file locking?

[Daniel Dignam]

Hmm,

  I've been using the following for years (I'm currently on 2.4.333
beta)

precmd () {
        fc -nl -1 | concat $MY_HISTFILE
}

  Were concat is a simple little program which gurantees you get a lock
(via some remote server proc). Then the .zshrc does something along the
lines of:

    tail -200 $MY_HISTFILE >/tmp/g$$

    fc -R  /tmp/g$$

    /bin/rm  /tmp/g$$

    It amazing how useful a shell history stretching back for a year can
be.

   As Bart said earlier, "if you can do it with an external process, it
doesn't belong in the shell"

   Coping with locking over NFS is not a nice hole.


-- 

Daniel Dignam,                              mailto:daniel@edsug.com                    
Assemblies Development                       Phone: +44 1223-371591
EDS Unigraphics                                FAX: +44 1223-316931

          http://www-sdl.ug.eds.com/ug_assemblies.html

Builtin append() and prepend() to PATH, CDPATH, etc.

[Fung-Chai Lim]

Hi,

I have not check the documentation to see if this is already in zsh.
I have not even compile and install the latest version; zsh is evolving
too fast for me to catch up.

Anyway, I am referring to the shell functions named append() and
prepend() that I'd found in Sun's /usr/openwin/bin/openwin.

They are used to add components to colon-separated variables like
PATH, CDPATH, MANPATH, etc, and will only add the component if the
component is not already in the variable.

I would like to see these 2 capabilities built-in into the shell
with some syntactic sugar on top.

For example, zsh has `pushd_ignore_dups'.  I think it would be easy
to add a builtin function, say, `uniq-var' that, like `export', accept
a variable list of arguments.  An example is
	$ uniq-var PATH CDPATH MANPATH
After evaluating this statement, modifying any of the 3 variables
would ensure no duplication:
	$ set path = (/usr/local/bin $path /usr/bin)
would prepend /usr/local/bin and append /usr/bin into PATH only if
they are not already in it.

Having such features would help with the current lengthy and redundant
output with "echo $PATH".

Having them builtin would speed up the evaluation of .zprofile.

Thanks in advance.

Regards,
fclim.

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Zoltan Hidvegi]

> For example, zsh has `pushd_ignore_dups'.  I think it would be easy
> to add a builtin function, say, `uniq-var' that, like `export', accept
> a variable list of arguments.  An example is
> 	$ uniq-var PATH CDPATH MANPATH

>From zsh-2.6-beta17 you can use typeset -U path cdpath manpath which does
exactly what you want.

> After evaluating this statement, modifying any of the 3 variables
> would ensure no duplication:
> 	$ set path = (/usr/local/bin $path /usr/bin)

This is the csh syntax.  In zsh you have to write

$ path=(/usr/local/bin $path /usr/bin)

Zoltan

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Bart Schaefer]

On Jun 4, 11:27am, Zefram wrote:
} Subject: Re: A peep into the future.
}
} >6. Hierarchical option settings.  E.g. unsetopt zle automatically
} >   unsetopts's the options dependant on its being set.  It itself also
} >   is an option.  It's there to make understanding the plethora of
} >   options easier for new users.
} 
} That's rather pointless.  If an option has no effect due to the state
} of another option, I'd rather it stayed the way it is, rather than get
} unset.

Exactly.  I don't want to have to reset half a dozen options to get back
to where I started after unsetting only one option!  (That doesn't mean
it wouldn't be a good idea to rearrange the to make option explanations
heirarchical.)

An alternative, however, would be to have options with three states: set,
unset, and disabled.  Options would become disabled if any other option,
upon which they depend, becomes unset or disabled; disabled options go
back to set if all the options on which they depend become set.

Then the question becomes, what happens if you set an unset option, and
it depends on some other unset or disabled option?  Does the newly set
option simply become disabled, or does it force all options upon which
it depends to also become set?

} >zsh 4.0:
} >
} >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
} >    and menu capabilities on text only terminals.  
} 
} It has colour capabilities to some extent: you can put colour sequences
} into prompts quite easily.  I don't see any advantage in having zsh use
} windows in any way.

I tend to agree.  At this point you've rewritten emacs.  Just *get* emacs,
and run zsh in a shell buffer.

} >2.  mount/umount is a shell builtin which simulates working with
} >    virtual filesystems e.g. ftpfs, tarfs, libfs, memfs.
}
} Virtual filesystems, of
} course, should be done in the kernel (for example, userfs under
} Linux).

I agree with Zefram.

} I'd like to see quite a lot of basic administration commands added as
} optional builtins, to make a sysadmin's shell.  There would be a
} configuration option to strip out ZLE, and to add builtins for cp, mv,
} rm, link, sln and so on.

This, on the other hand, has possibilities.

} >3.  zsh can now byte-code its scripts.
} 
} I never tried this, but I think it used to be possible, if you just put
} the token control characters into a script.

Not only does this not save you much, as Zoltan pointed out, but it's
problematic in the face of SH_WORD_SPLIT.  If a single variable reference
can explode into multiple tokens, the script ends up having to be reparsed
and interpreted anyway, and you've actually made parsing MORE expensive.

(Of course, zsh already does a little of this with shell functions.)

} >4.  zsh now supports dynamic files.  If a file has a specific magic no,
} >    it can be handled like a normal file of the *output* of that file.

What the heck does that even MEAN?

} >zsh 10.0:
} >
} >OS_TYPE is a shell variables which can be changed.  zsh simulates the
} >given OS.  Everything is a shell builtin.

(Run screaming in terror)

On Jun 4, 10:37pm, Zoltan Hidvegi wrote:
} Subject: Re: A peep into the future.
}
} I have already did some private hacks to add loadable module support to
} zsh.  This is quite trivial on elf systems (I did this on Linux) but I do
} not know how can it be ported to non-elf systems.

It probably can't be ported to every system on which zsh runs.  I think
with some carefully selected primitives, you could construct scripts to
handle nearly everything that would be useful as a loadable module.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Clinton Bunch]

On Jun 5,  2:25pm, Bart Schaefer wrote:

>
> } >zsh 4.0:
> } >
> } >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
> } >    and menu capabilities on text only terminals.
> }
> } It has colour capabilities to some extent: you can put colour sequences
> } into prompts quite easily.  I don't see any advantage in having zsh use
> } windows in any way.
>
> I tend to agree.  At this point you've rewritten emacs.  Just *get* emacs,
> and run zsh in a shell buffer.
>

	Wrong.  At this point, you've written a shell whose scripts can use
GUI objects to interact with end users.  If emacs can do that, it shouldn't.

(You know, if the FSF would just add device drivers to it, we could quit
calling
emacs an editor and call it an OS which seems to be what most of its users
want it to be.)

And, as importantly (at least to some of us), you've written a replacement for
one of the proprietary componets of CDE.

	My $.02 worth,
	Clinton

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Bart Schaefer]

On Jun 10,  2:22pm, Clinton Bunch wrote:
} Subject: Re: Builtin append() and prepend() to PATH, CDPATH, etc.
}
} On Jun 5,  2:25pm, Bart Schaefer wrote:
} 
} >
} > } >zsh 4.0:
} > } >
} > } >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
} > } >    and menu capabilities on text only terminals.
} > }
} > } It has colour capabilities to some extent: you can put colour sequences
} > } into prompts quite easily.  I don't see any advantage in having zsh use
} > } windows in any way.
} >
} > I tend to agree.  At this point you've rewritten emacs.  Just *get* emacs,
} > and run zsh in a shell buffer.
} 
} 	Wrong.  At this point, you've written a shell whose scripts can use
} GUI objects to interact with end users.

Exactly what kind of "GUI objects" are we talking about here?  The only
thing the phrase "windowing zsh" conjures in my mind is something that
looks like a bunch of xterms each running a shell.

It sounds to me like you want wish (the tcl/tk shell).  I don't think
it's appropriate to bloat zsh with a GUI-object-description language.
You can launch wish GUIs from $(...) if you need to feed the results
back into zsh (or any other shell).

} If emacs can do that, it shouldn't.

GNU emacs has an X11 GUI, which can have either Xaw or Motif appearance.
Within that UI, you can have multiple windows (emacs calls them "frames")
each of which shows one or more buffers and has a menu bar that changes
depending on what buffer has focus.  So any GUI object that can be
represented as a pulldown menu or as a prompt with optional text input,
you can construct with elisp.

Whether it "should" do that isn't a topic for this mailing list.

} And, as importantly (at least to some of us), you've written a replacement
} for one of the proprietary components of CDE.

??  Are you sure it's proprietary?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Hrvoje Niksic]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> } And, as importantly (at least to some of us), you've written a replacement
> } for one of the proprietary components of CDE.
> 
> ??  Are you sure it's proprietary?

Yes, it's windowing ksh.

-- 
hniksic@srce.hr              |  Student of electrical engineering
hniksic@fly.cc.fer.hr        |  University of Zagreb, Croatia
------------------------------------------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Builtin append() and prepend() to PATH, CDPATH, etc.

[Clinton Bunch]

On Jun 10, 12:54pm, Bart Schaefer wrote:
> Subject: Re: Builtin append() and prepend() to PATH, CDPATH, etc.
> On Jun 10,  2:22pm, Clinton Bunch wrote:
> } Subject: Re: Builtin append() and prepend() to PATH, CDPATH, etc.
> }
> } On Jun 5,  2:25pm, Bart Schaefer wrote:
> }
> } >
> } > } >zsh 4.0:
> } > } >
> } > } >1.  wzsh (windowing zsh) is now available.  Also, zsh now has colour
> } > } >    and menu capabilities on text only terminals.
> } > }
> } > } It has colour capabilities to some extent: you can put colour sequences
> } > } into prompts quite easily.  I don't see any advantage in having zsh use
> } > } windows in any way.
> } >
> } > I tend to agree.  At this point you've rewritten emacs.  Just *get*
emacs,
> } > and run zsh in a shell buffer.
> }
> } 	Wrong.  At this point, you've written a shell whose scripts can use
> } GUI objects to interact with end users.
>
> Exactly what kind of "GUI objects" are we talking about here?  The only
> thing the phrase "windowing zsh" conjures in my mind is something that
> looks like a bunch of xterms each running a shell.
	see below.
>
> It sounds to me like you want wish (the tcl/tk shell).  I don't think
> it's appropriate to bloat zsh with a GUI-object-description language.
> You can launch wish GUIs from $(...) if you need to feed the results
> back into zsh (or any other shell).
>
	First, Tcl has got to have the ugliest syntax of any language known to
man.  Second, Tk is a very poor rip-off of Motif and almost as ugly as Athena.
What I'm talking about is something that actually allows X/Xt/Motif calls from
within the shell (a la dtksh).  This wouldn't be zsh but a parallel and
derivate
work ( wzsh ).  This, of course, would best be accomplished through a dynamic
(or even not so dynamic) extension interface for adding builtins.  These
changes would be similar to the ones made for ksh93 in support of dtksh.
>
> ??  Are you sure it's proprietary?
	Yes,  dtksh is based off Korn Shell 93 and source code is not freely
available AFAIK.
>
> --
> Bart Schaefer                             Brass Lantern Enterprises
> http://www.well.com/user/barts            http://www.nbn.com/people/lantern
>
> New male in /home/schaefer:
> >N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"
>-- End of excerpt from Bart Schaefer

BUG: useheap in doexpandhist()

[Bart Schaefer]

I just got (in beta21):

	BUG: useheap in doexpandhist()

in the middle of completing the name of a zsh function.  It happened only
once, and I can't seem to make it happen again.

Possibly related --

In beta17 on IRIX, I can reliably crash zsh with the following sequence:

zsh% bindkey '\eq' push-line-or-edit
zsh% echo foo 'bar
> baz<ESC-q>
zsh% echo foo 'bar
baz<DEL><DEL><DEL><DEL>
zsh% echo foo 'bar'<RET>
foo bar
zsh% SA<TAB>
segmentation fault

(where SA can be any completion that will fail; I happened to be trying to
complete SAVEHIST, for reasons too obscure to go into).

I have automenu set, in case that matters; compctls are the defaults.

However, I can't crash beta21 on linux with that sequence.  I haven't had a
chance to compile beta21 on IRIX as yet.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: BUG: useheap in doexpandhist()

[Barton E. Schaefer]

On Jun 22,  1:12pm, Bart Schaefer wrote:
} Subject: BUG: useheap in doexpandhist()
}
} I just got (in beta21):
} 
} 	BUG: useheap in doexpandhist()
} 
} in the middle of completing the name of a zsh function.  It happened only
} once, and I can't seem to make it happen again.

I've gotten it several more times now, always in completion but not always
in the name of a function.  I can't yet isolate any preceding usages that
trigger it.  It may have something to do with that TMOUT=10 TRAPALRM that
I posted a few days ago.


-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                   Division of NetManage Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: BUG: useheap in doexpandhist()

[Zoltan Hidvegi]

> On Jun 22,  1:12pm, Bart Schaefer wrote:
> } Subject: BUG: useheap in doexpandhist()
> }
> } I just got (in beta21):
> } 
> } 	BUG: useheap in doexpandhist()
> } 
> } in the middle of completing the name of a zsh function.  It happened only
> } once, and I can't seem to make it happen again.
> 
> I've gotten it several more times now, always in completion but not always
> in the name of a function.  I can't yet isolate any preceding usages that
> trigger it.  It may have something to do with that TMOUT=10 TRAPALRM that
> I posted a few days ago.

Unfortunately there are some zsh functions which are not reentrant which
cause problems when a signal comes.  There are two solutions.  The best
would be make evry function which might be used when executing a trap
(which is practically all functions) reentrant.  This whould be a big and
difficult change.  The other solution is to queue signals in most cases and
process them in some well-defined cases.  The problem with this approach is
clearly that in some cases the shell will not respond immediately to the
signal.

But for your problem the patch below may help.  It does not solve the
problem with signals unfortunately (just try
trap 'echo interrupt' INT ; while true ; do ; done and hit ^C a few times
quickly and BUG's will come).

About the patch below: Peter suggested a stack for permalloc()/lastalloc().
This is not a bad idea but maybe it's not the best.  In most places of the
code either only permanent or only heap allocation is valid.  Also almost
always ncalloc, alloc, dupstrig are used to get space from the heap.  The
most important exeptions are the various dup*** routines and the routines
for creating new structures.  Perhaps a better solution is to use
halloc()/hcalloc() where the heap should be used and define a new function
as a replacement for dupstring() which always uses the heap.  An other
solution is using heapalloc()/permalloc() in all cases where the state of
the allocation is unknown or know to be wrong.

And does anyone know the historical reason why ncalloc refers to
halloc/zalloc and alloc refers to hcalloc/zcalloc?  This is exactly the
opposite of the logical behaviour.

Zoltan

*** Src/signals.c	1996/05/02 23:41:23	2.3
--- Src/signals.c	1996/06/24 15:26:36
***************
*** 684,689 ****
--- 684,690 ----
      LinkList args;
      char *name, num[4];
      int sav = sigtrapped[sig];
+     int luh;
   
      /* if signal is being ignored or the trap function		      *
       * is NULL, then return					      *
***************
*** 699,704 ****
--- 700,706 ----
      sigtrapped[sig] = 2;
  
      lexsave();
+     luh = useheap;
      permalloc();
      args = newlinklist();
      name = (char *) zalloc(5 + strlen(sigs[sig]));
***************
*** 707,713 ****
--- 709,718 ----
      sprintf(num, "%d", sig);
      addlinknode(args, num);
      trapreturn = -1;
+     heapalloc();
      doshfunc(sigfuncs[sig], args, 0, 1);
+     if (!luh)
+ 	permalloc();
      lexrestore();
      freelinklist(args, (FreeFunc) NULL);
      zsfree(name);
*** Src/exec.c	1996/06/21 10:12:47	2.43
--- Src/exec.c	1996/06/24 15:22:55
***************
*** 2364,2369 ****
--- 2364,2370 ----
      List xexitfn;
      char saveopts[OPT_SIZE];
  
+     MUSTUSEHEAP("doshfunc");
      pushheap();
      oldlastval = lastval;
      xexittr = sigtrapped[SIGEXIT];

Re: BUG: useheap in doexpandhist()

[Barton E. Schaefer]

On Jun 24,  9:11pm, Zoltan Hidvegi wrote:
} Subject: Re: BUG: useheap in doexpandhist()
}
} > } 	BUG: useheap in doexpandhist()
} > 
} > I've gotten it several more times now, always in completion but not always
} > in the name of a function.  I can't yet isolate any preceding usages that
} > trigger it.  It may have something to do with that TMOUT=10 TRAPALRM that
} > I posted a few days ago.

Of course I was thinking 10 *minutes* -- that should say TMOUT=600.

} Unfortunately there are some zsh functions which are not reentrant which
} cause problems when a signal comes.

In the case I suspect, though, all zsh should have been doing when the
signal arrived was sitting idle at the PS1 prompt.  The signal is not
arriving during the completion, as far as I can tell; rather, the heap
allocation has already been left in a confused state, and trying the
completion just happens to be what makes zsh notice the bad state.

Is that what your patch was intended to fix?

} About the patch below: Peter suggested a stack for permalloc()/lastalloc().
} This is not a bad idea but maybe it's not the best.  In most places of the
} code either only permanent or only heap allocation is valid.  Also almost
} always ncalloc, alloc, dupstrig are used to get space from the heap.  The
} most important exeptions are the various dup*** routines and the routines
} for creating new structures.  Perhaps a better solution is to use
} halloc()/hcalloc() where the heap should be used and define a new function
} as a replacement for dupstring() which always uses the heap.  An other
} solution is using heapalloc()/permalloc() in all cases where the state of
} the allocation is unknown or know to be wrong.

Yes, the right thing to do is to eliminate the global pointers to alloc
functions, and call the desired ones directly.  The pointers were used
in the first place so some utility routines (like dupstring) could be
written once and then be used regardless of whether heap or permanent
allocation was desired.  The zsh heap, in turn, is just a crude garbage
collection mechanism, as I'm sure you're aware.

Unfortunately, at this point there are probably so many routines that
depend on having this memory management magically handled for them, that
it'd be as big a change to fix that as to make everything reentrant.

} And does anyone know the historical reason why ncalloc refers to
} halloc/zalloc and alloc refers to hcalloc/zcalloc?  This is exactly the
} opposite of the logical behaviour.

It's been that way since before I started fooling with zsh, so I'm
willing to bet the only person who knows is Paul F.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                   Division of NetManage Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: BUG: useheap in doexpandhist()

[Zoltan Hidvegi]

> } Unfortunately there are some zsh functions which are not reentrant which
> } cause problems when a signal comes.
> 
> In the case I suspect, though, all zsh should have been doing when the
> signal arrived was sitting idle at the PS1 prompt.  The signal is not
> arriving during the completion, as far as I can tell; rather, the heap
> allocation has already been left in a confused state, and trying the
> completion just happens to be what makes zsh notice the bad state.
> 
> Is that what your patch was intended to fix?

Yes.  The signal trap can leave the allocation in some undefined state.  My
patch just makes sure that after executiong the trap the original
allocation state is restored.

> Yes, the right thing to do is to eliminate the global pointers to alloc
> functions, and call the desired ones directly.  The pointers were used
> in the first place so some utility routines (like dupstring) could be
> written once and then be used regardless of whether heap or permanent
> allocation was desired.  The zsh heap, in turn, is just a crude garbage
> collection mechanism, as I'm sure you're aware.
> 
> Unfortunately, at this point there are probably so many routines that
> depend on having this memory management magically handled for them, that
> it'd be as big a change to fix that as to make everything reentrant.

I think that the heap used in zsh is very useful.  It is convinient, it
certainly guarantees that there is no memory leak if the heap is used and
it is efficient since instead of calling malloc()/free() frequently we call
these only a few times.  This can make things faster since malloc()/free()
can be very expensive if sbrk()/brk() is called.  Once I played with the
Linux ypserv and I found that it spends most of its time in sbrk/brk in
some situations.  Then I linked it with the malloc from zsh with the brk
staff removed and it become much faster than before.

Zoltan

Re: BUG: useheap in doexpandhist()

[Barton E. Schaefer]

On Jun 25,  2:01am, Zoltan Hidvegi wrote:
} Subject: Re: BUG: useheap in doexpandhist()
}
} The signal trap can leave the allocation in some undefined state.  My
} patch just makes sure that after executiong the trap the original
} allocation state is restored.

Hmm.  I understand the part about restoring the original state, but how
can the trap leave the allocation in an *undefined* state?  Seems to me
that if the trap doesn't always *leave* the allocation in the same state
(heap, it appears) then there's something more serious wrong.  It's the
state when you *start* handling the signal that is unknown (to the trap).

That means restoring state is the right thing to do regardless of other
reentrancy issues; but maybe it's doshfunc() that should be saving and
restoring the state, so that it's consistent everywhere doshfunc() is
called?

} I think that the heap used in zsh is very useful.  It is convinient, it
} certainly guarantees that there is no memory leak if the heap is used and
} it is efficient since instead of calling malloc()/free() frequently we call
} these only a few times.

Yes, the heap certainly guarantees that zsh's performance will be just
about the same no matter how well or poorly the underlying malloc works.
It also guarantees that if you accidentally allocate something on the
zsh heap that should have been on the "permanent" heap, zsh eventually
will dump core; and it almost guarantees that programmers will be sloppy
about freeing memory, because they assume the heap prevents leakage.

I apologize to members of the Paul Falstad Fan Club, but I think zsh
would have been a lot more reliable a whole lot sooner if he had never
used that trick.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                   Division of NetManage Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: Use of qualifiers without glob pattern?

[Bart Schaefer]

On Jun 26,  1:02pm, Zoltan Hidvegi wrote:
} Subject: Re: Use of qualifiers without glob pattern?
}
} > the problem is, $i(:r) gives the same as $i!!!
} 
} Yes, it stopped working in beta20.  Here is the fix.

Gosh, guys, this is pretty basic stuff to have suddenly stop working.
This is why I get nervous every time a big patch like the metafication
stuff gets put in.

Maybe it's time to put together some kind of regression-test script
that can be run before each new release, to at least have some kind of
confidence that new bugs haven't been introduced?

It's probably impossible to test zle and completion from a script, which
is too bad because of the number of completion bugs that showed up in
the last few betas.  (Hopefully those have all been caught by now, but
who knows what's lurking in the esoterica ...)  However, it should at
least be possible to check globbing and substitutions and redirection,
aliasing and functions and so on.

Speaking of big patches and breaking things that have been working for
a long time, it's now been more than a year since RC said he was going
to stop accepting major changes and stabilize zsh to get an official
(not beta) release put out.  No indictment of anyone intended -- I know
zsh takes a back seat to the real world, which is among the reasons why
RC handed the archive over to Zoltan; and some of the recent changes
have fixed some really annoying long-standing bugs -- but do we have
any idea when a true release can finally happen?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Regression tests

[Bas V. de Bakker]

Bart Schaefer <schaefer@candle.brasslantern.com> writes:

> Maybe it's time to put together some kind of regression-test script
> that can be run before each new release, to at least have some kind
> of confidence that new bugs haven't been introduced?

Obviously, this would be very useful.  I've looked into it a bit when
managing zsh, but never came around to it.

> It's probably impossible to test zle and completion from a script,
> which is too bad because of the number of completion bugs that
> showed up in the last few betas.

Anyone looking into this should take a look at "dejagnu", to be found
at any GNU archive.  It uses "expect", which is able to test
interactive programs like zsh by running them on a pty and simulating
interactive input.

Bas.

Re: Use of qualifiers without glob pattern?

[Zoltan Hidvegi]

> On Jun 26,  1:02pm, Zoltan Hidvegi wrote:
> } Subject: Re: Use of qualifiers without glob pattern?
> }
> } > the problem is, $i(:r) gives the same as $i!!!
> } 
> } Yes, it stopped working in beta20.  Here is the fix.
> 
> Gosh, guys, this is pretty basic stuff to have suddenly stop working.
> This is why I get nervous every time a big patch like the metafication
> stuff gets put in.

The (:...) modifiers stopped working only if the argument had no wildcards
so *(:r) always worked.  And foo.bar(:r) works only since about a year.

That particular bug is related to the execcmd reorganization to allow
things like foo=exec ; $foo bar work which is probably more basic than the
modifiers.

> Speaking of big patches and breaking things that have been working for
> a long time, it's now been more than a year since RC said he was going
> to stop accepting major changes and stabilize zsh to get an official
> (not beta) release put out.  No indictment of anyone intended -- I know
> zsh takes a back seat to the real world, which is among the reasons why
> RC handed the archive over to Zoltan; and some of the recent changes
> have fixed some really annoying long-standing bugs -- but do we have
> any idea when a true release can finally happen?

In beta21 there was no really serious problems.  I'm going to release
beta22 within a couple of days.  It will contain a partial solution of the
signal reentrancy problem by saving and resoring some variables which fixes
the most serious problems.  If no problems reported within a few days
of that release I'll announce this beta in some newsgroups as a 3.0
pre-release.  Maybe beta22 is not a good name for that.  It may be better
to call it to zsh-2.99.0 as the next stable release will be zsh-3.0.0.

I know that there were many changes since beta16, more than I wanted.  RC
announced a feature freeze a year ago.  New features were introduced in
beta17 but these new features were already well tested as these were
present in my non-official releases for more than a year.  Sine beta17
there were many conceptual changes to fix long-standing bugs and to improve
sh compatibility.  The biggest change was making zsh 8-bit clean which was
unavoidable.  I think that beta21 is much more stable than beta16.  /bin/sh
can now be safely linked to zsh-2.6-beta21.  If invoked as sh/ksh zsh
almost conforms to POSIX 1003.2.

Also several debug tests were added and these are enabled by default.
These debug messages might give a feeling that recent betas are more buggy
than older ones but most of these bugs were always there.  In the final
stable release debug checks will be disabled by default but in beta
releases I'd like zsh to complain loudly if it thinks that there is a bug.

Zoltan

Re: Use of qualifiers without glob pattern?

[Bart Schaefer]

On Jun 26,  4:52pm, Zoltan Hidvegi wrote:
} Subject: Re: Use of qualifiers without glob pattern?
}
} > } > the problem is, $i(:r) gives the same as $i!!!
} > 
} > Gosh, guys, this is pretty basic stuff to have suddenly stop working.
} 
} The (:...) modifiers stopped working only if the argument had no wildcards
} so *(:r) always worked.  And foo.bar(:r) works only since about a year.

Ah.

zagzig<1> i=foo.bar
zagzig<2> echo $i:r $i(:r)
foo foo.bar

Hmm.

zagzig<3> echo ${i(:r)}
zsh: closing brace expected

Oh, well.

} > This is why I get nervous every time a big patch like the metafication
} > stuff gets put in.
} 
} That particular bug is related to the execcmd reorganization

Right, I was using metafication for example only.

} to allow
} things like foo=exec ; $foo bar work which is probably more basic than
} the modifiers.

I agree (now) that in this case the problem wasn't serious; I thought
the parameter-substitution modifiers were broken as well.

} In beta21 there was no really serious problems.  I'm going to release
} beta22 within a couple of days.  It will contain a partial solution of the
} signal reentrancy problem by saving and resoring some variables which fixes
} the most serious problems.

Sounds worthwhile.

} If no problems reported within a few days
} of that release I'll announce this beta in some newsgroups as a 3.0
} pre-release.

Has this one, reported a few days ago by someone else, been fixed?

zagzig<9> echo "foo\
> $bar"
foo$bar

That seems like an important thing to get right.

} Maybe beta22 is not a good name for that.  It may be better
} to call it to zsh-2.99.0 as the next stable release will be zsh-3.0.0.

Why not 3.0-prerelease, or something like that?

} I know that there were many changes since beta16, more than I wanted.  RC
} announced a feature freeze a year ago.  New features were introduced in
} beta17 but these new features were already well tested as these were
} present in my non-official releases for more than a year.  Sine beta17
} there were many conceptual changes to fix long-standing bugs and to improve
} sh compatibility.

Yes; let me reiterate that I'm happy with all of this, I was just
wondering about how much longer it was going to continue.

} Also several debug tests were added and these are enabled by default.
} These debug messages might give a feeling that recent betas are more buggy
} than older ones but most of these bugs were always there.

I understand about that.  I based my impression on the number of bug
reports that crossed the list following release of beta20.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Use of qualifiers without glob pattern?

[Zoltan Hidvegi]

> } The (:...) modifiers stopped working only if the argument had no wildcards
> } so *(:r) always worked.  And foo.bar(:r) works only since about a year.
> 
> Ah.
> 
> zagzig<1> i=foo.bar
> zagzig<2> echo $i:r $i(:r)
> foo foo.bar

$i:r and $i(:r) are different.  The former always works when $i is expanded
while the later is special form of filename generation (globbing).

> zagzig<3> echo ${i(:r)}
> zsh: closing brace expected

Yes, because (:r) is a glob modifier which only works if the word ends in
an unquoted closing parenthesis and there are no wildcards or embeded
parenthesis in this trailing parenthesized part of the word.

> Has this one, reported a few days ago by someone else, been fixed?
> 
> zagzig<9> echo "foo\
> > $bar"
> foo$bar
> 
> That seems like an important thing to get right.

Yes, I already fixed that but I did not send the patch.  The patch below
fixes that.

> } Maybe beta22 is not a good name for that.  It may be better
> } to call it to zsh-2.99.0 as the next stable release will be zsh-3.0.0.
> 
> Why not 3.0-prerelease, or something like that?

I think it is better if there are only numbers in the version since it is
easier to parse in scripts.  Also 3.0-prerelease is too long. 3.0-pre1 may
be better.  I used to have version specific code in my startup files but
removed these since it became too complicated to handle things like
2.5.03, 2.6-beta9, 2.6-beta21, 2.6-beta15-hzoli14, 2.6-beta??-test??
(fortunately I never tried any version older than 2.5.0 so that case can be
omitted).

But fortunately 3.0-something lexicographically comes before 3.0.something
so it is easy to handle this case which means that the next release may be
called 3.0-pre1.

Zoltan


rcsdiff -qc -kk -r2.26 -r2.27 Src/lex.c
*** Src/lex.c
--- Src/lex.c	1996/06/25 23:15:04	2.27
***************
*** 1016,1022 ****
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
  		    c == '\"' || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
! 		c = hgetc();
  	    break;
  	case '\n':
  	    err = !sub && isset(CSHJUNKIEQUOTES) && endchar == '"';
--- 1016,1022 ----
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
  		    c == '\"' || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
! 		continue;
  	    break;
  	case '\n':
  	    err = !sub && isset(CSHJUNKIEQUOTES) && endchar == '"';

Re: Bug in case stmt with '('

[Zoltan Hidvegi]

> >Unfortunately there is still an incompatibility in case:
> >
> >case foo in
> >( f* | b* ) echo yes
> >esac
> >
> >should print yes but in zsh it works as
> >
> >case foo in
> >\ f*\ |\ b*\ ) echo yes;;
> >esac
> 
> I was wondering whether that would be the case.  It's a serious problem.
> 
> >To fix this would be really difficult I think.
> 
> It could be easily fixed by modifying glob semantics such that unquoted
> whitespace embedded in a pattern is ignored.  I doubt that any real
> code relies on the current behaviour, which is in any case
> undocumented.

It is used in ${...%...} substitutions where a space stands for itself.
And it is not even a zsh feature.  So unquoted whitespace should not always
be ignored.  Ignoring unquoted whitespace before | and ) and after ( and |
seems to be a better solution but it is more difficult to implement.
Consistency is desirable so patterns should behave similarily in case
statements, ${...%...} substitutions (double quoted or not), in argumenents
to builtins after -m etc.

At a few places the code assumes that the lexer just tokenizes the input
but does not actually modfy it so omitting these spaces in the lexer is not
the best solution.

The best would be to handle it in glob.c but here it is a problem how can
we distinguish ( foo\ | bar ) from ( foo | bar ).  It would require a new
token for a null-space (the word `token' is amiguous in zsh, it can be
either a token returned by gettok or a character token for a character in
ztokens, here I use the second meaning).  A token for null-TAB may also be
necessary here.  The simplest solution is to convert every unquoted space
and TAB which is inside a globbing paren to a null-space and null-tab token
and later in glob.c a null-space or null-tab is either treated as space/tab
or discarded if it is adjacent to | or comes after a `(' of before a `)'
(or it may be better to disard these after `)' and before `(' as well).

This seems to be a quite simple solution.

On the other topic of empty patterns: it is true that POSIX does not allow
that.  Even previous zsh versions had problems with empty patterns in case
statement so it probably does not cause any problems if we do not allow
that in case statement.  That would simplyfy parsing since it means that
after a BAR a STRING token must come in a case pattern.  But in other
places empty patterns are usefull.  I ofter use (...|) for an optional
match and this should not be disallowed.

Zoltan

PS.  I'm now moving this quite technical discussion to zsh-workers.

Re: Bug in case stmt with '('

[Bart Schaefer]

On Jul 23,  4:08pm, Zoltan Hidvegi wrote:
} Subject: Re: Bug in case stmt with '('
}
} The best would be to handle it in glob.c but here it is a problem how can
} we distinguish ( foo\ | bar ) from ( foo | bar ).

The `if (incasepat && ...)' patch that I sent handles this correctly.
The only drawback I've found so far to my patch is that if you *don't*
use the POSIX balanced-parens syntax for "case", then parenthesized
patterns can't have *meaningful* spaces in them.

I don't think this is a significant difficulty, since "case" already
has the `|' syntax so there's not much reason to use glob-grouping
parens in "case" patterns in the first place.

} The simplest solution is to convert every unquoted space
} and TAB which is inside a globbing paren to a null-space and null-tab token
} and later in glob.c a null-space or null-tab is either treated as space/tab
} or discarded if it is adjacent to | or comes after a `(' of before a `)'
} (or it may be better to disard these after `)' and before `(' as well).
} 
} This seems to be a quite simple solution.

Maybe, but not simpler than mine, and it's solving a problem that I don't
think we ought to be solving -- we don't need to be able to ignore spaces
in generalized glob patterns, only in "case" statements.  I don't like the
suggestion to do it everywhere.


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Bug in case stmt with '('

[Morris M. Siegel]

On Jul 23,  9:25am, Bart Schaefer wrote:
> Subject: Re: Bug in case stmt with '('
> On Jul 23,  4:08pm, Zoltan Hidvegi wrote:
> } Subject: Re: Bug in case stmt with '('
> }
> } The best would be to handle it in glob.c but here it is a problem how can
> } we distinguish ( foo\ | bar ) from ( foo | bar ).
>
> The `if (incasepat && ...)' patch that I sent handles this correctly.
> The only drawback I've found so far to my patch is that if you *don't*
> use the POSIX balanced-parens syntax for "case", then parenthesized
> patterns can't have *meaningful* spaces in them.

Do you really think it user-friendly for the semantics of the case-prefix
to depend on whether the optional leading '(' is present or not?

> I don't think this is a significant difficulty, since "case" already
> has the `|' syntax so there's not much reason to use glob-grouping
> parens in "case" patterns in the first place.

It seems to me, and I alluded to this in a previous posting, that it's
most elegant for a whole case-prefix such as
	( a | b | c )
to be in fact treated simply as a single zsh glob pattern (again, provided
that zsh options allow '(' to be a glob metacharacter as it usually is).
That's why it's useful to ignore trivial blanks after '(', around '|',
before ')', and maybe elsewhere, as Zoltan writes.  (Actually, it might
perhaps be best for all blanks inside parentheses [unless quoted or
backslashed] to be ignored unless their omission would cause distinct
tokens to be erroneously fused.  E.g., '( a b | ^ d .c )' would be
equivalent to '(a b|^d .c)'.  However, '~' might pose problems, since it
serves both as a directory symbol when unary and as a pattern complementation
operator when binary.  At any rate, the need for compatibility with standard
'case' syntax is satisfied if blanks are ignored minimally, as Zoltan
suggests.)

In order for me to participate more intelligently in this discussion,
it would be helpful for me to know where STRINGs occur in the zsh grammar.
Where do they in fact occur besides in glob patterns?
Is there some document containing the formal grammar of zsh?

> } The simplest solution is to convert every unquoted space
> } and TAB which is inside a globbing paren to a null-space and null-tab token
> } and later in glob.c a null-space or null-tab is either treated as space/tab
> } or discarded if it is adjacent to | or comes after a `(' of before a `)'
> } (or it may be better to disard these after `)' and before `(' as well).
> }
> } This seems to be a quite simple solution.
>
> Maybe, but not simpler than mine, and it's solving a problem that I don't
> think we ought to be solving -- we don't need to be able to ignore spaces
> in generalized glob patterns, only in "case" statements.  I don't like the
> suggestion to do it everywhere.

On the contrary, zsh is improved by having glob patterns have
a uniform meaning throughout the grammar.

-- Morrie Siegel

Re: Bug in case stmt with '('

[Bart Schaefer]

On Jul 23,  4:01pm, Morris M. Siegel wrote:
} Subject: Re: Bug in case stmt with '('
}
} > } The best would be to handle it in glob.c but here it is a problem how can
} > } we distinguish ( foo\ | bar ) from ( foo | bar ).
} >
} > The `if (incasepat && ...)' patch that I sent handles this correctly.
} > The only drawback I've found so far to my patch is that if you *don't*
} > use the POSIX balanced-parens syntax for "case", then parenthesized
} > patterns can't have *meaningful* spaces in them.
} 
} Do you really think it user-friendly for the semantics of the case-prefix
} to depend on whether the optional leading '(' is present or not?

Given the choice of:

1.  The "current" behavior, i.e. spaces ARE significant only when the
    optional leading paren is there;
2.  The POSIX behavior, i.e. spaces are not significant in case patterns;
3.  Spaces are never significant in glob patterns anywhere.

I'll take (2) before I'll take (3).  My solution is equivalent to (2),
because it makes the spaces insignificant whether or not the opening
paren is there.

The "drawback" of my solution is that it makes PARENTHESES significant
only when the leading paren is there.  I don't have a problem with that
because other shells don't permit parentheses [other than the half-
optional outermost set] at all; thus the optional leading paren is
simply also introducing *additional* optional syntax.

} It seems to me, and I alluded to this in a previous posting, that it's
} most elegant for a whole case-prefix such as
} 	( a | b | c )
} to be in fact treated simply as a single zsh glob pattern (again, provided
} that zsh options allow '(' to be a glob metacharacter as it usually is).

I can't find any case where zsh doesn't permit '(' to be a glob metachar.
SH_GLOB relates to parameter and command substitutions, not filenames.
I have no objection to treating the whole case prefix as a single pattern;
as I've said, this is how it already works.

} That's why it's useful to ignore trivial blanks after '(', around '|',
} before ')', and maybe elsewhere, as Zoltan writes.

Except that blanks inside parenthesized glob patterns ARE NEVER TRIVIAL,
by the CURRENT definition of parenthesized glob patters.  I object to
changing this behavior.

} (Actually, it might
} perhaps be best for all blanks inside parentheses [unless quoted or
} backslashed] to be ignored unless their omission would cause distinct
} tokens to be erroneously fused.  E.g., '( a b | ^ d .c )' would be
} equivalent to '(a b|^d .c)'.  [...])

This is a big reason why I don't like the idea of stripping the spaces
everywhere.  Do YOU really think it user-friendly to have a set of
magic tokens around which spaces are or are not stripped?

} Is there some document containing the formal grammar of zsh?

Only comments in parse.c, unfortunately, and they aren't complete.

} On the contrary, zsh is improved by having glob patterns have
} a uniform meaning throughout the grammar.

I agree with the sentiment, but not with the realization.  IMHO it is
the insignificant spaces in case patterns that should be disallowed,
not spaces in glob patterns that should become insignificant.  POSIX
forbids us from making the better change; I don't believe we should
compound the error by making a worse one.  Two wrongs don't make a
right, and being consistently wrong is not better than being right
whenever possible.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Bug in case stmt with '('

[Zefram]

>I can't find any case where zsh doesn't permit '(' to be a glob metachar.
>SH_GLOB relates to parameter and command substitutions, not filenames.

Which is a failing, in my opinion.  The glob syntax should be as
consistent as possible (we seem to *need* some special handling in
`case`).  SH_GLOB having an effect only in certain places seems very
silly, and is rather confusing.  What's the rationale for it?

-zefram

Re: Bug in case stmt with '('

[Peter Stephenson]

schaefer@candle.brasslantern.com wrote:
> Given the choice of:
> 
> 1.  The "current" behavior, i.e. spaces ARE significant only when the
>     optional leading paren is there;
> 2.  The POSIX behavior, i.e. spaces are not significant in case patterns;
> 3.  Spaces are never significant in glob patterns anywhere.
> 
> I'll take (2) before I'll take (3).  My solution is equivalent to (2),
> because it makes the spaces insignificant whether or not the opening
> paren is there.

This seems to me the best solution.  It seems to create the minimal
disruption to existing zsh users and to would-be POSIX users.
Changing glob semantics more widely worries me --- even if done
logically.  Shells just aren't logical anyway.

> I can't find any case where zsh doesn't permit '(' to be a glob metachar.

Actually, there's one place we had to handle syntactically specially:

[[ ($foo = (bar|rab)) ]]

The first and matching `(' do grouping, then following the `=' zsh has
to be told to expect glob patterns.  I've never seen a problem with
this, though, and the upshot is that `(' does pattern matching when
you want it to.


On something which is related, I've never been quiet happy with this:

[ ( foo = bar ) ]

(note no globbing metacharacters inside the parentheses).  As test is
an ordinary builtin, it simply gets called with the single argument `(
foo = bar )' --- the parentheses are not stripped, which has non-zero
length, so the test is true.  In fact, parentheses here are
effectively not treated as glob metacharacters.

I felt rather guilty about this: some time ago I allowed spaces inside
parentheses because I couldn't think of a good reason not to, and
because it seemed to work better with glob modifiers --- things like
*(:s/foo/bar/) --- which appeared in the same patch, rather than from
any fundamental syntactical reason.  Before, the shell would have
reported a syntax error on the above test and the user would have
known to quote the parentheses.  This is what ksh88 does.  Perhaps it
should be subject to nomatch testing (which it isn't at the moment),
perhaps to stripping of the parentheses, too.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: Bug in case stmt with '('

[Bart Schaefer]

On Jul 24,  9:29am, Zefram wrote:
} Subject: Re: Bug in case stmt with '('
}
} >I can't find any case where zsh doesn't permit '(' to be a glob metachar.
} >SH_GLOB relates to parameter and command substitutions, not filenames.
} 
} Which is a failing, in my opinion.  The glob syntax should be as
} consistent as possible (we seem to *need* some special handling in
} `case`).  SH_GLOB having an effect only in certain places seems very
} silly, and is rather confusing.  What's the rationale for it?

I confess to not understanding what it even *means* to "[disable] the
special meaning of `(', `|', `)' and `<' for globbing the result of
parameter and command substitutions."  And what *are* the "some other
places where the shell accepts patterns" where this has effect?

One of them seems to be any command that takes a -m option as with
`typeset -m x\*' -- which seems bizarre to me; another is parameter
assignments with globsubst set.  Others?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Bug in case stmt with '('

[Zoltan Hidvegi]

> I confess to not understanding what it even *means* to "[disable] the
> special meaning of `(', `|', `)' and `<' for globbing the result of
> parameter and command substitutions."  And what *are* the "some other
> places where the shell accepts patterns" where this has effect?

In fact it affects every places where patterns can be used except explicit
glob patterns on the command line and case patterns.  This means -m builtin
options, completion glob patterns, ${...%...} substitutions, $foo[(r)...]
indexing etc.

It does not affect explicit glob patterns because in that case these
patterns result in syntax error in sh.  Also it would make the lexer a bit
more complicated since more special test sould be added and case patterns
should be treated specially.

Zoltan

Parameter expansion bug?

[Anthony Heading]

This does not print anything (at least with zsh 3.0.0) - shouldn't it print `-'?

% echo ${dqkjdkqdq:--}

Anthony

Re: Parameter expansion bug?

[Hrvoje Niksic]

Anthony Heading (aheading@jpmorgan.com) wrote:
> This does not print anything (at least with zsh 3.0.0) - shouldn't
> it print `-'?
> % echo ${dqkjdkqdq:--}

It prints a `-' in ksh and bash.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

Re: Parameter expansion bug?

[Zoltan Hidvegi]

Anthony Heading wrote:
> This does not print anything (at least with zsh 3.0.0) - shouldn't it print `-'?
> 
> % echo ${dqkjdkqdq:--}

In zsh echo - does not print anything and echo - -n prints -n.  How do you
print -n under bash?

Try

print -r - ${sdrgsdfdg:--}

Zoltan

Re: Parameter expansion bug?

[Bart Schaefer]

On Oct 31,  5:12pm, Zoltan Hidvegi wrote:
} Subject: Re: Parameter expansion bug?
}
} In zsh echo - does not print anything and echo - -n prints -n.  How do you
} print -n under bash?

As nearly as I can tell, `echo -e -n` is the only way.


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: Parameter expansion bug?

[Hrvoje Niksic]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Oct 31,  5:12pm, Zoltan Hidvegi wrote:
> } Subject: Re: Parameter expansion bug?
> }
> } In zsh echo - does not print anything and echo - -n prints -n.  How do you
> } print -n under bash?
> As nearly as I can tell, `echo -e -n` is the only way.

It doesn't work for me:

bash$ echo $BASH_VERSION 
1.14.6(1)
bash$ echo -e -n
bash$ 

`-e' in bash is used to enable interpretation of control sequences
like \n.

       echo [-neE] [arg ...]
              Output the args, separated by spaces.   The  return
              status is always 0.  If -n is specified, the trail-
              ing newline is suppressed.  If  the  -e  option  is
              given,  interpretation  of the following backslash-
              escaped characters is enabled.  The -E option  dis-
              ables  the  interpretation  of these escape charac-
              ters, even on systems where they are interpreted by
              default.
[... list of control sequences snipped ...]

As far as I can see, no way is described to print `-n'.

-- 
WWW:          World-Wide-Waste.  Waste management corporation, which
              handles the billions of tons of garbage generated by just
              about everybody these days.
You owe the Oracle a good book.  In HyperText, please.

Re: Parameter expansion bug?

[Zoltan Hidvegi]

Bart Schaefer wrote:
> On Oct 31,  5:12pm, Zoltan Hidvegi wrote:
> } Subject: Re: Parameter expansion bug?
> }
> } In zsh echo - does not print anything and echo - -n prints -n.  How do you
> } print -n under bash?
> 
> As nearly as I can tell, `echo -e -n` is the only way.

No it does not work either.  Perhaps you wanted to write

echo -e '\55n'

Zoltan

Re: Parameter expansion bug?

[Bart Schaefer]

On Oct 31,  5:57pm, Hrvoje Niksic wrote:
} Subject: Re: Parameter expansion bug?
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > On Oct 31,  5:12pm, Zoltan Hidvegi wrote:
} > } How do you print -n under bash?
} > As nearly as I can tell, `echo -e -n` is the only way.
} 
} It doesn't work for me:
} 
} `-e' in bash is used to enable interpretation of control sequences
} like \n.

Yes, I know.

On Oct 31,  6:04pm, Zoltan Hidvegi wrote:
} Subject: Re: Parameter expansion bug?
}
} Perhaps you wanted to write
} 
} echo -e '\55n'

No, I see how I confused myself.  I was trying various combinations like
`echo \\-n` and got as far as:

bash$ echo -e -n\\n
-n

bash$ 

And then mistakenly though that this meant that only the first parameter
that began with a `-' was interpreted (e.g. that `echo -ne` was required
to get both escapes and no newline), and thus that `echo -e -n` would
work, when in fact it was the presence of the \\n that was causing the
second word to not be interpreted as a switch.

But `echo \\55n` is easier than `echo -ne -n\\n` ...

Interestingly, GNU echo ignores the -e switch; you have to give it -E to
shut off escapes.  So `echo ...` and `/bin/echo ...` aren't the same on
my machine, though they accept the same switches.  Isn't bash GNUware?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: Parameter expansion bug?

[Anthony Heading]

Zoltan wrote:
> In zsh echo - does not print anything and echo - -n prints -n.  How do you
> print -n under bash?
> 
> Try
> 
> print -r - ${sdrgsdfdg:--}

Oops!  Light suddenly dawns.  Sorry...

Thanks

Anthony

fifo configure check

[Zoltan Hidvegi]

I discovered that fifo test fails if zsh is compiled in an NFS mounted
directory.  The patch below shoud fix it (it's only for configure.in, you
need autoconf).  I did not test it but it should work.

Zoltan


*** configure.in	1996/12/05 03:59:45	3.1.0.10
--- configure.in	1996/12/13 02:27:32
***************
*** 656,680 ****
  {
      char c;
      int fd;
!     int pid;
!     unlink("conftestfifo");
  #ifdef HAVE_MKFIFO
!     if(mkfifo("conftestfifo", 0600) < 0)
  #else
!     if(mknod("conftestfifo", 0010600, 0) < 0)
  #endif
  	exit(1);
      pid = fork();
      if(pid < 0)
  	exit(1);
      if(pid) {
! 	fd = open("conftestfifo", O_RDONLY);
  	exit(fd < 0 || read(fd, &c, 1) != 1 || c != 'x');
      }
!     fd = open("conftestfifo", O_WRONLY);
!     if(fd < 0 || write(fd, "x", 1) < 1)
! 	kill(getppid(), SIGTERM);
!     exit(0);
  }
  ],
    zsh_cv_sys_fifo=yes,
--- 656,680 ----
  {
      char c;
      int fd;
!     int pid, ret;
!     unlink("/tmp/conftestfifo");
  #ifdef HAVE_MKFIFO
!     if(mkfifo("/tmp/conftestfifo", 0600) < 0)
  #else
!     if(mknod("/tmp/conftestfifo", 0010600, 0) < 0)
  #endif
  	exit(1);
      pid = fork();
      if(pid < 0)
  	exit(1);
      if(pid) {
! 	fd = open("/tmp/conftestfifo", O_RDONLY);
  	exit(fd < 0 || read(fd, &c, 1) != 1 || c != 'x');
      }
!     fd = open("/tmp/conftestfifo", O_WRONLY);
!     ret = (fd < 0 || write(fd, "x", 1) < 1);
!     unlink("/tmp/conftestfifo");
!     exit(ret);
  }
  ],
    zsh_cv_sys_fifo=yes,

Re: fifo configure check

[Bart Schaefer]

On Dec 13,  3:30am, Zoltan Hidvegi wrote:
} Subject: fifo configure check
}
} I discovered that fifo test fails if zsh is compiled in an NFS mounted
} directory.  The patch below shoud fix it (it's only for configure.in, you
} need autoconf).  I did not test it but it should work.
} 
}   #ifdef HAVE_MKFIFO
} !     if(mkfifo("/tmp/conftestfifo", 0600) < 0)
}   #else
} !     if(mknod("/tmp/conftestfifo", 0010600, 0) < 0)
}   #endif

I'm concerned that fifos won't work on the ramdisk file system that many
newer suns are configured to use for /tmp.  (I know things like lockf()
fail on the ramdisk.)  Can someone who has a ramdisk /tmp please try this
soon and let us know?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: fifo configure check (seems to work here: Solaris 2.4)

[C. v. Stuckrad]

On Thu, 12 Dec 1996, Bart Schaefer wrote:

> On Dec 13,  3:30am, Zoltan Hidvegi wrote:

> } I discovered that fifo test fails if zsh is compiled in an NFS mounted
> } directory.  The patch below shoud fix it (it's only for configure.in, you
> } need autoconf).  I did not test it but it should work.
> 
> I'm concerned that fifos won't work on the ramdisk file system that many
> newer suns are configured to use for /tmp.  (I know things like lockf()
> fail on the ramdisk.)  Can someone who has a ramdisk /tmp please try this
> soon and let us know?

After unpacking 3.0.1 on /tmp and patching (including the nfs-patch),
configure DID find FIFOs correctly. 

We have Solaris2.4 (FOUR!) and use momentarily /tmp on swap.
It might go wrong on Solaris 5.1 (did somebody else test that ?)

Stucki

Christoph von Stuckrad       * *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-5913        /

Re: fifo configure check

[Zefram]

Bart wrote:
>On Dec 13,  3:30am, Zoltan Hidvegi wrote:
>} Subject: fifo configure check
>}
>} I discovered that fifo test fails if zsh is compiled in an NFS mounted
>} directory.

It works for me on NFS-mounted filesystems.  (Solaris 2.5.1 and SunOS
4.1.4.)  If FIFOs don't work on such filesystems, then that is a
serious bug in the operating system.

>}             The patch below shoud fix it (it's only for configure.in, you
>} need autoconf).  I did not test it but it should work.

It is certainly sensible to perform the test on the same filesystem we
will actually use the FIFOs on.  But the fixed name in /tmp can cause
clashes if two people are configuring zsh at the same time.  I think
some attempt at a unique name is necessary.

>I'm concerned that fifos won't work on the ramdisk file system that many
>newer suns are configured to use for /tmp.  (I know things like lockf()
>fail on the ramdisk.)  Can someone who has a ramdisk /tmp please try this
>soon and let us know?

It works on Solaris 2.5.1.  But of course we have /dev/fd, so the FIFOs
aren't required in any case.

-zefram

Re: fifo configure check

[Zoltan Hidvegi]

Zefram wrote:
> It works for me on NFS-mounted filesystems.  (Solaris 2.5.1 and SunOS
> 4.1.4.)  If FIFOs don't work on such filesystems, then that is a
> serious bug in the operating system.

But no.  On plain Solaris 2.5.1:

turan ~ % uname -a
SunOS turan.cs.elte.hu 5.5.1 Generic_103640-01 sun4m sparc SUNW,SPARCstation-10
turan ~ % ls -l foo
ls: foo: No such file or directory
turan ~ % mkfifo foo
mkfifo: cannot make fifo `foo': Invalid argument

My home directory is NFS mounted from Linux.  Fifos work in directories
mounted from Ultrix.

Zoltan

history-search-backward

[Peter Stephenson]

Looks like another incompatibility got in while I wasn't paying much
attention: ^[p will only search backwards on complete words.  (I
remember the discussion, not the conclusion, I presume this is
intentional.)  It seems to me this is going to cause lots of zsh users
endless confusion when they type part of a word, then ^[p, and nothing
happens.

It's also incompatible with the tcsh binding (it always was a bit, but
not so drastically).  It makes it essentially useless for me, too,
since I use it as a way of abbreviating the first word of a command,
but that's personal taste and I can live with
history-beginning-search-backward.

<customary diatribe about incompatibilities deleted, you've seen it before>

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: history-search-backward

[Zefram]

Peter Stephenson wrote:
>Looks like another incompatibility got in while I wasn't paying much
>attention: ^[p will only search backwards on complete words.  (I
>remember the discussion, not the conclusion, I presume this is
>intentional.)  It seems to me this is going to cause lots of zsh users
>endless confusion when they type part of a word, then ^[p, and nothing
>happens.

That's what history-beginning-search-backward is for.  It may cause
confusion, but only minimally, as the old behaviour wasn't documented.

-zefram

Re: history-search-backward

[Peter Stephenson]

Zefram wrote:
> That's what history-beginning-search-backward is for.  It may cause
> confusion, but only minimally, as the old behaviour wasn't documented.

Problem is, history-beginning-search-backward only got added a few
versions ago and has never been bound, while the
history-search-backward behaviour, partly inherited from tcsh, has
been around for years and years whether documented or not and I don't
believe I'm the only one to have been relying on it.  If it confused
me --- and I'm supposed in principal to be clued up --- I can't
imagine the general confusion will be any less.

It should go in the NEWS file when the release becomes official and
I'll put it in the FAQ.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: history-search-backward

[Bart Schaefer]

On Jan 31, 11:47am, Peter Stephenson wrote:
} Subject: history-search-backward
}
} Looks like another incompatibility got in while I wasn't paying much
} attention: ^[p will only search backwards on complete words.  (I
} remember the discussion, not the conclusion, I presume this is
} intentional.)  It seems to me this is going to cause lots of zsh users
} endless confusion when they type part of a word, then ^[p, and nothing
} happens.
} 
} It's also incompatible with the tcsh binding (it always was a bit, but
} not so drastically).  It makes it essentially useless for me, too,
} since I use it as a way of abbreviating the first word of a command,
} but that's personal taste and I can live with
} history-beginning-search-backward.

I have to completely agree with Peter here.

I have both history-search-backward and history-beginning-search-backward
bound to keys, and use them for different things, but in both cases I
expect them to work on partial words; the only difference I expect is
whether they match against a prefix of the first word or a prefix of the
whole line.

On Jan 31, 12:16pm, Zefram wrote:
} Subject: Re: history-search-backward
}
} That's what history-beginning-search-backward is for.  It may cause
} confusion, but only minimally, as the old behaviour wasn't documented.

I think you have no idea how wrong you are.

On Jan 31,  1:42pm, Peter Stephenson wrote:
} Subject: Re: history-search-backward
}
} Problem is, history-beginning-search-backward only got added a few
} versions ago and has never been bound, while the
} history-search-backward behaviour, partly inherited from tcsh, has
} been around for years and years whether documented or not and I don't
} imagine the general confusion will be any less.

Exactly.

} It should go in the NEWS file when the release becomes official and
} I'll put it in the FAQ.

I can't accept that as sufficient in this case.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: history-search-backward

[Vinnie Shelton]

I have to agree with Bart - IMO, the old behavior should be restored.
Peter, thanks for noticing this.  Bart, thanks for speaking up.

vin

schaefer@candle.brasslantern.com said:
> On Jan 31,  1:42pm, Peter Stephenson wrote: } Subject: Re:
> history-search-backward } } Problem is, history-beginning-search-backwa
> rd only got added a few } versions ago and has never been bound, while
> the } history-search-backward behaviour, partly inherited from tcsh,
> has } been around for years and years whether documented or not and I
> don't } imagine the general confusion will be any less.

> Exactly.

> } It should go in the NEWS file when the release becomes official and
> } I'll put it in the FAQ.

> I can't accept that as sufficient in this case. 

Re: history-search-backward

[Zoltan Hidvegi]

Peter Stephenson wrote:
> Zefram wrote:
> > That's what history-beginning-search-backward is for.  It may cause
> > confusion, but only minimally, as the old behaviour wasn't documented.
> 
> Problem is, history-beginning-search-backward only got added a few
> versions ago and has never been bound, while the
> history-search-backward behaviour, partly inherited from tcsh, has
> been around for years and years whether documented or not and I don't
> believe I'm the only one to have been relying on it.  If it confused
> me --- and I'm supposed in principal to be clued up --- I can't
> imagine the general confusion will be any less.

I think it would be a good idea to make history beginning-search bound to M-p
and M-n by default instead of history-search.  I personally never use
history-search, I always found it quite useless as history-beginning-* is much
better.

In fact, in tcsh M-p is bount to history-beginning instead of history search.

Any objections to change this default?

Zoltan

Re: history-search-backward

[Wayne Davison]

Peter Stephenson writes:
> Looks like another incompatibility got in while I wasn't paying much
> attention: ^[p will only search backwards on complete words.

I don't think anyone objected except me, which I found surprising.
I think the new method is less versatile.  Sure it agrees with the
man page, but it would have been just as easy to fix the manual.

The old method allowed someone to choose between searching for a
whole command and a sub-string by including a space or not.  Yes, I
know that history-beginning-search-backward lets you do this and
more (I've had that bound to ^[p for a long time now since it works
like bash's default ^[p command and I like that better), but it seems
to me that the undocumented working of the default binding was more
intuitive for those that didn't want the command arguments getting
into the search.

..wayne..

Re: history-search-backward

[Bart Schaefer]

On Jan 31,  8:02pm, Zoltan Hidvegi wrote:
} Subject: Re: history-search-backward
}
} Peter Stephenson wrote:
} > Zefram wrote:
} > > That's what history-beginning-search-backward is for.  It may cause
} > > confusion, but only minimally, as the old behaviour wasn't documented.
} > 
} > Problem is, history-beginning-search-backward only got added a few
} > versions ago and has never been bound
} 
} I think it would be a good idea to make history beginning-search bound to
} M-p and M-n by default instead of history-search.  I personally never use
} history-search, I always found it quite useless as history-beginning-* is
} much better.
} 
} In fact, in tcsh M-p is bount to history-beginning instead of history search.
} 
} Any objections to change this default?

I don't object to that default, but I still think the old behavior of
history-search-* should be restored.

On Jan 31, 11:13am, Wayne Davison wrote:
} Subject: Re: history-search-backward
}
} Peter Stephenson writes:
} > Looks like another incompatibility got in while I wasn't paying much
} > attention: ^[p will only search backwards on complete words.
} 
} I don't think anyone objected except me, which I found surprising.

I'd have objected if I'd seen it.  I still have a slew of zsh mail that
I stashed away while on my midwinter's holiday; there must be something
about this in there, where I haven't gotten to it yet.  (I also haven't
had a chance to build a new zsh since then, unfortunately.)

} I think the new method is less versatile.  Sure it agrees with the
} man page, but it would have been just as easy to fix the manual.

Agree completely.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

comptest* failed to load module: zsh/termcap

[Peter Whaite]

Cvs last couple of days says after 'make test'

./Y01completion.ztst: starting.
comptestinit:10: failed to load module: zsh/termcap
comptestinit:echotc:10: autoload failed
./Y01completion.ztst: all tests successful.
./Y02compmatch.ztst: starting.
comptestinit:10: failed to load module: zsh/termcap
comptestinit:echotc:10: autoload failed
./Y02compmatch.ztst: all tests successful.
./Y03arguments.ztst: starting.
comptestinit:10: failed to load module: zsh/termcap
comptestinit:echotc:10: autoload failed
./Y03arguments.ztst: all tests successful.

Is this OK? 

--
peta

Re: comptest* failed to load module: zsh/termcap

[Bart Schaefer]

On Apr 27,  3:54pm, Peter Whaite wrote:
} Subject: comptest* failed to load module: zsh/termcap
}
} 
} Cvs last couple of days says after 'make test'
} 
} ./Y01completion.ztst: starting.
} comptestinit:10: failed to load module: zsh/termcap
} comptestinit:echotc:10: autoload failed
} 
} Is this OK? 

No, it's not OK.  Standard question:

Did you remove your config.cache and re-run ./Util/preconfig and configure
before compiling?  There were a lot of changes to configure.in recently.

If that doesn't seem to be the problem, let's have a look at your config.h
and config.modules after running configure.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: comptest* failed to load module: zsh/termcap

[Andrej Borsenkow]

> } 
> } Cvs last couple of days says after 'make test'
> } 
> } ./Y01completion.ztst: starting.
> } comptestinit:10: failed to load module: zsh/termcap
> } comptestinit:echotc:10: autoload failed
> } 
> } Is this OK? 
> 
> No, it's not OK.  Standard question:
> 
> Did you remove your config.cache and re-run ./Util/preconfig and configure
> before compiling?  There were a lot of changes to configure.in recently.
> 
> If that doesn't seem to be the problem, let's have a look at your config.h
> and config.modules after running configure.
> 

And, of course - what system, what compiler, etc. 

-andrej

Re: comptest* failed to load module: zsh/termcap

[Peter Whaite]

"Bart Schaefer" said:
> On Apr 27,  3:54pm, Peter Whaite wrote:
> } Subject: comptest* failed to load module: zsh/termcap
> }
> } 
> } Cvs last couple of days says after 'make test'
> } 
> } ./Y01completion.ztst: starting.
> } comptestinit:10: failed to load module: zsh/termcap
> } comptestinit:echotc:10: autoload failed
> } 
> } Is this OK? 
> 
> No, it's not OK.  Standard question:
> 
> Did you remove your config.cache and re-run ./Util/preconfig and configure
> before compiling?  There were a lot of changes to configure.in recently.

I had tried that, except for the preconfig.  Tried just now and still have the
same problem.

> If that doesn't seem to be the problem, let's have a look at your config.h
> and config.modules after running configure.

Included below.  System is...

  % uname -a
  Linux ursula 2.4.2 #3 Tue Mar 13 08:51:29 EST 2001 i586 unknown

---------
config.h

/* config.h.  Generated automatically by configure.  */
/* config.h.in.  Generated automatically from configure.in by autoheader.  */

/***** begin user configuration section *****/

/* Define this to be the location of your password file */
#define PASSWD_FILE "/etc/passwd"

/* Define this to be the name of your NIS/YP password *
 * map (if applicable)                                */
#define PASSWD_MAP "passwd.byname"

/* Define to 1 if you want user names to be cached */
#define CACHE_USERNAMES 1

/* Define to 1 if system supports job control */
#define JOB_CONTROL 1

/* Define this if you use "suspended" instead of "stopped" */
#define USE_SUSPENDED 1
 
/* The default history buffer size in lines */
#define DEFAULT_HISTSIZE 30

/* The default editor for the fc builtin */
#define DEFAULT_FCEDIT "vi"

/* The default prefix for temporary files */
#define DEFAULT_TMPPREFIX "/tmp/zsh"


/***** end of user configuration section            *****/
/***** shouldn't have to change anything below here *****/

/* Define if using alloca.c.  */
/* #undef C_ALLOCA */

/* Define to empty if the keyword does not work.  */
/* #undef const */

/* Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems.
   This function is required for alloca.c support on those systems.  */
/* #undef CRAY_STACKSEG_END */

/* Define if the `getpgrp' function takes no argument.  */
#define GETPGRP_VOID 1

/* Define to `int' if <sys/types.h> doesn't define.  */
/* #undef gid_t */

/* Define if you have alloca, as a function or macro.  */
#define HAVE_ALLOCA 1

/* Define if you have <alloca.h> and it should be used (not on Ultrix).  */
#define HAVE_ALLOCA_H 1

/* Define if you have a working `mmap' system call.  */
#define HAVE_MMAP 1

/* Define if you have the strcoll function and it is properly defined.  */
#define HAVE_STRCOLL 1

/* Define if you have <sys/wait.h> that is POSIX.1 compatible.  */
#define HAVE_SYS_WAIT_H 1

/* Define to `int' if <sys/types.h> doesn't define.  */
/* #undef mode_t */

/* Define to `long' if <sys/types.h> doesn't define.  */
/* #undef off_t */

/* Define to `int' if <sys/types.h> doesn't define.  */
/* #undef pid_t */

/* Define as the return type of signal handlers (int or void).  */
#define RETSIGTYPE void

/* Define to `unsigned' if <sys/types.h> doesn't define.  */
/* #undef size_t */

/* If using the C implementation of alloca, define if you know the
   direction of stack growth for your system; otherwise it will be
   automatically deduced at run-time.
 STACK_DIRECTION > 0 => grows toward higher addresses
 STACK_DIRECTION < 0 => grows toward lower addresses
 STACK_DIRECTION = 0 => direction of growth unknown
 */
/* #undef STACK_DIRECTION */

/* Define if the `S_IS*' macros in <sys/stat.h> do not work properly.  */
/* #undef STAT_MACROS_BROKEN */

/* Define if you have the ANSI C header files.  */
#define STDC_HEADERS 1

/* Define if you can safely include both <sys/time.h> and <time.h>.  */
#define TIME_WITH_SYS_TIME 1

/* Define to `int' if <sys/types.h> doesn't define.  */
/* #undef uid_t */

/* The global file to source absolutely first whenever zsh is run; *
 * if undefined, don't source anything                             */
#define GLOBAL_ZSHENV "/etc/zshenv"

/* The global file to source whenever zsh is run; *
 * if undefined, don't source anything            */
#define GLOBAL_ZSHRC "/etc/zshrc"

/* The global file to source whenever zsh is run as a login shell; *
 * if undefined, don't source anything                             */
#define GLOBAL_ZLOGIN "/etc/zlogin"

/* The global file to source whenever zsh is run as a login shell, *
 * before zshrc is read; if undefined, don't source anything       */
#define GLOBAL_ZPROFILE "/etc/zprofile"

/* The global file to source whenever zsh was run as a login shell.  *
 * This is sourced right before exiting.  If undefined, don't source *
 * anything                                                          */
#define GLOBAL_ZLOGOUT "/etc/zlogout"

/* Define to 1 if compiler could initialise a union */
#define HAVE_UNION_INIT 1

/* Define to 1 if compiler incorrectly cast signed to unsigned */
/* #undef BROKEN_SIGNED_TO_UNSIGNED_CASTING */

/* Define to 1 if compiler supports variable-length arrays */
/* #undef HAVE_VARIABLE_LENGTH_ARRAYS */

/* Define if your system defines TIOCGWINSZ in sys/ioctl.h.  */
#define GWINSZ_IN_SYS_IOCTL 1

/* Define to 1 if you have NIS */
/* #undef HAVE_NIS */

/* Define to 1 if you have NISPLUS */
/* #undef HAVE_NIS_PLUS */

/* Define to 1 if you have RFS superroot directory. */
/* #undef HAVE_SUPERROOT */

/* Define to 1 if you need to use the native getcwd */
/* #undef USE_GETCWD */

/* Define to the path of the /dev/fd filesystem */
#define PATH_DEV_FD "/proc/self/fd"

/* Define if sys/time.h and sys/select.h cannot be both included */
/* #undef TIME_H_SELECT_H_CONFLICTS */

/* Define to be the machine type (microprocessor class or machine model) */
#define MACHTYPE "i586"

/* Define to be the name of the operating system */
#define OSTYPE "linux-gnu"

/* Define to 1 if ANSI function prototypes are usable.  */
#define PROTOTYPES 1

/* Define to be location of utmp file. */
#define PATH_UTMP_FILE "/var/run/utmp"

/* Define to be location of utmpx file. */
/* #undef PATH_UTMPX_FILE */

/* Define to be location of wtmp file. */
#define PATH_WTMP_FILE "/var/adm/wtmp"

/* Define to be location of wtmpx file. */
/* #undef PATH_WTMPX_FILE */

/* Define to 1 if struct utmp is defined by a system header */
#define HAVE_STRUCT_UTMP 1

/* Define to 1 if struct utmpx is defined by a system header */
#define HAVE_STRUCT_UTMPX 1

/* Define if your system's struct utmp has a member named ut_host.  */
#define HAVE_STRUCT_UTMP_UT_HOST 1

/* Define if your system's struct utmpx has a member named ut_host.  */
#define HAVE_STRUCT_UTMPX_UT_HOST 1

/* Define if your system's struct utmpx has a member named ut_xtime.  */
/* #undef HAVE_STRUCT_UTMPX_UT_XTIME */

/* Define if your system's struct utmpx has a member named ut_tv.  */
#define HAVE_STRUCT_UTMPX_UT_TV 1

/* Define if your system's struct dirent has a member named d_ino.  */
#define HAVE_STRUCT_DIRENT_D_INO 1

/* Define if your system's struct dirent has a member named d_stat.  */
/* #undef HAVE_STRUCT_DIRENT_D_STAT */

/* Define if your system's struct direct has a member named d_ino.  */
/* #undef HAVE_STRUCT_DIRECT_D_INO */

/* Define if your system's struct direct has a member named d_stat.  */
/* #undef HAVE_STRUCT_DIRECT_D_STAT */

/* Define if your system's struct sockaddr_in6 has a member named sin6_scope_id.  */
/* #undef HAVE_STRUCT_SOCKADDR_IN6_SIN6_SCOPE_ID */

/* Define to be a string corresponding the vendor of the machine */
#define VENDOR "pc"

/* Define to limit job table size */
#define MAXJOB 50
/* #undef NEED_LINUX_TASKS_H */

/* Define if your system defines `struct winsize' in sys/ptem.h.  */
/* #undef WINSIZE_IN_PTEM */

/* Define to 1 if you want to debug zsh */
/* #undef DEBUG */

/* Define to 1 if you want to use zsh's own memory allocation routines */
/* #undef ZSH_MEM */

/* Define to 1 if you want to debug zsh memory allocation routines */
/* #undef ZSH_MEM_DEBUG */

/* Define to 1 if you want to turn on warnings of memory allocation errors */
/* #undef ZSH_MEM_WARNING */

/* Define to 1 if you want to turn on memory checking for free() */
/* #undef ZSH_SECURE_FREE */

/* Define to 1 if you want to get debugging information on internal *
 * hash tables.  This turns on the `hashinfo' builtin.              */
/* #undef ZSH_HASH_DEBUG */

/* Undefine this if you don't want to get a restricted shell *
 * when zsh is exec'd with basename that starts with r.      *
 * By default this is defined.                               */
#define RESTRICTED_R 1

/* Define for Maildir support */
/* #undef MAILDIR_SUPPORT */

/* Define for function depth limits */
/* #undef MAX_FUNCTION_DEPTH */

/* Define if you want locale features.  By default this is defined. */
#define CONFIG_LOCALE 1

/* Define to 1 if your termcap library has the ospeed variable */
#define HAVE_OSPEED 1
/* Define to 1 if you have ospeed, but it is not defined in termcap.h */
/* #undef MUST_DEFINE_OSPEED */

/* Define to 1 if tgetent() accepts NULL as a buffer */
#define TGETENT_ACCEPTS_NULL 1

/* Define to 1 if you use POSIX style signal handling */
#define POSIX_SIGNALS 1

/* Define to 1 if you use BSD style signal handling (and can block signals) */
/* #undef BSD_SIGNALS */

/* Define to 1 if you use SYS style signal handling (and can block signals) */
/* #undef SYSV_SIGNALS */

/* Define to 1 if you have no signal blocking at all (bummer) */
/* #undef NO_SIGNAL_BLOCKING */

/* Define to `unsigned int' if <sys/types.h> or <signal.h> doesn't define */
/* #undef sigset_t */

/* Define to 1 if struct timezone is defined by a system header */
#define HAVE_STRUCT_TIMEZONE 1

/* Define to 1 if there is a prototype defined for brk() on your system */
#define HAVE_BRK_PROTO 1

/* Define to 1 if there is a prototype defined for sbrk() on your system */
#define HAVE_SBRK_PROTO 1

/* Define to 1 if there is a prototype defined for ioctl() on your system */
#define HAVE_IOCTL_PROTO 1

/* Define to 1 if there is a prototype defined for mknod() on your system */
#define HAVE_MKNOD_PROTO 1

/* Define to 1 if select() is defined in <sys/socket.h>, ie BeOS R4.51*/
/* #undef SELECT_IN_SYS_SOCKET_H */

/* Define to 1 if system has working FIFO's */
#define HAVE_FIFOS 1

/* Define to 1 if struct rlimit uses quad_t */
#define RLIM_T_IS_QUAD_T 1

/* Define to 1 if struct rlimit uses long long */
/* #undef RLIM_T_IS_LONG_LONG */

/* Define to 1 if rlimit uses unsigned */
/* #undef RLIM_T_IS_UNSIGNED */

/* Define to the type used in struct rlimit */
/* #undef rlim_t */

/* Define to 1 if /bin/sh does not interpret \ escape sequences */
#define SH_USE_BSD_ECHO 1

/* Define to 1 if system has working link() */
#define HAVE_LINK 1

/* Define to 1 if kill(pid, 0) doesn't return ESRCH, ie BeOS R4.51 */
/* #undef BROKEN_KILL_ESRCH */

/* Define to 1 if sigsuspend() is broken, ie BeOS R4.51 */
/* #undef BROKEN_POSIX_SIGSUSPEND */

/* Define to 1 if getpwnam() is faked, ie BeOS R4.51 */
/* #undef GETPWNAM_FAKED */

/* Define to 1 if tcsetpgrp() doesn't work, ie BeOS R4.51 */
/* #undef BROKEN_TCSETPGRP */

/* Define to 1 if an underscore has to be prepended to dlsym() argument */
/* #undef DLSYM_NEEDS_UNDERSCORE */

/* Define to 1 if multiple modules defining the same symbol are OK */
#define DYNAMIC_NAME_CLASH_OK 1

/* The exension used for dynamically loaded modules */
#define DL_EXT "so"

/* Define to 1 if you want to use dynamically loaded modules */
#define DYNAMIC 1

/* Define to 1 if you want to use dynamically loaded modules on AIX */
/* #undef AIXDYNAMIC */

/* Define to 1 if you want to use dynamically loaded modules on HPUX 10 */
/* #undef HPUXDYNAMIC */

/* Define to `unsigned long' if <sys/types.h> doesn't define. */
/* #undef ino_t */

/*
 * Definitions used when a long is less than eight byte, to try to
 * provide some support for eight byte operations.
 *
 * Note that ZSH_64_BIT_TYPE, OFF_T_IS_64_BIT, INO_T_IS_64_BIT do *not* get
 * defined if long is already 64 bits, since in that case no special handling
 * is required.
 */
/* Define to 1 if long is 64 bits */
/* #undef LONG_IS_64_BIT */

/* Define to a 64 bit integer type if there is one, but long is shorter */
#define ZSH_64_BIT_TYPE long long

/* Define to an unsigned variant of ZSH_64_BIT_TYPE if that is defined */
#define ZSH_64_BIT_UTYPE unsigned long long

/* Define to 1 if off_t is 64 bit (for large file support) */
#define OFF_T_IS_64_BIT 1

/* Define to 1 if ino_t is 64 bit (for large file support) */
/* #undef INO_T_IS_64_BIT */

/* Define to 1 if h_errno is not defined by the system */
/* #undef USE_LOCAL_H_ERRNO */

/* Define if you have the termcap boolcodes symbol.  */
#define HAVE_BOOLCODES 1

/* Define if you have the termcap numcodes symbol.  */
#define HAVE_NUMCODES 1

/* Define if you have the termcap strcodes symbol.  */
#define HAVE_STRCODES 1

/* Define if you have the terminfo boolnames symbol.  */
#define HAVE_BOOLNAMES 1

/* Define if you have the terminfo numnames symbol.  */
#define HAVE_NUMNAMES 1

/* Define if you have the terminfo strnames symbol.  */
#define HAVE_STRNAMES 1

/* Define if term.h chokes without curses.h */
/* #undef TERM_H_NEEDS_CURSES_H */

/* Define if you have the _mktemp function.  */
/* #undef HAVE__MKTEMP */

/* Define if you have the brk function.  */
#define HAVE_BRK 1

/* Define if you have the cap_get_proc function.  */
/* #undef HAVE_CAP_GET_PROC */

/* Define if you have the difftime function.  */
#define HAVE_DIFFTIME 1

/* Define if you have the dlclose function.  */
#define HAVE_DLCLOSE 1

/* Define if you have the dlerror function.  */
#define HAVE_DLERROR 1

/* Define if you have the dlopen function.  */
#define HAVE_DLOPEN 1

/* Define if you have the dlsym function.  */
#define HAVE_DLSYM 1

/* Define if you have the faccessx function.  */
/* #undef HAVE_FACCESSX */

/* Define if you have the fchdir function.  */
#define HAVE_FCHDIR 1

/* Define if you have the fseeko function.  */
#define HAVE_FSEEKO 1

/* Define if you have the ftello function.  */
#define HAVE_FTELLO 1

/* Define if you have the ftruncate function.  */
#define HAVE_FTRUNCATE 1

/* Define if you have the getenv function.  */
#define HAVE_GETENV 1

/* Define if you have the getgrgid function.  */
#define HAVE_GETGRGID 1

/* Define if you have the getgrnam function.  */
#define HAVE_GETGRNAM 1

/* Define if you have the gethostbyname2 function.  */
#define HAVE_GETHOSTBYNAME2 1

/* Define if you have the gethostname function.  */
#define HAVE_GETHOSTNAME 1

/* Define if you have the getipnodebyname function.  */
/* #undef HAVE_GETIPNODEBYNAME */

/* Define if you have the getlogin function.  */
#define HAVE_GETLOGIN 1

/* Define if you have the getpagesize function.  */
#define HAVE_GETPAGESIZE 1

/* Define if you have the getpwent function.  */
#define HAVE_GETPWENT 1

/* Define if you have the getpwnam function.  */
#define HAVE_GETPWNAM 1

/* Define if you have the getpwuid function.  */
#define HAVE_GETPWUID 1

/* Define if you have the getrlimit function.  */
#define HAVE_GETRLIMIT 1

/* Define if you have the gettimeofday function.  */
#define HAVE_GETTIMEOFDAY 1

/* Define if you have the inet_aton function.  */
#define HAVE_INET_ATON 1

/* Define if you have the inet_ntop function.  */
#define HAVE_INET_NTOP 1

/* Define if you have the inet_pton function.  */
#define HAVE_INET_PTON 1

/* Define if you have the initgroups function.  */
#define HAVE_INITGROUPS 1

/* Define if you have the killpg function.  */
#define HAVE_KILLPG 1

/* Define if you have the lchown function.  */
#define HAVE_LCHOWN 1

/* Define if you have the load function.  */
/* #undef HAVE_LOAD */

/* Define if you have the loadbind function.  */
/* #undef HAVE_LOADBIND */

/* Define if you have the loadquery function.  */
/* #undef HAVE_LOADQUERY */

/* Define if you have the lstat function.  */
#define HAVE_LSTAT 1

/* Define if you have the memcpy function.  */
#define HAVE_MEMCPY 1

/* Define if you have the memmove function.  */
#define HAVE_MEMMOVE 1

/* Define if you have the mkfifo function.  */
#define HAVE_MKFIFO 1

/* Define if you have the msync function.  */
#define HAVE_MSYNC 1

/* Define if you have the munmap function.  */
#define HAVE_MUNMAP 1

/* Define if you have the nice function.  */
#define HAVE_NICE 1

/* Define if you have the nis_list function.  */
#define HAVE_NIS_LIST 1

/* Define if you have the pathconf function.  */
#define HAVE_PATHCONF 1

/* Define if you have the poll function.  */
#define HAVE_POLL 1

/* Define if you have the putenv function.  */
#define HAVE_PUTENV 1

/* Define if you have the readlink function.  */
#define HAVE_READLINK 1

/* Define if you have the sbrk function.  */
#define HAVE_SBRK 1

/* Define if you have the select function.  */
#define HAVE_SELECT 1

/* Define if you have the seteuid function.  */
#define HAVE_SETEUID 1

/* Define if you have the setlocale function.  */
#define HAVE_SETLOCALE 1

/* Define if you have the setpgid function.  */
#define HAVE_SETPGID 1

/* Define if you have the setpgrp function.  */
#define HAVE_SETPGRP 1

/* Define if you have the setresuid function.  */
#define HAVE_SETRESUID 1

/* Define if you have the setreuid function.  */
#define HAVE_SETREUID 1

/* Define if you have the setsid function.  */
#define HAVE_SETSID 1

/* Define if you have the setuid function.  */
#define HAVE_SETUID 1

/* Define if you have the setupterm function.  */
/* #undef HAVE_SETUPTERM */

/* Define if you have the shl_findsym function.  */
/* #undef HAVE_SHL_FINDSYM */

/* Define if you have the shl_load function.  */
/* #undef HAVE_SHL_LOAD */

/* Define if you have the shl_unload function.  */
/* #undef HAVE_SHL_UNLOAD */

/* Define if you have the sigaction function.  */
#define HAVE_SIGACTION 1

/* Define if you have the sigblock function.  */
#define HAVE_SIGBLOCK 1

/* Define if you have the sighold function.  */
#define HAVE_SIGHOLD 1

/* Define if you have the signgam function.  */
#define HAVE_SIGNGAM 1

/* Define if you have the sigprocmask function.  */
#define HAVE_SIGPROCMASK 1

/* Define if you have the sigrelse function.  */
#define HAVE_SIGRELSE 1

/* Define if you have the sigsetmask function.  */
#define HAVE_SIGSETMASK 1

/* Define if you have the strerror function.  */
#define HAVE_STRERROR 1

/* Define if you have the strftime function.  */
#define HAVE_STRFTIME 1

/* Define if you have the strstr function.  */
#define HAVE_STRSTR 1

/* Define if you have the sysconf function.  */
#define HAVE_SYSCONF 1

/* Define if you have the tcgetattr function.  */
#define HAVE_TCGETATTR 1

/* Define if you have the tcsetpgrp function.  */
#define HAVE_TCSETPGRP 1

/* Define if you have the tgetent function.  */
#define HAVE_TGETENT 1

/* Define if you have the tigetflag function.  */
/* #undef HAVE_TIGETFLAG */

/* Define if you have the tigetnum function.  */
/* #undef HAVE_TIGETNUM */

/* Define if you have the tigetstr function.  */
/* #undef HAVE_TIGETSTR */

/* Define if you have the uname function.  */
#define HAVE_UNAME 1

/* Define if you have the unload function.  */
/* #undef HAVE_UNLOAD */

/* Define if you have the wait3 function.  */
#define HAVE_WAIT3 1

/* Define if you have the waitpid function.  */
#define HAVE_WAITPID 1

/* Define if you have the <curses.h> header file.  */
#define HAVE_CURSES_H 1

/* Define if you have the <dirent.h> header file.  */
#define HAVE_DIRENT_H 1

/* Define if you have the <dl.h> header file.  */
/* #undef HAVE_DL_H */

/* Define if you have the <dlfcn.h> header file.  */
#define HAVE_DLFCN_H 1

/* Define if you have the <errno.h> header file.  */
#define HAVE_ERRNO_H 1

/* Define if you have the <fcntl.h> header file.  */
#define HAVE_FCNTL_H 1

/* Define if you have the <grp.h> header file.  */
#define HAVE_GRP_H 1

/* Define if you have the <libc.h> header file.  */
/* #undef HAVE_LIBC_H */

/* Define if you have the <limits.h> header file.  */
#define HAVE_LIMITS_H 1

/* Define if you have the <linux/tasks.h> header file.  */
/* #undef HAVE_LINUX_TASKS_H */

/* Define if you have the <locale.h> header file.  */
#define HAVE_LOCALE_H 1

/* Define if you have the <memory.h> header file.  */
#define HAVE_MEMORY_H 1

/* Define if you have the <ndir.h> header file.  */
/* #undef HAVE_NDIR_H */

/* Define if you have the <netinet/in_systm.h> header file.  */
/* #undef HAVE_NETINET_IN_SYSTM_H */

/* Define if you have the <poll.h> header file.  */
#define HAVE_POLL_H 1

/* Define if you have the <pwd.h> header file.  */
#define HAVE_PWD_H 1

/* Define if you have the <stdlib.h> header file.  */
#define HAVE_STDLIB_H 1

/* Define if you have the <string.h> header file.  */
#define HAVE_STRING_H 1

/* Define if you have the <sys/capability.h> header file.  */
/* #undef HAVE_SYS_CAPABILITY_H */

/* Define if you have the <sys/dir.h> header file.  */
/* #undef HAVE_SYS_DIR_H */

/* Define if you have the <sys/filio.h> header file.  */
/* #undef HAVE_SYS_FILIO_H */

/* Define if you have the <sys/mman.h> header file.  */
#define HAVE_SYS_MMAN_H 1

/* Define if you have the <sys/ndir.h> header file.  */
/* #undef HAVE_SYS_NDIR_H */

/* Define if you have the <sys/param.h> header file.  */
#define HAVE_SYS_PARAM_H 1

/* Define if you have the <sys/resource.h> header file.  */
#define HAVE_SYS_RESOURCE_H 1

/* Define if you have the <sys/select.h> header file.  */
#define HAVE_SYS_SELECT_H 1

/* Define if you have the <sys/time.h> header file.  */
#define HAVE_SYS_TIME_H 1

/* Define if you have the <sys/times.h> header file.  */
#define HAVE_SYS_TIMES_H 1

/* Define if you have the <sys/types.h> header file.  */
#define HAVE_SYS_TYPES_H 1

/* Define if you have the <sys/utsname.h> header file.  */
#define HAVE_SYS_UTSNAME_H 1

/* Define if you have the <term.h> header file.  */
#define HAVE_TERM_H 1

/* Define if you have the <termcap.h> header file.  */
#define HAVE_TERMCAP_H 1

/* Define if you have the <termio.h> header file.  */
#define HAVE_TERMIO_H 1

/* Define if you have the <termios.h> header file.  */
#define HAVE_TERMIOS_H 1

/* Define if you have the <unistd.h> header file.  */
#define HAVE_UNISTD_H 1

/* Define if you have the <utmp.h> header file.  */
#define HAVE_UTMP_H 1

/* Define if you have the <utmpx.h> header file.  */
#define HAVE_UTMPX_H 1

/* Define if you have the cap library (-lcap).  */
/* #undef HAVE_LIBCAP */

/* Define if you have the dl library (-ldl).  */
#define HAVE_LIBDL 1

/* Define if you have the m library (-lm).  */
#define HAVE_LIBM 1

/* Define if you have the socket library (-lsocket).  */
/* #undef HAVE_LIBSOCKET */

---------
config.modules

# Edit this file to change the way modules are loaded.
# The format is strict; do not break lines or add extra spaces.
# Run `make prep' if you change anything here after compiling
# (there is no need if you change this just after the first time
# you run `configure').
#
# Values of `link' are `static', `dynamic' or `no' to compile the
# module into the shell, link it in at run time, or not use it at all.
# In the final case, no attempt will be made to compile it.
# Use `static' or `no' if you do not have dynamic loading.
#
# Values of `load' are `yes' or `no'; if yes, any builtins etc.
# provided by the module will be autoloaded by the main shell
# (so long as `link' is not set to `no').
#
# Values of `auto' are `yes' or `no'. configure sets the value to
# `yes'.  If you set it by hand to `no', the line will be retained
# when the file is regenerated in future.
#
# Note that the `functions' entry extends to the end of the line.
# It should not be quoted; it is used verbatim to find files to install.
#
# You will need to run `config.status --recheck' if you add a new
# module.
#
# You should not change the values for the pseudo-module zsh/main,
# which is the main shell (apart from the functions entry).
name=zsh/main modfile=Src/zsh.mdd link=static auto=yes load=yes functions=Functions/Misc/* Functions/Prompts/*
name=zsh/rlimits modfile=Src/Builtins/rlimits.mdd link=dynamic auto=yes load=yes
name=zsh/sched modfile=Src/Builtins/sched.mdd link=dynamic auto=yes load=yes
name=zsh/cap modfile=Src/Modules/cap.mdd link=dynamic auto=yes load=no
name=zsh/clone modfile=Src/Modules/clone.mdd link=dynamic auto=yes load=no
name=zsh/example modfile=Src/Modules/example.mdd link=dynamic auto=yes load=no
name=zsh/files modfile=Src/Modules/files.mdd link=dynamic auto=yes load=no
name=zsh/mapfile modfile=Src/Modules/mapfile.mdd link=dynamic auto=yes load=no
name=zsh/mathfunc modfile=Src/Modules/mathfunc.mdd link=dynamic auto=yes load=no
name=zsh/parameter modfile=Src/Modules/parameter.mdd link=dynamic auto=yes load=yes
name=zsh/stat modfile=Src/Modules/stat.mdd link=dynamic auto=yes load=no
name=zsh/termcap modfile=Src/Modules/termcap.mdd link=dynamic auto=yes load=yes
name=zsh/terminfo modfile=Src/Modules/terminfo.mdd link=dynamic auto=yes load=yes
name=zsh/zftp modfile=Src/Modules/zftp.mdd link=dynamic auto=yes load=no functions=Functions/Zftp/*
name=zsh/zprof modfile=Src/Modules/zprof.mdd link=dynamic auto=yes load=no
name=zsh/zpty modfile=Src/Modules/zpty.mdd link=dynamic auto=yes load=no
name=zsh/zutil modfile=Src/Modules/zutil.mdd link=dynamic auto=yes load=yes
name=zsh/compctl modfile=Src/Zle/compctl.mdd link=dynamic auto=yes load=yes
name=zsh/complete modfile=Src/Zle/complete.mdd link=dynamic auto=yes load=yes functions=Completion/comp* Completion/AIX/*/* Completion/BSD/*/* Completion/Base/*/* Completion/Debian/*/* Completion/Redhat/*/* Completion/Unix/*/* Completion/X/*/* Completion/Zsh/*/*
name=zsh/complist modfile=Src/Zle/complist.mdd link=dynamic auto=yes load=yes
name=zsh/computil modfile=Src/Zle/computil.mdd link=dynamic auto=yes load=yes
name=zsh/deltochar modfile=Src/Zle/deltochar.mdd link=dynamic auto=yes load=no
name=zsh/zle modfile=Src/Zle/zle.mdd link=dynamic auto=yes load=yes functions=Functions/Zle/*
name=zsh/zleparameter modfile=Src/Zle/zleparameter.mdd link=dynamic auto=yes load=yes

Re: comptest* failed to load module: zsh/termcap

[Peter Whaite]

"Andrej Borsenkow" said:

> And, of course - what system, what compiler, etc. 

% cat /etc/issue

Red Hat Linux release 6.2 (Zoot)
Kernel 2.4.2 on an i586

% uname -a
Linux ursula 2.4.2 #3 Tue Mar 13 08:51:29 EST 2001 i586 unknown

% cc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Also tried complete preconfig, configure, and rebuild on another machine, and
still the same problem.

% cat /etc/issue

Red Hat Linux release 6.2 (mixed)
Kernel 2.4.2 on an i686

% uname -a
Linux aragorn 2.4.2 #4 Thu Mar 22 08:23:55 EST 2001 i686 unknown

% cc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
gcc version 2.7.2.3

--
peta

Re: comptest* failed to load module: zsh/termcap

[Bart Schaefer]

On Apr 30, 11:44am, Peter Whaite wrote:
} 
} "Andrej Borsenkow" said:
} 
} > And, of course - what system, what compiler, etc. 
} 
} % cat /etc/issue
} 
} Red Hat Linux release 6.2 (Zoot)
} Kernel 2.4.2 on an i586

This is a completely off-topic question, but:  Did you build the 2.4.2
kernel yourself?  I've been trying to compile a newer kernel on my RH6.2
machine at work and keep getting complaints that it needs newer versions
of modutils and mkinitrd than those available for RH6.2.

Meanwhile, I can reproduce your problem on that machine.  I changed the
linkage for termcap and terminfo from dynamic to static and got:

Modules/termcap.o: In function `scantermcap':
Modules/termcap.o(.text+0x450): undefined reference to `boolcodes'
Modules/termcap.o(.text+0x459): undefined reference to `boolcodes'
Modules/termcap.o(.text+0x4bd): undefined reference to `numcodes'
Modules/termcap.o(.text+0x4c3): undefined reference to `numcodes'
Modules/termcap.o(.text+0x515): undefined reference to `strcodes'
Modules/termcap.o(.text+0x51b): undefined reference to `strcodes'

So the problem is that configure.in is still missing the AC_SEARCH_LIBS
call to find the ncurses libraries (it does one only for tgetent, which
finds old termcap first).

Edit configure.in; look for the line:

AC_SEARCH_LIBS(tgetent, [$termcap_curses_order])

Copy'n'paste that line, s/tgetent/tigetstr/, rerun autoconf and configure,
then try "make" again.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: comptest* failed to load module: zsh/termcap

[Andrej Borsenkow]

On Mon, 30 Apr 2001, Bart Schaefer wrote:

> On Apr 30, 11:44am, Peter Whaite wrote:
> }
> } "Andrej Borsenkow" said:
> }
> } > And, of course - what system, what compiler, etc.
> }
> } % cat /etc/issue
> }
> } Red Hat Linux release 6.2 (Zoot)
> } Kernel 2.4.2 on an i586
>
> Meanwhile, I can reproduce your problem on that machine.  I changed the
> linkage for termcap and terminfo from dynamic to static and got:
>
> Modules/termcap.o: In function `scantermcap':
> Modules/termcap.o(.text+0x450): undefined reference to `boolcodes'
> Modules/termcap.o(.text+0x459): undefined reference to `boolcodes'
> Modules/termcap.o(.text+0x4bd): undefined reference to `numcodes'
> Modules/termcap.o(.text+0x4c3): undefined reference to `numcodes'
> Modules/termcap.o(.text+0x515): undefined reference to `strcodes'
> Modules/termcap.o(.text+0x51b): undefined reference to `strcodes'
>
> So the problem is that configure.in is still missing the AC_SEARCH_LIBS
> call to find the ncurses libraries (it does one only for tgetent, which
> finds old termcap first).
>

But it should not find the above variables then and should not try use
them (or use local static placeholders). So, the question is - why
configure sets HAVE_BOOLCODES and others at all? I believe, we finally
cleaned this up ... are you sure you are using the lates CVS?


> Edit configure.in; look for the line:
>
> AC_SEARCH_LIBS(tgetent, [$termcap_curses_order])
>
> Copy'n'paste that line, s/tgetent/tigetstr/, rerun autoconf and configure,
> then try "make" again.
>

That's workaround; still, the actual bug is different IMHO.

-andrej

PATCH: Re: comptest* failed to load module: zsh/termcap

[Bart Schaefer]

On Apr 30,  8:47pm, Andrej Borsenkow wrote:
} Subject: Re: comptest* failed to load module: zsh/termcap
}
} On Mon, 30 Apr 2001, Bart Schaefer wrote:
} 
} > Modules/termcap.o: In function `scantermcap':
} > Modules/termcap.o(.text+0x450): undefined reference to `boolcodes'
} >
} > So the problem is that configure.in is still missing the AC_SEARCH_LIBS
} > call to find the ncurses libraries (it does one only for tgetent, which
} > finds old termcap first).
} 
} But it should not find the above variables then and should not try use
} them (or use local static placeholders). So, the question is - why
} configure sets HAVE_BOOLCODES and others at all? I believe, we finally
} cleaned this up ... are you sure you are using the lates CVS?

Yes, I did a "cvs up -d -P" immediately before buiding.

Checking config.log, it turns out that even without -lcurses in the link,
AC_TRY_LINK is succeeding for boolcodes et al. -- possibly gcc is doing
an optimization and throwing out the `test' variable because it's not
used, and therefore not actually trying to find boolcodes at link time:

configure:3112: checking if boolcodes is available
configure:3124: gcc -o conftest  -Wall -Wno-implicit -Wmissing-prototypes -O2 -D _LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  conftest.c -ltermcap -lm  -lc 1>&5
configure: In function `main':
configure:3120: warning: initialization discards qualifiers from pointer target type
configure:3120: warning: unused variable `test'

The compilation then succeeds and goes on to the next thing.  On my RH5.2
system at home, there's a link failure at this point.

Sure enough, if I change configure.in to:

#include <term.h>], [char **test = boolcodes; printf(*test);],

(so that `test' is used), then AC_TRY_LINK fails and all is well.  We've
been bitten by an overoptimizing compiler.

Index: configure.in
===================================================================
--- configure.in	2001/04/27 05:21:54	1.4
+++ configure.in	2001/04/30 17:13:21
@@ -533,36 +533,36 @@
 AC_TRY_LINK([#ifdef TERM_H_NEEDS_CURSES_H
 #include <curses.h>
 #endif
-#include <term.h>], [char **test = boolcodes;],
+#include <term.h>], [char **test = boolcodes; printf(*test);],
 AC_DEFINE(HAVE_BOOLCODES) boolcodes=yes, boolcodes=no)
 AC_MSG_RESULT($boolcodes)
 AC_MSG_CHECKING(if numcodes is available)
 AC_TRY_LINK([#ifdef TERM_H_NEEDS_CURSES_H
 #include <curses.h>
 #endif
-#include <term.h>], [char **test = numcodes;],
+#include <term.h>], [char **test = numcodes; printf(*test);],
 AC_DEFINE(HAVE_NUMCODES) numcodes=yes, numcodes=no)
 AC_MSG_RESULT($numcodes)
 AC_MSG_CHECKING(if strcodes is available)
 AC_TRY_LINK([#ifdef TERM_H_NEEDS_CURSES_H
 #include <curses.h>
 #endif
-#include <term.h>], [char **test = strcodes;],
+#include <term.h>], [char **test = strcodes; printf(*test);],
 AC_DEFINE(HAVE_STRCODES) strcodes=yes, strcodes=no)
 AC_MSG_RESULT($strcodes)
 AC_MSG_CHECKING(if boolnames is available)
 AC_TRY_LINK([#include <curses.h>
-#include <term.h>], [char **test = boolnames;],
+#include <term.h>], [char **test = boolnames; printf(*test);],
 AC_DEFINE(HAVE_BOOLNAMES) boolnames=yes, boolnames=no)
 AC_MSG_RESULT($boolnames)
 AC_MSG_CHECKING(if numnames is available)
 AC_TRY_LINK([#include <curses.h>
-#include <term.h>], [char **test = numnames;],
+#include <term.h>], [char **test = numnames; printf(*test);],
 AC_DEFINE(HAVE_NUMNAMES) numnames=yes, numnames=no)
 AC_MSG_RESULT($numnames)
 AC_MSG_CHECKING(if strnames is available)
 AC_TRY_LINK([#include <curses.h>
-#include <term.h>], [char **test = strnames;],
+#include <term.h>], [char **test = strnames; printf(*test);],
 AC_DEFINE(HAVE_STRNAMES) strnames=yes, strnames=no)
 AC_MSG_RESULT($strnames)
 

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: comptest* failed to load module: zsh/termcap

[Peter Whaite]

"Bart Schaefer" said:

> This is a completely off-topic question, but:  Did you build the 2.4.2
> kernel yourself?  I've been trying to compile a newer kernel on my RH6.2
> machine at work and keep getting complaints that it needs newer versions
> of modutils and mkinitrd than those available for RH6.2.

I built it at home and I didn't have to search too hard for the right rpms.  I
didn't build 2.4.2 at work, but the person who did says the same.

However he has not been able to build 2.4.3, the main problem being the need
for a later version of the compiler, and the lack of a corresponding rpm for
rh6.2.  So can't really comment on the modules, though it is in general
getting pretty hard to keep up to date on rh6.2.  I'll probably give up soon
and install rh7.1.

> Edit configure.in; look for the line:
> 
> AC_SEARCH_LIBS(tgetent, [$termcap_curses_order])
> 
> Copy'n'paste that line, s/tgetent/tigetstr/, rerun autoconf and configure,
> then try "make" again.

Yes that fixed it.  

In another message:

> Sure enough, if I change configure.in to:
> 
> #include <term.h>], [char **test = boolcodes; printf(*test);],
> 
> (so that `test' is used), then AC_TRY_LINK fails and all is well.  We've
> been bitten by an overoptimizing compiler.

I'm a bit surprised to be the only one who reported the problem.

Re: comptest* failed to load module: zsh/termcap

[Bart Schaefer]

On Apr 30,  2:54pm, Peter Whaite wrote:
> Subject: Re: comptest* failed to load module: zsh/termcap
> 
> "Bart Schaefer" said:
> 
> > Sure enough, if I change configure.in to:
> > 
> > #include <term.h>], [char **test = boolcodes; printf(*test);],
> > 
> > (so that `test' is used), then AC_TRY_LINK fails and all is well.  We've
> > been bitten by an overoptimizing compiler.
> 
> I'm a bit surprised to be the only one who reported the problem.

I would have found it eventually, but I hadn't rebuilt zsh at work for a
few days.  Apparently there aren't many RH6.2 installations out there, at
least not where people build their own stuff rather than wait for the RPM.