4 ms·

I have said it several times on HN, but it bears repeating: As much as I find shell programming approachable and enjoyable, it really should be avoided if you c

I have said it several times on HN, but it bears repeating: As much as I find shell programming approachable and enjoyable, it really should be avoided if you can help it. Using `set -euo pipefail` and tools like Shellcheck help, but there's a limit. https://sipb.mit.edu/doc/safe-shell/ https://sipb.mit.edu/doc/safe-shell/ ^ Says the guy who forked a project an hour ago just to fix a couple errors, found a subshell and said, 'You're done, go no further' :)

hpoe 5y ago
15 seconds on the shell beats 5 minutes trying to debug a ruby or pythons script. That said I would agree as soon as something becomes complex or you need to do computation looking outside the shell is probably a good idea. The huerestic that I use is 1. Do I need to do math? Move out of the shell. 2. Is the logic starting to get complicated enough that I need consider creating modules? Move out of the shell. 3. Is there enough code to fill more than one screen? Out of the shell I go. 4. Is this going to be something that needs robust error handling and that will be used frequently outside of me? Out of the shell. I've found that as long as I don't hit one of those conditions hacking around in the shell is quite powerful and useful.
- chrisfinazzo 5y ago
  For me (a Comms major/IS minor as an undergrad), most of what I'm manipulating is text and shell is just a tool to speed up the process and as such doesn't have those concerns. Still, I've found Rake and Make - as simple containers for shell rather useful and more flexible - newlines are sane, far less of this `\n` nonsense. ^ An odd complaint, but it just seems like the terminal or the environment should handle this without input from me. Now if only I could do something about Make syntax requiring tabs...
- pjmlp 5y ago
  In what concerns UNIX shell, Python always wins for me, other than very basic scripts to automate launching applications, or a pipeline.
- einpoklum 5y ago
  > 3. Is there enough code to fill more than one screen? Out of the shell I go. Completely disagree. Just parsing a command-line takes a screen's worth of lines. Hell, just the usage info message for a script can take that much. > 4. Is this going to be something that needs robust error handling and that will be used frequently outside of me? Out of the shell. Disagree even more strongly. You're saying never to write shell scripts for use by many people. Actually, shell scripts make up a lot of a typical systems' /usr/bin and /usr/sbin - and that is fine and proper.
mistrial9 5y ago
my colleague advised -uxe literally yesterday.. (I have a 30,000 line bash environment inherited from a chain-smoking author ten years ago.. no one wants to touch it.. it is built with autotools too!)

hpoe 5y ago

15 seconds on the shell beats 5 minutes trying to debug a ruby or pythons script. That said I would agree as soon as something becomes complex or you need to do computation looking outside the shell is probably a good idea. The huerestic that I use is 1. Do I need to do math? Move out of the shell. 2. Is the logic starting to get complicated enough that I need consider creating modules? Move out of the shell. 3. Is there enough code to fill more than one screen? Out of the shell I go. 4. Is this going to be something that needs robust error handling and that will be used frequently outside of me? Out of the shell. I've found that as long as I don't hit one of those conditions hacking around in the shell is quite powerful and useful.

chrisfinazzo 5y ago
For me (a Comms major/IS minor as an undergrad), most of what I'm manipulating is text and shell is just a tool to speed up the process and as such doesn't have those concerns. Still, I've found Rake and Make - as simple containers for shell rather useful and more flexible - newlines are sane, far less of this `\n` nonsense. ^ An odd complaint, but it just seems like the terminal or the environment should handle this without input from me. Now if only I could do something about Make syntax requiring tabs...
pjmlp 5y ago
In what concerns UNIX shell, Python always wins for me, other than very basic scripts to automate launching applications, or a pipeline.
einpoklum 5y ago
> 3. Is there enough code to fill more than one screen? Out of the shell I go. Completely disagree. Just parsing a command-line takes a screen's worth of lines. Hell, just the usage info message for a script can take that much. > 4. Is this going to be something that needs robust error handling and that will be used frequently outside of me? Out of the shell. Disagree even more strongly. You're saying never to write shell scripts for use by many people. Actually, shell scripts make up a lot of a typical systems' /usr/bin and /usr/sbin - and that is fine and proper.

mistrial9 5y ago

my colleague advised -uxe literally yesterday.. (I have a 30,000 line bash environment inherited from a chain-smoking author ten years ago.. no one wants to touch it.. it is built with autotools too!)