5 ms·

Nushell has filled this void for me. It elevates pipes by structuring them into lists or tables. It has all sorts of goodies for manipulating those data structu

by alxmng 3y ago

Nushell has filled this void for me. It elevates pipes by structuring them into lists or tables. It has all sorts of goodies for manipulating those data structures like inserting/updating rows and cells, better string interpolation, useful utility functions like case transformation, and more.

p-e-w 3y ago
Agreed. Nushell fulfills the Unix philosophy promise that the standard Unix tools have been breaking since forever. Traditional Unix commands feel like a hodgepodge of hacks by comparison, that only work together occasionally, and even then mostly by accident.
- imiric 3y ago
  The Unix philosophy doesn't dictate any specific data format to interoperate between commands, besides this being data streams, and typically text. Commands are free to interpret these streams however they want, which is why this seems like "hodgepodge", but in no way were tools breaking any sort of promise. FWIW I've been using *nix machines for decades, and very rarely have I had the need to use structured data between commands. Yes, it would make things cleaner or more robust in certain cases, but in practice there are common ways of handling this. E.g. most tools support outputting or inputting null-terminated lines.
  - regularfry 3y ago
    Null separators between fields is structured data. It might just be the simplest that can possibly work (because the null character is outside the normal data range for text, unlike the newline, which demonstrably doesn't work in that sense) but it is structure. A list structure, specifically. The world would be a much happier place if -print0 (or whatever) was universal, but no such luck.
    - imiric 3y ago
      Sure, but the reason it works with any tool is because it's generic and simple. If each tool had to implement anything more sophisticated like a JSON parser and serializer, it would be a nightmare to maintain. Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. Subtle changes in this strict contract means that pipelines will break, or just not be well supported[1]. If programs simply input and output unstructured data, it's up to the user to (de)structure this data in any way they need. The loose coupling is a feature, not a bug. [1]: You can see this in Nushell's issue tracker[2]. I'm not judging the amount of issues, as any healthy OSS project will have many issues, but some of these are critical bugs related to command handling and interop. I'm not blaming the Nushell team either, my hat's off to them, but just pointing out that the nature of the project will inevitably lead to a neverending stream of these types of issues. [2]: https://github.com/nushell/nushell/issues https://github.com/nushell/nushell/issues
      - p-e-w 3y ago
        > Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. I think you're misunderstanding how Nushell works. They don't parse outputs, or generate inputs, from/for standard Unix commands. Instead, they implement their own commands with the same names as standard commands, and generate/consume structured data by default, using the same data structures everywhere. There is only a single implementation of those data structures. That's very easy to maintain. So running `ls` from Nushell does not shell out to the `ls` program on your system, and then try to make sense of its output. It runs a Nushell-internal command that is tailored to the kind of pipelines that Nushell is built around. They already have hundreds such commands implemented and working, and that approach absolutely does scale. Whatever issues may remain, it already works much more reliably than the default Unix tools. Saying that unstructured text streams are a universal interface is like saying that atoms are a universal construction kit – it's technically correct, but pretty useless in practice.
        3y ago
  - p-e-w 3y ago
    > but in no way were tools breaking any sort of promise The Unix philosophy as usually stated includes the rule "write programs that work together". Most Unix commands don't work together in any meaningful sense. For example, `ps | kill` will not terminate all processes, as one might naively expect. I'd say this is a clear violation of both the letter and the spirit of the Unix philosophy.
    - imiric 3y ago
      I mean, neither will `ls | rm`, and a myriad of such combinations if you try them blindly, but it's unreasonable to assume that every combination of commands will work in the simplistic way you expect them to. Tools like xargs exist to fill that void, and it allows the tools themselves to work independently. Developing a set of tools from scratch that share a strict design principle is much easier than enabling an ecosystem of purpose-built tools developed over decades by external contributors to interoperate with each other. Leaving the exchange format open is a reason this still works so well today. Or would you rather use XML or whatever format was popular 40 years ago, have to adopt a new format whenever the previous one becomes outdated, and deal with compatibility hell when tools support different versions of the format?
      - mminer237 3y ago
        IMO, it's rather embarrassing how rarely they work together without a decent amount of effort. Especially in light of the fact that, e.g., `ls | rm` does work exactly as expected on Windows nowadays.
    - MisterTea 3y ago
      > For example, `ps | kill` will not terminate all processes, as one might naively expect. Who expects it to behave like that? Quite the assumption. Expecting automagic inference based on typing is building a system based on assumption. Have fun making breaking changes to a foundational component that every command will rely on. Everyone will assume you want typed data and if you don't accept/generate typed data then what? Will every shell program have to be burdened with this nonsense and require a rewrite? In the end ps does exactly what it was meant to do: print information on processes. Your assumption is missing the step where you extract the necessary information you want, e.g. the pid. That is where unix philosophy comes in. Your assumption also seems to make foot guns easier as ps|kill should not be that easy.
  - MisterTea 3y ago
    Everyone wants protobuf in their pipes.
- klysm 3y ago
  The “Unix philosophy” is whatever the writers philosophy is - it has no real meaning
shortrounddev2 3y ago
That's why I use powershell
bafe 3y ago
Isn't this what powershell tries to do,with the difference that it's structured objects being passed instead of tables?

by alxmng 3y ago

p-e-w 3y ago

Agreed. Nushell fulfills the Unix philosophy promise that the standard Unix tools have been breaking since forever. Traditional Unix commands feel like a hodgepodge of hacks by comparison, that only work together occasionally, and even then mostly by accident.

imiric 3y ago
The Unix philosophy doesn't dictate any specific data format to interoperate between commands, besides this being data streams, and typically text. Commands are free to interpret these streams however they want, which is why this seems like "hodgepodge", but in no way were tools breaking any sort of promise. FWIW I've been using *nix machines for decades, and very rarely have I had the need to use structured data between commands. Yes, it would make things cleaner or more robust in certain cases, but in practice there are common ways of handling this. E.g. most tools support outputting or inputting null-terminated lines.
- regularfry 3y ago
  Null separators between fields is structured data. It might just be the simplest that can possibly work (because the null character is outside the normal data range for text, unlike the newline, which demonstrably doesn't work in that sense) but it is structure. A list structure, specifically. The world would be a much happier place if -print0 (or whatever) was universal, but no such luck.
  - imiric 3y ago
    Sure, but the reason it works with any tool is because it's generic and simple. If each tool had to implement anything more sophisticated like a JSON parser and serializer, it would be a nightmare to maintain. Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. Subtle changes in this strict contract means that pipelines will break, or just not be well supported[1]. If programs simply input and output unstructured data, it's up to the user to (de)structure this data in any way they need. The loose coupling is a feature, not a bug. [1]: You can see this in Nushell's issue tracker[2]. I'm not judging the amount of issues, as any healthy OSS project will have many issues, but some of these are critical bugs related to command handling and interop. I'm not blaming the Nushell team either, my hat's off to them, but just pointing out that the nature of the project will inevitably lead to a neverending stream of these types of issues. [2]: https://github.com/nushell/nushell/issues https://github.com/nushell/nushell/issues
    - p-e-w 3y ago
      > Projects like Nushell essentially need to handle every type of output from any command, and every type of input to any command, which is an absurd amount of work, and just not scalable. I think you're misunderstanding how Nushell works. They don't parse outputs, or generate inputs, from/for standard Unix commands. Instead, they implement their own commands with the same names as standard commands, and generate/consume structured data by default, using the same data structures everywhere. There is only a single implementation of those data structures. That's very easy to maintain. So running `ls` from Nushell does not shell out to the `ls` program on your system, and then try to make sense of its output. It runs a Nushell-internal command that is tailored to the kind of pipelines that Nushell is built around. They already have hundreds such commands implemented and working, and that approach absolutely does scale. Whatever issues may remain, it already works much more reliably than the default Unix tools. Saying that unstructured text streams are a universal interface is like saying that atoms are a universal construction kit – it's technically correct, but pretty useless in practice.
      - 3y ago
- p-e-w 3y ago
  > but in no way were tools breaking any sort of promise The Unix philosophy as usually stated includes the rule "write programs that work together". Most Unix commands don't work together in any meaningful sense. For example, `ps | kill` will not terminate all processes, as one might naively expect. I'd say this is a clear violation of both the letter and the spirit of the Unix philosophy.
  - imiric 3y ago
    I mean, neither will `ls | rm`, and a myriad of such combinations if you try them blindly, but it's unreasonable to assume that every combination of commands will work in the simplistic way you expect them to. Tools like xargs exist to fill that void, and it allows the tools themselves to work independently. Developing a set of tools from scratch that share a strict design principle is much easier than enabling an ecosystem of purpose-built tools developed over decades by external contributors to interoperate with each other. Leaving the exchange format open is a reason this still works so well today. Or would you rather use XML or whatever format was popular 40 years ago, have to adopt a new format whenever the previous one becomes outdated, and deal with compatibility hell when tools support different versions of the format?
    - mminer237 3y ago
      IMO, it's rather embarrassing how rarely they work together without a decent amount of effort. Especially in light of the fact that, e.g., `ls | rm` does work exactly as expected on Windows nowadays.
  - MisterTea 3y ago
    > For example, `ps | kill` will not terminate all processes, as one might naively expect. Who expects it to behave like that? Quite the assumption. Expecting automagic inference based on typing is building a system based on assumption. Have fun making breaking changes to a foundational component that every command will rely on. Everyone will assume you want typed data and if you don't accept/generate typed data then what? Will every shell program have to be burdened with this nonsense and require a rewrite? In the end ps does exactly what it was meant to do: print information on processes. Your assumption is missing the step where you extract the necessary information you want, e.g. the pid. That is where unix philosophy comes in. Your assumption also seems to make foot guns easier as ps|kill should not be that easy.
- MisterTea 3y ago
  Everyone wants protobuf in their pipes.
klysm 3y ago
The “Unix philosophy” is whatever the writers philosophy is - it has no real meaning

shortrounddev2 3y ago

That's why I use powershell

bafe 3y ago

Isn't this what powershell tries to do,with the difference that it's structured objects being passed instead of tables?