I have no idea if anyone besides me still runs es (or anyone cares to
maintain their copies), but here is a patch to the last public release
(that I know of).  It bites you when you configure --with-readline and
then proceed to enter a really long command line under the built
shell.  To ensure that you don't accidentally reverse patch it to a
source tree where it was already done: It is strictly not legal to
call the sequence: ``efree(X); X = erealloc(X, Y);''.

I always love it when you can fix a bug by removing code. ;-)
Possible fix for the signal-handling problem

Below is a patch that was found tonight by manual inspection after
getting a handle on the failure mode.  I found that the file-scoped
variable ``blocked'' in signal.c became non-zero forever after the
first interrupt was processed inside a shell-level while loop.  Thus,
clearly, an imbalance in calls to blocksignals()/unblocksignals() must
be present in some code path.  I hope I am not just trading the
obvious fix of the call pairing for a race condition in some other
case (I figure that you can judge this far faster than I).

Although perhaps benign whenever HAVE_SIGACTION=1, I also removed the
gratuitous signal() call in catcher() when SYSV_SIGNALS=0 and,
conversely, added the needed signal() call in catcher() when
SYSV_SIGNALS=1.  According to my local CVS archive of es, someone
clearly hosed this between ES-0_9-ALPHA1 and ES-0_9-BETA1.
To get rid of the memory leak in the LIBREADLINE support
A word of warning for future committers so that you don't fall into
the same trap as I did: The source has an printf-style funtion
"print". This doesn't understand "%u", so the usual print-casting
stuff for long long ints isn't
  printf("%u", (unsigned int)foo);
but
  print("%d", (int)foo);
which obviously looses in some cases, but I didn't take the effort to
extend this function to take 64 bit value (just unsigned is limited as
well).

In this case, it isn't that bad, since it is used to print limits, but
memory limits are internally stored as "mega" or "kilo" anyway.
fixing es builds but does not run on amd64/FBSD 6.

mksignal tries to build some definitions, but at least for my system adds
too many and runs afoul of the check in signals.c
In particular, SIGLWP == NSIG

Note:
/sys/signal.h:#define SIGLWP SIGTHR
and SIGTHR was already a problem.

I just added 2 lines
that do a check against NSIG when defining signals. This seems better to
me than just adding ignores as it's general -- it will still work if the
signals get renumbered (as they apparently were).
some netbsd patch that looked useful
Found some typos in '/usr/share/man/man1/es.1.gz'
the assignment operator does not work on powerpc for varargs arguments.
it produces 'incombatible types in assignment' errors.
lots of debian tweaks, since I got bored of separate commits. I think it's:

   * Fixed over-popping in the %writeto primitive, reported by Peter
     Moulder. (Closes: #195632)
   * Use sysconf() and __GLIBC__, thanks to James A Morrison.
     (Closes: #106831)
   * removed va_arg(..., short) (closes #104711).  According to
     http://www.bero.org/gcc296.html, ISO C99 requires that
       Parameters passed to "..." type varargs are automatically promoted to int
     So, of course, gcc had to go and break backwards compatibility by
     making it an error to use short as a tag for va_arg.  INTERFACES ARE
     SACRED: DON'T GO BREAKING THEM BECAUSE SOME STANDARDS BODY HAS COME
     UP WITH A NEW ONE.  sigh
   * use __va_copy instead of = after va_end in fmtprint (Fixes #38740)