5 ms·

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python. I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan. What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a better choice for a lot of what people do with bash, even if you are running om a desktop.

caslon 5y ago
Shell scripts are nicer than Python, though. There was a brief moment in time where Python nearly rivaled shell scripts in convenience and straightforwardness, but November of 2008 was many years ago, now. We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it.
- rascul 5y ago
  > We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it. Arrays make a world of a difference. Deprecate sh, keep bash.
  - caslon 5y ago
    That's a terrible idea. A shell scripting language doesn't need to do everything in the world. It just needs to tape together tools that can do everything. POSIX sh can pass arrays around just fine, and that's all it needs to do. Feature creep is the worst possible thing you could do to a shell scripting language.
    - iforgotpassword 5y ago
      No it can't. You have the argument array which is a horrible workaround. If you need to write scripts that interact with other tools a lot, bash is the language of choice. Starting and handling other processes is a messy thing in any other language.
      - caslon 5y ago
        It's not a terrible workaround; it's a beautiful demonstration of how flexible the standard shell is.
        rascul 5y ago
        It's a bit of an inefficient hack compared to a language feature.
    - 1500100900 5y ago
      Which POSIX sh do you have in mind and how does one pass arrays around in it?
      - caslon 5y ago
        POSIX sh. Pass it as a string, use standard programs to turn it into what you want. Voila. Not that hard. Just like you do everything else in UNIX.
        1500100900 5y ago
        If you mean a standard, it will be too abstract to be considered as something that can run anything. Sometimes it has to be too vague in order to not make existing Bourne-style shells non-compliant. This isn't, for example, a standard for the C programming language where you can throw some things into the UB bag or the ID bag. POSIX sh is more what you'd call "guidelines" than actual standard. Even if it were an implementation, how would you write a "POSIX sh" equivalent of these lines taken from a bash script? (My point isn't that it's impossible.) mkdir -p /tmp/nodes/{a,b,c,d,e} ; NODES=( /tmp/nodes/{a,b,c,d,e} ) ; echo ${NODES[$((`date +%-j` % ${#NODES[@]}))]}
    - throwaway984393 5y ago
      But POSIX sh doesn't have array support? 99% of my use case for Bash over POSIX sh is arrays, associative arrays, BASH_SOURCE, and PIPELINE (or whatever that array is that has positional pipe return status)
  - iforgotpassword 5y ago
    This. The problem most people have with bash scripts is that they are mostly writing sh scripts and occasionally throw in [[ ]] but still use 99% of the ugly workarounds and tricks you had to use in sh to get anywhere.
axegon_ 5y ago
> I think we should really be working to deprecate large bash scripts. I second this: I myself have a problem here, which, I guess is somewhat related: I try to keep everything universal and each time I try to generalize what I'm trying to achieve through some sort of abstraction. As a consequence I keep adding functions and aliases to my (zsh/bash)rc to the point where they become absolutely unmanageable. At this very moment zshrc is 8000+ lines long. Sure, I have a cronjob which backs it up occasionally but it's more of a maintenance/readability hell.
- necheffa 5y ago
  Have you considered that your run config is probably not the place for this sort of thing? You could instead have focused libraries in smaller files located at /usr/local/lib/ or wherever tickles your fancy. Then source them as needed from scripts.
  - axegon_ 5y ago
    I do that too but usually ends up being harder to keep track of them and backup, even if I keep them in a separate directory and added it to $PATH.
- hyperupcall 5y ago
  Wow, 8 thousand lines is pretty insane. When my bashrc started to get long, I started to separate things into different files and source them. And then that got too complicated so then I made them separate executables with different directories. But then I couldn't reuse functionality as easily so then I found myself making a package manager. And now I'm moving some of that stuff _BACK_ into my bashrc (sort of). It seems there is really no end...
- eternityforest 5y ago
  This is one of the reasons I like GUIs. I can recreate almost all my configuration from scratch on a brand new Mint install in 15 minutes aside from a few VS code settings I'd need Google for. My .xonshrc just has a few visual tweaks. I have set up exactly zero cron jobs aside from maybe whatever mint's backup stuff uses for a timer for the snapshots. I don't have any custom bash scripts that I use, other than some build scripts and things like that, that live in project repos. I call it "decustomizing" as a counterpoint to minimalism. I don't try to simplify my life, I try to remove customization and unusual tech, even if that means using a 100MB app instead of a 1kb script I'd have to maintain myself. I've just... had about enough of small time garage tinkering level projects at this point, and have really started to appreciate monolithic opinionated systems. Stuff that lets you do anything, in exactly one way.
cushychicken 5y ago
Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?
- snidane 5y ago
  What Python is to Java, Bash is to Python. Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu. I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.
  - cushychicken 5y ago
    I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha rudimentary bash-fu I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.
    - snidane 5y ago
      You might want to check out 'hck' to replace 'cut'. https://github.com/sstadick/hck https://github.com/sstadick/hck
      - cushychicken 5y ago
        I may give it a try - I have a bias to stuff that comes preinstalled, though, as I know I'll always have the chance to use it on a stock linux box.
- Hizonner 5y ago
  So your 10 lines of bash use a bunch of other programs to do almost all the work, right? So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.
cjvirtucio 5y ago
Ansible has a linter. We do use it on our playbooks (locally and in CI). There's also a framework for testing and linting ansible plugins (ansible-test IIRC), though that's been a little painful for us to setup. That said, we do have a lot of helper scripts that we use in our day-to-day (local development). They're not "large bash scripts", but they're small enough that we don't really need a proper programming language. Some degree of code quality with style guides and shellcheck does help.
monkeybutton 5y ago
Seconded. I use Python daily and bash monthly at best. After the Nth time looking up how to do specific kind of conditional check in bash, I gave up started writing all the extra scripts and tooling I need using Python instead.

caslon 5y ago

Shell scripts are nicer than Python, though. There was a brief moment in time where Python nearly rivaled shell scripts in convenience and straightforwardness, but November of 2008 was many years ago, now. We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it.

rascul 5y ago
> We should probably deprecate Bash, though. It doesn't offer enough over the standard for it to be worth it. Arrays make a world of a difference. Deprecate sh, keep bash.
- caslon 5y ago
  That's a terrible idea. A shell scripting language doesn't need to do everything in the world. It just needs to tape together tools that can do everything. POSIX sh can pass arrays around just fine, and that's all it needs to do. Feature creep is the worst possible thing you could do to a shell scripting language.
  - iforgotpassword 5y ago
    No it can't. You have the argument array which is a horrible workaround. If you need to write scripts that interact with other tools a lot, bash is the language of choice. Starting and handling other processes is a messy thing in any other language.
    - caslon 5y ago
      It's not a terrible workaround; it's a beautiful demonstration of how flexible the standard shell is.
      - rascul 5y ago
        It's a bit of an inefficient hack compared to a language feature.
  - 1500100900 5y ago
    Which POSIX sh do you have in mind and how does one pass arrays around in it?
    - caslon 5y ago
      POSIX sh. Pass it as a string, use standard programs to turn it into what you want. Voila. Not that hard. Just like you do everything else in UNIX.
      - 1500100900 5y ago
        If you mean a standard, it will be too abstract to be considered as something that can run anything. Sometimes it has to be too vague in order to not make existing Bourne-style shells non-compliant. This isn't, for example, a standard for the C programming language where you can throw some things into the UB bag or the ID bag. POSIX sh is more what you'd call "guidelines" than actual standard. Even if it were an implementation, how would you write a "POSIX sh" equivalent of these lines taken from a bash script? (My point isn't that it's impossible.) mkdir -p /tmp/nodes/{a,b,c,d,e} ; NODES=( /tmp/nodes/{a,b,c,d,e} ) ; echo ${NODES[$((`date +%-j` % ${#NODES[@]}))]}
  - throwaway984393 5y ago
    But POSIX sh doesn't have array support? 99% of my use case for Bash over POSIX sh is arrays, associative arrays, BASH_SOURCE, and PIPELINE (or whatever that array is that has positional pipe return status)
- iforgotpassword 5y ago
  This. The problem most people have with bash scripts is that they are mostly writing sh scripts and occasionally throw in [[ ]] but still use 99% of the ugly workarounds and tricks you had to use in sh to get anywhere.

axegon_ 5y ago

> I think we should really be working to deprecate large bash scripts. I second this: I myself have a problem here, which, I guess is somewhat related: I try to keep everything universal and each time I try to generalize what I'm trying to achieve through some sort of abstraction. As a consequence I keep adding functions and aliases to my (zsh/bash)rc to the point where they become absolutely unmanageable. At this very moment zshrc is 8000+ lines long. Sure, I have a cronjob which backs it up occasionally but it's more of a maintenance/readability hell.

necheffa 5y ago
Have you considered that your run config is probably not the place for this sort of thing? You could instead have focused libraries in smaller files located at /usr/local/lib/ or wherever tickles your fancy. Then source them as needed from scripts.
- axegon_ 5y ago
  I do that too but usually ends up being harder to keep track of them and backup, even if I keep them in a separate directory and added it to $PATH.
hyperupcall 5y ago
Wow, 8 thousand lines is pretty insane. When my bashrc started to get long, I started to separate things into different files and source them. And then that got too complicated so then I made them separate executables with different directories. But then I couldn't reuse functionality as easily so then I found myself making a package manager. And now I'm moving some of that stuff _BACK_ into my bashrc (sort of). It seems there is really no end...
eternityforest 5y ago
This is one of the reasons I like GUIs. I can recreate almost all my configuration from scratch on a brand new Mint install in 15 minutes aside from a few VS code settings I'd need Google for. My .xonshrc just has a few visual tweaks. I have set up exactly zero cron jobs aside from maybe whatever mint's backup stuff uses for a timer for the snapshots. I don't have any custom bash scripts that I use, other than some build scripts and things like that, that live in project repos. I call it "decustomizing" as a counterpoint to minimalism. I don't try to simplify my life, I try to remove customization and unusual tech, even if that means using a 100MB app instead of a 1kb script I'd have to maintain myself. I've just... had about enough of small time garage tinkering level projects at this point, and have really started to appreciate monolithic opinionated systems. Stuff that lets you do anything, in exactly one way.

cushychicken 5y ago

Where do you draw the line as "large"? I just threw out a few hundred lines of Python in exchange for ten lines of bash script + cron job to automate nightly app updates. Way easier to get working, way less painful to debug. I grant, however, that it's not particularly large. What is?

snidane 5y ago
What Python is to Java, Bash is to Python. Many simple file and data munging tasks can be done on cli 100x faster with 10x less code than Python, using rudimentary bash-fu. I already see a wave of Python undoing in the data world. Python becoming the cobol of this field.
- cushychicken 5y ago
  I just learned about rev; rev plus cut could have saved me years of writing one off Python scripts to cut out the exact variable I need, haha rudimentary bash-fu I wish there were some guides on how to get past rudimentary bash-fu. My bash text munging is still pretty rudimentary. I'd love to get to journeyman text smash status.
  - snidane 5y ago
    You might want to check out 'hck' to replace 'cut'. https://github.com/sstadick/hck https://github.com/sstadick/hck
    - cushychicken 5y ago
      I may give it a try - I have a bias to stuff that comes preinstalled, though, as I know I'll always have the chance to use it on a stock linux box.
Hizonner 5y ago
So your 10 lines of bash use a bunch of other programs to do almost all the work, right? So what you need is a good language that lets you concisely express ways of calling out to other programs. Not necessarily a language that's backward-compatible with whatever seemed like a good idea for a CLI in 1979.

cjvirtucio 5y ago

Ansible has a linter. We do use it on our playbooks (locally and in CI). There's also a framework for testing and linting ansible plugins (ansible-test IIRC), though that's been a little painful for us to setup. That said, we do have a lot of helper scripts that we use in our day-to-day (local development). They're not "large bash scripts", but they're small enough that we don't really need a proper programming language. Some degree of code quality with style guides and shellcheck does help.

monkeybutton 5y ago

Seconded. I use Python daily and bash monthly at best. After the Nth time looking up how to do specific kind of conditional check in bash, I gave up started writing all the extra scripts and tooling I need using Python instead.