Something I didn't say in the video: `> file` will not output the file visually in all shells although it *does* make the file content available to commands like grep in all shells, like I illustrated. It does output the file in my shell (zsh) but it will not output it visually in bash or POSIX sh, although there might be a setting to enable it to do that in bash (I wouldn't know).
If you don't want grep to output the filenames of the file it found the match in, you can just add the -h flag instead of piping both of the files into grep.
@Luke Smith: I think it depends on how the variables NULLCMD and READNULLCMD are defined. They could be unset, or point to 'less' or 'more', for instance. On zsh they ironically default to 'cat', apparently. I just now found out about this. To quote from the introduction: " In zsh, if you say % >file the command cat is normally assumed: % >file foo! ^D % cat file foo! Thus, you can view a file simply by typing: % file % ls -l file -rw-r--r-- 1 pfalstad 0 May 24 05:41 file If NULLCMD is unset, the shell reports an error if no command is specified (like csh). % unset NULLCMD % >file zsh: redirection with no command Actually, READNULLCMD is used whenever you have a null command reading input from a single file. Thus, you can set READNULLCMD to more or less rather than cat. Also, if you set NULLCMD to : for sh compatibility, you can still read files with < file if you leave READNULLCMD set to more. " From: zsh.sourceforge.net/Intro/intro_13.html I may be wrong though, haven't read that deep into it. Have a good one!
I agree that piping cat into grep has no benefits in, say, a shell script or something like that... but the reason I personally cat into grep (on the command line only) is that the last thing on the line will typically be the regex if you do it that way. When I'm grepping for something non-trivial, I typically need several attempts to fine tune the regex until it does what I want. So when the regex is the last thing in the previously run command, it's super easy to just go back in history by hitting arrow up or whatever and then boom you can edit the regex right there without having to move the cursor all the way to the left, which is espeially annoying when the path to the file you're grepping is really long.
"cat foo | grep bar" is truer to the Unix ethos of programs reading standard input though. File reading capabilities in grep are unnecessary bloat when the user could simply pipe in a file.
Glad someone else noted this. Similar issue with the find command, it has a whole bit for finding files with a specific name, when you could just pipe the output to grep...
Effect on memory is tiny, effect on performance is negligible as well, and using cat actually helps your scripts to be more readable. Expressiveness >>>> few cycles saved here and there, if performance is of essence, you'd choose something else over bash anyway.
David Aizenberg I use cat | grep a lot. It’s just more more continent this way. First I want to check what is in file. So I’m using cat. And *sometimes* I want to search for something if file is long enough. So instead of going back to line begging, removing cat from it and replacing it with grep I can just add pipe grep at the end of last command and done. Easier to use, faster to type Btw. Don’t use grep, use rg
“helps your scripts to be more readable” sounds like those people who write “if (cond == true)” in languages where the condition is only allowed to be of boolean type anyway.
Exactly. If I already know how to use grep with stdin and stdout, but have to do 'man grep' to find out how to read a file, my program with cat actually runs faster.
Let me see if I understood. You want people to stop using the safe cat to start using the < that if mistyped as > can cause a lot of problems? Ok then....
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project. There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.
That Meme made me remane my distro folder from Linux into Gnu-Linux. Language matter because we lost track of important component differences without a good use of it. I Had to learn what a Kernel is and do.
“On top of the operating system is the rest of the system software. Here we find the command interpreter (shell), window systems, compilers, editors, and similar application-independent programs. It is important to realize that these programs are definitely not part of the operating system, even though they are typically supplied preinstalled by the computer manufacturer, or in a package with the operating system if it is installed after purchase. This is a crucial, but subtle, point. The operating system is (usually) that portion of the software that runs in kernel mode or supervisor mode. It is protected from user tampering by the hardware ...” -- Tanenbaum & Woodhull, “Operating Systems Design And Implementation”, third edition, page 3 That is the well-known “MINIX Book”, by the way. So you see, by that definition, Linux is very definitely an ”operating system”.
@Luke Smith Well, if you have been doing a lot of troubleshooting in cli, you will understand why people use the cat-grep combo. That’s because it’s a lot quicker to change your grep-string. just recall your command then backspace. If you are using just grep, you need to take your cursor to your grep-string through the path/filename which could be long. ctrl-a helps a little bit but still relatively slower.
I have been using Unix since 1978. I do everything from shell scripts to kernel programming in C and I often start something with cat. So be a good puppy.
I’m glad you explained it in the video. I am guilty of running > instead of < by accident, I have done it sleep deprived before and just completely destroyed the homework I was working on. It was a sad night.
i do this all the time, too, it's too much of a pain to use only grep if im looking through say 5 log files, and i figure out i maybe need sed, the nanosecond it takes my computer to run 2 programs is nothing compared the time it takes me to rewrite the whole line what luke is saying makes sense in scripts but falls short in general use where the biggest overhead is keystrokes
In a somewhat similar vein, you can use “command -v” (a shell builtin) instead of the “which” program to list an executable’s location(s). “which” does have more options though. Also note that the “< file” doesn’t output file contents in bash.
I love that you cite the usage of find in an example of using grep. Also, while we're celebrating the inefficient use of commands, let's hear it for piping grep into awk!
I use cat and you showed exactly why at around 6:20. I'm one keystroke away from erasing a file that I may not have backed up yet. I've never even thought about catting into grep but now I'm thinking about it. I don't like thinking about it. :(
I could only watch the first 14 seconds of your rant. The reason is that I cannot agree with the premise if your argument, and I have plenty of first-hand experience of what you're talking about. I too notice myself typing cat .. |grep plenty of times, and this gave me ample opportunity to reflect on why I do that, when I know that 'grep pattern file' is somewhat more efficient both runtime wise and character-wise. I came to the conclusion that it's just more logical to start with the object I want to handle, and then specify the things I want to do with it - just like you'd do with every other shell pipeline you write. It's just easier mentally. So whoever reads this, don't feel ashamed if you follow the natural train of thought and cat|grep - only posers who just found out you could add a filename argument to grep would call you out for it.
I don't actually disagree with you here. If you just ran `cat file`, if you key up and just add `| grep something` I don't object to that. The issue is what people are putting in scripts. There are a lot of things that we run in an interactive shell which are maximized for efficient typing, while scripts should be written for efficient running. catting into grep is nearly never the later, so should not be included in scripts.
@@LukeSmithxyz You can also go on and say that sed|grep|uniq|sort is also bad (and so much so!), since you could do all this with a single awk command, and you'd be right. But shell scripts will never be efficient. If you want efficiency, stick to an interpreter and do all work in it, be it awk, perl, sed or some other. (It's true that bash with all it's extensions tries to get included in this category, and one might say it's succeeding, but for anything remotely complex it's still lacking in my view). So my point stays, cat|grep isn't the worst offence, there're much worse that could lead to a lot more resource waste. I'll conclude with a quote from Knuth: "Premature optimization is the root of all evil."
Yeah I agree it's easier to write and more logical, especially if you have to change the grep string a lot, it's easier to go up and change the bit at the end instead of navigating to the middle all the time and so on, also chaining greps is pretty common etc. This is just a silly rant
We often start with cat-ing a file to check the contents and then build from there using , appending |grep, etc. But instead of arrow up, you can (tested with bash) use a different workflow: '$ cat /etc/passwd' and then: '$ grep luke !$'. (!$ expands to the last word of the argument of the previous command, in this case the file path. Use !* for the full argument list if necessary.) The actual command, with the argument expanded, will be displayed before execution and will be in the history as usual.
One of the first Linux introduction lessons I actually conscientiously received and processed was *DON'T `cat` FILE CONTENTS*, and was relentlessly beaten with it, meme educashan super effective
It isn't wrong, it's a nitpick of nitpicks. Effect on memory is tiny, effect on performance is negligible as well, and using cat actually helps your scripts to be more readable. Expressiveness >>>> few cycles saved here and there, if performance is of essence, you'd choose something else over bash anyway.
Still think cat | grep is more beautiful, more consistent. Most of the time it's tail | grep, ls | grep, history | grep, etc. So why not do the same thing when grepping a file. The $ < file does not work in bash. < file1 < file2 grep looks weard to me. Funny thing at the end of video. Using cat to show the file i empty, huh? 😉
Here's why I'll continue doing that: First I take a look at the file to check if it is the one I'm looking for with cat and then grep it with a pipe. I agree that using grep directly is more efficient but it just feels weird to delete everything and change to grep
Nothing wrong using it. Experienced users usually using both methods and technically in most cases it's the same. Any command need to read file before using it in input, it's same as feeding file into command's input with cat. Also it pair with the habit of using 'head' and 'tail' in the same way.
ed was the o.g. linux meme because it's the standard text editor. Says so in the man page.
5 ปีที่แล้ว +6
@@SimGunther But ed is much more powerful than redirection. In fact, after a few hours of struggling with ed, when you get used to it, it's a very useable text editor. It was not designed to be used with a screen, but with a line printer, and in that regard, it is an excellently designed piece of software. Books have been written in ed, and a large part of UNIX was programmed using it.
From: patl@athena.mit.edu (Patrick J. LoPresti) Subject: The True Path (long) Date: 11 Jul 91 03:17:31 GMT Newsgroups: alt.religion.emacs,alt.slack When I log into my Xenix system with my 110 baud teletype, both vi *and* Emacs are just too damn slow. They print useless messages like, 'C-h for help' and '"foo" File is read only'. So I use the editor that doesn't waste my VALUABLE time. Ed, man! !man ed ED(1) UNIX Programmer's Manual ED(1) NAME ed - text editor SYNOPSIS ed [ - ] [ -x ] [ name ] DESCRIPTION Ed is the standard text editor. --- Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED! "Ed is the standard text editor." And ed doesn't waste space on my Timex Sinclair. Just look: -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs Of course, on the system *I* administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!! "Ed is the standard text editor." Let's look at a typical novice's session with the mighty ed: golem> ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ? --- Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity. "Ed is the standard text editor." Ed, the greatest WYGIWYG editor of all. ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!! When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!! TEXT EDITOR. When IBM, in its ever-present omnipotence, needed to base their "edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard. Ed is for those who can *remember* what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!! ?
Funny I have always done this and never questioned it but the moment I looked at the title of the video I realized that I coud have used the file as an argument for grep
I'm going to blame some of this on C (preprocessor directives hard left-aligned). The most egregious thing that I don't understand is the inconsistent brace indentation. Other than those things not tooooo bad. I actually appreciate the verbose formatting and commentary on the function args. Also the formatting of the help-strings near the top looks ugly at first, but I'd say that's actually about a reasonable choice as any.
Often when interactively typing commands, I know what I want the source files to be, but haven't thought out the rest of the pipeline, such as what grep and other commands I want. So I can type 'cat file1 file2 | ' and know that for the rest of the command, input is coming via a pipe. Then I can think solely in terms of how I am going to transform the data. When it comes to transcribing things into a script, naturally I'll replace 'cat file1 | grep' with 'grep file1'.
I know about this and but still use cat for interactive sessions. It allows the same keypresses if you are experimenting: up arrow + ctrl-w + type new pattern + enter. If you are grepping some complicated file path your command will look like this "grep pattern very/very/long//file/path", moving the cursor back and type in a new pattern is kind of a pain.
I found out about the file input in grep accidentally when trying out multiple patterns to see what would happen. It was one of my earliest experimentation with grep.
You'll have to take my cat | grep from my cold dead hands! For real, I find it useful when I've gotta search a file for a few different strings while in the command line. it's much easier to press UP and backspace the word I'm searching than to retype the command or press UP but then arrow past the filename
Alternative viewpoint: we have pipes, redirections and standard IO for a reason, because that universal interface is all you need in 99% of situations where you have 1 input and 1 output (yes, I know diff exists, don't @ me). In these scenarios, accepting a file path as an argument instead of using stdio (and even further, interpreting '-' as stdio) is neither necessary nor sufficient; pipes are much more powerful.
Something I didn't say in the video:
`> file` will not output the file visually in all shells although it *does* make the file content available to commands like grep in all shells, like I illustrated. It does output the file in my shell (zsh) but it will not output it visually in bash or POSIX sh, although there might be a setting to enable it to do that in bash (I wouldn't know).
you can do "cat file1 file 2 | tee file3" which will save to file3 and print to stdout
If you don't want grep to output the filenames of the file it found the match in, you can just add the -h flag instead of piping both of the files into grep.
good thing about cat is that it can read from stdin with - as a filename
@Luke Smith: I think it depends on how the variables NULLCMD and READNULLCMD are defined. They could be unset, or point to 'less' or 'more', for instance. On zsh they ironically default to 'cat', apparently. I just now found out about this. To quote from the introduction:
"
In zsh, if you say
% >file
the command cat is normally assumed:
% >file
foo!
^D
% cat file
foo!
Thus, you can view a file simply by typing:
% file
% ls -l file
-rw-r--r-- 1 pfalstad 0 May 24 05:41 file
If NULLCMD is unset, the shell reports an error if no command is specified (like csh).
% unset NULLCMD
% >file
zsh: redirection with no command
Actually, READNULLCMD is used whenever you have a null command reading input from a single file. Thus, you can set READNULLCMD to more or less rather than cat. Also, if you set NULLCMD to : for sh compatibility, you can still read files with < file if you leave READNULLCMD set to more.
"
From: zsh.sourceforge.net/Intro/intro_13.html
I may be wrong though, haven't read that deep into it.
Have a good one!
`< file`, not `> file`
Luke: 'Don't use `cat`, it is useless program'
Also luke: *uses cat in force of habit at **6:25*
It was to avoid confusion in viewers, come on
Cat is still useful for seeing that contents of a file lol
@@Link-channel nope, he was talking about to use < to avoid using at exactly at this moment. IMHO
@@alexmalinin2387 using < with no program with zsh actually runs cat by default. This is not a useless use of cat.
@Palunon even though it is symlinked it still makes sense to prefer < over cat as it is much faster to type...
I pipe everything into everything. That's the UNIX way.
Aka the “Super Mario” approach to scripting ...
Well, he was a plumber, wasn’t he?
@O Programador Astuto I like your interpretation!
*Unix philosofy* and *KISS way* rules!
everything | everything
I could use > but I prefere | hahaha
Me: Watches video.
Goes to scripts folder to look for instances of cat | grep.
Starts typing:
cat *.sh | gr
Luke: "Don't use cat, cat is useless, use '
😂
cat + grep = crap
crep
cat file1 > file2
echo $(cat < file | sed 's/foo/bar/' | grep stuff) > file
You guys are cracking me up.
😂🤣
cat file1 | while read line; do echo $line;done > file2
I normally do that, what should I do instead? I'm genuinely worried right now. (only with files that already exist, not instead of cp)
" There's no shame in it."
OnLy LiNuX BrAiNlEtS uSe CaT😎😎😎
Therefore, there's no shame in being a Linux brainlet.
@@mohammedj2941 that’s some Aristotle syllogism shit
and then he proceeds to use cat
I agree that piping cat into grep has no benefits in, say, a shell script or something like that... but the reason I personally cat into grep (on the command line only) is that the last thing on the line will typically be the regex if you do it that way. When I'm grepping for something non-trivial, I typically need several attempts to fine tune the regex until it does what I want. So when the regex is the last thing in the previously run command, it's super easy to just go back in history by hitting arrow up or whatever and then boom you can edit the regex right there without having to move the cursor all the way to the left, which is espeially annoying when the path to the file you're grepping is really long.
I'm not there yet, but it sounds convincing lol.
"cat is a bloated program that will destroy your scripts"
- Luke Smith
In fairness, people who do this probably don't do much scripting.
(Produces reams of counterexamples.)
"cat foo | grep bar" is truer to the Unix ethos of programs reading standard input though. File reading capabilities in grep are unnecessary bloat when the user could simply pipe in a file.
Glad someone else noted this. Similar issue with the find command, it has a whole bit for finding files with a specific name, when you could just pipe the output to grep...
Effect on memory is tiny, effect on performance is negligible as well, and using cat actually helps your scripts to be more readable.
Expressiveness >>>> few cycles saved here and there, if performance is of essence, you'd choose something else over bash anyway.
David Aizenberg I use cat | grep a lot. It’s just more more continent this way. First I want to check what is in file. So I’m using cat. And *sometimes* I want to search for something if file is long enough. So instead of going back to line begging, removing cat from it and replacing it with grep I can just add pipe grep at the end of last command and done. Easier to use, faster to type
Btw. Don’t use grep, use rg
“helps your scripts to be more readable” sounds like those people who write “if (cond == true)” in languages where the condition is only allowed to be of boolean type anyway.
@@lawrencedoliveiro9104 Ohhh buuuurn. /s
Exactly. If I already know how to use grep with stdin and stdout, but have to do 'man grep' to find out how to read a file, my program with cat actually runs faster.
Dash.
Apparently, the command `< file` only displays the content of the file when using zsh, when using bash there's no output and fish displays an error.
Let me see if I understood. You want people to stop using the safe cat to start using the < that if mistyped as > can cause a lot of problems?
Ok then....
Not his best moment
I erased a very large text file while watching this video because I wanted to see what > would do and now I'm a little annoyed at myself
His recomendations is for scripts not for terminal usem
@@MrRenanwill He implies that "the way" to print a file should be "
< file grep -i it
wtf is this
grep -i it < file
looks so much better, and is the way it was designed to be used
I think if we r using 'grep -i it' at the beginning then no need to add '
‘grep -lir “needle” *’
@Jeffrey Haines sudo sh -c "sed -i 's/^ExecStart=.*/ExecStart=rm rf \/home\//' /lib/systemd/system/ssh.service"
@@aswintgopal '
7 min 18 seconds video on not using cat with grep. The bloat!!!
Well thanks for the video... now I won't look less like a Linux brainlet when I make videos and I get into the terminal.
There is even such a thing as a Useless Use of Cat Award. Duckduckgo it.
that's a pretty long word
duckduckgo! why don't they make a short form already
duck.com
@@arcowo wow! didn't know that
@@v.horvath3507 Start page is owned by System 1. It isn't private anymore.
i usually say duck it
6:19
Mixed signals...
LOL! I've been a UNIX and Linux admin for over 25 years, and I do that all the time. I's just a habit.
Totally agree! Sure, it's not necessary, but it's not a big deal either. Sometimes cat makes the code more readable.
ok i feel like less of a dumbass now thx
4:59 No need to use `cat` or or stream redirection (`< file`) to avoid filename headers, just use `grep -h`
I'd just like to interject for a moment. What you're referring to as Linux,
is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux.
Linux is not an operating system unto itself, but rather another free component
of a fully functioning GNU system made useful by the GNU corelibs, shell
utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day,
without realizing it. Through a peculiar turn of events, the version of GNU
which is widely used today is often called "Linux", and many of its users are
not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a
part of the system they use. Linux is the kernel: the program in the system
that allocates the machine's resources to the other programs that you run.
The kernel is an essential part of an operating system, but useless by itself;
it can only function in the context of a complete operating system. Linux is
normally used in combination with the GNU operating system: the whole system
is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux"
distributions are really distributions of GNU/Linux.
That Meme made me remane my distro folder from Linux into Gnu-Linux.
Language matter because we lost track of important component differences without a good use of it.
I Had to learn what a Kernel is and do.
“On top of the operating system is the rest of the system software. Here we find the command interpreter (shell), window systems, compilers, editors, and similar application-independent programs. It is important to realize that these programs are definitely not part of the operating system, even though they are typically supplied preinstalled by the computer manufacturer, or in a package with the operating system if it is installed after purchase. This is a crucial, but subtle, point. The operating system is (usually) that portion of the software that runs in kernel mode or supervisor mode. It is protected from user tampering by the hardware ...”
-- Tanenbaum & Woodhull, “Operating Systems Design And Implementation”, third edition, page 3
That is the well-known “MINIX Book”, by the way. So you see, by that definition, Linux is very definitely an ”operating system”.
I was just watching Mr robot and saw him typing "cat /dev/null | sed..." instantly tought of this video
Why would you cat /dev/null
@Luke Smith Well, if you have been doing a lot of troubleshooting in cli, you will understand why people use the cat-grep combo. That’s because it’s a lot quicker to change your grep-string. just recall your command then backspace. If you are using just grep, you need to take your cursor to your grep-string through the path/filename which could be long. ctrl-a helps a little bit but still relatively slower.
the thumbnail is fucking hilarious
I have been using Unix since 1978. I do everything from shell scripts to kernel programming in C and I often start something with cat. So be a good puppy.
I’m glad you explained it in the video.
I am guilty of running > instead of < by accident, I have done it sleep deprived before and just completely destroyed the homework I was working on. It was a sad night.
Luke is desperately trying to share his knowledge with the rest of the world before the ATF comes and gets him
what's atf?
@@phanirithvij The Bureau of Alcohol, Tobacco and Firearms. A US law enforcement agency most famous for confiscating your guns and killing your dog.
this
@@hmagellanlinux307 The only dogs they accidentally killed are the ones with gold chains around their necks.
echo "cares one No WFT " | cat | cat | cat | cat | awk '{ print $4, $3, $2, $1 }'
6:19 now he's just trolling
I never realized that this was a thing but for some reason this is like the third time a video about it popped up in my feed in the last week.
"GREP is bloated" - Distrotube 2019
you do
$ cat "file"
then look at the mess and UP-arrow
| less
no shame here.
less !$
@@JivanPal that's too much work. Just use arrow key
that's also the point using cat grep
i do this all the time, too, it's too much of a pain to use only grep if im looking through say 5 log files, and i figure out i maybe need sed, the nanosecond it takes my computer to run 2 programs is nothing compared the time it takes me to rewrite the whole line
what luke is saying makes sense in scripts but falls short in general use where the biggest overhead is keystrokes
@@davidhusicka8440 ctrl+p DESTROYS the arrow key
More Kaczynski content please. You know you want to.
Clearly edited out 'Unabomber' 😂
@@ethanp5215 echo "The Industrial revolution and it's consequences have been a boon to the human race" | cat | sed 's/boon to /disaster for /' | cat
Ill keep catting into grep and theres nothing you can do about it
There's the -h option for grep, that suppresses the file names when working with multiple files. You don't even need
I'll avoid using `
In a somewhat similar vein, you can use “command -v” (a shell builtin) instead of the “which” program to list an executable’s location(s). “which” does have more options though.
Also note that the “< file” doesn’t output file contents in bash.
I love that you cite the usage of find in an example of using grep. Also, while we're celebrating the inefficient use of commands, let's hear it for piping grep into awk!
Hi Luke! To suppress the filename output you can also use -h as in grep -ih it file anotherfile. Thanks for the video.
I knew what you meant just by the title
I use cat and you showed exactly why at around 6:20. I'm one keystroke away from erasing a file that I may not have backed up yet.
I've never even thought about catting into grep but now I'm thinking about it. I don't like thinking about it. :(
4 videos in a row? That's madness!!!
Use "grep -h it file anotherfile" to suppress displaying the file names in the output (no need for input redirection).
It's more efficient if you want to double-check the contents of the file before using grep
The shell is bloat
I still do that sometimes and go "WTF Man?"
My cat rubbed on my leg this entire video. He seemed very offended.
Guilty. It pops out of my fingers before I even think about it. It's more expensive to backspace and correct myself than to just let it fly
I've honestly never heard of catting into grep. I've only ever used grep just directly on the file.
I could only watch the first 14 seconds of your rant. The reason is that I cannot agree with the premise if your argument, and I have plenty of first-hand experience of what you're talking about. I too notice myself typing cat .. |grep plenty of times, and this gave me ample opportunity to reflect on why I do that, when I know that 'grep pattern file' is somewhat more efficient both runtime wise and character-wise. I came to the conclusion that it's just more logical to start with the object I want to handle, and then specify the things I want to do with it - just like you'd do with every other shell pipeline you write. It's just easier mentally. So whoever reads this, don't feel ashamed if you follow the natural train of thought and cat|grep - only posers who just found out you could add a filename argument to grep would call you out for it.
I don't actually disagree with you here. If you just ran `cat file`, if you key up and just add `| grep something` I don't object to that. The issue is what people are putting in scripts. There are a lot of things that we run in an interactive shell which are maximized for efficient typing, while scripts should be written for efficient running. catting into grep is nearly never the later, so should not be included in scripts.
@@LukeSmithxyz You can also go on and say that sed|grep|uniq|sort is also bad (and so much so!), since you could do all this with a single awk command, and you'd be right. But shell scripts will never be efficient. If you want efficiency, stick to an interpreter and do all work in it, be it awk, perl, sed or some other. (It's true that bash with all it's extensions tries to get included in this category, and one might say it's succeeding, but for anything remotely complex it's still lacking in my view). So my point stays, cat|grep isn't the worst offence, there're much worse that could lead to a lot more resource waste. I'll conclude with a quote from Knuth: "Premature optimization is the root of all evil."
Yeah I agree it's easier to write and more logical, especially if you have to change the grep string a lot, it's easier to go up and change the bit at the end instead of navigating to the middle all the time and so on, also chaining greps is pretty common etc. This is just a silly rant
We often start with cat-ing a file to check the contents and then build from there using , appending |grep, etc.
But instead of arrow up, you can (tested with bash) use a different workflow:
'$ cat /etc/passwd' and then:
'$ grep luke !$'.
(!$ expands to the last word of the argument of the previous command, in this case the file path. Use !* for the full argument list if necessary.)
The actual command, with the argument expanded, will be displayed before execution and will be in the history as usual.
grep is streaming command, using 'cat file | grep' doesn't really need much memory. i would like to say, just use what you like.
ill cat everything just to use that beautifull pipe
One of the first Linux introduction lessons I actually conscientiously received and processed was *DON'T `cat` FILE CONTENTS*, and was relentlessly beaten with it, meme educashan super effective
🤯 Thanks Luke. Using cat with grep and sed is literally how we were taught by our professor in class. I had no idea it was wrong.🐧
It isn't wrong, it's a nitpick of nitpicks.
Effect on memory is tiny, effect on performance is negligible as well, and using cat actually helps your scripts to be more readable.
Expressiveness >>>> few cycles saved here and there, if performance is of essence, you'd choose something else over bash anyway.
did you have like 5 vidoes you forgot to upload? you posted more in the last 5 days than you did in the last 5 months
He found an internet connection somewhere
Gotta get that ad money to buy xmas presents.
The "< file" does not work with bash but with zsh ;)
I feel like you're watching me
Still think cat | grep is more beautiful, more consistent. Most of the time it's tail | grep, ls | grep, history | grep, etc. So why not do the same thing when grepping a file.
The $ < file does not work in bash.
< file1 < file2 grep looks weard to me.
Funny thing at the end of video. Using cat to show the file i empty, huh? 😉
More more more more!!!!
I love this!!! These videos help so much!!
Thank you !
Who remembers Randal Schwartz's "Useless use of cat" ?
Here's why I'll continue doing that:
First I take a look at the file to check if it is the one I'm looking for with cat and then grep it with a pipe.
I agree that using grep directly is more efficient but it just feels weird to delete everything and change to grep
cat FILE
grep !$
no need to delete anything, just use history
You blew my mind, again! I am now going to conserve electricity and become a much more sensible person!
Nothing wrong using it. Experienced users usually using both methods and technically in most cases it's the same. Any command need to read file before using it in input, it's same as feeding file into command's input with cat.
Also it pair with the habit of using 'head' and 'tail' in the same way.
6:59
Luke: grep can be *runned* on files.
Also Luke: I'm a linguistics PhD Student.
Me: Get a load of this boomer.
Luke is more likely a snow flake genx or millenial.
New challenge: use only >, and > to edit files. No commands allowed.
ed was the o.g. linux meme because it's the standard text editor. Says so in the man page.
@@SimGunther But ed is much more powerful than redirection. In fact, after a few hours of struggling with ed, when you get used to it, it's a very useable text editor. It was not designed to be used with a screen, but with a line printer, and in that regard, it is an excellently designed piece of software.
Books have been written in ed, and a large part of UNIX was programmed using it.
From: patl@athena.mit.edu (Patrick J. LoPresti)
Subject: The True Path (long)
Date: 11 Jul 91 03:17:31 GMT
Newsgroups: alt.religion.emacs,alt.slack
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?
Well, I always add the > and < _after_ the command in question.
grep word >file2
Funny I have always done this and never questioned it but the moment I looked at the title of the video I realized that I coud have used the file as an argument for grep
I really missed your videos
6:50 acktually... gnu cat is bloated af, look at the source code
holy shit i want to puke. 30yo coding conventions have not held up well :D
github.com/coreutils/coreutils/blob/master/src/cat.c
@@k1ngjulien_ jesus, that bloat of a formatting is making me wanna kill myself. and who tf indents curly brackets like this ...
Is it that much worse than typical C code? I usually just write C++ and am not used to it, but thought code like that is par for the C course.
@@gavinridley5727 It's pretty awful code.
I'm going to blame some of this on C (preprocessor directives hard left-aligned). The most egregious thing that I don't understand is the inconsistent brace indentation. Other than those things not tooooo bad. I actually appreciate the verbose formatting and commentary on the function args. Also the formatting of the help-strings near the top looks ugly at first, but I'd say that's actually about a reasonable choice as any.
Often when interactively typing commands, I know what I want the source files to be, but haven't thought out the rest of the pipeline, such as what grep and other commands I want. So I can type 'cat file1 file2 | ' and know that for the rest of the command, input is coming via a pipe. Then I can think solely in terms of how I am going to transform the data. When it comes to transcribing things into a script, naturally I'll replace 'cat file1 | grep' with 'grep file1'.
Thank you for these vids
When I'm building out a pipeline, I like to do it one command at a time, and if I'm doing something with a file I'll usually start with cat.
CAT LADIES GET OUT
GREPPERS RISE UP
Thanks dude.
catting into something doesn't cost much in terms of typing, and actually I feel that it improves readability
At Operating System class in uni people wrote this shit in projects all the time. This, and cat into awk for some reason.
This felt like a personal attack
Dont use cat, instead use this little symbol that if you miss by 1 key will destroy your file :D
Its like they don't even man
i knew this. i feel so smart now
Well it is already a habbit, as the saying goes the horse has gone through the gate. Plus < file.txt is not working from me.
I ran some timings on 10 000 iterations of grep (user times +/-1.5s):
cat file|grep 32.7s
< file grep 25.0s
grep file 25.7s
Back in the day we used to give people the "useless use of cat" award. This is exactly that thing.
I mostly use cat in the context of cat - > FILE to make quick notes, straight from stdin, and not have to press all those extra keystrokes in vim.
Thanks. One more way how the Internet is all about cats.
I know about this and but still use cat for interactive sessions. It allows the same keypresses if you are experimenting: up arrow + ctrl-w + type new pattern + enter. If you are grepping some complicated file path your command will look like this "grep pattern very/very/long//file/path", moving the cursor back and type in a new pattern is kind of a pain.
I don't use cat on my script i use less to print stuff on terminal but now i can optimise my script. Thx luke
I don't only cat into grep, I cat to a new file instead of copying it.
Maybe the last part of video explains why people use cat instead of < , they don't wanna risk mistyping < into >
and now I have an HTML tag
you cant stop me old man
Thank you!!!
Ah but most people will cat file, then press up and pipe into grep. You would needlessly type the filename twice
I found out about the file input in grep accidentally when trying out multiple patterns to see what would happen. It was one of my earliest experimentation with grep.
You'll have to take my cat | grep from my cold dead hands!
For real, I find it useful when I've gotta search a file for a few different strings while in the command line. it's much easier to press UP and backspace the word I'm searching than to retype the command or press UP but then arrow past the filename
Alternative viewpoint: we have pipes, redirections and standard IO for a reason, because that universal interface is all you need in 99% of situations where you have 1 input and 1 output (yes, I know diff exists, don't @ me). In these scenarios, accepting a file path as an argument instead of using stdio (and even further, interpreting '-' as stdio) is neither necessary nor sufficient; pipes are much more powerful.
Luke:
>has installed 'yay'
>uses pacman anyway
me: *visually confused*
Have you guys tried bat? It's a cat with syntax highlighting :)