Somehow when I was learning Linux/UNIX 13 years ago, my default way of grepping for something in a file became `cat foo | grep bar`. I've tried, a bit, to break this habit, but can never stick with it. The only time it slows me down is when I'm trying to show someone something and they interrupt to ask why I do it that way :)
I love that the same set of people who like to wax poetic about the elegance of pipes and composable single-purpose tools are the most pedantic about not doing all that when a single tool happens to have all the features you strictly need, monolithically built in. Never mind that STDIN works the same on all processes, while the file argument is highly inconsistent! Never mind that the expansion of single tools to encompass common tasks is widely regarded as a pox on the cleanliness of UNIX! You must learn all the options! Minimize the number of processes! You have 16 GB of RAM but that unnecessary 'cat' is UNACCEPTABLE!
I do the same thing. It fits with how I think. I want to print out this file. Oh, it's too long to parse by hand, I'll search for something. Up-arrow, pipe less.
Sure I could use "<something.txt grep something", but that requires me to decide to use grep right off the bat, something I hardly ever do. Usually I want to look at it first.
It's not a bad idiom to use. You can keep retrieving the last command, and change the grep term quickly with ^w . When the search argument to grep is in the middle of the line, you can't easily iterate over a bunch of search terms by hand.
What if you just want to view the contents of input-file, unpaged. `<input-file` doesn't print anything unfortunately (curiously it doesn't error either).
