3 ms·

Serious Programming in BASH

2 points by noch 10y ago

dozzie 10y ago
It's "Bash", not "BASH". Don't use the keyword "function" to define a function. It's excessive and doesn't work in (some) other shells, while the original "foo() { ... }" syntax works everywhere.
- dllthomas 10y ago
  I don't see a downside to using "function" to define a function that contains a lot of bashisms anyway. If you find it more readable, go for it.
  - dozzie 10y ago
    Well, there certainly are heavy downsindes of using bashisms at all. And there are downsides of not knowing that you use bashisms. I've seen very little people who pay any attention to whether some syntax is Bash-specific or not. These people don't understand the difference between "#!/bin/sh" and "#!/bin/bash" shee-bang lines. With this being said, it's just safer to stick to syntax that works everywhere. Regarding bashisms, I've seen several times when Bash changed its behaviour slightly between minor versions. It was things along the lines of quoted pattern implying an anchored match before and unanchored match after. Such changes didn't visibly break the script, but its internal logic suddenly changed. And now go figure why your script stopped working after an upgrade. Bashisms rarely provide anything you couldn't do with POSIX/SUS shell syntax and tools (printing stack trace from the article being one such example that's hard to do otherwise), and even when you need to escape to an external tool, it rarely matters performance-wise.
    - dllthomas 10y ago
      I don't think I disagree substantially, I just think it was super weird to complain about the use of "function" in an article that was all about using bashisms. Personally, I find a lot of bashisms a nice affordance at the command line, and tend to avoid them in scripts meant to persist or be run outside a UI/bash-specific context. Bash is a great UI, poor programming language (sh isn't any better a programming language, but at least it's better standardized).
      - dozzie 10y ago
        > Personally, I find a lot of bashisms a nice affordance at the command line, and tend to avoid them in scripts meant to persist Oh, my bad: I haven't said this explicitly. Thank you for pointing this aspect out. Though the article is about scripts, so this context was somewhat implied. I don't mind the shell-specific syntax either, if it is for a command at hand. In fact, I quite often use what zsh offers with globbing, and sometimes special redirection. I just hate it being used in scripts.
        dllthomas 10y ago
        Yeah, the article was definitely talking about scripts - I just meant that as an aside, in case anyone but us actually reads these comments :)

2 points by noch 10y ago

It's "Bash", not "BASH". Don't use the keyword "function" to define a function. It's excessive and doesn't work in (some) other shells, while the original "foo() { ... }" syntax works everywhere.

dllthomas 10y ago
I don't see a downside to using "function" to define a function that contains a lot of bashisms anyway. If you find it more readable, go for it.
- dozzie 10y ago
  Well, there certainly are heavy downsindes of using bashisms at all. And there are downsides of not knowing that you use bashisms. I've seen very little people who pay any attention to whether some syntax is Bash-specific or not. These people don't understand the difference between "#!/bin/sh" and "#!/bin/bash" shee-bang lines. With this being said, it's just safer to stick to syntax that works everywhere. Regarding bashisms, I've seen several times when Bash changed its behaviour slightly between minor versions. It was things along the lines of quoted pattern implying an anchored match before and unanchored match after. Such changes didn't visibly break the script, but its internal logic suddenly changed. And now go figure why your script stopped working after an upgrade. Bashisms rarely provide anything you couldn't do with POSIX/SUS shell syntax and tools (printing stack trace from the article being one such example that's hard to do otherwise), and even when you need to escape to an external tool, it rarely matters performance-wise.
  - dllthomas 10y ago
    I don't think I disagree substantially, I just think it was super weird to complain about the use of "function" in an article that was all about using bashisms. Personally, I find a lot of bashisms a nice affordance at the command line, and tend to avoid them in scripts meant to persist or be run outside a UI/bash-specific context. Bash is a great UI, poor programming language (sh isn't any better a programming language, but at least it's better standardized).
    - dozzie 10y ago
      > Personally, I find a lot of bashisms a nice affordance at the command line, and tend to avoid them in scripts meant to persist Oh, my bad: I haven't said this explicitly. Thank you for pointing this aspect out. Though the article is about scripts, so this context was somewhat implied. I don't mind the shell-specific syntax either, if it is for a command at hand. In fact, I quite often use what zsh offers with globbing, and sometimes special redirection. I just hate it being used in scripts.
      - dllthomas 10y ago
        Yeah, the article was definitely talking about scripts - I just meant that as an aside, in case anyone but us actually reads these comments :)