Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

37%
+1 −3
Q&A What is cat abuse/useless use of cat?

UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before. cat is actually a program for concat...

posted 2mo ago by matthewsnyder‭  ·  edited 2mo ago by matthewsnyder‭

Answer
#9: Post edited by user avatar matthewsnyder‭ · 2024-03-24T05:48:33Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming up with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his brilliance!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `grep cookies <file1 | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming up with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his brilliance!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#8: Post edited by user avatar matthewsnyder‭ · 2024-03-24T02:28:48Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his brilliance!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming up with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his brilliance!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#7: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:24:31Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his brilliance!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#6: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:24:19Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He knows it doesn't matter! He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#5: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:22:22Z (about 2 months ago)
#4: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:20:43Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on puny little micro-computers, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#3: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:19:37Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline`, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#2: Post edited by user avatar matthewsnyder‭ · 2024-03-24T01:18:44Z (about 2 months ago)
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, cat or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline`, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
  • UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.
  • `cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.
  • Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.
  • Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?
  • The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.
  • How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, `cat` or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline`, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.
  • But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:
  • * "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
  • * "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
  • * There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.
  • But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"
  • I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!
  • As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.
#1: Initial revision by user avatar matthewsnyder‭ · 2024-03-24T01:16:32Z (about 2 months ago)
UUOC is an ancient Unix yarn. I can't find the original essay (I believe from Usenet, where else...) but if memory serves it's either from early 90s or before.

`cat` is actually a program for con**cat**enating files. `cat file1 file2 ...` will give you `file1+file2+file3`. Together with `split`, this is a primitive but effective system for partitioning and reassembling files. And when the files are text, it's a useful tool for transforming the text in various ways.

Of course `cat file1` does nothing. It just gives the file back as is. Useful though concatenation is, many people rarely use it, and a lot of newbies acquire the misapprehension that `cat file1` means "print `file1`", and by the time they see `cat` actually used with multiple arguments and discover the truth, the muscle memory has long set in.

Unix really does have a way to "print `file1`" which is `<file1` - the brother of "write to `file1`" which is `>file1`. See? Perfectly logical! Of course, `<file1 | grep cookies | wc` looks ridiculous, so even after learning this, people don't want to do it. Ditto for `grep cookies file1` - yes, `grep` can take input not only on STDIN... And yet, why bother, when `cat file1 | grep cookies | wc` looks so much neater?

The problem with this so called UUOC (or "cat abuse", someone must have felt mighty clever coming with that one) is that you run one more program. Another thing newbies don't realize is that programs in a Unix pipeline don't run one after the other - they run *all at once* and process input *concurrently* - just like a pipeline, see? So with UUOC you add an extra program, `cat`, to the pipeline and waste CPU cycles. But if you did `<file1` the OS reads it directly from the file, so you don't waste the CPU cycles, instead you waste brain cycles trying to remember what `<` is and why it's pointing in the wrong direction.

How much CPU cycles? Actually very little. `cat` is a very efficient program. If you're doing only `cat file1` to see the file, your computer is a mega-turbo-overkill for doing that, cat or not. You'll be bottlenecked by the speed of printing the characters out on your screen, not `cat`. If you're using it as the first step of a processing pipeline`, probably all the other programs are either simple in which case it's still mega-turbo-overkill (or hey, maybe just turbo-overkill), or they're *heavy*, and what counts as "heavy" for a computer today is a gazillion times more than the burden of running little old `cat`, so it doesn't matter.

But people *looove* pointing out cat abuse. You gotta admit, it has a real satisfying feel to gotcha someone with that one. "What are you concatenating?" - ha ha! So often, the argument will go on to reveal more pearls of Unix wisdom:

* "But what if you were on a tiny computer, like an SBC?" indeed, if you're running pipelines on these kinds of metal, mayhaps the humble `cat` will trip you up (aaah... 🐈).
* "But what if the file was huge, and you needed to do seeks in it?" indeed, some programs like `less` are *zippy* and can skip right to line 813,745,714 of that mammoth file, without first going through the eight hundred thirteen million seven hundred forty five thousand seven hundred thirteen preceding lines. How clever! The next time you use `less` to get the one line from the middle of your 5 petabyte diary, watch out for that dastardly `cat` 😼.
* There are surely many others - mine own beard is but a few fingers' length, so surely there are wiser heads with greyer growths than me that see *further* and *deeper*.

But, probably you encountered this while asking for help on a forum. You posted some logs to show where the problem is. And you thought you'd be extra helpful and include your command, so they can tell exactly where you're getting the 1 MB log and what trivial filtering you're insulting your 16-core gigahertz processor's intelligence with. "They can reproduce it on their own machine that way!"

I choose to look past the semantics in such things, and examine the *pragmatics*. Is the helpful user *really* trying to micromanage your simple, lazy log read? Are they *really* trying to save you that 5 bytes of memory? Well, probably not. I mean, you think what, he's stupid? He's trying to *communicate* something to you. Namely, that he is not stupid, but sharper, more keen of eye, more discerning of the smallest ripple on the boundless Ocean that is the modern Unix system. Recognize the mastery of this *o-sensei* and bask in his Glory!

As for the `cat`, it's probably fine, don't worry about it. Just don't tell the guy you're probably gonna keep doing it anyway.