5 ms·

I've found that every time my bash scripts become sufficiently complex, I end up rewriting them in Python.

by feisuzhu 4y ago

Cheeeetah 4y ago
I mainly use Python to handle JSON, while use Shell for other things.
deleted 4y ago
[deleted]
captnswing 4y ago
this ^
ff317 4y ago
Yeah, I figure if a bash script goes over ~10-20 lines, or involves really long lines, or quotes within quotes within quotes of different kinds, it's time to move on to Python or similar.
- 3np 4y ago
  It'\''s always the quotes.
vaughan 4y ago
TypeScript is now tenable for bash scripts with the fast-starting Bun runtime https://bun.sh/ https://bun.sh/. Before Bun, Node+V8 was just too slow to start. IMHO all scripts should be written in TypeScript...you get typechecking and all the rest of the editing experience. Plus things like Wallaby.js for live coding/testing. My `.bashrc` now just runs a TypeScript script with Bun. Allows you to use proper structure instead of brittle spaghetti stuff. The number of times I'm debugging silly PATH stuff was too much...
- c0wb0yc0d3r 4y ago
  Do you have an example?
  - vaughan 3y ago
    import {alias, _export, _eval} from './util.js' export default async function config() { git() } function git() { alias({ gpsuom: 'git push --set-upstream origin master', gpsuvm: 'git push --set-upstream vjpr master', gpsu: 'git push --set-upstream', gmvd: 'git merge vjpr/dev', gmvdgp: 'git merge vjpr/dev && git push', gprom: 'git pull --rebase origin master', gpuohm: 'git push origin head:master', gpom: 'git pull origin master', grhh: 'git reset --hard HEAD', gisquash: 'git reset --soft HEAD~$(git rev-list --count HEAD ^master)', gacp: "git add . && git commit --message 'Update' && git push", gacmu: "git add . && git commit --message 'Update'", gacmup: "git add . && git commit --message 'Update' && git push", }) } function brew() { alias('bbrew', 'br') alias({ br: 'HOMEBREW_NO_AUTO_UPDATE=1 brew', // x86_64 ibrew: 'arch -x86_64 /usr/local/bin/brew', abrew: '/opt/homebrew/bin/brew', }) _eval(`$(/opt/homebrew/bin/brew shellenv)`) }
    - c0wb0yc0d3r 3y ago
      I take it, then, in your .bashrc file you have a line to the effect: bun run bashrc.ts?
      - vaughan 3y ago
        Yeh something like that. I am using unix pipes to communicate with the shell, basically just eval'ing commands. I did this because bun didn't support sockets yet, which is probably a better approach. Pipes have crazy edge cases.
- ryapric 4y ago
  >you get typechecking and all the rest of the editing experience This is true for a number of languages that can also be run without AOT compilation (Go, Rust, etc). This feels like some really weird, incoherent astroturf take for Bun promotion.
  - vaughan 3y ago
    JavaScript was not tenable for scripts with Node.js. Startup time is too slow. Now it is because of Bun. I don't think you can argue with that. Rust isn't a scripting language - too strict, no optional typing, slow compilation.
jen20 4y ago
Fair - I find that every time a Python program becomes sufficiently complex though (defined as "needs something not in the stdlib of Python 3.6"), I end up rewriting them in Go or Rust ;-)
vultour 4y ago
Honestly, I don't think I found a single case where this was true. Every time I try to rewrite a moderately complex bash script in Python it becomes hundreds or thousands of lines of code dealing with calling external binaries, streams and proper error handling. Perhaps if you're only dealing with text processing it will work, but the moment you start piping together external programs via Python it's all pointless.
- iudqnolq 4y ago
  sh is the secret to transliterating bash to python. It's basically bash with proper loops and variables and string operations. import sh names = sh.ls("./src") for name in names: sh.mv(["./src/" + name, "./dst/" + name + ".out"])
- iamjackg 4y ago
  100% agree. There are some libraries like https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ that aim to make that easier, but they always have some quirks that, funnily enough, are often the corner cases you were hitting in your complicated Bash script in the first place.
- epr 4y ago
  Glad I'm not the only one. Honestly, whenever bash comes up in any context, 10 different people feel compelled to express this whole replace all bash scripts with python sentiment and I just have no clue what the fuck they're talking about. I would consider myself an expert or at least near-expert in python, but I don't see opportunities to replace my shell scripts with python popping up left and right. Do you open files manually and set up pipe chains with subprocess.Popen? I've done this, and its generally many more LOC compared to the shell original, and harder to read. On the other hand, I'd consider myself maybe 7/10 skill level with bash, but most developers are only ever a 2/10 or 3/10 with bash/shell. I can't help but think that the average developer's lack of shell understanding is where all these suggestions to convert to python come from. If it's that easy or beneficial to convert to python, then it probably should have been written in python originally.
- m463 4y ago
JohnFen 4y ago
When I'm working on/writing complex bash scripts, it's because the scripts have to run on a variety of different customer machines where Python is not consistently available (let alone being able to count on a particular version) and, if it's not there, cannot be installed. The main advantage of bash is that it exists on just about every unix machine.
m463 4y ago
that's exactly what I do, and argparse (I believe the motivation for argbash) helps a lot

I've found that every time my bash scripts become sufficiently complex, I end up rewriting them in Python.

Cheeeetah 4y ago

I mainly use Python to handle JSON, while use Shell for other things.

deleted 4y ago

[deleted]

captnswing 4y ago

this ^

ff317 4y ago

Yeah, I figure if a bash script goes over ~10-20 lines, or involves really long lines, or quotes within quotes within quotes of different kinds, it's time to move on to Python or similar.

3np 4y ago
It'\''s always the quotes.

vaughan 4y ago

TypeScript is now tenable for bash scripts with the fast-starting Bun runtime https://bun.sh/ https://bun.sh/. Before Bun, Node+V8 was just too slow to start. IMHO all scripts should be written in TypeScript...you get typechecking and all the rest of the editing experience. Plus things like Wallaby.js for live coding/testing. My `.bashrc` now just runs a TypeScript script with Bun. Allows you to use proper structure instead of brittle spaghetti stuff. The number of times I'm debugging silly PATH stuff was too much...

c0wb0yc0d3r 4y ago
Do you have an example?
- vaughan 3y ago
  import {alias, _export, _eval} from './util.js' export default async function config() { git() } function git() { alias({ gpsuom: 'git push --set-upstream origin master', gpsuvm: 'git push --set-upstream vjpr master', gpsu: 'git push --set-upstream', gmvd: 'git merge vjpr/dev', gmvdgp: 'git merge vjpr/dev && git push', gprom: 'git pull --rebase origin master', gpuohm: 'git push origin head:master', gpom: 'git pull origin master', grhh: 'git reset --hard HEAD', gisquash: 'git reset --soft HEAD~$(git rev-list --count HEAD ^master)', gacp: "git add . && git commit --message 'Update' && git push", gacmu: "git add . && git commit --message 'Update'", gacmup: "git add . && git commit --message 'Update' && git push", }) } function brew() { alias('bbrew', 'br') alias({ br: 'HOMEBREW_NO_AUTO_UPDATE=1 brew', // x86_64 ibrew: 'arch -x86_64 /usr/local/bin/brew', abrew: '/opt/homebrew/bin/brew', }) _eval(`$(/opt/homebrew/bin/brew shellenv)`) }
  - c0wb0yc0d3r 3y ago
    I take it, then, in your .bashrc file you have a line to the effect: bun run bashrc.ts?
    - vaughan 3y ago
      Yeh something like that. I am using unix pipes to communicate with the shell, basically just eval'ing commands. I did this because bun didn't support sockets yet, which is probably a better approach. Pipes have crazy edge cases.
ryapric 4y ago
>you get typechecking and all the rest of the editing experience This is true for a number of languages that can also be run without AOT compilation (Go, Rust, etc). This feels like some really weird, incoherent astroturf take for Bun promotion.
- vaughan 3y ago
  JavaScript was not tenable for scripts with Node.js. Startup time is too slow. Now it is because of Bun. I don't think you can argue with that. Rust isn't a scripting language - too strict, no optional typing, slow compilation.

jen20 4y ago

Fair - I find that every time a Python program becomes sufficiently complex though (defined as "needs something not in the stdlib of Python 3.6"), I end up rewriting them in Go or Rust ;-)

vultour 4y ago

Honestly, I don't think I found a single case where this was true. Every time I try to rewrite a moderately complex bash script in Python it becomes hundreds or thousands of lines of code dealing with calling external binaries, streams and proper error handling. Perhaps if you're only dealing with text processing it will work, but the moment you start piping together external programs via Python it's all pointless.

iudqnolq 4y ago
sh is the secret to transliterating bash to python. It's basically bash with proper loops and variables and string operations. import sh names = sh.ls("./src") for name in names: sh.mv(["./src/" + name, "./dst/" + name + ".out"])
iamjackg 4y ago
100% agree. There are some libraries like https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ that aim to make that easier, but they always have some quirks that, funnily enough, are often the corner cases you were hitting in your complicated Bash script in the first place.
epr 4y ago
Glad I'm not the only one. Honestly, whenever bash comes up in any context, 10 different people feel compelled to express this whole replace all bash scripts with python sentiment and I just have no clue what the fuck they're talking about. I would consider myself an expert or at least near-expert in python, but I don't see opportunities to replace my shell scripts with python popping up left and right. Do you open files manually and set up pipe chains with subprocess.Popen? I've done this, and its generally many more LOC compared to the shell original, and harder to read. On the other hand, I'd consider myself maybe 7/10 skill level with bash, but most developers are only ever a 2/10 or 3/10 with bash/shell. I can't help but think that the average developer's lack of shell understanding is where all these suggestions to convert to python come from. If it's that easy or beneficial to convert to python, then it probably should have been written in python originally.
m463 4y ago

JohnFen 4y ago

When I'm working on/writing complex bash scripts, it's because the scripts have to run on a variety of different customer machines where Python is not consistently available (let alone being able to count on a particular version) and, if it's not there, cannot be installed. The main advantage of bash is that it exists on just about every unix machine.

m463 4y ago

that's exactly what I do, and argparse (I believe the motivation for argbash) helps a lot