The one specified by mdoc is hard to read for non-native
speakers from countries which read the date day-first (like
Germany, Greece, North-Korea, Swamp,...).
This is also consistent with how we generally specify dates
at suckless.org.
Mostly manpage-shuffling according to the changes in the corrigendum,
wording changes and more idiomatic expressions.
All this is finished up by marking the POSIX 2013 conformant tools
with
.St -p1003.1-2013
which is not available in older mandoc builds or nroff, but which
reflects what we actually did, so who cares?
This is a huge step and it's not far until we can release sbase 0.1.
- add .Os, it is mandatory.
- don't redeclare .Nm when it's not needed.
- fix some warnings (checked with mandoc -Tlint).
- remove some leftover old stuff.
Having multibyte delimiters is not enough. For full flexibility,
the possiblity of cutting input lines with arbitrary length delimiters
is the real deal.
Given this functionality, it only sounds reasonable to also add support
to resolve escapes.
Thanks to Truls Becken for making the suggestion and designing such a
flexible cut(1)-implementation!
Now you can specify a multibyte-delimiter to cut, which should
definitely be possible for the end-user (Fuck POSIX).
Looking at GNU/coreutils' cut(1)[0], which basically ignores the difference
between characters and bytes, the -n-option and which is bloated as hell,
one has to wonder why they are still default. This is insane!
Things like this personally keep me motivated to make sbase better
every day.
[0]: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=HEAD
NSFW! You have been warned.
