midfavila/sbase
1
0
Fork 0
Code Issues Pull Requests Projects Releases 1 Wiki Activity
27656a0cbc
sbase/README

122 lines
5.6 KiB
Plaintext
Raw Normal View History

Add initial README
2014-02-12 09:34:09 -05:00
sbase - suckless unix tools
===========================
sbase is a collection of unix tools that are inherently portable
across UNIX and UNIX-like systems.
Add column to mark UTF-8 support One major milestone is to have the sbase-tools supporting UTF-8. Tools like cut(1) with the -n flag don't make sense otherwise. And while the gnu coreutils cut(1) blatantly ignores such an important aspect, we will not tolerate this madness and mark it as a TODO in the main README. Since most tools inherently support UTF-8 anyway, this just concerns tools which mangle with text or search in it in special ways.
2015-01-18 13:36:13 -05:00
The following tools are implemented ('*' == finished, '#' == UTF-8 support,
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
'=' == implicit UTF-8 support, '|' == audited):
Add an easier to edit "table" of tools in README We need to go through the tools and update this table to reflect current state.
2014-11-20 18:01:56 -05:00
Audit basename(1) 1) be stricter which number of arguments is accepted (1 or 2) 2) basename already returns a pointer to "." is argv[0] is "" 3) No need to check for *p != '/', because basename() only returns a string beginning with '/' which has length 1, so if strlen(p) == 1, the only way for suffix to be "evaluated" is for off to be > 0, being equal to suffix being "", but "" != "/". 4) don't calculate strlen twice for each string. Store it in a ssize_t and check if it's > 0.
2015-02-28 08:48:44 -05:00
UTILITY POSIX 2008 COMPLIANT MISSING OPTIONS
------- -------------------- ---------------
=*| basename yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* cal yes none
Audit cat(1) 1) Fix usage ... spacing 2) use *argv instead of argv[0] in the idiomatic for-loop 3) Stop the naïve usage of "/dev/fd/0" and use plain stdin instead (This also makes error-messages more consistent). 4) Add newline before return 5) Remove comma in manpage
2015-03-01 18:36:51 -05:00
=*| cat yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* chgrp yes none
=* chmod yes none
=* chown yes none
=* chroot non-posix none
=* cksum yes none
=* cmp yes none
#* cols non-posix none
=* comm yes none
= cp yes none (-i)
=* cron non-posix none
#* cut yes none
=* date yes -u
Audit dirname(1) Be stricter about the number of arguments passed to it.
2015-02-28 13:50:12 -05:00
=*| dirname yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* du yes none
Audit echo(1) Just a small change in the manpage.
2015-02-28 14:16:10 -05:00
=*| echo yes none
Audit env(1) 1) Shorten synopsis and reflect this in the manual 2) Use argv0 in usage() 3) Decrement argc in argv-loop for consistency 4) Make it clearer which error-code results from which errno in enprintf 5) Use idiomatic for-loop also for environ. Don't increment these pointers in the loop itself!
2015-03-02 08:50:43 -05:00
=*| env yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
#* expand yes none
#* expr yes none
Mark false(1) and true(1) as audited Nothing to be done there.
2015-02-28 09:12:19 -05:00
=*| false yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
= find yes none
#* fold yes none
=* grep yes none
=* head yes none
Audit hostname(1) 1) Be strict about argc 2) Fix a small error in the manpage
2015-02-28 15:22:55 -05:00
=*| hostname non-posix none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* kill yes none
Audit link(1)
2015-02-28 13:42:26 -05:00
=*| link yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* ln yes none
=* logger yes none
=* logname yes none
= ls no (-C), -S, -f, -m, -s, -x
Update *sum(1)-manpages and mark them as finished and audited Now that -c behaves correctly, the tools are pretty much done. Only the manpages were not clear enough what happens when you specify the c-flag. This is fixed now.
2015-03-01 16:59:20 -05:00
=*| md5sum non-posix none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* mkdir yes none
=* mkfifo yes none
=* mktemp non-posix none
=* mv yes none (-i)
=* nice yes none
= nl no -d, -f, -h, -l, -p
=* nohup yes none
#* paste yes none
Audit printenv(1) 1) argc style 2) safeguard argv-loop as already seen in echo(1) with argc-decrement.
2015-02-28 15:47:17 -05:00
=*| printenv non-posix none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
#* printf yes none
=* pwd yes none
= readlink non-posix none
=* renice yes none
Audit rm(1) 1) One small argc-style-matter 2) manpage cleanup 3) NOTE: The utility-functions will be evaluated separately.
2015-02-28 15:30:20 -05:00
=*| rm yes none (-i)
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* rmdir yes none
# sed
seq non-posix none
Audit setsid(1) Nothing special, just a small style-fix.
2015-03-01 18:20:35 -05:00
=*| setsid non-posix none
Update *sum(1)-manpages and mark them as finished and audited Now that -c behaves correctly, the tools are pretty much done. Only the manpages were not clear enough what happens when you specify the c-flag. This is fixed now.
2015-03-01 16:59:20 -05:00
=*| sha1sum non-posix none
=*| sha256sum non-posix none
=*| sha512sum non-posix none
Audit sleep(1) 1) Be strict about argc 2) Use "unsigned" instead of "unsigned int"
2015-02-28 14:10:25 -05:00
=*| sleep yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
sort no -m, -o, -d, -f, -i
=* split yes none
Audit sponge(1) Just a little usage()-fix. Mark it as audited in README.
2015-03-01 17:42:16 -05:00
=*| sponge non-posix none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
#* strings yes none
=* sync non-posix none
=* tail yes none
=* tar non-posix none
=* tee yes none
=* test yes none
Update README for time(1)
2015-02-28 09:42:11 -05:00
= time yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* touch yes none
#* tr yes none
Mark false(1) and true(1) as audited Nothing to be done there.
2015-02-28 09:12:19 -05:00
=*| true yes none
Audit tty(1) 1) Be strict about number of arguments passed 2) Use a simpler logic while returning
2015-02-28 13:59:34 -05:00
=*| tty yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* uname yes none
#* unexpand yes none
=* uniq yes none
Audit unlink(1) One small thing, use argv0 in usage. Also, add a blank line in link.c which I forgot earlier.
2015-02-28 14:05:22 -05:00
=*| unlink yes none
Add audit-section to README Okay, so why another section? The finished-section applies to general feature-completeness and manual status. It somehow is not an indicator for general code- clarity, so the audited-column reflects a thorough audit of the underlying code and optimization. Take a look at the upcoming basename(1)-patch for an example on how this goes.
2015-02-28 08:42:26 -05:00
=* uudecode yes none
=* uuencode yes none
#* wc yes none
= xargs no -I, -L, -p, -s, -t, -x
Mark yes(1) as audited in README
2015-02-28 15:12:27 -05:00
=*| yes non-posix none
Add an easier to edit "table" of tools in README We need to go through the tools and update this table to reflect current state.
2014-11-20 18:01:56 -05:00
Minor fix for README
2014-02-12 13:39:13 -05:00
The complement of sbase is ubase[1] which is Linux-specific and
Add initial README
2014-02-12 09:34:09 -05:00
provides all the non-portable tools. Together they are intended to
form a base system similar to busybox but much smaller and suckless.
Building
--------
To build sbase, simply type make. You may have to fiddle with
config.mk depending on your system.
You can also build sbase-box, which generates a single binary
containing all the required tools. You can then symlink the
README: document sbase-box-install rule
2015-02-28 09:40:16 -05:00
individual tools to sbase-box or run: make sbase-box-install
Add initial README
2014-02-12 09:34:09 -05:00
Ideally you will want to statically link sbase. If you are on Linux
we recommend using musl-libc[2].
Portability
-----------
sbase has been compiled on a variety of different operating systems,
including Linux, *BSD, OSX, Haiku, Solaris, SCO OpenServer and others.
Various combinations of operating systems and architectures have also
been built.
You can build sbase with gcc, clang, tcc, nwcc and pcc.
[1] http://git.suckless.org/ubase/
[2] http://www.musl-libc.org/
Reference in New Issue Copy Permalink