3 ms·

I'd actually like the ability to do either raw bytes (traditional) or structured bytes (the NuShell/PowerShell idea) in an "opt-in" scenario. This would also al

I'd actually like the ability to do either raw bytes (traditional) or structured bytes (the NuShell/PowerShell idea) in an "opt-in" scenario. This would also allow a smoother transition/lack of needing to fully commit right off the bat. I've considered writing wrappers for standard utilities in Bash/Zsh that accept and output structured data in JSON (or maybe a denser serialization format that can easily convert to JSON?) instead of a raw byte stream that you could then just use regular old pipes with (a lot of `jq` would likely get called in between...) The "structured" versions of the utilities would have some namespacing convention such as a "struct_" prefix (or perhaps optionally, or aliased, for brevity, "s_") or (another naming idea I just had... oooh, I like this one) they would be boxed in brackets, so "[ls]" or "]ls[" would call "structured ls" (note that brackets without spaces around them are valid name characters) To handle the transition to/from structured data, an idea I had was to omit one of the brackets in these names, so for example "ls[" would emit structured data but accept (well, assuming "ls" was a command that took stdin) an unstructured bytestream, and something like "]cat" would take in structured data on stdin but emit raw data... "cat[" would take raw data and... interpret it as JSON? or something? and output that as structured data? I don't know, it has to be fleshed out, but this could work maybe! To get the JSON data back to a visual format like a table, we'd probably have to explicitly do what NuShell implicitly calls when you don't provide it (I forgot the name of it). anyway, I haven't even begun a POC of this idea, but it was one I had. Anyone else like this idea?

hnlmorg 4y ago
This is similar to how my shell works. It still just passes bytes around but additionally passes information about how those bytes could be interpreted. A schema if you will. So it works as cleanly with POSIX / GNU / et al tools as it does with fancy JSON, YAML, CSV and other document formats. It basically sits somewhere between Powershell and Bash: typed pipelines like Powershell but without sacrificing familiarity with all the CLI commands you already use day in and day out. https://github.com/lmorg/murex https://github.com/lmorg/murex As an aside, I’m about to drop a massive update in the next few days that will make the shell even more intuitive to use.
- pmarreck 4y ago
  Very interesting! Do you transmit this metadata on a different fd, like 3? (reading more) Super cool. Since it's Go, does that mean runtime errors will silently fail and keep chugging along? /dig ;) Can you customize the PS1?
  - hnlmorg 4y ago
    > Very interesting! Do you transmit this metadata on a different fd, like 3? At the moment there is POC code to transmit over fd 3 but I’m looking into using UNIX sockets instead. > Super cool. Since it's Go, does that mean runtime errors will silently fail and keep chugging along? /dig ;) This project predates Rust 1.0 so it was a no brainier at the time to use Go. But actually I do think Go is well suited for this type of problem because much as some complain about errors being regular types, the way Go encourages granular handling of errors rather than larger try / catch blocks or exceptions does lead to more tailored error messages. Which ultimately helps explain the problem better for the end user. Not taking anything away from Rust or any other language. Nor am I saying Go’s error handling doesn’t have its problems. Just that I’d probably choose Go again if I were to start this project tomorrow. > Can you customize the PS1? Every part of the shell is customisable. However rather than having hard to discover environmental variables that can alter the shells behaviour, instead there is a command called config that allows you to inspect every option. https://murex.rocks/docs/commands/config.html https://murex.rocks/docs/commands/config.html

hnlmorg 4y ago

This is similar to how my shell works. It still just passes bytes around but additionally passes information about how those bytes could be interpreted. A schema if you will. So it works as cleanly with POSIX / GNU / et al tools as it does with fancy JSON, YAML, CSV and other document formats. It basically sits somewhere between Powershell and Bash: typed pipelines like Powershell but without sacrificing familiarity with all the CLI commands you already use day in and day out. https://github.com/lmorg/murex https://github.com/lmorg/murex As an aside, I’m about to drop a massive update in the next few days that will make the shell even more intuitive to use.

pmarreck 4y ago
Very interesting! Do you transmit this metadata on a different fd, like 3? (reading more) Super cool. Since it's Go, does that mean runtime errors will silently fail and keep chugging along? /dig ;) Can you customize the PS1?
- hnlmorg 4y ago
  > Very interesting! Do you transmit this metadata on a different fd, like 3? At the moment there is POC code to transmit over fd 3 but I’m looking into using UNIX sockets instead. > Super cool. Since it's Go, does that mean runtime errors will silently fail and keep chugging along? /dig ;) This project predates Rust 1.0 so it was a no brainier at the time to use Go. But actually I do think Go is well suited for this type of problem because much as some complain about errors being regular types, the way Go encourages granular handling of errors rather than larger try / catch blocks or exceptions does lead to more tailored error messages. Which ultimately helps explain the problem better for the end user. Not taking anything away from Rust or any other language. Nor am I saying Go’s error handling doesn’t have its problems. Just that I’d probably choose Go again if I were to start this project tomorrow. > Can you customize the PS1? Every part of the shell is customisable. However rather than having hard to discover environmental variables that can alter the shells behaviour, instead there is a command called config that allows you to inspect every option. https://murex.rocks/docs/commands/config.html https://murex.rocks/docs/commands/config.html