Hacker News Reader

Comment by _false | Hacker News Reader

A lot of people here are leaning towards just writing the script in Py.

Could somebody please educate me on why bashing it would be preferable?

> Could somebody please educate me on why bashing it would be preferable?

Bash is a much better glue language than python. If all your script does is to call other programs that do all the work, it is very likely you can write it as a single line shell script. In python, you'll have to import libraries, call functions with many arguments, and whatnot.

If you have to parse output from one binary as input to another, I find it is way less error prone to use bash. There are subtleties to flushing output from processes in python that can lead to surprises.

In general "use the right tool for the job" but arguments for Bash:

* Succinctness: When you mostly glue together other programs, Bash will often be shorter than Python.

* Familiarity/Ubiquity: If you're using a Unix-like you're already using Bash (probably; or another shell that's similar) as your main "REPL to the system". When you wanna automate a thing you can start off with what you've already been doing for that task and go from there. Similar story for experimenting when writing a script, though Python also has a REPL for that.

In devops nowadays:

Bash is a prototype to the app in Python that is a prototype to the app in Golang.

which is a prototype to the one in Rust.

Which is a prototype to the small C utils that solve the problem better, and bash again

Small Rust utils are better than C equivalents. Ripgrep is lot faster than grep, despite slower regex engine.

I look forward to the slow but steady reinvention of various coreutils in Rust or Go. Rg-ripgrep is better than grep. Fd-find is better than find. Exa is better than ls/tree. Fzf has no equivalent. I'm still looking for a ping that lets me timeout less than 1 second.

There are so many assumptions baked in to the early tools that a complete rewrite just bypasses.

As far as I see, ripgrep isn't small - a multimegabyte heavily compressed package.

  $ ldd /usr/bin/grep
 linux-vdso.so.1 (0x00007ffed59ab000)
 libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f387c8cf000)
 libc.so.6 => /lib64/libc.so.6 (0x00007f387c705000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f387c6e3000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f387c9aa000)

  $ du -ch /usr/bin/grep `readlink -f /lib64/libpcre.so.1` `readlink -f /lib64/libc.so.6` `readlink -f /lib64/libpthread.so.0`
  168K /usr/bin/grep
  484K /usr/lib64/libpcre.so.1.2.12
  3.1M /usr/lib64/libc-2.31.so
  312K /usr/lib64/libpthread-2.31.so
  4.0M total

I mean https://github.com/BurntSushi/ripgrep/releases/download/12.1... - /usr/bin/rg 5mb executable. And I think it was something about 20mb in first release.

Only because I didn't bother to strip the binary. The binary you're linking to is statically linked, which includes PCRE2 and Rust's regex engine, among other things. The GP's point is that if you look at all of grep's pieces, it comes in at a similar size.

Overall, I don't even know what the point of this kind of questioning even is.

What makes you say ripgrep has a slower regex engine?

Compare performance of Rust #7 (PCRE2) vs Rust #6 (regex) at benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

That's a single benchmark. Before regex-redux was regex-dna, and Rust's regex engine was faster than PCRE2 on that benchmark. So how does that change your conclusion?

The regex crate has many more benchmarks: https://github.com/rust-lang/regex/blob/master/bench/log/07/... and https://github.com/rust-lang/regex/blob/master/bench/log/07/... for example.

And then there are things like this which can impact the performance of real world use cases: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcr...

Please don't draw sweeping conclusions about the comparative performance of regex engines from a single benchmark.

I do: bash -> js -> (rarely ever get this far)

The bash step is fast to write as it subsumes all the process calling / management.

JS (or python) is a reasonable next step, often just a tight cli wrapper around a function to be called in bash that is hard to write in bash / is from a library. I find its normally easier to pack JS dependencies for these one offs than python, but both work.

Next step is perf/testing focused. Js works as a great first step here as the Promises & event loop let you get a whole bunch of perf naturally that is a pita to arrange in python.

Now you have a program laid out and usage tested that can be re-written in something else for real or percieved benefits (go, bash, c++, rust)

Sometimes pipelines are the right tool for the job.

It wouldn't

Reply on news.ycombinator.com