fbt/sbase
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
Files
3e160b616a183798e3dba34b93651a27851b1886
sbase/README

145 lines
3.7 KiB
Plaintext
Raw Normal View History

Add initial README
2014-02-12 14:34:09 +00:00
sbase - suckless unix tools
===========================
Don't justify text in README
2019-06-30 13:17:17 -07:00
sbase is a collection of unix tools that are inherently portable across
UNIX and UNIX-like systems.
Add initial README
2014-02-12 14:34:09 +00:00
Don't justify text in README
2019-06-30 13:17:17 -07:00
The complement of sbase is ubase[1] which is Linux-specific and provides
all the non-portable tools. Together they are intended to form a base
system similar to busybox but much smaller and suckless.
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
Building
--------
Don't justify text in README
2019-06-30 13:17:17 -07:00
To build sbase, simply type make. You may have to fiddle with config.mk
depending on your system.
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
Don't justify text in README
2019-06-30 13:17:17 -07:00
You can also build sbase-box, which generates a single binary containing
all the required tools. You can then symlink the individual tools to
sbase-box or run: make sbase-box-install
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
Don't justify text in README
2019-06-30 13:17:17 -07:00
Ideally you will want to statically link sbase. If you are on Linux we
recommend using musl-libc[2].
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
Portability
-----------
Don't justify text in README
2019-06-30 13:17:17 -07:00
sbase has been compiled on a variety of different operating systems,
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
including Linux, *BSD, OSX, Haiku, Solaris, SCO OpenServer and others.
Don't justify text in README
2019-06-30 13:17:17 -07:00
Various combinations of operating systems and architectures have also
Move utility status to its own section at the end of README This way the important information can be found easily at the top.
2019-06-30 13:13:07 -07:00
been built.
You can build sbase with gcc, clang, tcc, nwcc and pcc.
Status
------
Prepare POSIX 2013 audit I can't believe we've come this far! The idea is to look at the 2013 POSIX corrigendum for each tool and deep-test features before making the first 0.1 release. To keep the noise low, I'll do this in batches, not on a per-tool- basis (as many of these are trivial to test). In the meantime, I'll also think of a fitting STANDARDS section for the non-POSIX tools. Now that the audits are pretty much done, I can also have a more relaxed view on standards compliance instead of having to dig through some uncleaned mess. To mark this "new beginning", the README has gotten a liftover. The POSIX 2008-column was more or less useless and as I expect the checks to go along pretty quickly, I "reset" the compliance state of all but the non-POSIX tools and will then go along and check every single one of them in the next few days. Apart from the few missing flags and audits, sbase should then be ready to hit the world with the first release after 4 years of work.
2015-03-23 16:22:00 +01:00
The following tools are implemented:
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 23:01:56 +00:00
Prepare POSIX 2013 audit I can't believe we've come this far! The idea is to look at the 2013 POSIX corrigendum for each tool and deep-test features before making the first 0.1 release. To keep the noise low, I'll do this in batches, not on a per-tool- basis (as many of these are trivial to test). In the meantime, I'll also think of a fitting STANDARDS section for the non-POSIX tools. Now that the audits are pretty much done, I can also have a more relaxed view on standards compliance instead of having to dig through some uncleaned mess. To mark this "new beginning", the README has gotten a liftover. The POSIX 2008-column was more or less useless and as I expect the checks to go along pretty quickly, I "reset" the compliance state of all but the non-POSIX tools and will then go along and check every single one of them in the next few days. Apart from the few missing flags and audits, sbase should then be ready to hit the world with the first release after 4 years of work.
2015-03-23 16:22:00 +01:00
'#' -> UTF-8 support, '=' -> Implicit UTF-8 support, '*' -> Finished,
'|' -> Audited, 'o' -> POSIX 2013 compliant, 'x' -> Non-POSIX,
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
'0' -> NUL handling, '()' -> Petty flag
Prepare POSIX 2013 audit I can't believe we've come this far! The idea is to look at the 2013 POSIX corrigendum for each tool and deep-test features before making the first 0.1 release. To keep the noise low, I'll do this in batches, not on a per-tool- basis (as many of these are trivial to test). In the meantime, I'll also think of a fitting STANDARDS section for the non-POSIX tools. Now that the audits are pretty much done, I can also have a more relaxed view on standards compliance instead of having to dig through some uncleaned mess. To mark this "new beginning", the README has gotten a liftover. The POSIX 2008-column was more or less useless and as I expect the checks to go along pretty quickly, I "reset" the compliance state of all but the non-POSIX tools and will then go along and check every single one of them in the next few days. Apart from the few missing flags and audits, sbase should then be ready to hit the world with the first release after 4 years of work.
2015-03-23 16:22:00 +01:00
Indent README headings properly
2016-03-07 10:50:29 +01:00
UTILITY MISSING
------- -------
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o basename .
0=*|o cal .
0=*|o cat .
0=*|o chgrp .
0=*|o chmod .
0=*|o chown .
0=*|x chroot .
0=*|o cksum .
0=*|o cmp .
Use the UTF8_POINT macro in cols(1) No need for libutf any more
2016-03-07 20:56:15 +01:00
0#*|x cols .
Support NUL containing lines in comm(1)
2016-03-07 01:42:01 +01:00
0=*|o comm .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o cp (-i)
0=*|x cron .
Support NUL containing lines in cut(1)
2016-03-07 12:34:41 +01:00
0#*|o cut .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o date .
0=*|o dirname .
0=*|o du .
0=*|o echo .
o ed .
0=*|o env .
0#*|o expand .
0#*|o expr .
0=*|o false .
0= find .
0=* x flock .
Support NUL containing lines in fold(1) and reuse the line-buffer(!)
2016-03-09 12:38:44 +01:00
0#*|o fold .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o getconf (-v)
=*|o grep .
Support NUL containing lines in head(1) Very trivial this time.
2016-03-07 10:48:17 +01:00
0=*|o head .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|x hostname .
0=*|x install .
Support NUL containing lines in join(1) while also simplyfing the line-field-parser.
2016-03-09 15:56:59 +01:00
0=* o join .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o kill .
0=*|o link .
0=*|o ln .
logger(1) is NUL compliant because we can't call the syslog-syscall without becoming unportable. The syslog() libc-function does not accept a length though, so we're fucked. Anyway, let's carry on.
2016-03-07 22:00:27 +01:00
0=*|o logger .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o logname .
0#* o ls (-C, -k, -m, -p, -s, -x)
0=*|x md5sum .
0=*|o mkdir .
0=*|o mkfifo .
Import mknod from ubase Although mknod is not a POSIX tool, it is widely available on nearly all UNIX-like systems. It also can be implemented portably apart from use of the makedev macros, which is already a requirement of a couple other tools in sbase. While we're at it, fix a few bugs: - Include sys/sysmacros.h if makedev was not defined by sys/types.h - The default mode should respect the user's umask, rather than assuming it is 022. - Clear the umask when -m is specified explicitly so that nodes can be created with permissions wider than the user's umask. - Utilize parsemode from libutil to support symbolic mode strings.
2020-03-01 15:58:37 -08:00
0=*|x mknod .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|x mktemp .
0=*|o mv (-i)
0=*|o nice .
Support NUL containing lines in nl(1) and reuse the line-buffer(!)
2016-03-10 05:40:34 +01:00
0#*|o nl .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o nohup .
0=*|o od .
0#* o pathchk .
#*|o paste .
0=*|x printenv .
0#*|o printf .
0=*|o pwd .
0=*|x readlink .
0=*|o renice .
Add rev(1) Signed-off-by: Mattias Andrée <maandree@kth.se>
2016-03-26 17:23:03 +01:00
0#* x rev .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o rm (-i)
0=*|o rmdir .
# sed .
0=*|x seq .
0=*|x setsid .
0=*|x sha1sum .
0=* x sha224sum .
0=*|x sha256sum .
0=* x sha238sum .
0=*|x sha512sum .
0=* x sha512-224sum .
0=* x sha512-256sum .
0=*|o sleep .
Support NUL-containing lines in sort(1) For sort(1) we need memmem(), which I imported from OpenBSD. Inside sort(1), the changes involved working with the explicit lengths given by getlines() earlier and rewriting some of the functions. Now we can handle NUL-characters in the input just fine.
2016-02-29 00:47:10 +01:00
0#*|o sort .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o split .
0=*|x sponge .
0#*|o strings .
0=*|x sync .
Support NUL containing lines in tail(1) This was rather simple this time.
2016-03-07 10:20:40 +01:00
0=*|o tail .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|x tar .
0=*|o tee .
0=*|o test .
0=*|x tftp .
0=*|o time .
0=*|o touch .
0#*|o tr .
0=*|o true .
0=* o tsort .
0=*|o tty .
0=*|o uname .
0#*|o unexpand .
Support NUL containing lines in uniq(1)
2016-03-10 07:02:04 +01:00
0=*|o uniq .
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|o unlink .
0=*|o uudecode .
0=*|o uuencode .
0#*|o wc .
0=*|x which .
0=*|x whoami .
xargs(1) already supports NUL characters
2016-03-10 07:05:36 +01:00
0=*|o xargs (-p)
Add symbol to mark NUL handling in each tool (and where it is missing) The assumption of NUL-terminated strings is actually quite a good one in most cases. You don't have to worry about paths, because they may not contain NUL. Same applies to arguments passed to you. Unless you have to unescape, there is no way for you to receive a NUL. There are two important exceptions though, and it's important that we address them, or else we get unexpected behaviour: 1) All tools using unescape() have to be strict about delimlen. Else they end up for instance unescaping '\\0abc' to '\0abc', which in C's string-vision is an empty string. 2) All tools doing line wrenching and putting them out again as lines again. puts() will cut each line containing NULs off at the first occurence.
2016-02-26 00:36:53 +01:00
0=*|x yes .
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 23:01:56 +00:00
Add initial README
2014-02-12 14:34:09 +00:00
[1] http://git.suckless.org/ubase/
[2] http://www.musl-libc.org/
Reference in New Issue Copy Permalink