considered harmful

http://harmful.cat-v.org/software/
>2013
>using harmful software

>>80
Text is better naturally divided into words or sentences.

HIBT?

>>74
Have you read your REST today?:
http://en.wikipedia.org/wiki/REST

>>78
http://www.mcsr.olemiss.edu/unixhelp/
http://www.cs.duke.edu/csl/docs/sysadmin_course/
http://www.cs.duke.edu/csl/docs/unix_course/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics.html

>>82
REST
Back to Hacker Hymies, ``please''.

>>83
>hymies

EGIN

>>82
Why do they call it ``REST'' when its real name is HTTP?

>>82
http://www.mcsr.olemiss.edu/unixhelp/
That version's outdated by 12 years, dood.

http://unixhelp.ed.ac.uk/

>>75
It's not that it blocks until it sees a full line, it's that it guarantees that it will output the full line with a single `write` call, presumably so that it will be returned by a single `read` call to the next program in the pipeline. Which means that those programs rely on a broken stream abstraction: suddenly fragmentation is no longer an implementation detail but an essential side-channel, the stream protocol is transformed into a datagram protocol, in a completely ad-hoc, unreliable way.

The fact that read(1) makes this guarantee does not mean that downstream filters are compelled to rely on it. It is still perfectly sensible to continue writing programs that can handle a partial read(3) for compatibility with older Unix. However if you need to work with a broken program you at least have the option.

I also don't accept that relying on one-write-per-read behavior is necessarily unreliable. If the reader and the writer agree on the format of the data to be exchanged, they can easily structure it in a way that allows its correctness to be verified by the reader. There's no guaranteeing that a bad writer will produce correct-looking input by coincidence, but there's no way to avoid that in all cases anyway.

>>75
Also, if you need to use a program that expects to read(3) only once per line to filter output from a program that fragments its writes, the solution is simple: just pipe the input through read(1) first.

>>76,77
Same here when I read >>49.

>>80
How long is a line? That is the big issue.

>>88
The solution is to rewrite the broken program. Many of the standard *nix utilities don't even need to hold entire lines, like cut. (How to implement this is left as an exercise for the reader. Anoncoreutils might have some inspiration.)

>>89
How to implement this is left as an exercise for the reader
triez man. like da kool kidz do.

oh neffermind. looks like we have a counter kid on our hands

>>91
LOL TWENTY? Looks like we have a caterpillar on our hands.

>>87,88
That read(1) writes entire lines is a symptom, I argue that the OS itself must be retarded to guarantee that reads are matched to writes.

This breaks an abstraction of a stream protocol, converting it to a somewhat message-oriented protocol.

This is bad in practice because now if you want to transparently pipe stuff through a real stream protocol, like tcp/ip, suddenly the OS has to implement an actual message-oriented protocol on top of that, on the off-chance that some moron depends on the guaranteed property.

What's worse, the guaranteed property is useless since read(2) can't allocate the buffer itself, so it is impossible to utilize it reliably in a general-purpose utility, so it's going to be used by morons writing unreliable programs only, indeed. And! And it encourages morons to write broken programs!

And if you're writing a special purpose program, you can use a real message-oriented format, maybe? And a library function like strtok for tokenizing your shit, instead of an external utility? Because you can't have external utilities all the way down, at some point you have to use a library function for parsing the output of an external utility?

Any guarantee is a liability. Any additional programs exposing and complimenting the guarantee increase the burden. A guarantee completely unrelated to the abstraction at hand is bad. Making a guarantee that is not only mostly useless, but also impossible to use correctly is insane.

I'm saying that with a fucking baobab like that in their collective eye, Plan9 developers have no business Considering stuff Harmful.

PS: don't put the empty line after a quote, this is not reddit.

>>93
Nc and sed/wak
They're the logic lot♫

s/wak/awk/

>>93
I argue that the OS itself must be retarded to guarantee that reads are matched to writes.
The OS isn't doing that. read(1), the user program, does that; other programs can do as they like.

This is bad in practice because now if you want to transparently pipe stuff through a real stream protocol, like tcp/ip, suddenly the OS has to implement an actual message-oriented protocol on top of that, on the off-chance that some moron depends on the guaranteed property.
Again, you don't have to do what read(1) does. It would be insane to suggest otherwise.

What's worse, the guaranteed property is useless since read(2) can't allocate the buffer itself, so it is impossible to utilize it reliably in a general-purpose utility, so it's going to be used by morons writing unreliable programs only, indeed. And! And it encourages morons to write broken programs!
Caller-allocates-memory is standard practice for C programs, and for a language that operates at a systems level it's the only sane thing to do. The read routine should not be responsible for allocating memory when the caller knows best where the read buffer ought to be.

Also, saying that it's impossible to use read properly is just total bullshit. Allocate a fixed size buffer, call read with the size of the buffer, check the return value. That can't overflow, ever.

I argue that the OS itself must be retarded to guarantee that reads are matched to writes.
The OS isn't doing that. read(1), the user program, does that; other programs can do as they like.
ur tarded. You can't implement read(1) guaranteeing atomic `read` on an OS that doesn't guarantee atomicness of reads and writes. The fact that they flaunt the tarded decision by implementing userspace programs that reinforce the guarantee means that they're all retarded.

Again, you don't have to do what read(1) does. It would be insane to suggest otherwise.
Not me, nobody has to do that, nobody wants to do that, and yet they guarantee that.

Caller-allocates-memory is standard practice for C programs, and for a language that operates at a systems level it's the only sane thing to do. The read routine should not be responsible for allocating memory when the caller knows best where the read buffer ought to be.

Why do you explain the obvious? Do you believe that if you explain the obvious, no, wait a second

Also, saying that it's impossible to use read properly is just total bullshit. Allocate a fixed size buffer, call read with the size of the buffer, check the return value. That can't overflow, ever.
Ah! You are retarded in truth! Like, I'm not trying to offend you, but I realize that you're actually retarded and unilaterally terminate the discussion.

>>99
your dubs are considered harmful

>>98
False. Dubz considered nice.

>>99
s/nice/checked/

_____
| moo |
 -----   \ n_n
          (. .)_______
          \ v    \_/  |
           \_________\
             |    \/\/|

I like you're custom cowsay, >>101-san. It is quite kawaii^[1] if I do say so myself.
____________________________________
_{[1] Translator's note: ``kawaii'' means ``cute''.}

>>40

Vala compiles to C (with heavy GLib use), but Uriel was a fucking retarded guy, so he catalogued Vala as harmful.

>>103
Dude, who the fuck would use an under-specified C# clone just for writing GTK+ apps?

>>104
Who the fuck would use C#, besides for sucking MS cockNet?

>>105
C# is a better Java.
and Scala is best than both.

>>97
I understand that you might have gotten confused by the documentation, but you make too many assumptions and criticize it based on that. You suggest that the single write(2) call that read(1) performs after it has found the line break will be matched by a single read(2) by the next process in the pipe line, but this is not the case. It says that it's helpful, and that's all it is, and I'll tell you why.

The process that receives what read(1) wrote can have a buffer of any size and can call fgets(3) or read(2) directly to get as much as possible of the line at a time. If the buffer fills, then read(2) more. What the receiver doesn't have to do is to look for the line break. This does not mean that the whole line was received in one read(2) call.

When read(2) returns a non-negative number less than the size of the buffer, the receiver knows that it has gotten one line. Does this mean that the receiver has to assume that its input came from read(1)? No, what the line-at-a-time program will do is parse the buffer again on its end and look for a line break (with the help of fgets(3), for instance). The parsing starts when read(2) returns, and wouldn't you know it, the input looks exactly like you want it to; there's not even anything past line break, and nothing in the buffer has to be moved for the next read(2). Of course, if the line is too long and the buffer is too small, read(2) will return many times and the buffer has to be resized.

The processes that receive their input from read(1) will also get the input as soon as it's available, which is both helpful and useful for interactive shell scripts.

JUST USE GETS AND PUTS YOU FUCKING FAGGOTS

YOU MENA PEEK AND POKE

>>108
NOPE, I WILL CONTINUE TO USE INSERT AND SELECT.

Triples!

>>107
>>97's point is that requiring write(2) to always complete on the first attempt places an undue burden on the OS. If the output device or file cannot accept writes over a certain size, the OS is now obligated to buffer the whole input and fragment it itself, rather than just accepting as much as will fit and relying on the caller handle the rest.

The argument is that this added complexity is pointless as in the general case the reader will end up fragmenting the data anyway because it can't guarantee all of it will fit in the buffer it allocates for read(2).

>>38
>look at my mommy!  I'm trolling on 4chan!

>>113
jesus christ... did you actually read anything more than the last 5 posts? did you SERIOUSLY read the thread? or are you just advertising your own post?

autism

>>113,114
back to /g/, /g/ shitstain

>>115
LLLLLLLLLLLLLEEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>LE CRETIN XDDDDDD

>>112
In the write(2) syscall, keeping track of how much has been written is very little added complexity for much gain. Also, when you write(2) to a pipe, it doesn't go directly to the read(2)er's buffer, no matter how big or small it is, but to the pipe buffer (you can start writing before there's a reader). You only write to a file descriptor, not to a receiving read(2) call.

On UNIX, when you write(2) to a file descriptor (say, a socket) that isn't ready to receive the whole buffer at once, the call might return early with a partial write success. What will the caller do now, when only some data has been written? Call write again and again until everything has been written, or write(2) returns a negative value. Is there any other valid action to take than to continue writing? You can never know (or should never have to care) what's small enough for the file descriptor you're writing to so that write(2) is guaranteed to succeed.

It's no problem for an operating system to perform this loop itself. It knows everything about the file descriptor, things that user space programs shouldn't have to care about. It knows when it's possible to write again and how it's most efficiently done. When a socket or pipe buffer is full, the thread can wait until it is writable again, and yield to the dispatcher in the mean time. When it's possible to read again, resume the write by moving a new range of bytes from user memory to the IO device's buffer page, and repeat until everything's written and return to user space or if there's an IO error return early. Why is it better to have every program include a write(2) loop, rather than having a better write(2) syscall?

Plan9 does writing this way. The manual states that if write returns anything less than what was intended, it should be considered an error (http://plan9.bell-labs.com/magic/man2html/2/read). Now, say you run read(1) from plan9port on linux. There's a single write(2), which might not write everything the first time, and the receiver will only get as much as fit in the pipe. read(1) has a bug when run on this system, although it won't appear very often.

anus

>>107,112,117
No, wait, you're discussing wrong things.

* I don't have a problem with write blocking until all data was written, in fact I think that's the Right behaviour.

* After some consideration, I think that it should be guaranteed that `read` will return early if there is insufficient data in buffer, because it is necessary for interactive programs to work and is a more or less natural, expected behaviour.

* It must not be guaranteed that read will never return less data than the corresponding write has written; in other words the OS should be allowed to introduce additional fragmentation.

Not giving such guarantee is useful because most other stream protocols do not give it either, so not allowing OS to introduce additional fragmentation for pipes means that instead of sending data directly to the tcp/ip driver it should wrap every `writ`ten buffer in a message with length and shit, send that, collect the entire message in a dynamically reallocated buffer on the other side, and only then give it to the program waiting on read.

Giving such guarantee is useless because you have to check if your buffer ends with newline or whatever other delimiter you expect your source to use when read returned sizeof(buffer) anyway, so just check buffer[len-1] always.

Giving such guarantee is harmful because it encourages programmers to assume that lines longer than 8192 or whatever bytes don't real instead of doing the aforementioned check.

* It probably should not be guaranteed that read will never return more data than a single write has written; in other words the OS should be allowed to remove fragmentation when it has enough data available.

This is useful because tcp/ip does this (for performance reasons, which are important to us as well), as far as I know. Not forcing OS to do retarded things to stream pipes over tcp/ip is good.

Having such guarantee is mostly useless, because why don't you play safe and properly search the data for the delimiter you want, instead of having an unwritten requirement that something earlier in the pipe should split output using that delimiter? The only thing that you can't do otherwise is, well, consume a single line from input, but idk, that actually sounds harmful. That's not how piping should work, in my opinion. You want to send parts of the stream to different program, use xargs or something, that shit is too rarely used and too magical to be allowed to contaminate the core abstraction.

I LIKE MY OPERATING SYSTEMS LIKE I LIKE MY WOMEN
IF THEY DON'T FINISH I JUST JAM IT IN AGAIN