5 ms·

Not trying to offend anyone here but I think shell scripts are the wrong solution for anything over ~50 lines of code. Use a better programming language. Go, T

Not trying to offend anyone here but I think shell scripts are the wrong solution for anything over ~50 lines of code. Use a better programming language. Go, Typescript, Rust, Python, and even Perl come to mind.

f1shy 2y ago
I agree with the general idea, but 1) LOC is not a good metric 2) I would immediately take off the list Python and Typescript, and anything what is compiled, leaving the list much shorter
- xyzzy4747 2y ago
  TypeScript is good for this kind of a thing if you're only running it on your own machines and don't have to mess around with environments all the time. You can also run it with ts-node.
shepherdjerred 2y ago
Deno is great for writing quick scripts: https://deno.com/learn/scripts-clis https://deno.com/learn/scripts-clis Bun has similar features: https://bun.sh/docs/runtime/shell https://bun.sh/docs/runtime/shell
sgarland 2y ago
Some of us enjoy the masochism, thank you very much.
- nativeit 2y ago
  Hear, hear! Bash me datty.
httbs 2y ago
I draw the line at around 300 lines.
heresie-dabord 2y ago
> shell scripts are the wrong solution for anything over ~50 lines of code. I don't think LOC is the correct criterion. I do solve many problems with bash and I enjoy the simplicity of shell coding. I even have long bash scripts. But I do agree that shell scripting is the right solution only if = you can solve the problem quickly = you don't need data structures = you don't need math = you don't need concurrency
- kragen 2y ago
  some data structures, math, and some concurrency are just fine in shell scripts. bash has arrays so you can do pretty elaborate data structures. where it falls down is being bug-prone. but some code is useful even if it's buggy
- wruza 2y ago
  I enjoy the simplicity of shell coding You mean, the complexity of shell coding? Any operation that in a regular language is like foo.method(arg) in shell expands into something like ${foo#/&$arg#%} or `tool1 \`tool2 "${foo}"\` bar | xargs -0 baz`.
  - xyzzy4747 2y ago
    Exactly, plus there's no compiler or type safety.
  - heresie-dabord 2y ago
    > in a regular language [...] like foo.method(arg) Note what you just said: when you want an object with a method that takes a parameter, you find bash too complex. You gave an example that is not appropriate for bash. However, bash does have functions. So if you don't need an entire underlying object system just to run your logic, you could have function foomethod () { parm1=$1 #more logic }
    - wruza 2y ago
      My comment was more about basic string/number ops implemented as cryptic incantations, not functions per se. I regularly write bash. Simple things like trimming, deleting suffix, removing quotes, taking a substring, etc always look like someone is cursing in the code. I can’t remember this afterthought gibberish no matter how many times I write it, so I have to maintain few pages of bash snippets in my obtf. Be damned the day I decided to write a set of scripts in it rather than looking for a way to make typescript my daily driver, like it is now. Bash “code” “base” is one of the worst programming jokes.
pmarreck 2y ago
Try running a 6 month old Python project that you haven't run in that time and report back. Meanwhile, 10 year old Bash scripts I've written still run unmodified. Winner by a mile (from a software-longevity and low-maintenance perspective at least): Bash
- bpshaver 2y ago
  Isn't compare a Python project to a Bash script an unfair comparison? Compare a Python script to a Bash script. If your Python3 script (assuming no dependencies) doesn't work after 6 months I got some questions for you. (And I don't really get how a 6 month old Python _project_ is likely to fail. I guess I'm just good at managing my dependencies?)
  - elashri 2y ago
    Unless you have pinned the exact version numbers in requirements.txt (which you should) or kept you conda/venv..etc around it might be hard. I know at this stage this would be too much compared to what we are talking about regarding python scripts but non-python dependencies are real painful. I know that this is probably beyond bash scripting vs python scripting but I was just replying to how 6 months project can have problems. Also not a 6 months scale but the python standard library definitely changes and I would take bash anytime if I have to use venv for running util scripts. Edit: When python3.8 removed 'time.clock()' it was annoying to change that. I know that it was deprecated since 3.3 (as I remember) but this is the example I have in mind now. But probably it was before I was born that people using start=$(date +%s%N) end=$(date +%s%N) And I will be dead before/if this becomes impossible to use.
- Diti 2y ago
  That’s a testament to your distribution/package manager’s stability, not to the language itself. I happen to write my scripts in Elixir (which is as fast-moving as Python 3), using a pinned version of it in a Nix flake at the root of my `~/bin` directory. Scripts from 5 years ago are still as reproducible as today’s.
Hamuko 2y ago
I draw the line after a single if.

f1shy 2y ago

I agree with the general idea, but 1) LOC is not a good metric 2) I would immediately take off the list Python and Typescript, and anything what is compiled, leaving the list much shorter

xyzzy4747 2y ago
TypeScript is good for this kind of a thing if you're only running it on your own machines and don't have to mess around with environments all the time. You can also run it with ts-node.

shepherdjerred 2y ago

Deno is great for writing quick scripts: https://deno.com/learn/scripts-clis https://deno.com/learn/scripts-clis Bun has similar features: https://bun.sh/docs/runtime/shell https://bun.sh/docs/runtime/shell

sgarland 2y ago

Some of us enjoy the masochism, thank you very much.

nativeit 2y ago
Hear, hear! Bash me datty.

httbs 2y ago

I draw the line at around 300 lines.

heresie-dabord 2y ago

> shell scripts are the wrong solution for anything over ~50 lines of code. I don't think LOC is the correct criterion. I do solve many problems with bash and I enjoy the simplicity of shell coding. I even have long bash scripts. But I do agree that shell scripting is the right solution only if = you can solve the problem quickly = you don't need data structures = you don't need math = you don't need concurrency

kragen 2y ago
some data structures, math, and some concurrency are just fine in shell scripts. bash has arrays so you can do pretty elaborate data structures. where it falls down is being bug-prone. but some code is useful even if it's buggy
wruza 2y ago
I enjoy the simplicity of shell coding You mean, the complexity of shell coding? Any operation that in a regular language is like foo.method(arg) in shell expands into something like ${foo#/&$arg#%} or `tool1 \`tool2 "${foo}"\` bar | xargs -0 baz`.
- xyzzy4747 2y ago
  Exactly, plus there's no compiler or type safety.
- heresie-dabord 2y ago
  > in a regular language [...] like foo.method(arg) Note what you just said: when you want an object with a method that takes a parameter, you find bash too complex. You gave an example that is not appropriate for bash. However, bash does have functions. So if you don't need an entire underlying object system just to run your logic, you could have function foomethod () { parm1=$1 #more logic }
  - wruza 2y ago
    My comment was more about basic string/number ops implemented as cryptic incantations, not functions per se. I regularly write bash. Simple things like trimming, deleting suffix, removing quotes, taking a substring, etc always look like someone is cursing in the code. I can’t remember this afterthought gibberish no matter how many times I write it, so I have to maintain few pages of bash snippets in my obtf. Be damned the day I decided to write a set of scripts in it rather than looking for a way to make typescript my daily driver, like it is now. Bash “code” “base” is one of the worst programming jokes.

pmarreck 2y ago

Try running a 6 month old Python project that you haven't run in that time and report back. Meanwhile, 10 year old Bash scripts I've written still run unmodified. Winner by a mile (from a software-longevity and low-maintenance perspective at least): Bash

bpshaver 2y ago
Isn't compare a Python project to a Bash script an unfair comparison? Compare a Python script to a Bash script. If your Python3 script (assuming no dependencies) doesn't work after 6 months I got some questions for you. (And I don't really get how a 6 month old Python _project_ is likely to fail. I guess I'm just good at managing my dependencies?)
- elashri 2y ago
  Unless you have pinned the exact version numbers in requirements.txt (which you should) or kept you conda/venv..etc around it might be hard. I know at this stage this would be too much compared to what we are talking about regarding python scripts but non-python dependencies are real painful. I know that this is probably beyond bash scripting vs python scripting but I was just replying to how 6 months project can have problems. Also not a 6 months scale but the python standard library definitely changes and I would take bash anytime if I have to use venv for running util scripts. Edit: When python3.8 removed 'time.clock()' it was annoying to change that. I know that it was deprecated since 3.3 (as I remember) but this is the example I have in mind now. But probably it was before I was born that people using start=$(date +%s%N) end=$(date +%s%N) And I will be dead before/if this becomes impossible to use.
Diti 2y ago
That’s a testament to your distribution/package manager’s stability, not to the language itself. I happen to write my scripts in Elixir (which is as fast-moving as Python 3), using a pinned version of it in a Nix flake at the root of my `~/bin` directory. Scripts from 5 years ago are still as reproducible as today’s.

Hamuko 2y ago

I draw the line after a single if.