Make editors slightly moist
--Donald E. Knuth, «The TeXbook»
There is no easy walk to freedom anywhere, and many of us will have to pass through the valley of the shadow of death again and again before we reach the mountaintop of our desires.
--Nelson Mandela
git://git.code.sf.net/p/s-nail/code
{*master*, next, [heirloom]}
S-nail is a mail processing system, which has a command syntax reminiscent of
ed(1) with lines replaced by messages.
It is based on Heirloom mailx that is based upon Berkeley Mail 8.1, is
intended to provide the functionality of the POSIX mailx(1) command,
and offers extensions for MIME, IDNA, IMAP, POP3, SMTP and S/MIME,
most of which being compile-time options.
S-nail provides enhanced features for interactive use.
It is also usable as a mail batch language, both for sending and receiving
mail.
... read the complete manual.
git://git.code.sf.net/p/s-web42/code
{*master*, next}
One more option to manage your website. A camel approach to website building. ∞ vim(1) and it actually generated what you are looking at. ... read the complete documentation.
git://git.code.sf.net/p/ssymobj/code
{*master*}
Throw an eye on my Symbol table and Object ∞ perl(1) module, it offers a somewhat easy symbol table and object creation/management. ... read the complete PODocumentation.
I'm using ∞ perl(1) since 1997 in many projects and for a lot of purposes. In all that time i haven't found a single bug! Hoooray and thanks, ∞ perl(1) porters!
git://git.code.sf.net/p/s-ctext/code
{*master*, next}
Unix / POSIX continues to be byte-based, slowly drifting towards the
byte-based UTF-8 multibyte character set.
But the C and POSIX standards don't offer any option to work on multibyte
character data except by first converting it into wide character strings.
This means that expensive and most often completely redundant round-trip
conversions are necessary, even for the most simple tasks.
Furthermore, ∞ Unicode defines multi-codepoint characters -- characters that are composed out of multiple codepoints, so-called graphems (see ∞ Unicode Text Segmentation), many of which don't have a precomposed single-codepoint representation. Neither ISO C nor POSIX define an interface that can deal with these sequences-of-codepoints that form a single character.
S-CText provides a programming interface that addresses these problems. It offers sets of string functions which deal with (possible) multibyte strings in the encoding of the / a LC_CTYPE locale (sct_ prefix function family) as well as with UTF-8 encoded strings (sut_ prefix function family). In addition the internal representation of the Unicode character database can be accessed (sud_ prefix function family).
Expect a first usable, at least beta quality version during this summer.
git://git.code.sf.net/p/s-musicbox/code
{*master*}A complete rewrite of our internal rather shitty jukebox, that managed to encapsulate HTML interface, CGI server side (TCP server using MPG321 remote control for playback), ripping (split on CDROM size boundaries with best fit, and that was the best feature of it) in a single script. It only supported MP3 (lame(1), that is). It ran (and still runs) on Linux and FreeBSD. It's database (using a lout-style trigger followed by a content line) did not store much information about recordings:
# @ARTIST NL # NAME TAB [COMMENT] NL # @ALBUM NL # ARTIST TAB ALBUM TAB CDID TAB NOOFTRACKS(integer) TAB -> # [PLAYTIME(0000:00.00 string..)] TAB [COMMENT] NL # @SONG NL # ARTIST TAB [ALBUM] TAB SONG TAB TRACKNO(integer) -> # [PLAYTIME(0000:00.00 string)] TAB [GENRE] TAB [COMMENT] NL # @FILE NL # ARTIST TAB [ALBUM] TAB SONG TAB PATH NL # @PLAYLIST NL # COUNT TAB ARTIST TAB [ALBUM] TAB SONG NL
Yes, it's really, really odd, but remember it was indeed FILE based and splitted on CDROM size boundaries, so that each CDROM's database had to contain all the information of all files on it. The final database could be gained by cat(1)ing all those together, redundant entries would be removed upon load ...
So it becomes obvious why i actually wanted to have a new musicbox with a more sophisticated database, one that is capable to deal with the odds of classical music. Well, i did and re-ripped all my CDs with the s-disc-ripper.pl script, which is yet the only ready component of S-Musicbox. It's CDInfo:: class, the one that is responsible for actual CDROM detection and ripping, supports only Mac OS X at the moment, however. It is pretty easy to extend, though. And the s-disc-ripper.pl is a rather mature program, that i like.
Since the beginning of november 2011 i am the maintainer of the german translations of the ∞ OpenBSD website, and since 2012-01-22 those pages are in sync again.
I hope i can realize and afford it to provide a uniform style through all pages until the release of OpenBSD 5.7. See DEification for a wordlist of changes that have been applied to [de], or will be applied to it in the future.
Unfortunately i had to drop my anti-german-language-reform attitude after one and a half decade for this maintainership (and only for it), so this reveals that the first paragraph of my homepage is actually a lie. But hey, do you know what: this standard committee currently is and furthermore always was deeply broken! You possibly don't want to see ∞ a photo of the current chairman. But anyway, it's official german, now. (Sob.)
I also did my part to maintain the ∞ daily changelog from the beginning of november 2011 until the end of june 2012; being part of a team that was formed out of the australian-based male Alpha Centaurian Brett Mahar (brett@), the swedish sweetheart Janne Johannson (jj@) and the flying german unionist Ingo Schwarze (schwarze@; all [openbsd DOT org]).
So i finally contribute(d) a little bit to the ∞ OpenBSD and ∞ OpenSSH projects, just as i'd promised in 2001 (that could also have been 2002).
git://git.code.sf.net/p/s-toolbox/code
{*master*}
The README as of 2013-05-07:
A repo of some small tools
==========================
uushar:
Writes a sh(1) shell script to the standard output which will
recreate the file hierarchy specified by the command line operands.
Directories will be recreated and must be specified before the files
they contain. Compared to the well-known shar(1) program, uushar
adds optional compression and an uuencode(1)/uudecode(1) binary
safe layer::
$ uushar [--(compress|gzip|bzip2|xz)] file ...
It is easy to insert trojan horses into uushar files. It is thus
strongly recommended that all shell archive files be examined before
running them through sh(1). Archives produced using this
implementation of uushar may be easily examined with the command::
$ grep '^[^X#]' shar.file
Note that the uudecode(1) program must be capable of decoding to
/dev/stdout, i.e., it must be POSIX compliant (Issue 6 iirc).
gen-uushar-wrapper:
Creates a shell archive similar to uushar as above, except that the
archive (1) consists only of executable file members, and (2) will
be itself executable. Run it (the generated shell archive script)
to invoke any of the programs contained therein. On the first run,
the wrapper will create a hidden directory in your $TMPDIR to unpack
the archive members therein. (Run without arguments to show its
contents and the creation date.)
Note that the uudecode(1) program must be capable of decoding to
/dev/stdout, i.e., it must be POSIX compliant (Issue 6 iirc).
real-periodic.sh:
A *real* periodic for FreeBSD, NetBSD and OpenBSD that ensures that
the daily/weekly/monthly maintenance stuff is executed, even if
your laptop is running only one hour a day. Invoke this once per
hour in the roots crontab and disable the usual periodic stuff of
your system instead. E.g., on my NetBSD 6.0 box (lines wrapped)::
# do daily/weekly/monthly maintenance
15 * * * * /usr/bin/nice -n 15 /usr/libexec/real-periodic.sh
#15 3 * * * /bin/sh /etc/daily 2>&1 | \
tee /var/log/daily.out | sendmail -t
#30 4 * * 6 /bin/sh /etc/weekly 2>&1 | \
tee /var/log/weekly.out | sendmail -t
#30 5 1 * * /bin/sh /etc/monthly 2>&1 | \
tee /var/log/monthly.out | sendmail -t
git-topic-creator.pl:
To ease maintaining of topic branches i use a linear history, so
that i can use ``$ git rebase -i`` for fixups and squashes, without
having to worry about recreation of topic branches. Instead i tag
commit messages, and use this script to create the topics once i'm
finished. Read the --help output for more, and make use of verbosity
when you use it first.
git-pre-commit.sh:
git(1)'s diff --check does unfortunately not offer a mode which
detects NBSP (non-breaking space, U+00A0) characters.
This is a real problem for keyboards (layouts) which produce combined
sequences, i.e., the german keyboard produces NBSP for ALT+SPC, but
it also requires ALT to get any of []|{} (ALT+[5-9]). So NBSPs
happen. This script can be used as (a template for a custom)
pre-commit hook, especially since i've looked at it, 2013-02-11 ,
It also handles non-space indentations, tabulators and mixed indents,
dependent on the environment variables NSPACEINDENT, TABINDENT and
MIXINDENT. E.g., this is one of my pre-commit hooks::
#!/bin/sh -
NSPACEINDENT=1 TABINDENT=1
export NSPACEINDENT TABINDENT
exec "$HOME/usr/bin/git-pre-commit.sh" "$@"
s-ws-check.pl:
Check indentation, trailing whitespace and non-breaking spaces (see
git-pre-commit.sh above) for all files given on the command line.
Sufficient for a needed quick-n-dirty check of some random file;
especially since i've looked at it, 2013-02-11 ,
arena-manager:
Offers some automatized operations on revision control repositories,
like updating, (fast-forward) merging, garbage-collecting.
s-base64.c:
Encode to/decode from Base64 content-transfer-encoding, as specified
in RFC 2045, section 6.8.
s-idn.c:
Simple GNU Libidn based thing that encodes and decodes IDNs.
Rather identical to the idn utility that comes with that one, but
i needed to get comfortable with Libidn and so i've wrote it.
Even less of widespread usability:
showkey.c:
Show keyboard scancodes for FreeBSD, OpenBSD, NetBSD and Linux.
This is not yet finished but for Linux. But it should help to get
you going. (Unfortunately the BSDs are not so documented and i
need to dig into the kernel sources to implement the missing pieces.)
backup.pl:
My private backup script. Simple (uses tar(1)), but does some stuff
which i need for my work flow (backups data which is in local repo
clones but not yet pushed to their "real" counterparts).
super-shutdown.c:
Single setuid root BSD program to invoke /sbin/shutdown(8), either
to reboot or to halt the system.
You've been warned.
cdoc-freebsd.S:
FreeBSD 5.3 x86 prog to open/close /dev/cdrom tray. May work on
newer ones, but haven't tried it in a while. It had 416 object
file bytes when everything was placed in ``.text`` (no .EH frames
back then).
openbsd-changelog-plus.pl,
openbsd-changeset-plus.pl:
Simple scripts to ease maintaining of OpenBSD plus.html entries.
git://git.code.sf.net/p/spostman/code
{*master*, next}This script is in daily use for SSL-secured POP3 download since mid 2011, but it is incomplete and stale. Please see its README first! ... read the complete documentation.
An unsophisticated end-user mail fetcher, processor and sender; it's easy configurable and offers a pretty good rule matching engine. This application has been written in ∞ Python.
In january 2011 this very project caused me to try Payprout 3000. Since then i stumbled over the discovery of dozens of bugs (in the standard library) and even got involved a little bit on ∞ their bug tracker. Payprout? Yes! (The details perhaps had had a negative influence on the emotional well-being of at least one of the mentioned characters.)
Well, it turns out that i curse the day when i decided that it try Python for this. The basic idea was that a Python installation always ships with the standard library, and that was supposed to already include most things ever needed. But if this projects takes that much longer there will not remain that many stdlib modules being used in the end.
If you want to get more than you ever need, then i would point you to ∞ fdm(1) instead; that is a fully blown, mature program and not a small portable script (though).
git://git.code.sf.net/p/s-xs/code
{*master*, next}
The basic library of my S programming framework. It encapsulates almost all CPU and OS dependencies under its generic interface.
This will in fact be my free clone of my (our) internal non-free C++ library; different to that with full Unicode support, however. It will also be possible to use that as a normal library, whereas the C++ version does not link against any libraries and ships it's own threading module. That however implies that there will be speed impacts, because then the extremely time critical s_thr_self() function will depend on some system thread-library provided thing etc. The situation is somewhat better on platforms with ELF TLS, but still worse than a fast manual driven thread-local storage (though completely automatic, on the other hand). And then of course: signals. As if that wouldn't be hard enough in a monolithic situation, only interacting with the OS. Horror in the pipeline!
It's pretty large so that i need at least until 2018 to port it:
$ du -s cvsroot/cpp-sys 5460 cvsroot/cpp-sys
git://git.code.sf.net/p/s-xc/code
{*master*, next}
S library for (basic) console screen management. This is my free clone of my (our) internal non-free C++ library, which is conversely called Terminal. Different to that with full Unicode support.
It is already finished in theory, but since it requires the S-XSystem library it will take some years until it is really usable. At that time it will be clear wether it runs in practice, too. :-). (P.S.: this simple minded port would not really work with real Unicode characters but only with single Unicode codepoints. The README file talks a bit about that.)
It'll be extended once a normal development cycle is possible: there will be (non-overlapping) windows, a single-line-only mode will perhaps be implemented. The drawing mechanism can be improved in respect to performance. And a termcap interface would be a win, too. (I.e., dynamically extending the static builtin database of supported terminals.)
I love C, ∞ perl(1) and dig plain old sh(1) more and more. I've discovered ∞ mksh(1) and use it exclusively on all my boxes for quite some time now. Since about year 2000 i'm a fanatic fan (though not a sophisticated user) of ∞ vim(1). It gave up in an endless loop once.
When on X(1) i'm running the fantastic ∞ ahwm(1) window manager, and i do so almost as long as i use ∞ vim(1). For years my terminal emulator was ∞ aterm(1), but now i've switched to ∞ rxvt-unicode -- that not only supports ∞ Unicode, but also offers a "server" that manages all the windows, which saves a lot of memory. (On NetBSD 6.0 X, however, one must compile a version from before May or so 2012, since otherwise xfs support will not work.) For browsing there is ∞ elinks(1) (rather seldom) and ∞ Opera.
I'm thankful for being able to use ∞ git(1) for version control today, after a lot of distress with other VCSs. And i'm also thankful for being able to use virtual machines via ∞ QEMU and ∞ VirtualBox; it is so handy to have a bunch of operating systems at hand for immediate testing, just as necessary!
I've used ∞ FreeBSD for about ten years, and it made me free. Today i'm working with ∞ Apple hardware, and i love to use ∞ NetBSD, because it offers a lot of nice stuff for people that are willing to dig -- just take netpgp(1); unfortunately the community doesn't like me :(. While looking around for ∞ Unicode aware software i have been pointed to the ∞ Plan9 from Bell Labs operating system and its ∞ Plan9front successor, which appear to follow a fascinating "real UNIX -- everything is a file" design.
Copyright (c) 1997 - 2013, Steffen "Daode" Nurpmeso <sdaoden@users.sf.net>
@(#)code.html-w42 1.94 2013/05/07T21:14:34+0000