5 ms·
Nice list! > If you want to cat bunch of files at once you can this command You can use cat itself for this (and save typing a few characters): cat *
by fooblat 5y ago
Nice list!
> If you want to cat bunch of files at once you can this command
You can use cat itself for this (and save typing a few characters):
cat *
- karatinversion 5y agoThat one gave me a giggle too - perhaps the author got told off for useless uses of cat too many times?
- enriquto 5y agoThat meme "useless use of cat" is a major pet peeve of mine... It makes no sense. Starting your pipe with cat is alright. I make a point of always starting all my pipes with cat, even in the cases where it is a bit unnatural.
- tzot 5y agoIt's one more process to run, so `cat single_file | ` can be easily substituted with `<single_file `.
- justin_oaks 5y agoI was going to point this out too. For those who may not know, you can put the I/O redirection anywhere in the command, not just at the end. So you can write < input_file.txt grep some_pattern | grep another Which has the same effect as grep some_pattern < input_file.txt | grep another but puts the input redirection at the beginning so you can easily follow the data flow from left to right. I use "redirection first" in other cases such as 1>&2 echo "Error: missing file" To make it clear up-front that I'm writing to stderr.
- tzot 5y agoOr plain `>&2` since the `1` is implied for '>'
- enriquto 5y agoYep. Writing "<file " is just as good as "cat file |". Still I'm more used to writing cat. The only (marginal) advantage of cat over explicit redirection at the beginning is maybe that you can split the lines more cleanly with cat: cat file |\ program1 |\ program2 |\ ... If you use a redirection, since the command does not start with a pipe the symmetry is broken. Redirections at the start of the line are fun. I have an alias alias null='>/dev/null 2>/dev/null' this allows to run GUI programs without cluttering the terminal with useless GTK/QT warnings: null evince file.pdf
- fooblat 5y agoPro tip, if a line ends in a | you don't need a trailing backslash. The same is true if a line ends in || or && as those all imply continuation. Edit: cat file | program1 | program2 | ...
- enriquto 5y agowow, that's great. Now what I miss is to be able to put comments after each such line.
- fooblat 5y agoI just tested it and, in bash at least, it actually works fine. echo foo | # echoing foo tr 'a-z' 'A-Z' FOO
- enriquto 5y agothis is incredible, I had already given up on this, and the solution was in front of my eyes the whole time! You have just greatly enhanced the elegance of several scripts in my lab.
- scubbo 5y agoWow. Thank you for explaining this! I'd never understood why `cat` was called useless when (so far as I then knew) there was no other way to "start a left-to-right pipe by reading from a file" (other than the aforementioned `grep <filename> *`). This helps!
- probably_wrong 5y agoThere's a natural workflow that tends to get ignored in these discussions: when you're not sure of all the details of the pipeline yet and your file is big enough to slow you down. I typically start with (say) `head file | grep '2020'`. Once it does what I want I move to the next step, and so on until it's done. At that point, and having chained 5-6 commands, replacing `head` with `cat` is faster and less likely to break due to me putting the '<' in the wrong place. The simplicity and extra peace of mind is well worth an extra process IMHO.
- aflag 5y agoWhy always start with cat? Not using cat when you don’t need to means less typing, more efficient and mor robust code. Why use it if you don’t need to?
- petepete 5y agoIt's easier to change the start of a chain that starts with cat than if you're passing a filename into your first program. Even though it's _technically_ misuse, cat can improve composability.
- alpaca128 5y agoIn many situations it's quicker to just rely on muscle memory than coming up with the most efficient way to read a few 50kB files. It's a good thing to be aware of the differences when needed, but often the execution speed is not the reason for writing a bash script.
- aflag 5y agoI don’t think efficiency matters much in this case, but more robust and concise code is better. Most commands either take a file as a unnamed argument or you can just do something like <filename. But I agree, there may be commands where passing the file name is awkward (eg. jq)
- deleted 5y ago[deleted]
- scrooched_moose 5y agoI often prefer it in scripts for easier parsing later. cat file.txt | somemonstrousoneliner immediately tells me it's reading file.txt and doing something with the contents. Burying the filename deeper in the string makes it harder to figure that out.
- aflag 5y agoIf it was grey -R . * it’d make more sense. Maybe they just missed the -R?
- tzot 5y ago`grep . *` has different output than `cat` if `*` expands to more than one filename: every line is prefixed by the filename it exists in.
- gbrown_ 5y agoThe use of grep the author proposes will have each line of output prefixed with the name of the file it came from followed by a colon. That is if the glob expands to more than one file though, if it only expands to a single file then it is equivalent to cat. Use of the -h option should be passed to grep if the difference in format is something the author wishes to guarantee.
- naniwaduni 5y agoEven when it expands to a single file, it has different output when the file contains empty lines.
- justin_oaks 5y agoI think grep ^ * would fix that and is just as short.