Discussion:
sbase
(too old to reply)
Connor Lane Smith
2011-05-23 02:15:43 UTC
Permalink
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
2011-05-23 02:33:59 UTC
Permalink
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
2011-05-23 03:37:52 UTC
Permalink
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
2011-05-23 10:43:15 UTC
Permalink
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/
--
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes fÃŒr Tastaturbenutzung
Jens Staal
2011-05-23 11:05:55 UTC
Permalink
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
2011-05-23 03:36:00 UTC
Permalink
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
2011-05-23 06:27:40 UTC
Permalink
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
2011-05-23 10:14:15 UTC
Permalink
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
2011-05-23 17:57:42 UTC
Permalink
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
2011-05-23 18:22:39 UTC
Permalink
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
2011-05-23 18:53:40 UTC
Permalink
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
2011-05-23 19:08:28 UTC
Permalink
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
2011-05-23 20:01:39 UTC
Permalink
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
2011-05-23 20:27:16 UTC
Permalink
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
--
# Kurt H Maier
Robert Ransom
2011-05-23 20:31:05 UTC
Permalink
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
2011-05-23 22:51:59 UTC
Permalink
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.
--
# Kurt H Maier
Connor Lane Smith
2011-05-24 00:17:20 UTC
Permalink
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
2011-05-24 06:00:02 UTC
Permalink
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
2011-05-24 09:23:14 UTC
Permalink
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
2011-05-24 00:58:52 UTC
Permalink
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
2011-05-24 01:33:22 UTC
Permalink
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.
--
# Kurt H Maier
Christian Neukirchen
2011-05-24 16:16:51 UTC
Permalink
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.
--
Christian Neukirchen <***@gmail.com> http://chneukirchen.org
Rafa Garcia Gallego
2011-05-24 17:12:56 UTC
Permalink
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
2011-05-25 08:54:50 UTC
Permalink
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
2011-05-25 09:25:58 UTC
Permalink
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
2011-05-23 08:16:57 UTC
Permalink
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
2011-05-23 08:45:16 UTC
Permalink
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
2011-05-23 10:05:55 UTC
Permalink
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
2011-05-23 11:12:56 UTC
Permalink
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
2011-05-23 12:37:25 UTC
Permalink
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
2011-05-23 13:50:06 UTC
Permalink
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
2011-05-24 10:45:14 UTC
Permalink
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.
--
Pierre 'catwell' Chapuis
Connor Lane Smith
2011-05-24 10:54:11 UTC
Permalink
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
2011-05-24 11:12:39 UTC
Permalink
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
2011-05-24 11:57:21 UTC
Permalink
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
2011-05-24 12:07:18 UTC
Permalink
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
2011-05-24 12:17:41 UTC
Permalink
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...
--
Pierre 'catwell' Chapuis
Szabolcs Nagy
2011-05-23 08:42:13 UTC
Permalink
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
2011-05-23 17:05:08 UTC
Permalink
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.
--
# Kurt H Maier
stateless
2011-05-23 14:43:48 UTC
Permalink
Added pwd.
Sir Cyrus
2011-05-24 19:10:54 UTC
Permalink
Not too clued in on coreutils alternatives, but what's wrong with busybox?
Troels Henriksen
2011-05-24 19:19:37 UTC
Permalink
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.
--
\ Troels
/\ Henriksen
Sir Cyrus
2011-05-24 19:25:43 UTC
Permalink
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
2011-05-24 23:57:07 UTC
Permalink
Maybe most people on earth aren't masochists and try to do something
more productive instead?
Connor Lane Smith
2011-05-25 00:29:49 UTC
Permalink
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
2011-05-25 07:31:37 UTC
Permalink
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
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Kurt H Maier
2011-05-25 12:30:48 UTC
Permalink
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.
--
# Kurt H Maier
Connor Lane Smith
2011-05-26 05:19:22 UTC
Permalink
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
2011-05-26 06:18:22 UTC
Permalink
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
2011-05-26 06:39:49 UTC
Permalink
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
2011-05-26 12:02:14 UTC
Permalink
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
2011-05-26 18:45:13 UTC
Permalink
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
2011-05-26 19:01:15 UTC
Permalink
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
2011-05-26 19:46:50 UTC
Permalink
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.'
--
# Kurt H Maier
Connor Lane Smith
2011-06-08 16:58:00 UTC
Permalink
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
2011-06-09 12:40:46 UTC
Permalink
Attached cmp.c and cmp.1.
stateless
2011-06-09 12:48:08 UTC
Permalink
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
2011-06-09 12:54:21 UTC
Permalink
Small update, attached cmd.c and cmd.1.
stateless
2011-06-09 12:54:57 UTC
Permalink
Arrgh fucking gmail.
Rob
2011-06-09 13:00:19 UTC
Permalink
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
2011-06-09 13:01:21 UTC
Permalink
Post by stateless
Arrgh fucking gmail.
+1
stateless
2011-06-09 13:06:48 UTC
Permalink
No worries Rob! :)
Hiltjo Posthuma
2011-06-09 15:06:26 UTC
Permalink
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
2011-06-09 15:28:39 UTC
Permalink
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
2011-06-09 22:24:01 UTC
Permalink
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
2011-06-10 02:26:26 UTC
Permalink
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
2011-06-10 05:55:00 UTC
Permalink
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
2011-06-10 12:25:32 UTC
Permalink
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
2011-06-10 12:38:21 UTC
Permalink
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
2011-06-10 13:24:51 UTC
Permalink
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
2011-06-09 22:25:40 UTC
Permalink
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
2011-06-10 00:20:02 UTC
Permalink
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.
--
# Kurt H Maier
Connor Lane Smith
2011-06-10 03:30:02 UTC
Permalink
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
2011-06-10 13:23:13 UTC
Permalink
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
2011-06-10 13:24:30 UTC
Permalink
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
2011-06-10 23:40:21 UTC
Permalink
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
2011-06-16 01:18:28 UTC
Permalink
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
2011-06-16 19:59:17 UTC
Permalink
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
2011-06-10 01:32:35 UTC
Permalink
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
2011-06-10 02:14:34 UTC
Permalink
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
2011-06-10 00:58:25 UTC
Permalink
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
2011-06-10 01:22:47 UTC
Permalink
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
2011-06-10 07:57:46 UTC
Permalink
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)
Continue reading on narkive:
Loading...