Live data from Hacker News

How efficient can cat(1) be?

ariadne.space

31–40 of 51 posts

Re: How efficient can cat(1) be?

#32

Earlier quoted context omitted.

Should sendfile(2) not report error if it managed to send a non-zero amount of data? IIRC write(2) behaves like that.

I don't honestly remember all of the write semantics - I thought it will only not report error if it gets interrupted by a signal handler after it wrote something. In case of true error, i thought it always return an error. write does have a weird error-checking semantic - you can get it to check for a bunch of errors without writing data by using a count of 0. At least as documented, sendfile does not have any of th…

As documented, sendfile (I haven't looked at whatever this "spliced_copy" is) does what Joker_vD said it should: if it does a partial write then it is considered "successful" and the caller is required to retry the call if less than the expected amount of data was sent.

Re: How efficient can cat(1) be?

#33

From my experience, it will never be so efficient that someone smarter than me doesn't publicly shame me for winning the "useless use of cat" award on a forum where I ask for help. 28 years later and I'm still sore I asked for help as a 15 year old that one time. Very effective way to teach a new user.

that’s a lesson that’s no longer applicable on modern machines I think? —- it often makes sense to start a sequence of piped commands with a cat invocation. One reason is that then the order of sources and sinks in the command syntax matches reality.

Re: How efficient can cat(1) be?

#34
post #10

Slightly out of topic: > There have been a few initiatives in recent years to implement new a new userspace base system for Linux distributions as an alternative to the GNU coreutils and BusyBox. Have there been? And why?

> Have there been? And why?

A few reasons why people might want to do this:

- Optimizing for small approachable codebase instead of featurefulness or performance (sbase)[1]

- Dissatisfaction with GPL (toybox)[2]

- Desire to replace C (described as an "unsafe" language) with Rust or Go (examples exist but I don't know of specific ones)

[1]: https://core.suckless.org/sbase/

[2]: https://landley.net/toybox/

Re: How efficient can cat(1) be?

#35

From my experience, it will never be so efficient that someone smarter than me doesn't publicly shame me for winning the "useless use of cat" award on a forum where I ask for help. 28 years later and I'm still sore I asked for help as a 15 year old that one time. Very effective way to teach a new user.

that’s a lesson that’s no longer applicable on modern machines I think? —- it often makes sense to start a sequence of piped commands with a cat invocation. One reason is that then the order of sources and sinks in the command syntax matches reality.

I always pipe from cat, as a matter of habit.

Reason being: I've probably just catted the file at least once, and it's even likely I catted it right before piping it. So I can extend that command from the history, and if I keep piping (likely) I don't have the weird syntactic stutter at the beginning where `blah Also, you can't mistype `cat file.txt | blah` and overwrite file.txt accidentally with the output of blah. That's ergonomic.

Re: How efficient can cat(1) be?

#36
Tangent: It frustrates me that it's apparently impossible to implement cat(1) in a truly portable way.

The problem is supporting unbuffered I/O (`cat -u`). Standard C simply can't do it. setvbuf(3) allows you to change the buffering on an I/O stream, but then fread(3) only allows you to read exact-sized blocks of data. You can only get a short read on EOF or error. So there is no way to say "give me as much data as is available, up to X amount of bytes" and therefore no way to implement unbuffered cat(1) efficiently using only ISO C. You need POSIX for that.

Re: How efficient can cat(1) be?

#39

From my experience, it will never be so efficient that someone smarter than me doesn't publicly shame me for winning the "useless use of cat" award on a forum where I ask for help. 28 years later and I'm still sore I asked for help as a 15 year old that one time. Very effective way to teach a new user.

Another reason I still use "cat" is that I don't want the remaining commands to modify the input file, but I don't want to spend the time to inspect the command line to make sure that is the case.

For example I'm pretty sure "grep" won't change the input file but "sed" may depending on the "-i" flag. Using "cat" conveniently bypasses all that thinking because the program only gets stdin from a pipe.

Post reply on HN