7 ms·

I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.

by xchaotic 10y ago

tormeh 10y ago
Why not use Python instead? Shellscript is so... chaotic.
- chillydawg 10y ago
  cos they run without needing python.
  - DonHopkins 10y ago
    It's much easier to not need shell scripts, than to not need Python scripts.
- DonHopkins 10y ago
  I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Like the way the shell would fork off an "expr" sub-process to parse a mathematical expression to add two numbers, then write the result to a pipe via stdout, then terminate the process, clean up all its resources, and switch context back to the shell, which then read the serialized sum back in from the other end of the pipe, and went about its business, regardless of the fact that the CPU running the shell already had its own built-in "add" instruction in hardware.
  - karma_vaccum123 10y ago
    > I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Unless you are over fifty years old, you never experienced this. Rob Pike said it best: "Those days are dead and gone and the eulogy was delivered by Perl." Perl being a thing in 1995...
    - DonHopkins 10y ago
      Now "expr" has finally been rewritten as a jQuery plug-in. [1] https://github.com/baphomet-berlin/jQuery-basic-arithmetic-plugin https://github.com/baphomet-berlin/jQuery-basic-arithmetic-p...
  - linkregister 10y ago
    This is the first coherent refutation of the "do one thing well" ethos I have ever read. Thanks for putting into words what I haven't been able to express myself.
- tom-lord 10y ago
  Shell/batch scripting can often be useful in the devops world, where you have no guarantee that any additional tools (python, ruby, perl, powershell, whatever) wil be available. Shell scripts are guaranteed to be runnable on all machines. Unfortunately the shell "language" sucks, but still...
  - kbutler 10y ago
    So you're running 'sh' scripts, right? none of that new-fangled bash stuff... Oh, and be very careful of the commands your script invokes! shell scripts have no guarantee of portability (often less than Python, which has a rich standard library available on all platforms).
  - CaptSpify 10y ago
    > Unfortunately the shell "language" sucks, but still... Why do you say that? genuinely curious
  - Retra 10y ago
    Shell languages are great at doing interactive programming. Few non-shell languages can match the convenience, flexibility, and expressiveness in that domain. Of course, in any other domain (scripts) they are awful.
- andybak 10y ago
  Python + Fabric is a lovely devops/sysadmin toolbox.
  - aaronbasssett 10y ago
    Still no Python 3 support though
- mbrock 10y ago
  How do you write "foo | bar" in Python?
  - IshKebab 10y ago
    How often do you actually need to do that. 99% of `foo | bar` command could easily be `foo > a && bar < a` which is pretty trivial to do in Python.
    - mbrock 10y ago
      Well, how do you write that in Python? I'm curious because these simple things that are delightfully easy in bash often turn out to be surprisingly tedious in other languages. Of course, some things are tedious in bash too. But a basic principle of shell scripting is that you call other programs to do the stuff you don't want to do in shell.
      - IshKebab 10y ago
        Like this: http://stackoverflow.com/a/1996540 http://stackoverflow.com/a/1996540 I agree it is tedious, but to be honest, reading and writing to stdin/out isn't something that would commonly need to be done in a robust system. If the world were perfect you would use library functions. I definitely think there is scope for a language that works well as an interactive shell, and as a general purpose language. They have somewhat conflicting constraints but I'm sure we can do better than Bash. Have you seen how [ is implemented?
        mbrock 10y ago
        No stdout or stdin for robust systems? I disagree. Yeah, a nicer shell-like language would be cool. I've been thinking about it for a while. Bash is quirky but it gets a lot of stuff right and once you understand it it can be extremely ergonomic and productive. And not depending on language run times other than shell can be really glorious in some situations, too...
    - prodigal_erik 10y ago
CrLf 10y ago
I worry when I can't tell if a comment like this is based on fact or just trying to be funny. Because I've seen my share of nasty "legacy" automation but, surprisingly, I still think a good set of well thought-out shell scripts written by someone that understands what's being automated still beat modern tools, even when the person doing the automation is the same. I don't quite know why this is, but there's something timeless about shell scripts. I've also seen shell script automation survive for a long time unattended and with zero issues. Not so with some of the modern tools that are supposed to be all unicorns and rainbows.
- acveilleux 10y ago
  My take is that the shell script does not have any unspoken assumption or magic that is performed by the tool. It all has to be in the script building up strictly from well-understood and long stable basic bricks (and the few places where you don't it's even worse with devops tools.) Any issue, any question can be answered by reading the damn shell script and you're never dependent on a cookbook/recipe/playbook/component that you got off of some github repo that you need 5% of to do X.
- CaptSpify 10y ago
  An un-researched opinion from someone who replaced chef/ansible/puppet with his own shell-script config-management system: I don't have to rewrite my shell-scripts every 6 months when a new version comes out. New updates usually only happen when security issues arise. Shell-scripts tend to be simple. There's not a lot of magic hand-holding going on, which means not a lot of complexity to break things. It keeps you from getting too abstract. Your writing pretty close and specific to what you want it to do, not "how it should be". They are typically standalone. It's really easy to have 1 script that solves one problem, and another script that solves another. You don't need a giant code-infrastructure to keep things going. I think config-mgmt tools can be extremely useful if your running a widely-ranged environment. But, you probably shouldn't be running a widely-ranged environment. If you keep things simple, and run as homogeneous as possible, you probably don't need all the added complexity.
  - CrLf 10y ago
praptak 10y ago
Pffft, shell scripts. In Lisp I can emulate shell scripts and all of the technologies mentioned in the article with three to five macros.

I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.

tormeh 10y ago

Why not use Python instead? Shellscript is so... chaotic.

chillydawg 10y ago
cos they run without needing python.
- DonHopkins 10y ago
  It's much easier to not need shell scripts, than to not need Python scripts.
DonHopkins 10y ago
I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Like the way the shell would fork off an "expr" sub-process to parse a mathematical expression to add two numbers, then write the result to a pipe via stdout, then terminate the process, clean up all its resources, and switch context back to the shell, which then read the serialized sum back in from the other end of the pipe, and went about its business, regardless of the fact that the CPU running the shell already had its own built-in "add" instruction in hardware.
- karma_vaccum123 10y ago
  > I pine for the days of yore when the Unix Philosophy was strong and pure, and every program did one thing well, and only one. Unless you are over fifty years old, you never experienced this. Rob Pike said it best: "Those days are dead and gone and the eulogy was delivered by Perl." Perl being a thing in 1995...
  - DonHopkins 10y ago
    Now "expr" has finally been rewritten as a jQuery plug-in. [1] https://github.com/baphomet-berlin/jQuery-basic-arithmetic-plugin https://github.com/baphomet-berlin/jQuery-basic-arithmetic-p...
- linkregister 10y ago
  This is the first coherent refutation of the "do one thing well" ethos I have ever read. Thanks for putting into words what I haven't been able to express myself.
tom-lord 10y ago
Shell/batch scripting can often be useful in the devops world, where you have no guarantee that any additional tools (python, ruby, perl, powershell, whatever) wil be available. Shell scripts are guaranteed to be runnable on all machines. Unfortunately the shell "language" sucks, but still...
- kbutler 10y ago
  So you're running 'sh' scripts, right? none of that new-fangled bash stuff... Oh, and be very careful of the commands your script invokes! shell scripts have no guarantee of portability (often less than Python, which has a rich standard library available on all platforms).
- CaptSpify 10y ago
  > Unfortunately the shell "language" sucks, but still... Why do you say that? genuinely curious
- Retra 10y ago
  Shell languages are great at doing interactive programming. Few non-shell languages can match the convenience, flexibility, and expressiveness in that domain. Of course, in any other domain (scripts) they are awful.
andybak 10y ago
Python + Fabric is a lovely devops/sysadmin toolbox.
- aaronbasssett 10y ago
  Still no Python 3 support though
mbrock 10y ago
How do you write "foo | bar" in Python?
- IshKebab 10y ago
  How often do you actually need to do that. 99% of `foo | bar` command could easily be `foo > a && bar < a` which is pretty trivial to do in Python.
  - mbrock 10y ago
    Well, how do you write that in Python? I'm curious because these simple things that are delightfully easy in bash often turn out to be surprisingly tedious in other languages. Of course, some things are tedious in bash too. But a basic principle of shell scripting is that you call other programs to do the stuff you don't want to do in shell.
    - IshKebab 10y ago
      Like this: http://stackoverflow.com/a/1996540 http://stackoverflow.com/a/1996540 I agree it is tedious, but to be honest, reading and writing to stdin/out isn't something that would commonly need to be done in a robust system. If the world were perfect you would use library functions. I definitely think there is scope for a language that works well as an interactive shell, and as a general purpose language. They have somewhat conflicting constraints but I'm sure we can do better than Bash. Have you seen how [ is implemented?
      - mbrock 10y ago
        No stdout or stdin for robust systems? I disagree. Yeah, a nicer shell-like language would be cool. I've been thinking about it for a while. Bash is quirky but it gets a lot of stuff right and once you understand it it can be extremely ergonomic and productive. And not depending on language run times other than shell can be really glorious in some situations, too...
  - prodigal_erik 10y ago

CrLf 10y ago

I worry when I can't tell if a comment like this is based on fact or just trying to be funny. Because I've seen my share of nasty "legacy" automation but, surprisingly, I still think a good set of well thought-out shell scripts written by someone that understands what's being automated still beat modern tools, even when the person doing the automation is the same. I don't quite know why this is, but there's something timeless about shell scripts. I've also seen shell script automation survive for a long time unattended and with zero issues. Not so with some of the modern tools that are supposed to be all unicorns and rainbows.

acveilleux 10y ago
My take is that the shell script does not have any unspoken assumption or magic that is performed by the tool. It all has to be in the script building up strictly from well-understood and long stable basic bricks (and the few places where you don't it's even worse with devops tools.) Any issue, any question can be answered by reading the damn shell script and you're never dependent on a cookbook/recipe/playbook/component that you got off of some github repo that you need 5% of to do X.
CaptSpify 10y ago
An un-researched opinion from someone who replaced chef/ansible/puppet with his own shell-script config-management system: I don't have to rewrite my shell-scripts every 6 months when a new version comes out. New updates usually only happen when security issues arise. Shell-scripts tend to be simple. There's not a lot of magic hand-holding going on, which means not a lot of complexity to break things. It keeps you from getting too abstract. Your writing pretty close and specific to what you want it to do, not "how it should be". They are typically standalone. It's really easy to have 1 script that solves one problem, and another script that solves another. You don't need a giant code-infrastructure to keep things going. I think config-mgmt tools can be extremely useful if your running a widely-ranged environment. But, you probably shouldn't be running a widely-ranged environment. If you keep things simple, and run as homogeneous as possible, you probably don't need all the added complexity.
- CrLf 10y ago

praptak 10y ago

Pffft, shell scripts. In Lisp I can emulate shell scripts and all of the technologies mentioned in the article with three to five macros.