sbase

[Connor Lane Smith]

Hey all,

I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.
Some of us seem to be resorting to using those from Plan 9, which were
designed for another operating system and exist on Unix through a
compatibility shim.

So, in a glorious demonstration of NIH syndrome, let's make our own!
I'm unsure exactly which utilities we should include (suggestions on a
comprehensive set?), but in terms of functionality a good rule of
thumb is to only include flags present in both POSIX and Plan 9, thus
making a sweet little subset. There are exceptions to this, like grep
-q and ls -a, but it's a useful guideline.

I've written a handful so far (basename, cat, echo, false, grep, tee,
touch, true, wc), which I've attached. Each tool is between 6 and 88
SLOC, and compiles with musl into a static binary between 13K and 45K
in size. The manual pages are nice and short, too.

If anyone else wants to contribute a tool written in the same style
they are most welcome. I'd like to set up an hg repo soon, but I'm
quite busy with exams atm.

Thanks,
cls

[Bryan Bennett]

I would suggest first re-writing the ones that 9Base has listed. It seems
a relatively exhaustive list and - with our case of NIH - we don't want to
be using anything from another OS entirely, now do we ;)

I'm pretty excited by this proposition. The idea seems pretty good.

[Jens Staal]

If you want to replace stuff in a standard distribution with something
else I guess it should have the same features as the thing you are
replacing (except for the redundant and/or un-needed ones)

For fun, I have been trying to replace GNU with

Busybox: https://wiki.archlinux.org/index.php/Base2busybox

Heirloom: https://wiki.archlinux.org/index.php/Base2heirloom

Plan9port: https://wiki.archlinux.org/index.php/Base2plan9

in Arch. Stuff work surprisingly well when central parts of the OS:s
innards are ripped out and replaced by something that looks similar
(do not try on production systems though!). Unfortunately, some stuff
are not found in Heirloom and Plan9port which means that one needs to
fall back to Busybox in order to have a drop-in replacement of GNU
coreutils.

A possible foundation for sbase would be Goblin - a *nix/9base written in Go
https://aur.archlinux.org/packages.php?ID=48413
(git://github.com/jdparent/goblin.git)

Another possiblility that I do not know if it really is possible would
be native compilation of Inferno. There is an experimental limbo
compiler for posix systems:
http://sourceforge.net/projects/acheron-l/
I have not tried it so I do not know how well it works.

An extension of the scope of this one to cover the needed parts to
replace GNU coreutils et al would be cool (one thing currently
lacking: chroot)

Post by Bryan Bennett
I would suggest first re-writing the ones that 9Base has listed. It seems
a relatively exhaustive list and - with our case of NIH - we don't want to
be using anything from another OS entirely, now do we ;)
I'm pretty excited by this proposition. The idea seems pretty good.

[ilf]

Post by Jens Staal
For fun, I have been trying to replace GNU with
Busybox: https://wiki.archlinux.org/index.php/Base2busybox
Heirloom: https://wiki.archlinux.org/index.php/Base2heirloom
Plan9port: https://wiki.archlinux.org/index.php/Base2plan9

Very interesting.
Tried these, too? http://www.fefe.de/embutils/

[Jens Staal]

Post by ilf

Post by Jens Staal
https://wiki.archlinux.org/index.php/Base2plan9

Very interesting.
Tried these, too? http://www.fefe.de/embutils/
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
               -- Eine Initiative des Bundesamtes für Tastaturbenutzung

Thanks!

I had never seen those before. I will check them out and see if I can
do something fun with them :)

[Noah Birnel]

Post by Connor Lane Smith
I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.

Cool.

Your Makefile, though, is GNU-dependant.

cheers
Noah

[Kamil Cholewiński]

Hi,

had a sleepless night, so contributing sleep.c and sleep.1.

Thanks,
Kamil

Post by Connor Lane Smith
Hey all,
I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.
Some of us seem to be resorting to using those from Plan 9, which were
designed for another operating system and exist on Unix through a
compatibility shim.
So, in a glorious demonstration of NIH syndrome, let's make our own!
I'm unsure exactly which utilities we should include (suggestions on a
comprehensive set?), but in terms of functionality a good rule of
thumb is to only include flags present in both POSIX and Plan 9, thus
making a sweet little subset. There are exceptions to this, like grep
-q and ls -a, but it's a useful guideline.
I've written a handful so far (basename, cat, echo, false, grep, tee,
touch, true, wc), which I've attached. Each tool is between 6 and 88
SLOC, and compiles with musl into a static binary between 13K and 45K
in size. The manual pages are nice and short, too.
If anyone else wants to contribute a tool written in the same style
they are most welcome. I'd like to set up an hg repo soon, but I'm
quite busy with exams atm.
Thanks,
cls

[Connor Lane Smith]

Post by Bryan Bennett
I would suggest first re-writing the ones that 9Base has listed. It seems
a relatively exhaustive list and - with our case of NIH - we don't want to
be using anything from another OS entirely, now do we ;)

Some of them, certainly, but we don't need to rewrite everything 9base
provides, like sam and mk. My hope is we can find a sufficiently
minimalist Unix shell, editor, and so on. If not, I suppose we can
write them after the smaller things. We'll see how it goes.

Post by Bryan Bennett
had a sleepless night, so contributing sleep.c and sleep.1.

Thanks Kamil, I'll add them when I create a repo.

cls

[pancake]

You can just remove the local variable, it's only used once.

I would suggest linking all those .c in a single binary like busybox
does. that would make it slight if you want it to compile it statically.

btw. anybody is gonna upload all this stuff into the hg?

Post by Kamil Cholewiński
Hi,
had a sleepless night, so contributing sleep.c and sleep.1.
Thanks,
Kamil

Post by Connor Lane Smith
Hey all,
I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.
Some of us seem to be resorting to using those from Plan 9, which were
designed for another operating system and exist on Unix through a
compatibility shim.
So, in a glorious demonstration of NIH syndrome, let's make our own!
I'm unsure exactly which utilities we should include (suggestions on a
comprehensive set?), but in terms of functionality a good rule of
thumb is to only include flags present in both POSIX and Plan 9, thus
making a sweet little subset. There are exceptions to this, like grep
-q and ls -a, but it's a useful guideline.
I've written a handful so far (basename, cat, echo, false, grep, tee,
touch, true, wc), which I've attached. Each tool is between 6 and 88
SLOC, and compiles with musl into a static binary between 13K and 45K
in size. The manual pages are nice and short, too.
If anyone else wants to contribute a tool written in the same style
they are most welcome. I'd like to set up an hg repo soon, but I'm
quite busy with exams atm.
Thanks,
cls

[Connor Lane Smith]

I've just created a repo at http://hg.suckless.org/sbase

I'll get around to adding others' contributions soon. Note that I'll
likely reformat them a little to make sure all the tools have a
consistent style. It's important that they all look and behave alike.

Thanks,
cls

[Rob]

I have a gripe about the fread() business - I have to hit ^D twice
before eof is reported - the first ^D causes fread() to return non-zero,
with text I entered previously, the second ^D causes fread() to return 0.
Probably not a major problem but here's a patch if anyone's interested.

Also rm.c
I don't think it has any problems with symlinks, but I accept no
responsibility for your lost home directory, anime collection or
childhood memories. I've never ever found a use for -f, it's just a
pain having rm prompt me, so I've assumed an always present -f. Stick it
in if you're going for posix or whatever though.

One more thing, we're not bothering with the -- flag, are we?

but I'm quite busy with exams atm.

UK, right? Up late coding even with exams, I'm impressed.

Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though</vapourware>.

Cheers,
Rob.

[Bjartur Thorlacius]

Post by Rob
One more thing, we're not bothering with the -- flag, are we?

We should, if only for the sake of portable scripts. We may not need
or want full POSIX, but we should at least support general conventions
used by properly written scripts.

Post by Rob
Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though</vapourware>.

Interesting. More details, or show me the code. What's novel about him?

[pancake]

Maybe you are interested in:

http://hg.youterm.com/smash

Post by Bjartur Thorlacius

Post by Rob
One more thing, we're not bothering with the -- flag, are we?

We should, if only for the sake of portable scripts. We may not need
or want full POSIX, but we should at least support general conventions
used by properly written scripts.

Post by Rob
Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though</vapourware>.

Interesting. More details, or show me the code. What's novel about him?

[Kurt H Maier]

On Mon, May 23, 2011 at 3:08 PM, Bjartur Thorlacius

Post by Bjartur Thorlacius

Post by Rob
One more thing, we're not bothering with the -- flag, are we?

We should, if only for the sake of portable scripts. We may not need
or want full POSIX, but we should at least support general conventions
used by properly written scripts.

POSIX flags never start with --.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

[Robert Ransom]

On Mon, 23 May 2011 16:27:16 -0400

Post by Kurt H Maier
On Mon, May 23, 2011 at 3:08 PM, Bjartur Thorlacius

Post by Bjartur Thorlacius

Post by Rob
One more thing, we're not bothering with the -- flag, are we?

We should, if only for the sake of portable scripts. We may not need
or want full POSIX, but we should at least support general conventions
used by properly written scripts.

POSIX flags never start with --.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

The point of the “--” ‘flag’ is to tell the program to not interpret
following arguments as options.


Robert Ransom

[Kurt H Maier]

The point of the “--” ‘flag’ is to tell the program to not interpret
following arguments as options.

Sorry, I assumed he was talking about --long-options. I use -- pretty
regularly and will probably wind up patching it in if it's missing.

[Connor Lane Smith]

Sorry, I assumed he was talking about --long-options.  I use -- pretty
regularly and will probably wind up patching it in if it's missing.

In a moment of uncharacteristic pragmatism, I've decided for these
tools it's probably best to use getopt. Not using it works well for
dwm and dmenu, but .. yeah. So -- is now supported, as are grouped
flags, etc.

cls

[Anselm R Garbe]

Post by Connor Lane Smith

Sorry, I assumed he was talking about --long-options.  I use -- pretty
regularly and will probably wind up patching it in if it's missing.

In a moment of uncharacteristic pragmatism, I've decided for these
tools it's probably best to use getopt. Not using it works well for
dwm and dmenu, but .. yeah. So -- is now supported, as are grouped
flags, etc.

Now my alarm bells ring. Why is getopt() a good idea? What's wrong
with making no assumptions and checking flags with strcmp like we did
in suckless tools? I understand why ARGBEGIN { } ARGEND is no option
for the -- case, but I really can't see why getopt() would be any
advantageous compared to our style?

Cheers,
Anselm

[Connor Lane Smith]

Post by Anselm R Garbe
Now my alarm bells ring. Why is getopt() a good idea? What's wrong
with making no assumptions and checking flags with strcmp like we did
in suckless tools? I understand why ARGBEGIN { } ARGEND is no option
for the -- case, but I really can't see why getopt() would be any
advantageous compared to our style?

The core tools are used run more frequently from the shell, and
grouping flags has its benefits. One, it means you can actually run
'make' on suckless projects without rm saying there is no -fr flag;
two, it's less verbose -- I have sbase at the front of my PATH right
now, and can tell you it would get tiresome; and three, '--'. dwm and
dmenu don't have any of these problems.

Of course, it would be *possible* to write our own 'ARGBEGIN' kinda
functionality, but then we're basically creating an ad hoc getopt.
Since it's POSIX, and we assume libc sanity -- musl's getopt is about
as simple as we'd get it[1] -- I think getopt is better for these
tools.

[1] http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=blob;f=src/misc/getopt.c

Thanks,
cls

[Connor Lane Smith]

Post by Rob
I have a gripe about the fread() business - I have to hit ^D twice
before eof is reported - the first ^D causes fread() to return non-zero,
with text I entered previously, the second ^D causes fread() to return 0.
Probably not a major problem but here's a patch if anyone's interested.

I wonder why this behaves differently to read(). Any ideas?

Post by Rob
Also rm.c

Thanks. I've modified it slightly to avoid having to get the cwd,
since that opens a can of worms. (In short, POSIX makes it literally
impossible ensure that you've got the entire path.)

Post by Rob
I've never ever found a use for -f, it's just a
pain having rm prompt me, so I've assumed an always present -f. Stick it
in if you're going for posix or whatever though.

I agree, though I've added -f as a null flag, so it's ignored but
doesn't cause an error either, since scripts quite sensibly use -f.

Post by Rob
UK, right? Up late coding even with exams, I'm impressed.

I can't help it, I think I code obsessively. :p

Post by Rob
Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though</vapourware>.

Looking forward to it. imo we need a new editor...

Thanks,
cls

[Kurt H Maier]

Post by Connor Lane Smith
Looking forward to it. imo we need a new editor...

I like this:
http://www.stabie-soft.com/sre/re.html

it's no sam, but for short one-off edits (or even as a pager) I like it.

[Christian Neukirchen]

Post by Kurt H Maier

Post by Connor Lane Smith
Looking forward to it. imo we need a new editor...

http://www.stabie-soft.com/sre/re.html
it's no sam, but for short one-off edits (or even as a pager) I like it.

Remotely reminds me of http://code.google.com/p/aoeui/ which also is
pretty lightweight, has UTF8, is binary-safe, and has infinite
undo. ~7KLOC, no curses dependency.

[Rafa Garcia Gallego]

On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen

Post by Christian Neukirchen
Remotely reminds me of http://code.google.com/p/aoeui/ which also is
pretty lightweight, has UTF8, is binary-safe, and has infinite
undo. ~7KLOC, no curses dependency.

This reminds me of my very own sandy[1]. Sorry for the blatant publicity.

Ok, mine depends on ncurses, but the again it weights some 1700 SLOC
only. The idea of using external tools to process text seems quite
suckless to me.

[1] http://sandyeditor.sf.net/

[pancake]

Post by Rafa Garcia Gallego
On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen

Post by Christian Neukirchen
Remotely reminds me of http://code.google.com/p/aoeui/ which also is
pretty lightweight, has UTF8, is binary-safe, and has infinite
undo. ~7KLOC, no curses dependency.

This reminds me of my very own sandy[1]. Sorry for the blatant publicity.
Ok, mine depends on ncurses, but the again it weights some 1700 SLOC
only. The idea of using external tools to process text seems quite
suckless to me.
[1] http://sandyeditor.sf.net/

Wow. sandy sources looks great. I managed to reproduce some segfaults and
I feel not comfortable with a non-hjkl editor. but as long as it's
configurable in
the config.h.

Great work Rafa! :)

What about moving that repo to hg.suckless.org ?

[Rafa Garcia Gallego]

Post by pancake

Post by Rafa Garcia Gallego
On Tue, May 24, 2011 at 6:16 PM, Christian Neukirchen

Post by Christian Neukirchen
Remotely reminds me of http://code.google.com/p/aoeui/ which also is
pretty lightweight, has UTF8, is binary-safe, and has infinite
undo. ~7KLOC, no curses dependency.

This reminds me of my very own sandy[1]. Sorry for the blatant publicity.
Ok, mine depends on ncurses, but the again it weights some 1700 SLOC
only. The idea of using external tools to process text seems quite
suckless to me.
[1] http://sandyeditor.sf.net/

Wow. sandy sources looks great. I managed to reproduce some segfaults and
I feel not comfortable with a non-hjkl editor. but as long as it's
configurable in
the config.h.

Well, I tried to go for an almost modeless editor because I like it
better in theory. But I keep falling back to vi(m) to do serious
edits, even on the sandy code (shame on me!). Maybe I should try
adding two modes to it, see how it plays out.

The default bindings are there to be changed, of course. I imagined
emacs-like bindings (read bash-like too) would be comfy for most
people.

About the segfaults, argh! Could you please point them out to me? Or
maybe patch them yourself if you have the time :)

Post by pancake
What about moving that repo to hg.suckless.org ?

Sure! don't I need a SSH account or something?

Cheers,
Rafa.

[Mate Nagy]

Hi,

Post by Connor Lane Smith
I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.
Some of us seem to be resorting to using those from Plan 9, which were
designed for another operating system and exist on Unix through a
compatibility shim.

please, please don't take this as a troll - it's just a personal
feeling... but I do feel that the suckless project is at its best when
it produces fantastically useful minimalistic software like dwm.

These days it seems a moronic, unproductive crusade on features and
rewriting completely serviceable utilities to be much worse is more popular.

Best regards,
Mate

[Anselm R Garbe]

Post by Mate Nagy

Post by Connor Lane Smith
I think it's about time we started a minimalist, statically linked set
of core utilities. The BSD family are bloated, and the GNU monstrous.
Some of us seem to be resorting to using those from Plan 9, which were
designed for another operating system and exist on Unix through a
compatibility shim.

please, please don't take this as a troll - it's just a personal
feeling... but I do feel that the suckless project is at its best when
it produces fantastically useful minimalistic software like dwm.
These days it seems a moronic, unproductive crusade on features and
rewriting completely serviceable utilities to be much worse is more popular.

I agree. Nevertheless, the effort already undertaken should at least
be preserved in a sbase repository which I asked Connor to set up.

For 9base the main purpose is mk and rc (and the assumptions of mk to
rely on a rc shell) -- it will be hard to pointless to rewrite those
for the sake of 9base.

Cheers,
Anselm

Post by Mate Nagy
Best regards,
 Mate

[Connor Lane Smith]

Hey,

Post by Noah Birnel
Your Makefile, though, is GNU-dependant.

Really, which part? It seems to work with NetBSD make.

Post by Noah Birnel
please, please don't take this as a troll - it's just a personal
feeling... but I do feel that the suckless project is at its best when
it produces fantastically useful minimalistic software like dwm.
These days it seems a moronic, unproductive crusade on features and
rewriting completely serviceable utilities to be much worse is more popular.

I completely understand the sentiment. Just the other day on #suckless
I was saying, the reason why dwm and dmenu are so good is they bring
something new in terms of usability. Things like surf do not, they
just have fewer features.

So where does this fit in? Okay, this is basically my computing
tactic: simplifying my operating system to the point where I can
actually understand what on Earth is going on. When I use a system
like Ubuntu and Gnome, when shit breaks I have no idea what went
wrong, and I tend to end up reinstalling everything. When I use a
system like Debian and dwm, when shit breaks I say, "ohhh," and fix
it, and it takes a couple of seconds. (X is an exception.) The simpler
the internals, the easier it is to use, not because of anything on the
surface -- though the manuals are rather easier to read -- but because
you can clearly visualise the mechanisms inside whatever tools you are
using.

So I hope that explains my view on the subject. I agree that dwm and
friends are "suckless at its best", but this sort of paring is
necessary to build on my relationship with my computer as a whole: I
don't understand how it all works, so instead of spending the next
decade creating a mental image of the system, I'll just make my own,
thus bringing its complexity within the boundaries of my own ken. (Is
that a pun? I don't know.) I don't know how others live with the
complexity of their system, but I suspect it involves Perl and
duct-tape. :p

Post by Noah Birnel
scripts will break

Yeah, when I started out I wanted to make it entirely POSIX, but once
I saw the flaggishness of the POSIX standard I decided I'd just make a
compromise. This will begin as a supplement to, rather than a
replacement for, standard utilities, and maybe we can get to a point
where a static distro like Stali can use only them. I don't know about
you, but I could genuinely live without autoconf on my laptop.

Thanks,
cls

[Kamil Cholewiński]

Hi,

Post by Connor Lane Smith
So where does this fit in? Okay, this is basically my computing
tactic: simplifying my operating system to the point where I can
actually understand what on Earth is going on.

This.

Also, contributing date.c and date.1. Both probably need refinements.

Thanks,
Kamil

[Bryan Bennett]

Connor - Sorry. I meant the ones that were useful to the 'cause'.
On an initial read through of that page, I saw sam but missed mk
& rc.

Bryan

[Noah Birnel]

Post by Connor Lane Smith

Post by Noah Birnel
Your Makefile, though, is GNU-dependant.

Really, which part? It seems to work with NetBSD make.

On FreeBSD, make does
CC -c util.c
and nothing else.
make clean works as expected.

Had to run GNU make to get the actual programs. Sorry I'm ignorant of
what freebsd is not getting, or why.

-Noah

[Pierre Chapuis]

Post by Connor Lane Smith
So where does this fit in? Okay, this is basically my computing
tactic: simplifying my operating system to the point where I can
actually understand what on Earth is going on. When I use a system
like Ubuntu and Gnome, when shit breaks I have no idea what went
wrong, and I tend to end up reinstalling everything. When I use a
system like Debian and dwm, when shit breaks I say, "ohhh," and fix
it, and it takes a couple of seconds. (X is an exception.) The
simpler
the internals, the easier it is to use, not because of anything on the
surface -- though the manuals are rather easier to read -- but
because
you can clearly visualise the mechanisms inside whatever tools you are
using.

If you push that to the extreme you want to understand how the kernel
works too. So you should make sure those tools work on Minix3 so that
you can achieve "big picture" understanding.

I don't understand why so few people on this list are interested in
Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of
the software you need on a Unix box sounds nice to me.

[Connor Lane Smith]

Post by Pierre Chapuis
If you push that to the extreme you want to understand how the kernel
works too. So you should make sure those tools work on Minix3 so that
you can achieve "big picture" understanding.

Fair point, though since we're pushing for a POSIX subset they ought
to work on Minix fine. I'll check at some point.

Post by Pierre Chapuis
I don't understand why so few people on this list are interested in
Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of
the software you need on a Unix box sounds nice to me.

I'm secretly very fond of Minix. I remember getting a negative
reaction to it from the Plan 9 folks so I've not bothered to bring it
up since. But a tiny POSIX microkernel? Win. I've read a bunch of
Tanenbaum's books, too...

Only problem is hardware support. Ain't that always the way?

cls

[Anselm R Garbe]

Post by Connor Lane Smith

Post by Pierre Chapuis
If you push that to the extreme you want to understand how the kernel
works too. So you should make sure those tools work on Minix3 so that
you can achieve "big picture" understanding.

Fair point, though since we're pushing for a POSIX subset they ought
to work on Minix fine. I'll check at some point.

Post by Pierre Chapuis
I don't understand why so few people on this list are interested in
Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of
the software you need on a Unix box sounds nice to me.

I'm secretly very fond of Minix. I remember getting a negative
reaction to it from the Plan 9 folks so I've not bothered to bring it
up since. But a tiny POSIX microkernel? Win. I've read a bunch of
Tanenbaum's books, too...
Only problem is hardware support. Ain't that always the way?

If you want to go that route, I suggest to build the hardware yourself
as well, here is a brilliant guy who did it a couple of years ago:

http://www.homebrewcpu.com/

Cheers,
Anselm

[Rob]

Post by Bjartur Thorlacius

Post by Rob
Finally, I have an editor in the works, unfinished, but I plan to show
you lot at some point though</vapourware>.

Interesting. More details, or show me the code. What's novel about him?

Nothing novel I'm afraid, I'm still waiting for that idea, it's a
stripped down vi clone and I'm planning on having the majority of the
commands filter though external programs, like :s would use sed and so
on. I'm busy with exams at the moment and I managed to brick the curses
stuff, so I'd rather not upload until I've got it back together.

Post by Bjartur Thorlacius

Post by Rob
I have to hit ^D twice before eof is reported

I wonder why this behaves differently to read(). Any ideas?

Guessing stdio buffering, I tried stuff like setbuf(stdin, NULL), but it
was having none of it. I suppose you could drop to read(fileno(..)) but
.. well.. I'm sure fread() shouldn't be doing that in the first place.

Post by Bjartur Thorlacius

Post by Rob
Also rm.c

Thanks. I've modified it slightly to avoid having to get the cwd,
since that opens a can of worms. (In short, POSIX makes it literally
impossible ensure that you've got the entire path.)

I'm not sure whether moving up a directory will always work, what if
you're in $HOME and do
rm -r /tmp/dir1 ./dir2
(assuming /tmp/dir1 isn't empty, causing the chdir) it'll change to
/tmp/dir1, remove entries in there, move up to /tmp, remove dir1, then
attempt to remove dir2 (i.e. /tmp/dir2) when you actually mean
$HOME/dir2.

Post by Bjartur Thorlacius

Post by Rob
UK, right? Up late coding even with exams, I'm impressed.

I can't help it, I think I code obsessively. :p

Haha, good luck with your exams if you keep that up!

Post by Bjartur Thorlacius
I don't understand why so few people on this list are interested in
Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of
the software you need on a Unix box sounds nice to me.

5K? Why has no one mentioned this before?!

Post by Bjartur Thorlacius
If you want to go that route, I suggest to build the hardware yourself
http://www.homebrewcpu.com/

Or if you don't have the time for hardware:

Cheers,
Rob.

[Connor Lane Smith]

Post by Rob
I'm not sure whether moving up a directory will always work, what if
you're in $HOME and do
rm -r /tmp/dir1 ./dir2

Ugh, you're right. That means we'll have to do the never-quite-sure
buffer allocation stuff in rm as well. It's getting tiring having to
write those same lines of code... Fixed in tip.

Post by Rob
Haha, good luck with your exams if you keep that up!

Thanks. :) Got one right now, so it's time to run...

cls

[Pierre Chapuis]

Post by Anselm R Garbe

Post by Connor Lane Smith

Post by Pierre Chapuis
I don't understand why so few people on this list are interested in
Minix3. ~5k LOC for a POSIX-compatible kernel that can run most of
the software you need on a Unix box sounds nice to me.

I'm secretly very fond of Minix. I remember getting a negative
reaction to it from the Plan 9 folks so I've not bothered to bring it
up since. But a tiny POSIX microkernel? Win. I've read a bunch of
Tanenbaum's books, too...
Only problem is hardware support. Ain't that always the way?

If you want to go that route, I suggest to build the hardware
yourself
http://www.homebrewcpu.com/

Looks cool. I'm not courageous enough to try though. I have written a
few FPGAs with VHDL/Xilinx but that's as far as my knowledge of
numerical electronics go so the limit of my "big picture understanding"
is that I have some layer that can execute a reduced instructions set
(eg. x86).

As for the hardware to run Minix3, I am lucky to have an old Dell
laptop with one of the few supported ethernet chipsets, but otherwise
emulation (with QEMU) works fine, with sufficient performance if your
CPU has VT-x capabilities.

I haven't had much time to play with it recently. I was disappointed
by the move towards GNU tools (glibc, gcc) but I have to admit that
ack is old and lagging behind modern compilers.

I wonder how hard it would be to build a "suckless" Minix3
distribution with tcc / musl...

[Szabolcs Nagy]

Post by Connor Lane Smith
thumb is to only include flags present in both POSIX and Plan 9, thus
making a sweet little subset. There are exceptions to this, like grep

scripts will break

(eg autoconf generated scripts depend on all sort of flags
and lot of software uses autoconf..)

[Kurt H Maier]

Post by Szabolcs Nagy
scripts will break
(eg autoconf generated scripts depend on all sort of flags
and lot of software uses autoconf..)

if you want gnu coreutils, you know where to find it.

[stateless]

Added pwd.

[Sir Cyrus]

Not too clued in on coreutils alternatives, but what's wrong with busybox?

[Troels Henriksen]

Post by Sir Cyrus
Not too clued in on coreutils alternatives, but what's wrong with busybox?

Enormously ugly code (IMO worse than GNU coreutils, but in a different
way), and not much hackability. It's designed for something much
different than sbase.

[Sir Cyrus]

In that case, best of luck to you lot! Though surely a core utilities
project with this same philosophy in mind _has_ to exist somewhere...?

[hiro]

Maybe most people on earth aren't masochists and try to do something
more productive instead?

[Connor Lane Smith]

Post by Sir Cyrus
In that case, best of luck to you lot! Though surely a core utilities
project with this same philosophy in mind _has_ to exist somewhere...?

Not that I've found. Simple hackability isn't often an aim for software.

Post by Sir Cyrus
Maybe most people on earth aren't masochists and try to do something
more productive instead?

Hah, I don't think that's very likely.

I've still got exams and such, but have added chown, dirname, and ln
since I last posted, so it's getting there.

cls

[Marc Andre Tanner]

Post by Troels Henriksen

Post by Sir Cyrus
Not too clued in on coreutils alternatives, but what's wrong with busybox?

Enormously ugly code (IMO worse than GNU coreutils, but in a different
way), and not much hackability.

I think you are exaggerating quite a bit. Most of the uglyness comes
from the fact that they try to save each and every byte.

Post by Troels Henriksen
It's designed for something much different than sbase.

True, but I think it's still be the best real world usable alternative.
And patches are certainly welcome.

You might also want to take a look at toybox:

http://landley.net/code/toybox/

Marc

[Kurt H Maier]

Post by Marc Andre Tanner
I think you are exaggerating quite a bit. Most of the uglyness comes
from the  fact that they try to save each and every byte.

The rest comes from this monolithic-binary problem.
I remember reading about Toybox, but it's got the same
monolithic-binary goal as busybox. I dislike all the global unions
and other such, but at least the code is much, much nicer than
busybox.

[Connor Lane Smith]

Update!

We've got 20 utilities now: basename, cat, chown, date, dirname, echo,
false, grep, head, ln, ls, mkdir, mkfifo, pwd, rm, sleep, tee, touch,
true, and wc.

I think the most crucial ones missing are chmod, cp, mv, seq, sort,
tail, test, and uniq. And probably others. Working on it! I've been
given cal, too, which I'll sort out once the more important stuff is
done.

cls

[pancake]

What about cat and tac? I already pushed tac to 9base few time ago, but it was removed.. It fits better in sbase.

Post by Connor Lane Smith
Update!
We've got 20 utilities now: basename, cat, chown, date, dirname, echo,
false, grep, head, ln, ls, mkdir, mkfifo, pwd, rm, sleep, tee, touch,
true, and wc.
I think the most crucial ones missing are chmod, cp, mv, seq, sort,
tail, test, and uniq. And probably others. Working on it! I've been
given cal, too, which I'll sort out once the more important stuff is
done.
cls

[Anselm R Garbe]

Post by pancake
What about cat and tac? I already pushed tac to 9base few time ago, but it was removed.. It fits better in sbase.

Afaik tac sucks more, as it is quite an arbitrary command, not part of
Plan 9 and can be imitated with a awk one liner like

awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'

As for sbase I'm still sceptical this is a good idea as it
re-implements perfectly sound 9base tools, but avoids the real tricky
ones such as rc, mk or awk.
In the end sbase adds up to the already highly diverse universe of
different Unix command implementations, and probably breaks here and
there as it will contain bugs as well. I mean it is a nice effort but
apart from having some busybox competitor the use is rather limited.

Instead I agree with Szabolcs that this idea of having a high level C
API that implements commonly used stuff like the allocatorz, dial(),
etc, seems more valuable.

Don't get me wrong, I think this sbase thing is a great excercise but
I really do believe there is more interesting stuff that we should
rather focus on.

I created 9base because I didn't need to reimplement every command and
because its source roots back to the real Unix inventors. So I expect
their code to be rather stable and sound. For scripts it seems perfect
to rely on 9base as it should behave equally regardless the underlying
OS (granted there were some issues the Szabolcs and others pointed to
with regards to the fmt implementation, but those will be resolved
quickly).
can't really see the value of it.

Cheers,
Anselm

[Connor Lane Smith]

Post by Anselm R Garbe
As for sbase I'm still sceptical this is a good idea as it
re-implements perfectly sound 9base tools, but avoids the real tricky
ones such as rc, mk or awk.

I, basically, disagree. The Plan 9 tools were written for another
operating system: ls has no -a flag, but you can use -q to list the 9P
QIDs? Fantastic. You can't distinguish between a failed match and an
error in grep, because Plan 9's exit returns a string? Even better.

No other utils that I have found are designed just to be simple and
hackable, with only a few useful flags, and not all the cruft. There's
9base, but all the benefits Plan 9 brings are totally screwed by the
marshalling back into Unix. Using P9P is a compromise, not an
alternative userspace.

-rwxr-xr-x 1 cls cls 604908 May 26 11:47 9base/cat/cat
-rwxr-xr-x 1 cls cls 21268 May 26 11:47 sbase/cat

My intention is to build a userspace for Unix which is very simple
(see my earlier post), and actually *designed* for Unix, not just a
compatibility shim. I tend to prefer Unix tools which are actually,
you know, Unix tools.

Regarding awk, we should probably use bwk. I haven't decided what to
do about make or the shell, yet.

Thanks,
cls

[markus schnalke]

Post by Anselm R Garbe
Afaik tac sucks more, as it is quite an arbitrary command, not part of
Plan 9 and can be imitated with a awk one liner like
awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'

Okay, but who want's to type this line by hand?

IMO tac *should be included* in some Unix toolchain, but as a
shell/awk script, containing this line. This would be software
leverage.

Unfortunately it seems as if this concept is just too often handed
over to the administrators. If programs are distributed, people focus
on performance and write them in C instead ...

Post by Anselm R Garbe
Don't get me wrong, I think this sbase thing is a great excercise but
I really do believe there is more interesting stuff that we should
rather focus on.

I fully agree.


meillo

[pancake]

The tac.c i pushed few time ago is magnitudes faster than awk.

That was the reasom why nibble and me wrote it.

Post by markus schnalke

Post by Anselm R Garbe
Afaik tac sucks more, as it is quite an arbitrary command, not part of
Plan 9 and can be imitated with a awk one liner like
awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }'

Okay, but who want's to type this line by hand?
IMO tac *should be included* in some Unix toolchain, but as a
shell/awk script, containing this line. This would be software
leverage.
Unfortunately it seems as if this concept is just too often handed
over to the administrators. If programs are distributed, people focus
on performance and write them in C instead ...

Post by Anselm R Garbe
Don't get me wrong, I think this sbase thing is a great excercise but
I really do believe there is more interesting stuff that we should
rather focus on.

I fully agree.
meillo

[Kurt H Maier]

Here is a half-assed old version of chmod, in the vein of v5 chmod.
It has a man page and informative ed-style error messages, but no
recursion or POSIX-style 'symbolic mode expressions.' I'll refactor
it to use util/recurse later. I don't really care about 'symbolic
mode expressions.'

[Connor Lane Smith]

Hey,

For anyone interested in helping out with sbase, I've pushed a TODO
file containing all the commands I think we need to implement, at
least to begin with. I'll be working on these whenever I have free
time, and if anyone else could help that would be great.

Thanks,
cls

[stateless]

Attached cmp.c and cmp.1.

[stateless]

Hi,

Just to be on the same page and we don't start working on the same
tools. I'll look into implementing id, kill and comm.

Thanks,
stateless

[stateless]

Small update, attached cmd.c and cmd.1.

[stateless]

Arrgh fucking gmail.

[Rob]

Post by stateless
Hi,
Just to be on the same page and we don't start working on the same
tools.  I'll look into implementing id, kill and comm.
Thanks,
stateless

Ah man, I've just been doing kill.c myself. Lowest SLOC count makes it
into base?

[Rob]

Post by stateless
Arrgh fucking gmail.

+1

[stateless]

No worries Rob! :)

[Hiltjo Posthuma]

Post by Rob
Ah man, I've just been doing kill.c myself. Lowest SLOC count makes it
into base?

I like it, but what about -signalnumber (and maybe -signalname), I use
-9 all the time :)

[Rob]

Post by Hiltjo Posthuma
I like it, but what about -signalnumber (and maybe -signalname), I use
-9 all the time :)

I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.

[pancake]

Here's my contribution:

* support for string mode format in chmod. Now you can do stuff like chmod +x .. g-rwx , ...
* fix uninitialized bug in tail
* simplify sleep() -- do not use getopt here.

The chmod patch is not complete at all, but works much better and +x is something many ppl use.

About sleep.. The bsd and gnu supprt milisecond resolution for sleep. The manpage doesnt reflects this. But maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 )

http://lolcathost.org/b/sbase.patch

Post by Rob

Post by Hiltjo Posthuma
I like it, but what about -signalnumber (and maybe -signalname), I use
-9 all the time :)

I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.
<kill.c>

[Connor Lane Smith]

Post by pancake
support for string mode format in chmod. Now you can do stuff like chmod +x .. g-rwx , ...

Thanks, I'll get round to looking at this tomorrow.

Post by pancake
fix uninitialized bug in tail

No, there's no bug here; size is allocated and memset on the next line.

Post by pancake
simplify sleep() -- do not use getopt here.

If a utility takes any arguments I'd like it to refuse invalid flags,
and accept '--'. I dislike inconsistency.

Post by pancake
maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 )

Not POSIX, imo not useful. You could make a separate usleep(1) or
something anyway.

Thanks,
cls

[pancake]

Hi

Post by Connor Lane Smith

Post by pancake
support for string mode format in chmod. Now you can do stuff like chmod +x .. g-rwx , ...

Thanks, I'll get round to looking at this tomorrow.

Post by pancake
fix uninitialized bug in tail

No, there's no bug here; size is allocated and memset on the next line.

Your gcc sucks. Mine reports the error here. Size is only allocated if the or condition applies which is not something to always happen opening the doors to use an uninitialized pointer.

Post by Connor Lane Smith

Post by pancake
simplify sleep() -- do not use getopt here.

If a utility takes any arguments I'd like it to refuse invalid flags,
and accept '--'. I dislike inconsistency.

Sleep takes only numeric aegument. My patch works as expected if u pass a string kr a flag.

Post by Connor Lane Smith

Post by pancake
maybe its useful to handle arguments like 0.5 or so ( sleep 0.5 )

Not POSIX, imo not useful. You could make a separate usleep(1) or
something anyway.

Ok

Post by Connor Lane Smith
Thanks,
cls

[Connor Lane Smith]

Hey,

Post by pancake
Your gcc sucks. Mine reports the error here. Size is only allocated if the
or condition applies which is not something to always happen opening the
doors to use an uninitialized pointer.

I wasn't talking about GCC. Step through the logic in your head. What
happens if the if statement is false? The program exits. If GCC whines
about it it just means it's not very smart. (It doesn't on my machine,
but does on my server using an older version.) I'll add the assignment
just to silence it, I suppose.

cls

[pancake]

Post by Connor Lane Smith
Hey,

Post by pancake
Your gcc sucks. Mine reports the error here. Size is only allocated if the
or condition applies which is not something to always happen opening the
doors to use an uninitialized pointer.

I wasn't talking about GCC. Step through the logic in your head. What
happens if the if statement is false? The program exits. If GCC whines
about it it just means it's not very smart. (It doesn't on my machine,
but does on my server using an older version.) I'll add the assignment
just to silence it, I suppose.
cls

you are right. you can also silent gcc by specifying an __noreturn__
attribute to the eprintf function.

[Rob]

Post by pancake

Post by Connor Lane Smith
No, there's no bug here; size is allocated and memset on the next line.

Your gcc sucks. Mine reports the error here. Size is only allocated if the
or condition applies which is not something to always happen opening the
doors to use an uninitialized pointer.

It's because gcc doesn't understand that eprintf will never return.
Add something like __attribute__((noreturn)) to eprintf's prototype and
you'll see.

[pancake]

What do you think about creating a single main() in sbase.c that works like busybox (as a proxy for the rest of binaries) i think this can be interesting for embeddeds. So reading symlink of argv0 and act accordingly.

Post by Rob

Post by Hiltjo Posthuma
I like it, but what about -signalnumber (and maybe -signalname), I use
-9 all the time :)

I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.
<kill.c>

[Kurt H Maier]

Post by pancake
What do you think about creating a single main() in sbase.c that works like busybox (as a proxy for the rest of binaries) i think this can be interesting for embeddeds. So reading symlink of argv0 and act accordingly.

please for the love of god no

there are already so many packages that do this (busybox, toybox,
etc). heirloom does something similar with a 'common.c' or some shit
and it makes it a complete pain in the ass to hack on. one file, one
utility, please, with certain exceptions for stuff like awk, sed,
grep, and sh.

if you want busybox, you know where to find it.

[Connor Lane Smith]

Post by pancake
What do you think about creating a single main() in sbase.c that works like busybox (as a proxy for the rest of binaries) i think this can be interesting for embeddeds. So reading symlink of argv0 and act accordingly.

The only way this is going to happen is if someone writes a script
which does it automatically, by going through each utility prefixing
their main() functions (in a separate build directory), generating a
common main() which dispatches to the correct places, and then
compiles them.

That is to say, I'm not going to change the utilities themselves, but
if someone were to write a separate 'boxing' script I'd be happy to
add it to the repo.

Thanks,
cls

[Rob]

Post by Connor Lane Smith
The only way this is going to happen is if someone writes a script
which does it automatically, by going through each utility prefixing
their main() functions (in a separate build directory), generating a
common main() which dispatches to the correct places, and then
compiles them.
That is to say, I'm not going to change the utilities themselves, but
if someone were to write a separate 'boxing' script I'd be happy to
add it to the repo.
Thanks,
cls

I had a go at writing one last night, but it didn't work properly due to static
variables and no one on here seemed to want it so I didn't bother submitting.
Anyway, I had another pop this morning and here's what I got. It's a bit
hackish, but to do the job properly would require a parser so yeah...

Thanks,
Rob.

[Rob]

Post by Rob
Anyway, I had another pop this morning and here's what I got.

Also, forgot to mention, you'll need to alter true.c, false.c and tty.c
so their main conforms, otherwise it won't compile.

[Connor Lane Smith]

Post by pancake
support for string mode format in chmod. Now you can do stuff like chmod +x .. g-rwx , ...

I got round to looking at this. I had to change some of it to make it
POSIX and so on, but I like the approach (which basically avoids the
POSIX's BNF grammar (seriously)).

Post by pancake
I had a go at writing one last night, but it didn't work properly due to static
variables and no one on here seemed to want it so I didn't bother submitting.
Anyway, I had another pop this morning and here's what I got. It's a bit
hackish, but to do the job properly would require a parser so yeah...

Why not just edit the individual files' main() functions (in a build
directory) and generate a main.c, compile them, and link the object
files together? Don't have to worry about anything except main(),
then.

Thanks,
cls

[Connor Lane Smith]

Post by Connor Lane Smith
Why not just edit the individual files' main() functions (in a build
directory) and generate a main.c, compile them, and link the object
files together? Don't have to worry about anything except main(),
then.

An update: I've done this, and added it to the Makefile. It's a little
simpler than doing it by concatenating all the sources, since we don't
need to worry about statics or anything. Currently sbase-box comes out
at 69K statically linked against musl, or 23K dynamically linked
against glibc.

So next I'll carry on with the items in TODO. Any contributions are welcome. ;)

Thanks,
cls

[Rob]

Post by Connor Lane Smith
An update: I've done this, and added it to the Makefile. It's a little
simpler than doing it by concatenating all the sources, since we don't
need to worry about statics or anything. Currently sbase-box comes out
at 69K statically linked against musl, or 23K dynamically linked
against glibc.

That looks much nicer than my script, actually, nicely done.

[Connor Lane Smith]

Post by Rob
I was wondering whether to do that or not, it's pretty useful but
there's a fair bit more code. I'll leave it to cls to decide.

Thanks. I actually decided the name system is better, since only that
is required by POSIX, and it means we can use the same arg parsing as
every other util.

cls

[Connor Lane Smith]

Post by Connor Lane Smith
Thanks. I actually decided the name system is better, since only that
is required by POSIX

Though we can allow signums for '-s', despite its not being strictly POSIX.

cls

[Connor Lane Smith]

Post by stateless
Attached cmp.c and cmp.1.

Thanks! I'm also not bothering with '-', so I took that out, which
meant we could simplify the code a lot.

cls

[Anthony J. Bentley]

Post by Connor Lane Smith

Post by stateless
Attached cmp.c and cmp.1.

Thanks! I'm also not bothering with '-', so I took that out, which
meant we could simplify the code a lot.

Don’t we have /dev/stdin for that anyway?

--
Anthony J. Bentley

[Szabolcs Nagy]

Don???t we have /dev/stdin for that anyway?

no
/dev/stdin, /dev/fd/0, /proc/self/fd/0 are non standard and
not always available (even on linux systems)