> email the patches for elks 0.77 and elkscmd 0.77.  
: > 
: >     o Ported elvis to ELKS
: 
: Is this based on the code that was in elkscmd?


        Yep.

: 
: >     o changed all elkscmd srcs to use tcsetattr/tcgetattr instead of ioctl
: 
: I previously held back from doing this to make the minimal size saving, but
: I guess it is not significant.

        There's a much bigger reason that I did this, and have almost completed
all the work.  The reason is to be able to run *all* the ELKS cmds on Linux.  Then
I can debug them on a debugged OS.  So, I made elvis first run on Linux.  After
I made sure it worked there, I was able to debug elvis on ELKS.  Thats why
I have the commented out CC= stuff in the elkscmd Makefiles.  I'd like to leave that
stuff in there, beleive me, it helps for debugging.




: 
: >     o added /etc/termcap to elks distribution with elks terminal type
: > BTW, the ansi elks console doesn't work.  I can rewrite it quickly if nobody minds.
: > The new elks terminal type "elks" is mostly vt52.  I think it should be ansi.
: > vt52 doesn't support attributes, and elvis needs at least reverse video.
: 
: Okay, we can make anis the standard one. People should still be able to

        Good typo     ^                 ;-)

: drop back to vt52 if they want a mimal cursor addressabel terminal. DOn't
: remove that capabiltiy.

        Last night I heavily modifed dircon.c.  It now includes full support
for required minimal ansi sequences, and is 400 bytes smaller.  I suggest that
we move to TERM=ansi for elks console.  I have left all the vt52 stuff in as well.

: >In the meantime,
: > I found that the libc putenv() is completely buggy and doesn't work.  I will 
:rewrite
: > this soon.
: >     o added TERM=elks to /bin/login exported environment.
: >     o added setenv and printenv to internal sash commands.
: 
: Please don't commit too much effort into sash. I don't really think it is
: worth it. We need a proper shell, and ash is a much better candidate.


        The sash work just set some prebuilt config settings.  We should have
them set for default.  If you want ash to run, I'll do the work, tell me what doesn't 
work.


: I am sure I have had programs with larger data segments that 32K running
: before. It sounds like brk() would not allow the data segment to grow to
: more than 32K. Again, well done. This is a major breakthrough.

        Yes, I said that wrong.  ELKS previously wouldn't allow brk to be > 32k.
large data segments did run.  This is a big breakthrough though, as all sorts
of programs that didn't run will now run.

Greg

Reply via email to