4 ms·

The problem with this project is that somebody might use it. I argue that if you need to do something in bash that involves more than a sequence of commands, in

The problem with this project is that somebody might use it. I argue that if you need to do something in bash that involves more than a sequence of commands, including a simple if statement, then you should switch from bash to a proper scripting language (python, perl, ruby, nodejs, take your pick.)

adrusi 11y ago
I disagree. Shell scripts are great for automating system tasks — for sysadminy type stuff, including tasks with high complexity with nested loops and conditionals. A scripting language like those you mentioned is great for if you need to run your script on systems you don't control, or you need it to be cross platform, or you'd describe what you're doing as creating software rather than automating tasks. No scripting language can ever integrate with the host system quite as well as shell scripts can. Sure, shell scripts make it easy to shoot yourself in the foot, but then can't you say the same of at least perl and ruby? I don't really see many good use cases for this library though. By the time you'd use it you should probably move on to something else.
- dragonwriter 11y ago
  > No scripting language can ever integrate with the host system quite as well as shell scripts can. What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. There's no real reason why other scripting languages can't integrate with the system as well as shell languages.
  - AnimalMuppet 11y ago
    >> No scripting language can ever integrate with the host system quite as well as shell scripts can. > What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. Disagree. The defining characteristic of shell scripting languages is that they are a shell that can be scripted. What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. So the only way a non-shell scripting language can become that powerful is to become a shell scripting language.
    - brazzledazzle 11y ago
      >What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. I think that's what they were getting at when they said: >optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL The only real difference is optimization for the REPL. Many of the things you might consider part of the experience aren't even shell built-ins, they're utilities maintained separately from your shell. Powershell is a good example of a shell scripting language that has a lot more going on than your traditional shell. Native object pipelines, .net libraries, etc. but the most important thing about it is that it's optimized for the REPL.
  - adrusi 11y ago
    In addition to AnimalMuppet's point, shell scripts make no attempt to be cross platform, so you don't get any awkward leaky abstractions when trying to interact with low-level system facilities. The primitives in shell scripts are the primitives of the operating system. The fundamental building blocks of your language are strings and files and processes, which makes it really convenient to work with strings and files and processes, AKA the operating system.
    - AndyKelley 11y ago
      You can easily invoke platform-specific binaries from within a scripting language. You can even invoke them in a shell if you want. Check out this API: https://docs.python.org/3/library/subprocess.html#subprocess.check_call https://docs.python.org/3/library/subprocess.html#subprocess...
      - adrusi 11y ago
        Well of course you can. Scripting languages aren't useless stunted toys. The point is that if that's what most of your program is doing, you'll have a lot more success using a language where that functionality is first class.
      - yarrel 11y ago
        If most of your scripting language code is calls to other programs and to the shell, there's a simpler way...
- AndyKelley 11y ago
  Can you give a shell script example of something that perl/python/ruby/nodejs can't do?
  - e12e 11y ago
    > Can you give a shell script example of something that perl/python/ruby/nodejs can't do? Install perl/python/ruby and nodejs -- requiring just the shell to be installed? Snark aside (it's not only snark - pretty much every system will have something like a posix shell), proper posix portable shell is hard - it's an old gnarly language -- but it's what we've got. And with a bit of discipline and good practices -- it doesn't have to be bad. That said, a lot of real-world shell scripts are bad. I tend to agree with the overall sentiment; shell isn't a great language. As soon as you start to mix awk (which awk is that, do you need GNU awk?), sed and perhaps a bit of egrep (or grep -E -- are both available? Does it accept only BSD-style parameters?) -- one should consider moving "up". And for eg: setting up a python package/program -- I'd generally prefer a python script -- hopefully one that handles different file-paths (eg: / vs \ ) and other cross-platform stuff. If you already depend on python, why add dependency on shell?
    - AndyKelley 11y ago
      > Install perl/python/ruby and nodejs -- requiring just the shell to be installed? I just meant using any one of them, not all of them. And you can pretty much always rely on python and perl being installed. But my point is that if you're doing something other than a one-off thing, then it belongs to some project and you're probably going to commit that script to that project's codebase. That means it has to be maintained. Do future you and whoever else has to maintain the project a favor and use one of the popular scripting languages that has reasonable syntax and semantics.
      - e12e 11y ago
        Many minimal distributions have only the shell installed - which make it (still) relevant for provisioning/bootstrap etc. Personally I'd much rather maintain a shell script than a perl script - but that's just because I know shell better. Maybe shell is the first language people would program without learning it (js being the second)?

adrusi 11y ago

I disagree. Shell scripts are great for automating system tasks — for sysadminy type stuff, including tasks with high complexity with nested loops and conditionals. A scripting language like those you mentioned is great for if you need to run your script on systems you don't control, or you need it to be cross platform, or you'd describe what you're doing as creating software rather than automating tasks. No scripting language can ever integrate with the host system quite as well as shell scripts can. Sure, shell scripts make it easy to shoot yourself in the foot, but then can't you say the same of at least perl and ruby? I don't really see many good use cases for this library though. By the time you'd use it you should probably move on to something else.

dragonwriter 11y ago
> No scripting language can ever integrate with the host system quite as well as shell scripts can. What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. There's no real reason why other scripting languages can't integrate with the system as well as shell languages.
- AnimalMuppet 11y ago
  >> No scripting language can ever integrate with the host system quite as well as shell scripts can. > What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. Disagree. The defining characteristic of shell scripting languages is that they are a shell that can be scripted. What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. So the only way a non-shell scripting language can become that powerful is to become a shell scripting language.
  - brazzledazzle 11y ago
    >What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. I think that's what they were getting at when they said: >optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL The only real difference is optimization for the REPL. Many of the things you might consider part of the experience aren't even shell built-ins, they're utilities maintained separately from your shell. Powershell is a good example of a shell scripting language that has a lot more going on than your traditional shell. Native object pipelines, .net libraries, etc. but the most important thing about it is that it's optimized for the REPL.
- adrusi 11y ago
  In addition to AnimalMuppet's point, shell scripts make no attempt to be cross platform, so you don't get any awkward leaky abstractions when trying to interact with low-level system facilities. The primitives in shell scripts are the primitives of the operating system. The fundamental building blocks of your language are strings and files and processes, which makes it really convenient to work with strings and files and processes, AKA the operating system.
  - AndyKelley 11y ago
    You can easily invoke platform-specific binaries from within a scripting language. You can even invoke them in a shell if you want. Check out this API: https://docs.python.org/3/library/subprocess.html#subprocess.check_call https://docs.python.org/3/library/subprocess.html#subprocess...
    - adrusi 11y ago
      Well of course you can. Scripting languages aren't useless stunted toys. The point is that if that's what most of your program is doing, you'll have a lot more success using a language where that functionality is first class.
    - yarrel 11y ago
      If most of your scripting language code is calls to other programs and to the shell, there's a simpler way...
AndyKelley 11y ago
Can you give a shell script example of something that perl/python/ruby/nodejs can't do?
- e12e 11y ago
  > Can you give a shell script example of something that perl/python/ruby/nodejs can't do? Install perl/python/ruby and nodejs -- requiring just the shell to be installed? Snark aside (it's not only snark - pretty much every system will have something like a posix shell), proper posix portable shell is hard - it's an old gnarly language -- but it's what we've got. And with a bit of discipline and good practices -- it doesn't have to be bad. That said, a lot of real-world shell scripts are bad. I tend to agree with the overall sentiment; shell isn't a great language. As soon as you start to mix awk (which awk is that, do you need GNU awk?), sed and perhaps a bit of egrep (or grep -E -- are both available? Does it accept only BSD-style parameters?) -- one should consider moving "up". And for eg: setting up a python package/program -- I'd generally prefer a python script -- hopefully one that handles different file-paths (eg: / vs \ ) and other cross-platform stuff. If you already depend on python, why add dependency on shell?
  - AndyKelley 11y ago
    > Install perl/python/ruby and nodejs -- requiring just the shell to be installed? I just meant using any one of them, not all of them. And you can pretty much always rely on python and perl being installed. But my point is that if you're doing something other than a one-off thing, then it belongs to some project and you're probably going to commit that script to that project's codebase. That means it has to be maintained. Do future you and whoever else has to maintain the project a favor and use one of the popular scripting languages that has reasonable syntax and semantics.
    - e12e 11y ago
      Many minimal distributions have only the shell installed - which make it (still) relevant for provisioning/bootstrap etc. Personally I'd much rather maintain a shell script than a perl script - but that's just because I know shell better. Maybe shell is the first language people would program without learning it (js being the second)?