3 ms·

I’m also impressed. For a 5000+ line shell script, it’s pretty well-structured & quite readable.

kick 7y ago
You have to go out of your way to make a shell script that isn't easy to read. They're generally more readable at scale than "proper" languages.
- mratsim 7y ago
  As soon as you deal with env variables, need to support zsh and various shells, it quickly devolves into a hot mess.
  - kick 7y ago
    Ignoring POSIX-compliance does that, yes.
    - throwaway2048 7y ago
      POSIX compliance in no way makes environmental variables in shell scripting more usable and readable, its usually the opposite. I say this as somebody who has written shell scripts for almost 20 years. Constructs like if [ "X${str1}" = "X${str2}" ] to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. Not to mention the hell that is trying to use a user supplied filename safely in shellscript. (for the uninitiated, a unix filename can contain any character, and any sequence of bytes besides / and 0x00, including newlines, backspaces, shell meta-charachters and so many more exciting things)
      - YSFEJ4SWJUVU6 7y ago
        > to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables. The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway). # this is bad (also obsolete) [ "$var" != foo -a "$var" != bar ] # this is good (and fully POSIX compliant) [ "$var" != foo ] && [ "$var" != bar ] # you probably don't need to care for systems where this was necessary [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]
      - clarry 7y ago
        Sounds like your POSIX-fu is more than 20 years out of date. Even 1003.2-1992 refers to systems that break with the correct form as historical. https://i.imgur.com/p20s8Pi.png https://i.imgur.com/p20s8Pi.png

kick 7y ago

You have to go out of your way to make a shell script that isn't easy to read. They're generally more readable at scale than "proper" languages.

mratsim 7y ago
As soon as you deal with env variables, need to support zsh and various shells, it quickly devolves into a hot mess.
- kick 7y ago
  Ignoring POSIX-compliance does that, yes.
  - throwaway2048 7y ago
    POSIX compliance in no way makes environmental variables in shell scripting more usable and readable, its usually the opposite. I say this as somebody who has written shell scripts for almost 20 years. Constructs like if [ "X${str1}" = "X${str2}" ] to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. Not to mention the hell that is trying to use a user supplied filename safely in shellscript. (for the uninitiated, a unix filename can contain any character, and any sequence of bytes besides / and 0x00, including newlines, backspaces, shell meta-charachters and so many more exciting things)
    - YSFEJ4SWJUVU6 7y ago
      > to avoid things exploding because a zero length variable might exist is a stupid and ugly hack. That has less to do with POSIX compliance, as opposed to working around quirks with less-compliant historical implementations. Also, I think you'd have to dig pretty deep to find a test that doesn't support zero-length arguments; you'd be safe as long as you quote your variables. The actual problem of ambiguity arises from variables that are also syntax, like '(', or '!', when using compound expressions (which you should avoid anyway). # this is bad (also obsolete) [ "$var" != foo -a "$var" != bar ] # this is good (and fully POSIX compliant) [ "$var" != foo ] && [ "$var" != bar ] # you probably don't need to care for systems where this was necessary [ "X$var" != Xfoo ] && [ "X$var" != Xbar ]
    - clarry 7y ago
      Sounds like your POSIX-fu is more than 20 years out of date. Even 1003.2-1992 refers to systems that break with the correct form as historical. https://i.imgur.com/p20s8Pi.png https://i.imgur.com/p20s8Pi.png