Re: [dev] writing a suckless sed

From: FRIGN <>
Date: Tue, 23 Sep 2014 02:40:27 +0200

On Mon, 22 Sep 2014 16:01:28 -0700
Evan Gates <> wrote:

Hey Evan

> 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.

This is really cool! Implementing sed is far from trivial.

> 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)

You are on a good way, but keep in mind that you shouldn't move too far
away from POSIX.
Added functionality? Why not. But the key here is not to break what
works with strict implementations.

> 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.

I prefer dynamic arrays, but sometimes, being static is the best way
to go. Cases like PATH_MAX show how hard it is to do it most effectively.

> 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)?

glibc's regex-engine is a mess, however, we more and more rely on the
musl libc-regex-implementation, which is really sane.
There's currently no plan to implement a regex-engine, because we don't
suffer from NiH.
After all, Mr. Gates, I hope you aren't a secret spy sent by Microsoft.



Received on Tue Sep 23 2014 - 02:40:27 CEST

This archive was generated by hypermail 2.3.0 : Tue Sep 23 2014 - 02:48:06 CEST