6 ms·

> Recently, I had a chat with some of my friends about Nushell and why they stuck with traditional shells like bash/zsh or the "new" hotness like fish rather th

by p-e-w 3y ago

> Recently, I had a chat with some of my friends about Nushell and why they stuck with traditional shells like bash/zsh or the "new" hotness like fish rather than using Nushell. Umm... because Nushell is pre-1.0, with major language changes every few weeks? Living on the bleeding edge isn't everyone's cup of tea, and certainly not with something as fundamental to the system as a shell. Rest assured I will switch the moment 1.0 is released and a stability promise is published. That being said, yeah – Nushell is the real deal. It's the Unix philosophy, except this time it actually works.

imiric 3y ago
> It's the Unix philosophy, except this time it actually works. How is Nushell compatible with the Unix philosophy? The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. Nushell implements a monolithic ecosystem with commands that support its fancy features, but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. This goes against the open philosophy of Unix, which is partly what has allowed it to grow and succeed.
- ChrisSD 3y ago
  So long as a tool can output a machine readable format, it can be consumed by nushell. If it can't then... that's actually a big problem when composing tools in bash too. Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. As well as each and every argument for each and every tool for those arguments that happen to change the output in different ways.
  - imiric 3y ago
    > Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. Right, but therein lies the flexibility of using unstructured text as the exchange format. Each tool doesn't need to be aware of the format it needs to consume or output; it just cares about what makes sense for itself and the user. It's up to the user to determine the best way of composing each tool within a specific pipeline. This might seem cumbersome, but there are a limited set of ways tools can be composed, and generic helper tools exist for a variety of use cases (xargs, sed, awk, grep, cut, paste, etc.). If one tool breaks, then it's easy to either replace it, or fix the pipeline to support that specific tool. In contrast, by making a strict contract of the exchange format, each tool needs to support a specific contract, and any deviation or update of it means that all tools need to be updated as well, while also maintaining backwards compatibility. This might be fine for a monolithic environment where a single project maintains all tools, but it's unsustainable if one wants to build an open ecosystem of tools that work independently, but can still be composed in any pipeline.
    - ChrisSD 3y ago
      Except that means tools aren't doing "one thing" as in the Unix philosophy. Or least I know of very few unix tools that actually do that. At a minimum they need to bundle an argument parser (or more often reinvent their own). They also need to do the same for generating output, often in multiple different display formats depending on the precise flags used. And I think your overstating the contract argument. If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. With a well structured output format it's better able to maintain backwards compatibility while adding new features.
      - follower 3y ago
        > If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. The `jc` ("CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON") documentation[1] & parser[2] for `ls` also demonstrate that reliable & cross-platform parsing of even the current output can be non-trivial based on filenames encountered, flags used & host platform--which means there's probably a non-zero number of bash scripts that are already broken but they don't know it. [1] https://kellyjonbrazil.github.io/jc/docs/parsers/ls https://kellyjonbrazil.github.io/jc/docs/parsers/ls [2] https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b620cc26cd455d95bf56b85b/jc/parsers/ls.py#L187 https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b6...
- p-e-w 3y ago
  > The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. You mean like ls | rm deletes the files in a directory? Uh wait, that doesn't actually work. Because the Unix tools actually don't implement the Unix philosophy at all. Because as it turns out, text streams are not a universal interface after all. Nushell succeeds where the coreutils have failed for decades precisely because its commands are designed to work together. They pass structured data around, which means that pipelines can actually work without requiring weird hacks to make one underspecified text format conform to the other. That is the Unix philosophy: Tools that work together. But don't worry, the old Unix tools can be used from Nushell – and they work together just as poorly in Nushell as in every other shell, not one bit worse.
  - ball_of_lint 3y ago
    This is a strawman. It's trivially easy to do what you're describing. ls | xargs rm And in fact, a better implementation is rm * The Unix philosophy doesn't say "Every program interfaces intuitively and correctly with every other program". It says that programs should be able to work together. There are arguments that coreutils such as ls aren't following the Unix philosophy, but they lie much more in that ls has dozens of arguments than they do in your contrived example not working.
    - zucker42 3y ago
      The fact that the first example has a bug (it doesn't handle file names with spaces correctly) sort of proves the point of the commenter you responded to. I personally don't use nushell (or another alternative, oil) because bash for scripting and zsh for interactive shell is good enough for me, and compatibility with other people is valuable. However, whenever you start to write slightly complex scripts in bash, you have to think carefully about spaces in file names and other similar problems. Of course, you can argue you should just write those scripts in Python, but shell is a lot quicker to write and would be more elegant if it had fewer footguns and less esoteric syntax.
    - IshKebab 3y ago
      `ls | xargs rm` is still wrong. Maybe you can accept the point...
- steveklabnik 3y ago
  > but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. As someone who uses nu as his main shell for the past few years, this is not my experience. Nu has great tools for adapting programs not written for it. And if your tool already produces a standard format as output, like json or toml, you don’t even need those things.
  - fuzztester 3y ago
    >And if your tool already produces a standard format as output, like json or toml, you don’t even need those things. json or toml So already we have two (not one) formats that nushell presumably has to support? Or am I not getting something?
    - steveklabnik 3y ago
      "like" is doing some work here. nushell supports: * 16 formats to convert from https://www.nushell.sh/commands/docs/from.html#subcommands https://www.nushell.sh/commands/docs/from.html#subcommands * 10 formats to convert to https://www.nushell.sh/commands/docs/to.html#subcommands https://www.nushell.sh/commands/docs/to.html#subcommands by default. I believe that via its plugin system, anyone can write a plugin to support whatever additional formats they want, but I haven't needed to investigate that deeply. And that's if you want to support a format specifically. You can do something similar to like, how you'd manipulate plaintext output on UNIX with other commands. For example, see this example for parsing the output of git log: https://www.nushell.sh/cookbook/parsing_git_log.html https://www.nushell.sh/cookbook/parsing_git_log.html the 'lines' command will take any text and produce a nu table, where each row is a line. At that point the data has been converted, no specific "git log" format needed.
      - fuzztester 3y ago
        Okay. Sounds interesting, should check it out.

by p-e-w 3y ago

imiric 3y ago

> It's the Unix philosophy, except this time it actually works. How is Nushell compatible with the Unix philosophy? The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. Nushell implements a monolithic ecosystem with commands that support its fancy features, but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. This goes against the open philosophy of Unix, which is partly what has allowed it to grow and succeed.

ChrisSD 3y ago
So long as a tool can output a machine readable format, it can be consumed by nushell. If it can't then... that's actually a big problem when composing tools in bash too. Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. As well as each and every argument for each and every tool for those arguments that happen to change the output in different ways.
- imiric 3y ago
  > Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. Right, but therein lies the flexibility of using unstructured text as the exchange format. Each tool doesn't need to be aware of the format it needs to consume or output; it just cares about what makes sense for itself and the user. It's up to the user to determine the best way of composing each tool within a specific pipeline. This might seem cumbersome, but there are a limited set of ways tools can be composed, and generic helper tools exist for a variety of use cases (xargs, sed, awk, grep, cut, paste, etc.). If one tool breaks, then it's easy to either replace it, or fix the pipeline to support that specific tool. In contrast, by making a strict contract of the exchange format, each tool needs to support a specific contract, and any deviation or update of it means that all tools need to be updated as well, while also maintaining backwards compatibility. This might be fine for a monolithic environment where a single project maintains all tools, but it's unsustainable if one wants to build an open ecosystem of tools that work independently, but can still be composed in any pipeline.
  - ChrisSD 3y ago
    Except that means tools aren't doing "one thing" as in the Unix philosophy. Or least I know of very few unix tools that actually do that. At a minimum they need to bundle an argument parser (or more often reinvent their own). They also need to do the same for generating output, often in multiple different display formats depending on the precise flags used. And I think your overstating the contract argument. If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. With a well structured output format it's better able to maintain backwards compatibility while adding new features.
    - follower 3y ago
      > If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. The `jc` ("CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON") documentation[1] & parser[2] for `ls` also demonstrate that reliable & cross-platform parsing of even the current output can be non-trivial based on filenames encountered, flags used & host platform--which means there's probably a non-zero number of bash scripts that are already broken but they don't know it. [1] https://kellyjonbrazil.github.io/jc/docs/parsers/ls https://kellyjonbrazil.github.io/jc/docs/parsers/ls [2] https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b620cc26cd455d95bf56b85b/jc/parsers/ls.py#L187 https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b6...
p-e-w 3y ago
> The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. You mean like ls | rm deletes the files in a directory? Uh wait, that doesn't actually work. Because the Unix tools actually don't implement the Unix philosophy at all. Because as it turns out, text streams are not a universal interface after all. Nushell succeeds where the coreutils have failed for decades precisely because its commands are designed to work together. They pass structured data around, which means that pipelines can actually work without requiring weird hacks to make one underspecified text format conform to the other. That is the Unix philosophy: Tools that work together. But don't worry, the old Unix tools can be used from Nushell – and they work together just as poorly in Nushell as in every other shell, not one bit worse.
- ball_of_lint 3y ago
  This is a strawman. It's trivially easy to do what you're describing. ls | xargs rm And in fact, a better implementation is rm * The Unix philosophy doesn't say "Every program interfaces intuitively and correctly with every other program". It says that programs should be able to work together. There are arguments that coreutils such as ls aren't following the Unix philosophy, but they lie much more in that ls has dozens of arguments than they do in your contrived example not working.
  - zucker42 3y ago
    The fact that the first example has a bug (it doesn't handle file names with spaces correctly) sort of proves the point of the commenter you responded to. I personally don't use nushell (or another alternative, oil) because bash for scripting and zsh for interactive shell is good enough for me, and compatibility with other people is valuable. However, whenever you start to write slightly complex scripts in bash, you have to think carefully about spaces in file names and other similar problems. Of course, you can argue you should just write those scripts in Python, but shell is a lot quicker to write and would be more elegant if it had fewer footguns and less esoteric syntax.
  - IshKebab 3y ago
    `ls | xargs rm` is still wrong. Maybe you can accept the point...
steveklabnik 3y ago
> but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. As someone who uses nu as his main shell for the past few years, this is not my experience. Nu has great tools for adapting programs not written for it. And if your tool already produces a standard format as output, like json or toml, you don’t even need those things.
- fuzztester 3y ago
  >And if your tool already produces a standard format as output, like json or toml, you don’t even need those things. json or toml So already we have two (not one) formats that nushell presumably has to support? Or am I not getting something?
  - steveklabnik 3y ago
    "like" is doing some work here. nushell supports: * 16 formats to convert from https://www.nushell.sh/commands/docs/from.html#subcommands https://www.nushell.sh/commands/docs/from.html#subcommands * 10 formats to convert to https://www.nushell.sh/commands/docs/to.html#subcommands https://www.nushell.sh/commands/docs/to.html#subcommands by default. I believe that via its plugin system, anyone can write a plugin to support whatever additional formats they want, but I haven't needed to investigate that deeply. And that's if you want to support a format specifically. You can do something similar to like, how you'd manipulate plaintext output on UNIX with other commands. For example, see this example for parsing the output of git log: https://www.nushell.sh/cookbook/parsing_git_log.html https://www.nushell.sh/cookbook/parsing_git_log.html the 'lines' command will take any text and produce a nu table, where each row is a line. At that point the data has been converted, no specific "git log" format needed.
    - fuzztester 3y ago
      Okay. Sounds interesting, should check it out.