open example.json -> foreach { -> regexp s/foo/bar/ }
open example.json | foreach { | regexp s/foo/bar/ }
You could even use both tokens in the same pipeline if you wanted: command -> command | command -> command | command
...though I'd urge against doing that - it's better to pick one token and use that throughout your pipeline.re jq: that certainly covers some use cases but it doesn't cover them all.
For example murex has a hint text - which is a line below the interactive command prompt - and it works a little like the tool tip text in GUIs. It's context sensitive and will give you hints about the command line you're typing such as
+ full path to an executable (including resolving symlinks) so you can be confident you're about to execute the program you think you are
+ it expands variables if any $VARs are used to give you a clue about how the final command line will be interpreted
+ it gives you descriptions about the application - parsed from man pages or the source code (if available)
+ it will display the code behind an alias so
The idea is to inform the user of any hidden traps behind shells that often lead to mistakes.
That's just the hint text. There's been some improvements in autocomplete suggestions that aren't available in most shells eg:
+ man page parsing,
+ suggestion descriptions,
+ the ability to use regexp to jump areas in a nested path (similar to fzf)
+ and it can also manages timeouts in dynamic suggestions better than bash.
I've tried to model the REPL environment of murex more on what tooling I'd expect from an IDE rather than what tooling I'd expect from a POSIX shell. That's not to say I've created a polished UI/UX nor that there isn't some Bash/zsh features missing from murex. There's still someway to go before murex will be out of it's beta stage. But that's the design inspiration behind the shell.