7 ms·

Bash is awful. But so are shells in general. Even Rob Pike says as soon as your shell program gets longer than a few lines, write it in a proper language.

clebio 10y ago
Citation please? I would love to share this with some of my coworkers.
- SixSigma 10y ago
  I can't find it anywhere, I have tried. I think it is in the plan 9 mailing list - 9fans, as that is where I have interacted with Rob
satysin 10y ago
I feel that principle is true from all high-level languages as you move down the chain. Shell scripts should be 1-20 lines. Python/Ruby/whatever for 20-100 and compiled for anything >100.
- jamespo 10y ago
  What if you use Nuitka or PyPy for Python, does that magically allow you across the arbitrary border?
- mikestew 10y ago
  I was about to refute you with a recent example of mine that just needed to serially execute a bunch of commands, and it's well over 20 lines. Then I remembered that I needed to introduce some branching logic, said "not in bash, I'm not", and rewrote it in Python. So for me, it's not a matter of LoC but complexity. Need to copy file from here to there, then commit to git repo, blah, blah, blah, then kick off a build? Whether it's a 1000 lines or 2, I don't have a problem with doing that in bash. But as soon as I need some logic (or on rare occasions, perf), I go to something else. Given that, why do you cut shell scripts off at 20 lines? I ask in the spirit of being open to the possibility that maybe I'm doing it wrong. :-)
  - satysin 10y ago
    Well it isn't a hard limit. I am okay with a 25 line script for example ;) Well really you are more right than me. It is about complexity more than the number of lines. However for the most part the longer something is the more complex it is to work with even if it does something simple. Managing a 1000 line bash script is almost certainly going to be more painful than doing it "properly" in Python or Java or whatever. It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained and I find that gets easier as I work "down the chain".
    - mikestew 10y ago
      It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained. Thanks for taking the time to reply. And you're right, even I wouldn't want to maintain 1000 lines of serially-executed commands, meaning I have a line limit somewhere as well. So maybe a mix of complexity, and at some point length even if I don't put a number on it like you did.
      - satysin 10y ago
        Everyone has their own way of working :) I first got into things with batch files on Windows 95 and quickly realised how awful they are when more than 5 lines! I quickly moved on to their Windows Scripting Host stuff which was better but still painful. Then VB6 then C++/MFC.... The usual Windows user story. Scripting on Unix is a lot better but it is only recently that places seriously use VCS for scripts in my experience so before the days of Git if you wanted to do anything with an iota of manageability it meant you did it in a "real" language hehe.
  - vacri 10y ago
    For me, the marker point is arrays. Arrays in shell are terrible - if I'm going to need an array, drop shell for something else.
- scarygliders 10y ago
  Respectfully disagree. I've been writing full-on applications using Python and Qt4 which are well over 100 lines of code.
  - satysin 10y ago
    That's cool, we are just different is all. I use Python for automation tasks that require more than what I can do with Bash/Batch/PowerShell but don't warrant a full write/compile/deploy process. If your job is working in Python then sure you are going to use it way past the limits of what I would use it for. Things are a lot nicer these days than 10 years ago though with PyCharm, etc. it makes managing a Python project so much easier.
  - dagw 10y ago
    Me too. And personally I'm somewhat conflicted as to whether or not it's a good idea. On the one hand I love python and use it for virtually all code I write (that doesn't have to run in a browser) and I'm quite convinced that for what I'm doing it's the most efficient language for me to use. On the other hand I have found myself on more than one occasion really wishing python wasn't quite so dynamic when working on large python code bases and if I was starting a new large desktop application today I'm not sure python would be my first choice. There really is something to be said for a better/stricter type system.
GlennS 10y ago
When my shell program gets longer than a few lines, it's time to break it into some makefile targets with intermediate files. I have in the past written a moderate size program in Powershell (installer for a program which needed a lot of configuration for a lot of components and got installed into a lot of different environments). And while that probably wasn't the best approach in hindsight, it wasn't actually that awful an experience. It's not a million miles off writing a moderate size JavaScript program, except that it has an actual module system. I wish they hadn't chosen dynamic scope though, nor the silly array result squashing behaviour. Also the IIS 7 Powershell Provider - that was bad. (Or a proper language is good too.)

clebio 10y ago

Citation please? I would love to share this with some of my coworkers.

SixSigma 10y ago
I can't find it anywhere, I have tried. I think it is in the plan 9 mailing list - 9fans, as that is where I have interacted with Rob

satysin 10y ago

I feel that principle is true from all high-level languages as you move down the chain. Shell scripts should be 1-20 lines. Python/Ruby/whatever for 20-100 and compiled for anything >100.

jamespo 10y ago
What if you use Nuitka or PyPy for Python, does that magically allow you across the arbitrary border?
mikestew 10y ago
I was about to refute you with a recent example of mine that just needed to serially execute a bunch of commands, and it's well over 20 lines. Then I remembered that I needed to introduce some branching logic, said "not in bash, I'm not", and rewrote it in Python. So for me, it's not a matter of LoC but complexity. Need to copy file from here to there, then commit to git repo, blah, blah, blah, then kick off a build? Whether it's a 1000 lines or 2, I don't have a problem with doing that in bash. But as soon as I need some logic (or on rare occasions, perf), I go to something else. Given that, why do you cut shell scripts off at 20 lines? I ask in the spirit of being open to the possibility that maybe I'm doing it wrong. :-)
- satysin 10y ago
  Well it isn't a hard limit. I am okay with a 25 line script for example ;) Well really you are more right than me. It is about complexity more than the number of lines. However for the most part the longer something is the more complex it is to work with even if it does something simple. Managing a 1000 line bash script is almost certainly going to be more painful than doing it "properly" in Python or Java or whatever. It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained and I find that gets easier as I work "down the chain".
  - mikestew 10y ago
    It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained. Thanks for taking the time to reply. And you're right, even I wouldn't want to maintain 1000 lines of serially-executed commands, meaning I have a line limit somewhere as well. So maybe a mix of complexity, and at some point length even if I don't put a number on it like you did.
    - satysin 10y ago
      Everyone has their own way of working :) I first got into things with batch files on Windows 95 and quickly realised how awful they are when more than 5 lines! I quickly moved on to their Windows Scripting Host stuff which was better but still painful. Then VB6 then C++/MFC.... The usual Windows user story. Scripting on Unix is a lot better but it is only recently that places seriously use VCS for scripts in my experience so before the days of Git if you wanted to do anything with an iota of manageability it meant you did it in a "real" language hehe.
- vacri 10y ago
  For me, the marker point is arrays. Arrays in shell are terrible - if I'm going to need an array, drop shell for something else.
scarygliders 10y ago
Respectfully disagree. I've been writing full-on applications using Python and Qt4 which are well over 100 lines of code.
- satysin 10y ago
  That's cool, we are just different is all. I use Python for automation tasks that require more than what I can do with Bash/Batch/PowerShell but don't warrant a full write/compile/deploy process. If your job is working in Python then sure you are going to use it way past the limits of what I would use it for. Things are a lot nicer these days than 10 years ago though with PyCharm, etc. it makes managing a Python project so much easier.
- dagw 10y ago
  Me too. And personally I'm somewhat conflicted as to whether or not it's a good idea. On the one hand I love python and use it for virtually all code I write (that doesn't have to run in a browser) and I'm quite convinced that for what I'm doing it's the most efficient language for me to use. On the other hand I have found myself on more than one occasion really wishing python wasn't quite so dynamic when working on large python code bases and if I was starting a new large desktop application today I'm not sure python would be my first choice. There really is something to be said for a better/stricter type system.

GlennS 10y ago

When my shell program gets longer than a few lines, it's time to break it into some makefile targets with intermediate files. I have in the past written a moderate size program in Powershell (installer for a program which needed a lot of configuration for a lot of components and got installed into a lot of different environments). And while that probably wasn't the best approach in hindsight, it wasn't actually that awful an experience. It's not a million miles off writing a moderate size JavaScript program, except that it has an actual module system. I wish they hadn't chosen dynamic scope though, nor the silly array result squashing behaviour. Also the IIS 7 Powershell Provider - that was bad. (Or a proper language is good too.)