3 ms·

I disagree too. Bash has many downsides, but there are very few languages out there which have the ability to 'connect' different programs so easily. Bash scri

by JepZ 9y ago

I disagree too. Bash has many downsides, but there are very few languages out there which have the ability to 'connect' different programs so easily. Bash scripts are slow as hell (as most commands have to spawn new processes), it is hard to write "secure" code (if even possible), handling whitespaces can be a pain in the * and the amount of repetition is awful. If your kid has done something wrong, just tell it to write a bash script: it is the equivalent of writing a hundred times: x="$(...)" Nevertheless, I enjoy writing bash scripts. Many times it starts with a simple curl command and by the end of the day you have a new OS installer. Granted, there are tasks which other languages can do better, but thats the real power of bash, it doesn't care: Then off you go write your super complicated algorithm in Rust, Go, Python, R or whatever and just call the other program, that's what Bash is good at. It is the glue which keeps everything working together. Disclaimer: Please don't build a complete cathedral out of glue.

dgsb 9y ago
I'd rather use perl for these use cases. It's almost as concise as bash regarding subprocess management. It's ubiquitous as bash, and have the python like 2 vs 3 version issue.
joncrane 9y ago
"Bash is the glue which keeps everything working together. Please don't build a complete cathedral out of glue." --JepZ
IshKebab 9y ago
The reason it can connect programs so "easily" is because it basically ignores errors and robustness - it really relies on there being a user looking at the output and going "hmm that looked like it failed". Doing things properly in Python or Go may take a few more lines (not much more really) but it is 100 tones more robust, and you need that if you are writing anything more than a 10-line one-off hack.
- mbrock 9y ago
  No, it doesn't. Unix error codes are extremely well understood. Tell the Git maintainers that their program ignores errors and robustness—they'll be surprised.
  - viraptor 9y ago
    Even when well understood, it doesn't mean easy to work with. If you're lucky, the app you're calling only has two states: success+result, or failure+error message. But working with text commands, one day you'll get a "skipped file Xyz" somewhere in the output, because it's neither an error not a success. If you're very lucky, you'll get it in stderr, otherwise it will be mixed with the output. If you're not lucky, the command will print out the error and exit with 0 anyway. What crazy app would do that? For example standard initctl on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/552786 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/55278... Exit codes are a poor substitute for proper error handling with verbose error reports. They do the job most of the time, as long as you remember exactly which command behaves which way. And that's a clear path to mistakes :-(

by JepZ 9y ago

dgsb 9y ago

I'd rather use perl for these use cases. It's almost as concise as bash regarding subprocess management. It's ubiquitous as bash, and have the python like 2 vs 3 version issue.

joncrane 9y ago

"Bash is the glue which keeps everything working together. Please don't build a complete cathedral out of glue." --JepZ

IshKebab 9y ago

The reason it can connect programs so "easily" is because it basically ignores errors and robustness - it really relies on there being a user looking at the output and going "hmm that looked like it failed". Doing things properly in Python or Go may take a few more lines (not much more really) but it is 100 tones more robust, and you need that if you are writing anything more than a 10-line one-off hack.

mbrock 9y ago
No, it doesn't. Unix error codes are extremely well understood. Tell the Git maintainers that their program ignores errors and robustness—they'll be surprised.
- viraptor 9y ago
  Even when well understood, it doesn't mean easy to work with. If you're lucky, the app you're calling only has two states: success+result, or failure+error message. But working with text commands, one day you'll get a "skipped file Xyz" somewhere in the output, because it's neither an error not a success. If you're very lucky, you'll get it in stderr, otherwise it will be mixed with the output. If you're not lucky, the command will print out the error and exit with 0 anyway. What crazy app would do that? For example standard initctl on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/552786 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/55278... Exit codes are a poor substitute for proper error handling with verbose error reports. They do the job most of the time, as long as you remember exactly which command behaves which way. And that's a clear path to mistakes :-(