Hello suckless,
I somewhat recently wrote my own sed[0]. It was mostly for fun and to
check sed scripts for strict POSIX compliance. Seeing as it was a
first attempt and enforced some horrendous POSIX requirements my sed
sucks more. A lot more.
Moving forward I plan on rewriting it now that I have a better idea of
what to expect. This time I want my sed to suck less, both in feature
set and implementation so that we can have a suckless sed (possibly as
part of sbase). As such I would like to ask the community what would
make sed suck less? As a start I would assume:
- UTF-8 aware
- support for longer labels, file names, and lines
- use of semicolons after labels, file names, and inside {}
(disallowed by POSIX)
One thing I'm not clear on, in your opinion does suckless software use
fixed or dynamic sized buffers/stacks? i.e. should it support
arbitrarily long lines? depth of nested blocks? number of write files?
I've seen some of both in software that seems suckless.
And lastly, somewhat off topic, is there a plan for a suckless regex
engine to use in sbase? Or will it continue to rely upon the libc's
engine (which causes different results on different systems)?
-emg
[0]
https://bitbucket.org/emg/sed
Received on Tue Sep 23 2014 - 01:01:28 CEST