Earlier quoted context omitted.
Pinfo makes regular man pages navigable.
I'm having a great Linux day! TIL about 'splice' and 'pinfo'. Thanks!
How efficient can cat(1) be?
31–40 of 51 posts
Re: How efficient can cat(1) be?
#32Earlier 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…
Re: How efficient can cat(1) be?
#33From 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.
Re: How efficient can cat(1) be?
#34Slightly 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?
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)
Re: How efficient can cat(1) be?
#35From 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.
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?
#36The 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?
#37Re: How efficient can cat(1) be?
#38Re: How efficient can cat(1) be?
#39From 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.
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.
Re: How efficient can cat(1) be?
#40 cat_spew()
Eww.