3 ms·

There are a lot of unsafe defaults in JavaScript too, most prominently async error propagation. Basically all languages have some tricky fatal flaws, even Haske

by mbrock 10y ago

There are a lot of unsafe defaults in JavaScript too, most prominently async error propagation. Basically all languages have some tricky fatal flaws, even Haskell (lazy I/O can make very strange bugs, etc). I just don't think we should reject shell scripts entirely because some care is required to write them correctly. Shell is way too valuable.

TheAceOfHearts 10y ago
You make a fair point. Although in more recent versions of JS the whole async error propagation isn't as big of an issue thanks to async functions and promises. I guess the biggest reason to use JS is that since I'm already using it every day, it's much easier to continue using a language I'm highly familiar with. Whenever I have to write a shell script I always have to pull up references and read through a couple Stack Overflow posts. I don't reject shell scripts, though. I agree that in some cases it can lead to much simpler code. The power and composability with pipes and immediate substitutions is incredibly powerful. I've had a few cases where I replaced far more complicated node scripts with simpler shell scripts. What I'd truly love is a reference guide that showed how to correctly do certain things with shell scripts. Here's a real-world example I struggled with: Writing end-to-end tests with selenium and a test runner. I wanted a script to start up a selenium server and wait for it to be ready. Then it should start the test runner. If the test runner exited successfully, kill the selenium server and browser, and exit with a 0. If the test runner or selenium server crashed or failed somehow, clean up and exit with a 1. Even after much trial and error, I still ended up with occasional Chrome copies staying open after failures.
- mbrock 10y ago
  Ah, for me one of the biggest reasons to use shell is that I use it every day to just do stuff in the terminal, so it's great to use that knowledge in scripts, too. But yeah, some of the syntax is quite obscure. That kind of reference guide would be great. I haven't checked out any of the books on shell programming, but there should be a decent audience for a website with just good patterns for shell scripts, like you describe. Trapping signals and keeping track of child PIDs is quite tricky, yeah. (It's quite tricky in any language!) You might be interested in my "wd" program that's basically a bash wrapper for the WebDriver API, which I made because I wanted to write end-to-end tests and automation tools in shell. https://github.com/mbrock/wd https://github.com/mbrock/wd

by mbrock 10y ago

TheAceOfHearts 10y ago

You make a fair point. Although in more recent versions of JS the whole async error propagation isn't as big of an issue thanks to async functions and promises. I guess the biggest reason to use JS is that since I'm already using it every day, it's much easier to continue using a language I'm highly familiar with. Whenever I have to write a shell script I always have to pull up references and read through a couple Stack Overflow posts. I don't reject shell scripts, though. I agree that in some cases it can lead to much simpler code. The power and composability with pipes and immediate substitutions is incredibly powerful. I've had a few cases where I replaced far more complicated node scripts with simpler shell scripts. What I'd truly love is a reference guide that showed how to correctly do certain things with shell scripts. Here's a real-world example I struggled with: Writing end-to-end tests with selenium and a test runner. I wanted a script to start up a selenium server and wait for it to be ready. Then it should start the test runner. If the test runner exited successfully, kill the selenium server and browser, and exit with a 0. If the test runner or selenium server crashed or failed somehow, clean up and exit with a 1. Even after much trial and error, I still ended up with occasional Chrome copies staying open after failures.

mbrock 10y ago
Ah, for me one of the biggest reasons to use shell is that I use it every day to just do stuff in the terminal, so it's great to use that knowledge in scripts, too. But yeah, some of the syntax is quite obscure. That kind of reference guide would be great. I haven't checked out any of the books on shell programming, but there should be a decent audience for a website with just good patterns for shell scripts, like you describe. Trapping signals and keeping track of child PIDs is quite tricky, yeah. (It's quite tricky in any language!) You might be interested in my "wd" program that's basically a bash wrapper for the WebDriver API, which I made because I wanted to write end-to-end tests and automation tools in shell. https://github.com/mbrock/wd https://github.com/mbrock/wd