4 ms·

`->` used instead of `|`? How does that not severely destroy any kind of attempt of compatibility with bash? `-` is often used as parameter to mean "read from

`->` used instead of `|`? How does that not severely destroy any kind of attempt of compatibility with bash? `-` is often used as parameter to mean "read from stdin" or "output to stdout", and `>` is a redirection. `cat ... ¦ myprog -> log.txt` would now call myprog with no parameter and try to pipe that to a file, instead of just having myprog read from stdin and write myprog's stdout to log.txt A workflow I often use is: `aws s3 cp s3://somewhere/file.txt -` That copies a file to stdout (i.e. it displays the file content from S3). I would then routinely just "arrow up" and add a `> file.txt` to save it. Something I wonder too is why writing a new shell while most of the features could be implemented as just regular programs that you would pipe to? `file.txt -> cast csv -> [ column_name ]` Why the need to create a special syntax with [] I stead of just writing a `filter` program that reads input optionally decorated by that type information added by `cast`?

cixter 6y ago
Probably like this: myprog - > file.txt
hnlmorg 6y ago
Author here: > `->` used instead of `|`? How does that not severely destroy any kind of attempt of compatibility with bash? `|` tokens are still supported. I just prefer `->` because I think it's more readable. But that's a personal preference and those who disagree are welcome to use pipe instead. > `cat ... ¦ myprog -> log.txt` would now call myprog with no parameter and try to pipe that to a file, instead of just having myprog read from stdin and write myprog's stdout to log.txt Fair point. That issue is somewhat mitigated by the REPL automatically inserting a space at the end of commands and parameters (ie `-$SPACE>` isn't a token) but I agree there is still a risk. The shell is highly configurable (via the `config` command) and I could easily add a config option to disable `->` tokens in the parser. But I'd wager those who complain about it the most are unlikely to be individuals who would ever convert to using the shell. Which would make pandering to those complaints a fools errand. However if you are sincere about giving this a try but put off by `->` tokens then create a Github issue requesting a `config` option to disable said token I'll gladly implement it. > Something I wonder too is why writing a new shell while most of the features could be implemented as just regular programs that you would pipe to? Because I wanted to :) In fairness though, this evolved into a shell. Originally the syntax was very different and the goal was better log parsing. It was an AWK / Javascript kind of hybrid. But I'm not a massive fan of either language and a shell just organically came from the ashes of the original project. However if you wanted to make use of murex as a command rather than as a shell then you can still do the following: cat example.json | murex -c 'cast json | [ Index ]' > Why the need to create a special syntax with [] I stead of just writing a `filter` program that reads input optionally decorated by that type information added by `cast`? Because murex pipelines aren't just dumb byte streams like in Bash. They fallback to dumb byte streams when the STDIN end is a typical POSIX command, but all other times they pass type information too. This means that `[]` doesn't need casting the majority of the time. It means all the other builtin commands can natively handle JSON arrays like plain text lists. And it means you can use TOML, YAML, S-Expressions, CSV files and so on and so forth without having to learn different tooling for each nor remember to manually cast your data correctly. I've been using this as my primary shell for over 3 years and bar the odd annoyance with how I've implemented globbing, I actually find this quite intuitive vs bash (baring in mind I had ~20 years of experience with bash previously so definitely wasn't a noob). But ultimately it boils down to personal preference and thus I'd never begrudge someone preferring `|` / bash / AWK / etc over any monstrosity I might build. I just make this project public in case anyone else might like it.

cixter 6y ago

Probably like this: myprog - > file.txt

hnlmorg 6y ago

Author here: > `->` used instead of `|`? How does that not severely destroy any kind of attempt of compatibility with bash? `|` tokens are still supported. I just prefer `->` because I think it's more readable. But that's a personal preference and those who disagree are welcome to use pipe instead. > `cat ... ¦ myprog -> log.txt` would now call myprog with no parameter and try to pipe that to a file, instead of just having myprog read from stdin and write myprog's stdout to log.txt Fair point. That issue is somewhat mitigated by the REPL automatically inserting a space at the end of commands and parameters (ie `-$SPACE>` isn't a token) but I agree there is still a risk. The shell is highly configurable (via the `config` command) and I could easily add a config option to disable `->` tokens in the parser. But I'd wager those who complain about it the most are unlikely to be individuals who would ever convert to using the shell. Which would make pandering to those complaints a fools errand. However if you are sincere about giving this a try but put off by `->` tokens then create a Github issue requesting a `config` option to disable said token I'll gladly implement it. > Something I wonder too is why writing a new shell while most of the features could be implemented as just regular programs that you would pipe to? Because I wanted to :) In fairness though, this evolved into a shell. Originally the syntax was very different and the goal was better log parsing. It was an AWK / Javascript kind of hybrid. But I'm not a massive fan of either language and a shell just organically came from the ashes of the original project. However if you wanted to make use of murex as a command rather than as a shell then you can still do the following: cat example.json | murex -c 'cast json | [ Index ]' > Why the need to create a special syntax with [] I stead of just writing a `filter` program that reads input optionally decorated by that type information added by `cast`? Because murex pipelines aren't just dumb byte streams like in Bash. They fallback to dumb byte streams when the STDIN end is a typical POSIX command, but all other times they pass type information too. This means that `[]` doesn't need casting the majority of the time. It means all the other builtin commands can natively handle JSON arrays like plain text lists. And it means you can use TOML, YAML, S-Expressions, CSV files and so on and so forth without having to learn different tooling for each nor remember to manually cast your data correctly. I've been using this as my primary shell for over 3 years and bar the odd annoyance with how I've implemented globbing, I actually find this quite intuitive vs bash (baring in mind I had ~20 years of experience with bash previously so definitely wasn't a noob). But ultimately it boils down to personal preference and thus I'd never begrudge someone preferring `|` / bash / AWK / etc over any monstrosity I might build. I just make this project public in case anyone else might like it.