[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ksh file name completion oddity / ksh cleanup question



Sorry for crossposting, but someone suggested that tech@ would be
the right list. For technical discussions, please respect the
reply-to.

Notorious self-quoter Matthias Kilian wrote:
> For the first pass I leave KSH, JOBS, BRACE_EXPAND and other #ifdefs
> that could be called "features" untouched.
> 
> Expect a patch this evening (CET).

Since I don't want to send a 209 kB patch over the lists, here's
where you can download it.

http://openbsd.dead-parrot.de/ksh.diffs.gz

Remarks (you'll find a copy of this in the patch):


This is a patch for ksh that removes about 10% of the ksh sources
containing unused OS dependent #ifdef blocks, lots of #defines in
config.h and sh.h, as well as IMHO unnecessary preprocessor
abstractions (e.g. PATHSEP, DIRSEP, ISABSPATH, ...).

All ksh_*.h wrappers except for ksh_limval.h have been removed. See
the added note in PROJECTS for ksh_limval.h.

I'm sure there's more code that waits for cleanup, but this initial
pass is rather trivial and doesn't change semantics -- at least in
theory ;-)

Additionally, Thorsten Glaser dropped me a message that he also did
some heavy cleanup on ksh, but based on a slightly different version
for MirOS. I'll try to merge both cleanups in the next days.

Built, tested and compared on i386 and macppc. Test results are
equal to the ksh sources in -CURRENT (including one unexpectedly
failed test). However, there were some differences in the resulting
binaries, at least one of them is really bizarre (see the EAGAIN
note below). I'll probably investigate a little bit more, but for
now, I'll have to drink some beer and fix that silly completion
bug.

Possible additional trivial cleanups:

- Remove #ifdef KSH (some people may veto on this)
- Remove #ifdef EDIT, #ifdef EMACS, #ifdef VI, or at least melt them
  down to one #ifdef EDIT.
- Remove the allready disabled FP stuff in shf.c, or get it back to
  life.

Here are the bizarre effects on the generated binaries:

misc.[co]: there is a difference in the generated code in
blocking_read(). Changing

	if (!tried_reset && errno == EAGAIN) {

into

	if (!tried_reset && (errno == EAGAIN || errno == EGAIN)) {

seems "fix" this. Looks like some strange shortcoming in gcc's
optimizer.


misc.[co]: removing the #include <ctype.h> results in the generated
code on i386. I still have to check this; probably some inline stuff
in ctype.h?


jobs.[co]: there's a difference in the generated code on macppc.
I didn't yet look at this.


Please read, test, and/or comment.


Ciao,
	Kili