18 ms·

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?

• azaras 6y ago
  In devops nowadays: Bash is a prototype to the app in Python that is a prototype to the app in Golang.
  • richardwhiuk 6y ago
    which is a prototype to the one in Rust.
    • elitepleb 6y ago
      Which is a prototype to the small C utils that solve the problem better, and bash again
      • drran 6y ago
        Small Rust utils are better than C equivalents. Ripgrep is lot faster than grep, despite slower regex engine.
        • kortex 6y ago
          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.
        • GoblinSlayer 6y ago
          As far as I see, ripgrep isn't small - a multimegabyte heavily compressed package.
          • drran 6y ago
            $ 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
            • GoblinSlayer 6y ago
              I mean https://github.com/BurntSushi/ripgrep/releases/download/12.1.1/ripgrep_12.1.1_amd64.deb 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.
              • burntsushi 6y ago
                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.
        • burntsushi 6y ago
          What makes you say ripgrep has a slower regex engine?
          • drran 6y ago
            Compare performance of Rust #7 (PCRE2) vs Rust #6 (regex) at benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
            • burntsushi 6y ago
              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/pcre2 https://github.com/rust-lang/regex/blob/master/bench/log/07/... and https://github.com/rust-lang/regex/blob/master/bench/log/07/rust 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#pcre2-slow 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.
• zeepzeep 6y ago
  It wouldn't
• emptyparadise 6y ago
  Sometimes pipelines are the right tool for the job.
• enriquto 6y ago
  > 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.
  • DaniloDias 6y ago
    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.
• Normal_gaussian 6y ago
  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)
• t0astbread 6y ago
  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.