Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

suckless unix tools

Name: Anonymous 2015-04-02 21:41

Name: Anonymous 2015-04-03 0:00

>>5
No, it is not. Let's see

The echo utility shall not recognize the "--" argument in the manner specified by Guideline 10 of XBD Utility Syntax Guidelines; "--" shall be recognized as a string operand.

Implementations shall not support any options.

Name: Anonymous 2015-04-03 8:36

Suckless? LOL, more like dickless, even the echo is wrong. And that's the easiest of them.

Name: Anonymous 2015-04-03 11:36

Name: Anonymous 2015-04-03 11:49

Name: Anonymous 2015-04-03 12:28

>>6

I presume "loons" is a typo of "looks". If I understand you
correctly, you are wrong:

; ./echo -h -a hello
-h -a hello

Are you suggesting you thought it would not print '-h -a'?

Name: Anonymous 2015-04-03 13:40

For comparison, Cudder's echo(1) from anoncoreutils[1]

/* @echo.c */
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv) {
int i=1, no_nl=0, ret=0;
if(argc>1 && !strcmp(argv[1],"-n")) {
no_nl=1;
i++;
}
while(i<argc) {
ret|=(fputs(argv[i++], stdout)==EOF);
if(i!=argc)
ret|=(fputc(' ',stdout)==EOF);
}
if(!no_nl)
ret|=(fputc('\n',stdout)==EOF);
return ret;
}


[1] http://rechan.eu.org/misc/anoncoreutils-20080617-2.tar.bz2

Name: Anonymous 2015-04-03 13:41

And here's sbase echo(1) [1]

/* See LICENSE file for copyright and license details. */
#include <stdio.h>
#include <string.h>
#include "util.h"

int
main(int argc, char *argv[])
{
int nflag = 0;

if (*++argv && !strcmp(*argv, "-n")) {
nflag = 1;
argc--, argv++;
}

for (; *argv; argc--, argv++)
putword(*argv);
if (!nflag)
putchar('\n');

return 0;
}


http://git.2f30.org/sbase/tree/echo.c

Name: Anonymous 2015-04-03 13:59

I SUMMON LAC!!!

Name: Anonymous 2015-04-03 16:16

I think the command ``command'' is very useful, especially the -v option.

When the -v or -V option is used, the command utility shall provide information concerning how a command name is interpreted by the shell.

So you can do ``command -v program'' and get the location of ``program''. It's pretty neat.

Can sbase get this command, please?

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Name: Anonymous 2015-04-03 20:59

It lacks error handling, below is bash's echo
$ echo test > /dev/full
bash: echo: write error: No space left on device
$ echo $?
1


Bellow is suckmore's echo
$ echo test > /dev/full
$ echo $?
0


Based on POSIX if an error has occurred echo should return a value bigger than 0. It also may use stderr for diagnostic messages.

Name: Anonymous 2015-04-03 21:28

>>16

This is a "known issue".
Basically, on return, the system flushes all buffers. in case flushing errors-out (the libc fails to write its internal buffers to the kernel device) it can't report an error and ignores it.
GNU coreutils solve this by having an onexit-function doing the cleanup and reporting errors in case something fails.
However, _exit is usually used across sbase which doesn't call onexit-functions and generally speaking, onexit-functions are a pain in the ass to take care of.
Another idea was to have a efclose-function which closes stdin and stdout at the end and reports an error in case it fails. However, it's not simple to take care of that across sbase either. In the end, the conclusion was that this is a more or less non-priority issue.
This has been kept it mind, same with echo, but not reflected on it as there were more important issues.

If you have any ideas, let it be known.

Name: Anonymous 2015-04-03 21:36

I copy-pasted >>17 from IRC.
The developers said they won't use this BBS because they aren't hipsters and that people should send patches. They don't give a damn about anything but patches, even though >>7-san made them review echo(1).
Who the hell criticizes people testing their software and reporting bugs? LOL
I've never seen this before.

Name: Anonymous 2015-04-03 22:23

>>17
What's wrong with this? return fclose (stdout) == EOF;
It seems to work nicely for the case of >/dev/full, fflush works fine too.
Or they could just use write(2) like their friends at plan9, write does not use buffers. (or just disable buffering on stdout)

Name: Anonymous 2015-04-04 5:03

>>18 Why would they give a damn about this BBS... They don't get it, they're filthy casuals.
>>3 I remember... fuckn spammin his AnonOS project everywhere

Name: Anonymous 2015-04-04 19:05

>>18
4chan/g/ ``trolling'' mozilla. Social Justice Warriors spamming mailing lists. There's a reason for it.

Name: Anonymous 2015-04-04 19:49

Name: Anonymous 2015-04-04 20:20

>>22
Amazing how fast things can change when your code is not an XBOX HUEG pig disgusting mess.

Name: Anonymous 2015-04-04 20:28

suckless
The developers said they won't use this BBS because they aren't hipsters
in theatres september 1993
Potmeetskettle
"Hilarious!" - Paul Arden, Minneapolis Gazette

Name: Anonymous 2015-04-04 22:50

Name: Anonymous 2015-04-04 22:50

Name: Anonymous 2015-04-04 22:51

Name: Anonymous 2015-04-04 22:57

>>25-27
Go back to /g/, please!

Name: Anonymous 2015-04-04 23:33

Name: Anonymous 2015-04-05 2:13

Name: Anonymous 2015-04-05 7:23

Great Satori~n, this isn't just coreutils, it's a complete system, using musl libc, static linking, binary packages & source ports, etc. etc.

http://morpheus.2f30.org/

It's too bad the last update was 2014, they need more people to keep the packages current.

Name: Anonymous 2015-04-05 11:13

>>31
Alpine Linux is a complete system using musl libc.
Why not work on it instead of coming up with another distribution?
Just convince Alpine developers to migrate to sbase, sinit, etc. and be done with it.
Can you imagine Morpheus getting libreoffice, firefox and all other big programs? I can't.

Name: Anonymous 2015-04-05 11:44

>>30
Wow, nice. Except it should've been implemented in Haskell, not Racket.

Name: Anonymous 2015-04-05 23:02

>>33
Wow, nice. Except these dubs should have been gotten by a more worthy poster.

Name: Anonymous 2015-04-05 23:07

>>30
Who are you quoting?

Name: Anonymous 2015-04-06 5:20

>>35
*whom

Name: Anonymous 2015-04-14 15:42

Name: Anonymous 2015-04-14 15:58

/* because putting integers in pointers is undefined by the standard */
What? uintptr_t is very well defined.

Name: Anonymous 2015-04-14 19:29

>>38
uintptr_t is unsigned. It looks like the author wants a signed integer here and that is a significant difference.

Technically uintptr_t is also a POSIXism so if you actually care about non-Unix like systems it's best not to rely on it. Since this is a suckless project I assume that is not the case here, though.

Name: Anonymous 2015-04-14 19:59

SuckLess Unix Tools

Name: Anonymous 2015-04-15 16:16

>>39
How is it a POSIXism? It's standardized in C11 and was already in C99 if I remember correctly.

Name: Anonymous 2015-04-15 16:34

>>39
Why would anyone care about non-Unix platforms besides maybe Windows, which is never going to be truly portable without massive rewrites or compatibility layers anuway?

Name: Anonymous 2015-04-15 16:39

uintptr_t is unsigned. It looks like the author wants a signed integer here and that is a significant difference.

I don't know which commit you're referring to, but conversion from a signed integer of the same size to uintptr_t is well-defined by The Standard, see 6.3.1.3.

Name: Anonymous 2015-04-15 16:44

why would a pointer ever be "signed"?

a pointer difference I can understand but not this..

Name: Anonymous 2015-04-15 17:27

>>44
It's not the pointer that is signed, read DA STANDARD.

Name: Anonymous 2015-04-15 18:14

>>41
Unix programmers have been stashing pointers in longs and the like since (approximately) the beginning of time. POSIX provides cover for many historic practices like this one (use of void * to store function pointers is another example). C99 is too recent.

>>43
It may well be defined but the conversion is still destructive.

I will confess I forgot about intptr_t entirely. I believe this particular code could get away with using an intptr_t or if the the range of values to be stored will fit in an intptr_t.

Name: Anonymous 2015-04-15 18:44

>>19
I am guessing it is just laziness. According to >>17 sbase is relying on required implementation behavior of closing streams after exit, which is of course too late if you want to set the exit status should closing fail. This is painful if you have a lot of streams open but in the case of things like echo it is not so hard.

Name: Anonymous 2015-04-15 19:07

>>46
Too recent for what?

Name: Anonymous 2015-04-18 8:29

>>48
;) ur mom

Name: FRIGN 2015-04-18 18:23

>>47
No, it's not laziness. We found out it's not mandated by POSIX that the fclose-function should return an error in case the flush fails (yes, you read that right).
Glibc just behaves this way, and we only noticed that after testing with musl and discussing this with the musl-developers.

fshut() is the combination of literally a day's work of reading standards and applying best practices. A simple fclose() is not sufficient here.

Name: Anonymous 2015-04-18 21:36

>>50
I think the musl developers are being legalistic here. The description of fclose in C89 says it shall deliver buffered data to the host environment (just like fflush does) and return EOF if any errors occur. Not returning EOF for a write error just because it's not specifically called out like the fflush description does is bullshit, or at least very surprising.

Can you name any libc other than musl that behaves this way?

Name: Anonymous 2015-04-18 21:50

In fact, POSIX has exactly the same text in fflush and fclose in the RETURN VALUE section (except the "it shall set the error indicator for the stream" part simply because the stream will be closed).
It also says "The fclose() function shall cause the stream pointed to by stream to be flushed and the associated file to be closed". It does not say anything about not returning EOF if an error has happened in the flushing part.
And in fact, some of the ERRORS in the POSIX page are about flushing failing.

Name: Anonymous 2015-04-19 6:06

>>52
Yeah, looking at the POSIX.1-2013 version of the spec, if you look at the History section for fclose, you see that the errno values for the errors that could occur during fflush were added a couple of years before POSIX.1-2008 was ratified.

musl advertises itself as supporting POSIX.1-2008, but maybe the musl developers erroneously were looking at the older IEEE 1003.1-2001 spec when implementing some of those functions.

Name: Anonymous 2015-04-19 12:07

Name: Anonymous 2015-04-19 12:08

Name: Anonymous 2015-04-19 14:17

>>54
>>55
why are you linking this garbage?

Name: Anonymous 2015-04-19 16:45

>>55
recurse() is getting smarter every day. I expect it to pass the Turing
test in a few months.

Better hope Mentifex doesn't catch wind of this.

Name: Anonymous 2015-04-19 20:10

I hope Mentifex doesn't catch wind of this!

*farts*

Name: Anonymous 2015-04-19 21:02

>>58
I should hope he doesn't, you rude degenerate.

Name: Anonymous 2015-04-20 11:49

>>56
Optimize your quotes, 「下さい」

Name: Anonymous 2015-04-20 16:55

New commits. Check them out.

Name: Anonymous 2015-04-20 17:49

>>61
no

:grumpycat:

Name: Anonymous 2015-04-20 17:53

>>61
They commit too fast so it's not easy to track.

Name: Anonymous 2015-04-21 11:05

Tools still not implemented:
at
awk
bc
diff
ed
getconf
install
od
patch
pathchk
stty

Anyone interested in giving a try on one of these?
Send a patch.

Name: Anonymous 2015-04-21 13:36

It's now possible to tar multiple files in a single run
http://git.2f30.org/sbase/commit/?id=76aa9c05736b0e4e2f06fa45945e5cf702347c48

Name: Anonymous 2015-04-21 15:42

are you suckless developers?

why are you posting this here?

Name: Anonymous 2015-04-21 15:51

In the README0 it says tar is audited. Why so many changes and fixes, then? Audited should mean it's pretty close to perfect. Remove the audit flag and audit everything again, I propose. And keep doing that: multiple audits. What do you think?

0 http://git.2f30.org/sbase/tree/README

Name: Anonymous 2015-04-21 16:48

Why is there no dc? It's my favourite program. And it's the oldest language shipped in UNIX (older than C).

Name: Anonymous 2015-04-21 17:06

send a patch fgt

Name: Anonymous 2015-04-21 20:19

>>69
Sent :^)

Name: Anonymous 2015-04-21 22:49

why is this being spammed here

Name: Anonymous 2015-04-22 1:21

>>71
Because Cudder is all talk and no action, so his anoncoreutils failed hard.
sbase is actually good.

Name: Anonymous 2015-04-22 2:15

>>72
just stop

Name: Anonymous 2015-04-22 2:22

I sent a patch for st. I'm using st every day now, it's sugoi!

>>73
Your idle jealousy is showing, Cudder. Your anoncoreutils were in vain, because you didn't have what it takes to see things through to completion. If only you were a man, instead of being a girl who has long lost her innocence.

Name: Anonymous 2015-04-22 2:37

>>74
Can you send a patch to make st work with the keypress ``Delete''? Onegai, it makes me nervous.

Name: Anonymous 2015-04-22 10:04

>>75
There is already an optional patch for that!

http://st.suckless.org/patches/delkey

They also explain why del doesn't work by default in the FAQ:

http://git.suckless.org/st/tree/FAQ

Name: Anonymous 2015-04-22 10:19

>>75,76
Also, if you press Ctrl-H, it generates DEL.

Name: Anonymous 2015-04-22 11:44

Only on suckless, a ``simple terminal'' consists of a single file that measures over 4000 lines.

Name: Anonymous 2015-04-22 12:37

>>78
The next simplest X11 terminal emulator is uxrvt, and it's over 32,000 lines.

Name: Anonymous 2015-04-22 12:41

>>79
I somehow doubt that urxvt is a single file.

Name: Anonymous 2015-04-22 13:56

what are you posting here

Name: Anonymous 2015-04-22 14:24

>>80
Are you suggesting that if urxvt was converted into a single source file, it would magically be less than 4000 lines of code? Surely, you jest?

Name: Anonymous 2015-04-22 14:33

>>82
Are you illiterate or just pretending?

Name: Anonymous 2015-04-22 16:18

SUCKLESS FARTING

Name: Anonymous 2015-04-22 20:33

check out this sweet web page for a top replacement

https://mmonit.com/monit/

Name: Anonymous 2015-04-22 20:38

>>85
Javascript on, please!
How about no.

Name: Anonymous 2015-04-22 22:58

It happened again: http://git.2f30.org/sbase/commit/?id=43578242669d7f6bf7c3713d2745034acbc4b804
How can tar be marked as audited if commits like this one keep happening? Something's wrong.

Name: Anonymous 2015-04-23 2:24

why is this thread here?

>>87
wow they reimplemented tar. why?

Name: Anonymous 2015-04-23 2:28

http://lists.suckless.org/dev/1504/26135.html

le freedom hating /g/entoo installer :^)

oyyy lmoa wew these guys have their dank rare memes meming nice!

Name: Anonymous 2015-04-23 2:30

Name: Anonymous 2015-04-23 2:32

it's really fucking embarassing that /b/ has leaked so bad that this is now the norm

Name: Anonymous 2015-04-23 2:36

ok some faggot is trying to make us look bad by pasting crap from this thread into their ML:

http://lists.suckless.org/dev/1504/26153.html

Name: Anonymous 2015-04-23 3:44

Stupid thread. Worthless project. Stop posting this garbage.

>>92
It's you and you know it.

Name: Anonymous 2015-04-23 14:58

>>93
no it's genuinely not, I just discovered this and thought it would be useful for the shitters here to know.

Name: Anonymous 2015-04-23 17:27

>>94
How is that in any way useful?

Name: FRIGN 2015-04-24 8:51

>>87
Tuning in again, because a colleague linked me here.

Please do not misunderstand the term "audit" in this context.
It's not easily chosen, as we have security audits in relevant
places, but the raw term "audit" is equivalent to a "revision",
and that's exactly what I did in the code.

Over the years, we've improved our coding style and how to write good code, so the audits made sure these good styles were applied consistently across the base.

In no way does this claim the software is bug-free after an audit, only in a coding-state which we consider consistent.

It's easy to write bug-free software when it's trivial (e.g. echo, true, false, ...), but the more complex it gets, you can always hit new traps.
Don't shit your pants when we fix a bug in tar(1), the recent changes were fixes for edge-cases (limited user-namespace) and are an actual convenience to support tars with vendor-extensions.

We find bugs here and there, but overall, we have a stable product and for instance pass the busybox-tests without problems (modulo XSI-extensions).

Name: Anonymous 2015-04-24 15:18

Soon there will be trips, which is pretty nice. Otherwise this thread is useless.

Next time write your dickless tools in Rust. That would actually be useful.

Name: Anonymous 2015-04-24 17:47

>>97
Did you miss the "reasons not to use rust" thread? rust was btfo, provento be utter shit there

Name: Anonymous 2015-04-24 18:01

>>97
Rust sucks you loser. Gtfo!

Name: Anonymous 2015-04-24 22:23

Name: Anonymous 2015-04-24 22:33

Name: Anonymous 2015-04-24 22:45

Fuck off.

Name: Anonymous 2015-04-25 2:01

Fuck on!

Name: Anonymous 2015-04-25 2:18

Fuck high impedance?

Name: Anonymous 2015-04-25 16:42

>>96
Thanks for the clarification. For your sanity, please don't take the autists and trolls here too seriously when they critique your software, they're just doing it because they're bored and need something to shitpost about. The more intelligent among us understood what was meant by ``audit.''

Name: Anonymous 2015-04-25 19:00

>>105
Thanks for the clarification. For your sanity, please don't take the autistsshrine maidens and trollsyokai here too seriously when they critique your software, they're just doing it because they're bored and need something to shitcutepost about.
The more intelligentautistic among us understood what was meant by ``audit.''

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List