Re: Cleaning up elkscmd and adding help text...any volunteers?

Re: Cleaning up elkscmd and adding help text...any volunteers?

[Juan Perez-Sanchez]

>
> I also got a bug report that the C strlen() implementation in BCC libc is
> wrong (it returns a number 1 too large). Not checked the 8086 asm version.
>
> Alan

I checked the source and found that the assembly version has that bug.
The compiler selects the C version unless the macro __AS386_16__ is
defined (in not).

Juan

Re: Cleaning up elkscmd and adding help text...any volunteers?

[Alan Cox]

> developers that use musl seemed interested in it.  One of them did
> some modifications to it.  You can find the modified version here:
> https://github.com/rofl0r/hardcore-utils
> 
> Might be worth comparing to the current version in Elks to see if any
> of the changes are worth using.
> 
> I've been working on my own version of various core utilities.  Some
> of them are based on the simple Minix utilities (which Elks uses in
> some cases).  Some of them are based on BSD or public domain code.  A
> few, I've written from scratch.  They use ANSI prototypes not K&R in
> most cases.  My goal for this project is to make them as portable as I
> can, so they'll work on POSIX systems or Windows or even DOS.  I have
> the following utilities:

Interesting. We are doing similar things for FUZIX in some cases from
Minix and from ELKS, in other cases from things like V7 and from other
public sources.

In the FUZIX case we also have the challenge of supporting 3 different
compilers (currently), and needing to squash everything into very low
memory footprints (ideally below 32K running) and to try and avoid
floating point.

The FUZIX stuff so far (barring a few more v7 ports) is at 

https://github.com/EtchedPixels/FUZIX/tree/master/Applications

> pretty much in flux.  I'd be interested in sharing code or ideas for
> improvements though.  It would be nice to share some changes rather
> than needing to duplicate effort.

Definitely.

Alan

Re: Cleaning up elkscmd and adding help text...any volunteers?

[LM]

I mentioned the man program in Elks on the musl wiki and some of the
developers that use musl seemed interested in it.  One of them did
some modifications to it.  You can find the modified version here:
https://github.com/rofl0r/hardcore-utils

Might be worth comparing to the current version in Elks to see if any
of the changes are worth using.

I've been working on my own version of various core utilities.  Some
of them are based on the simple Minix utilities (which Elks uses in
some cases).  Some of them are based on BSD or public domain code.  A
few, I've written from scratch.  They use ANSI prototypes not K&R in
most cases.  My goal for this project is to make them as portable as I
can, so they'll work on POSIX systems or Windows or even DOS.  I have
the following utilities:

based on Minix utilities:
cat
ls
du - with modifications for reusable functions for directory traversal
tr
xargs
find

based on obase utilities:
expr

original:
echo
mv

based on NetBSD utlities:
mktemp
tee
test

based on OpenBSD utiltiies:
patch

Others are also in the works and I'm still making improvements to
these when I can.  I also have BSD versions of gzip, libintl and
libiconv.  I've done some work on msh to try to add
internationalization support and minimize/remove the need to use fork.
I haven't officially released anything because everything's still
pretty much in flux.  I'd be interested in sharing code or ideas for
improvements though.  It would be nice to share some changes rather
than needing to duplicate effort.

Sincerely,
Laura

On Wed, Mar 18, 2015 at 8:43 AM, Jody Bruchon <jody@jodybruchon.com> wrote:
> I'm currently spending time cleaning up the elkscmd code base. There's a lot
> that needs to be done.

Re: Cleaning up elkscmd and adding help text...any volunteers?

[Alan Cox]

> We especially need help text because GNU and/or BusyBox commands is what 
> anyone trying ELKS will currently be used to. Users won't know how to 
> use the commands if they don't explain themselves. One example is how 
> the 'dd' ELKS command doesn't support 'conv=' or 'oflag=' while the 
> other two do.


You may also want to look at the V7 and 2.11 BSD releases. The encumbered
Unix licensed bits were freed up by Caldera before they went evil and it
contains a lot of useful stuff although some of it contains PDP11-isms
and a few other traps for the unwary.

Also while I remember, as FUZIX uses some of the same code I've got
ansified versions of certain critical v7 apps done (wumpus, backgammon,
arithmetic, and fish) 8)

I also got a bug report that the C strlen() implementation in BCC libc is
wrong (it returns a number 1 too large). Not checked the 8086 asm version.

Alan

Cleaning up elkscmd and adding help text...any volunteers?

[Jody Bruchon]

Hello all,

I'm currently spending time cleaning up the elkscmd code base. There's a 
lot that needs to be done. A recent example is that the 'dd' command had 
the infrastructure in place that would get the 'count=xxx' value from 
the argument list, then simply did NOTHING with the specified count. I 
have already fixed this bug but it is probably just one of many in the 
elkscmd software collection.

Most of the code in elkscmd components is still K&R C. We've got a 
compiler that is a K&R C compiler but it has an ANSI prototype handler 
that we already use everywhere, so I'd like to see all of the K&R style 
cleared out. You'll probably notice in the recent commit history that 
I've been cleaning up ugly K&R C prototypes and modernizing the overall 
code style. I'm building elkscmd programs with 'gcc -Wall -pedantic' to 
find potential problems to fix and ANSI-fying the code makes GCC happier 
(and looks better!)

One of my current goals is to introduce some simple help text into 
elkscmd applications. I've already written usage help for 'dd' which 
(somewhat tersely) gives the user information on what options are 
available and what the expected command arguments are. The ELKS kernel 
is reasonably stable, but basic commands are a pain to use.

We especially need help text because GNU and/or BusyBox commands is what 
anyone trying ELKS will currently be used to. Users won't know how to 
use the commands if they don't explain themselves. One example is how 
the 'dd' ELKS command doesn't support 'conv=' or 'oflag=' while the 
other two do.

If anyone wants to add help text to elkscmd components, feel free to do 
so and send me some patches. My expectations are as follows:

* If main() doesn't have a return or exit() at the end, add one, and be 
sure that the main() function is specified as 'int main' rather than 
'void main' (all programs should return zero on success, so main() must 
never be a void function.)

* If argument parsing is done in main() I expect the use of 'goto usage' 
for all points where the help text should be displayed. A 'usage:' label 
should be placed AFTER the return or exit() statement at the end of 
main() instead of creating a separate usage() function when possible. 
Every added function and function call increases binary size, so avoid 
adding functions unless they introduce a net decrease in size or overall 
complexity. See my changes to elkscmd/file_utils/dd.c if you need an 
example.

* Regarding use of 'goto' statements in general: they may only be 
forward-jumping. Don't write a usage section somewhere near (for 
example) the top of main() and have future code 'goto' that place.

* If usage needs to be shown from places other than main(), write a 
usage() function that does exit(1) at the end and call that...but see if 
you can have the function(s) propagate error codes back to the 
originating code in main() instead, which is usually a better choice and 
avoids adding a new function.

* You don't have to clean up the K&R C prototyping since removing it 
sometimes requires shuffling functions around; I'll clean it out 
eventually. If you DO want to clean up prototypes, make sure they 
compile correctly before sending me a patch.

* You can use GCC to error check most of the simpler programs and build 
a native binary that'll run on your own system by running i.e. 'gcc 
-Wall -pedantic dd.c -o dd' GCC has way better diagnostics than bcc, 
especially the GCC 5 snapshots which have colorized diagnostic output. 
Many problems that are missed by bcc get caught by GCC and make a lot of 
noise. (GCC can't be used for ELKS-only programs like ktcp though.)

-Jody