4 ms·

I’d rather write bash for orchestration than nearly anything else: bash is designed to make coordinating processes easy, something very few programming language

I’d rather write bash for orchestration than nearly anything else: bash is designed to make coordinating processes easy, something very few programming languages have managed to do.

laumars 7y ago
The thing that gets me about all the new shells and shell scripting languages popping up these days is they loosely seem to fall into 2 categories: 1. more emphasis traditional programming paradigms (be it JS, LISP, Python, whatever) which leaves a platform that is arguably a better designed language but however is a poorer REPL environment for it. Bash works because it's terse and terseness is actually preferable for "write many, read once" style environments like an interactive command prompt. 2. or they spend so much effort supporting POSIX/Bash -- including their warts -- that they end up poorer scripting languages. I think what we really need isn't to rewrite all our shell scripts in Python but rather better shells. Ones which work with existing muscle memory but isn't afraid to break compatibility for the sake of eliminating a few footguns. Shells that can straddle both the aforementioned objectives without sacrificing the other. But there doesn't seem to be many people trying this (I can only think of a couple off hand).
- jhasse 7y ago
  What are your thoughts about fish?
  - fiddlerwoaroof 7y ago
    Does fish still have the issue where pipelines aren’t really concurrent?
- fiddlerwoaroof 7y ago
  If you haven’t tried scripting in zsh, I’d give it a go. zsh has a lot of safety improvements and quality of life features. https://news.ycombinator.com/item?id=22029662 https://news.ycombinator.com/item?id=22029662
  - laumars 7y ago
    It's also subject to many of the same footguns as Bash so I'd put that into the 2nd camp (re my previous post). Not that I'm taking anything away from zsh. It is a nice shell. But I think we can do even better considering how dependant we still are on shells for day to day stuff.
    - fiddlerwoaroof 7y ago
      I realize that it has similar footguns, however reading through their info pages, I was surprised by how many they just decided to fix, unless you explicitly turn on compatibility mode.
    - fiddlerwoaroof 7y ago
      > Zsh had arrays from the start, and its author opted for a saner language design at the expense of backward compatibility. In zsh (under the default expansion rules) $var does not perfom word splitting; if you want to store a list of words in a variable, you are meant to use an array; and if you really want word splitting, you can write $=var. https://unix.stackexchange.com/a/26672 https://unix.stackexchange.com/a/26672
- lukeschlather 7y ago
  I've been writing a lot of Powershell lately, and my only real gripe with it is that it seems suspiciously like not being Posix compliant in any way was a design goal. I agree with the idea of breaking backwards compatibility, but Powershell honestly has enough core design issues that it itself is starting to feel like it needs a major backwards-incompatible update.
  - leosarev 7y ago
    Major backwards-incompatible update have come recently (Powershell Core).
    - nailer 7y ago
      What did they break? Powershell core just doesn't include Win32, but that's fine, it runs on Linux and macOS and they don't need Win32. Powershell 7 has a full Win32.
      - leosarev 7y ago
        I.e. curl command now means actual curl, not Invoke-webrequest
spc476 7y ago
Here's one thing that I find difficult to remember how to do in shell: run a command, have stdout go to a file (or /dev/null or whatever), but pipe stderr to more or grep or some other program to process. I mean, I would expect the syntax to be something like: make >/dev/null 2| more but no ... it's some incomprehensible mess of redirection arcana to get that to work.
- pwg 7y ago
  The syntax for that is present in the manual: Note that the order of redirections is significant. For example, the command ls > dirlist 2>&1 directs both standard output and standard error to the file dirlist, while the command ls 2>&1 > dirlist directs only the standard output to file dirlist, because the standard error was duplicated from the standard output before the standard output was redirected to dirlist. Does it look a little arcane, yes, esp. until one memorizes it. Can it be memorized? Yes, because it is just a single 'incantation': "2>&1". Just put that redirection operator before the redirection of the standard output to the file, and the result is stdout goes to the file, stderr goes to the pipe.
  - dllthomas 7y ago
    It's actually a pretty simple model. Every process has an array of open file objects. File descriptors are indexes into that array. "Redirection" copies the underlying entries, and are processed left-to-right. "Redirecting streams" winds up being confusing - it's all just `dup2`.
  - Legogris 7y ago
    Just in case someone's confused by this, it becomes clear if you know how pipes work. `2>&1` means "redirect stderr to whatever stdout is currently pointed to" (redirection by copy, not by reference). More recent version of bash manual[0] has a less confusing wording in the same paragraph IMO: Note that the order of redirections is significant. For example, the command ls > dirlist 2>&1 directs both standard output (file descriptor 1) and standard error (file descriptor 2) to the file dirlist, while the command ls 2>&1 > dirlist directs only the standard output to file dirlist, because the standard error was made a copy of the standard output before the standard output was redirected to dirlist. [0]: https://www.gnu.org/software/bash/manual/html_node/Redirections.html https://www.gnu.org/software/bash/manual/html_node/Redirecti...
XorNot 7y ago
Go is actually superb at this IMO. Channels and goroutines provide the actual primitives you need to handle streaming data, and the integration of the context library makes starting up and shutting down everything a breeze. Best of all though, it's absolutely compatible wherever you need to run it.
- fiddlerwoaroof 7y ago
  The issue with I’ve had with go is that it’s batch compiled: I can repl something together in an interactive shell and then generalize it, which is my preferred workflow

I’d rather write bash for orchestration than nearly anything else: bash is designed to make coordinating processes easy, something very few programming languages have managed to do.

laumars 7y ago

The thing that gets me about all the new shells and shell scripting languages popping up these days is they loosely seem to fall into 2 categories: 1. more emphasis traditional programming paradigms (be it JS, LISP, Python, whatever) which leaves a platform that is arguably a better designed language but however is a poorer REPL environment for it. Bash works because it's terse and terseness is actually preferable for "write many, read once" style environments like an interactive command prompt. 2. or they spend so much effort supporting POSIX/Bash -- including their warts -- that they end up poorer scripting languages. I think what we really need isn't to rewrite all our shell scripts in Python but rather better shells. Ones which work with existing muscle memory but isn't afraid to break compatibility for the sake of eliminating a few footguns. Shells that can straddle both the aforementioned objectives without sacrificing the other. But there doesn't seem to be many people trying this (I can only think of a couple off hand).

jhasse 7y ago
What are your thoughts about fish?
- fiddlerwoaroof 7y ago
  Does fish still have the issue where pipelines aren’t really concurrent?
fiddlerwoaroof 7y ago
If you haven’t tried scripting in zsh, I’d give it a go. zsh has a lot of safety improvements and quality of life features. https://news.ycombinator.com/item?id=22029662 https://news.ycombinator.com/item?id=22029662
- laumars 7y ago
  It's also subject to many of the same footguns as Bash so I'd put that into the 2nd camp (re my previous post). Not that I'm taking anything away from zsh. It is a nice shell. But I think we can do even better considering how dependant we still are on shells for day to day stuff.
  - fiddlerwoaroof 7y ago
    I realize that it has similar footguns, however reading through their info pages, I was surprised by how many they just decided to fix, unless you explicitly turn on compatibility mode.
  - fiddlerwoaroof 7y ago
    > Zsh had arrays from the start, and its author opted for a saner language design at the expense of backward compatibility. In zsh (under the default expansion rules) $var does not perfom word splitting; if you want to store a list of words in a variable, you are meant to use an array; and if you really want word splitting, you can write $=var. https://unix.stackexchange.com/a/26672 https://unix.stackexchange.com/a/26672
lukeschlather 7y ago
I've been writing a lot of Powershell lately, and my only real gripe with it is that it seems suspiciously like not being Posix compliant in any way was a design goal. I agree with the idea of breaking backwards compatibility, but Powershell honestly has enough core design issues that it itself is starting to feel like it needs a major backwards-incompatible update.
- leosarev 7y ago
  Major backwards-incompatible update have come recently (Powershell Core).
  - nailer 7y ago
    What did they break? Powershell core just doesn't include Win32, but that's fine, it runs on Linux and macOS and they don't need Win32. Powershell 7 has a full Win32.
    - leosarev 7y ago
      I.e. curl command now means actual curl, not Invoke-webrequest

spc476 7y ago

Here's one thing that I find difficult to remember how to do in shell: run a command, have stdout go to a file (or /dev/null or whatever), but pipe stderr to more or grep or some other program to process. I mean, I would expect the syntax to be something like: make >/dev/null 2| more but no ... it's some incomprehensible mess of redirection arcana to get that to work.

pwg 7y ago
The syntax for that is present in the manual: Note that the order of redirections is significant. For example, the command ls > dirlist 2>&1 directs both standard output and standard error to the file dirlist, while the command ls 2>&1 > dirlist directs only the standard output to file dirlist, because the standard error was duplicated from the standard output before the standard output was redirected to dirlist. Does it look a little arcane, yes, esp. until one memorizes it. Can it be memorized? Yes, because it is just a single 'incantation': "2>&1". Just put that redirection operator before the redirection of the standard output to the file, and the result is stdout goes to the file, stderr goes to the pipe.
- dllthomas 7y ago
  It's actually a pretty simple model. Every process has an array of open file objects. File descriptors are indexes into that array. "Redirection" copies the underlying entries, and are processed left-to-right. "Redirecting streams" winds up being confusing - it's all just `dup2`.
- Legogris 7y ago
  Just in case someone's confused by this, it becomes clear if you know how pipes work. `2>&1` means "redirect stderr to whatever stdout is currently pointed to" (redirection by copy, not by reference). More recent version of bash manual[0] has a less confusing wording in the same paragraph IMO: Note that the order of redirections is significant. For example, the command ls > dirlist 2>&1 directs both standard output (file descriptor 1) and standard error (file descriptor 2) to the file dirlist, while the command ls 2>&1 > dirlist directs only the standard output to file dirlist, because the standard error was made a copy of the standard output before the standard output was redirected to dirlist. [0]: https://www.gnu.org/software/bash/manual/html_node/Redirections.html https://www.gnu.org/software/bash/manual/html_node/Redirecti...

XorNot 7y ago

Go is actually superb at this IMO. Channels and goroutines provide the actual primitives you need to handle streaming data, and the integration of the context library makes starting up and shutting down everything a breeze. Best of all though, it's absolutely compatible wherever you need to run it.

fiddlerwoaroof 7y ago
The issue with I’ve had with go is that it’s batch compiled: I can repl something together in an interactive shell and then generalize it, which is my preferred workflow