71–80 of 136 posts
If you don't mind a bit of Perl, then Perl can be used for grep, awk and sed. And find. Even comes with little conversion utilities to do it (mostly) for you: a2p, s2p, find2perl. I used Python most of the time but still use Perl where it is appropriate.
They are available as a separate distributions on CPAN:
https://metacpan.org/pod/App::a2p
$ [data is generated] | awk '!/something/'Earlier quoted context omitted.
The main reason I use awk 90% of the time is that its field parsing algorithm does "the right thing" in most cases (i.e. divide fields by 1 or more whitespace characters) without a lot of boilerplate, so it's really easy to throw into a pipeline.
That's what I was referencing when I said > Pulling out a field from a line is what most people use awk for, but it's honestly the least interesting part of awk. In fact, if cut supported regular expressions for specifying the field and record separators people wouldn't be using awk for that purpose (because that's all that $n does). There's nothing magical about awk's default FS. It's literally just /\s+/. If cut's…
Also, cut's output manipulation is surprising. '-f 2,1' is actually the same as '-f 1,2' - you can't change the order of printing.
I know there are other programs that can do the job, but it's a little frustrating when you can 'almost' get there with a chain of piped commands and a simple tool like cut, but have to fall back on a 'real' programming language to do just that extra bit of manipulation (awk, perl, whatever, and yes, I know the shell is a programming language but you get my point!)
ripgrep[1] is functionally incredibly similar to grep and ag, but is significantly faster[2] and supports a wider range of character encodings. In its short lifetime it has already become the default search tool for VSCode. I've switched to using it as my daily driver for text search and am incredibly happy with it. [1]: https://github.com/BurntSushi/ripgrep [2]: http://blog.burntsushi.net/ripgrep/ Edit: I confused a…
I had a loop operating on a text file like this:
while read line
do
echo "$line" | sed -e "s/A/X/" -e "s/B/Y/" -e "s/C/Z/"
...
while read line
do
echo "$line" | sed -e "s/A/X/" | sed -e "s/B/Y/" | sed -e "s/C/Z/"
...
I'd like to share a recent experience on a related note, but in the opposite spirit - rather than reduce the number of command invocations on a command line, it may make sense to increase it. I had a loop operating on a text file like this: while read line do echo "$line" | sed -e "s/A/X/" -e "s/B/Y/" -e "s/C/Z/" ... Gradually, as I added more things to replace, I noticed severe slowdown. Things got fast again when I…
It's a nice idea, but I think maybe only to replace a simple egrep. grep has tons of great option like -F = fgrep; no regex - way faster -v = as mentioned in the article -o = print only matched input, not the entire line -C = context, print lines before and after the match; can also be used partially with -A (after) and -B (before)
ripgrep[1] is functionally incredibly similar to grep and ag, but is significantly faster[2] and supports a wider range of character encodings. In its short lifetime it has already become the default search tool for VSCode. I've switched to using it as my daily driver for text search and am incredibly happy with it. [1]: https://github.com/BurntSushi/ripgrep [2]: http://blog.burntsushi.net/ripgrep/ Edit: I confused a…
ripgrep doesn't yet support compressed files (z/gz), while grep/ack/ag do. On *nix it's extremely common to have sparsely compressed directories, from logfiles to non-changing documentation. I really wished ripgrep would just stream to a fast coprocess and support any stream compressor transparently instead of trying to use a built-in rust library.
It's a nice idea, but I think maybe only to replace a simple egrep. grep has tons of great option like -F = fgrep; no regex - way faster -v = as mentioned in the article -o = print only matched input, not the entire line -C = context, print lines before and after the match; can also be used partially with -A (after) and -B (before)
My favourite bad example of using grep was from a big enterprise software vendor to kill one of their processes. It looked something like ps -ef| grep SomeDaemon | grep -v grep | grep -v perl | perl -e ' '
grep -v grep.. I wish I could admit to using this less often than I do; but it's always manual not automated. At some point I'll figure out a better alternative than this or pgrep which often misses processes.
psgrep () {
ps aux | sed -n '1p;/\/d;/'"$1"'/p'
}