3 ms·

What task do you use with a shell that could be performed better by a different type of interactive shell? If it’s more than a few commands I’m going to be wri

What task do you use with a shell that could be performed better by a different type of interactive shell? If it’s more than a few commands I’m going to be writing a script in Perl or Python. If it’s a one off I’m going to be using basic commands like cat, sed, cut, grep, sort, jq, curl etc to investigate But what is the problem is is simple and unique enough not to write a proper utility to tackle it, but complex enough that normal bash isn’t good enough?

hnlmorg 6y ago
Not the OP but maybe I can answer this by describing the history of murex and how the shell evolved: This shell actually started out as a non-REPL tool (like grep, sort, jq, etc) for better log parsing were logs were structured data rather than flat test file. You can see some of the earlier influences with my Apache log parsers also on Github (eg https://github.com/lmorg/firesword https://github.com/lmorg/firesword). But I increasingly wanted to group, count, etc records and not just Apache logs but other structured data. I wrote a few tools that used sqlite3 but I wanted something a little more generic. So I wrote a tool that could parse structured data and supported smarter iteration syntax (`foreach` to iterate through items in an array rather than just lines in a file, `formap` to iterate through items in a hash/map). A lot of this stuff could have been written in Perl, but Perl is slow and I'd often want to parse through several million records of data. Before I knew it, I'd written enough functionality for it to be a shell in it's own right. So the next problem I thought to solve was just how crappy bash is from a UI/UX perspective. I mean I'd had ~20 years of experience using bash so I wasn't scared nor confused by it. But I wanted something that could: - parse man pages to populate auto-completions - something that was easier to template out basic completions - provided meaningful descriptions alongside the auto-completion suggestions - had meaningful context sensitive hints on every keystroke - syntax highlighting - something that could perform fzf-like searches through the completions without having to install and configure numerous additional tools - something with sane defaults Basically the convenience of an IDE in a shell. I've since added other features like: - spell checking - colourised errors (STDERR is written in red so they stand out) - events (so you can define hotkeys, trigger scripts on file system changes, etc) - plugins for smarter tmux integration. eg if I hit "F1" inside tmux the murex will open another pane to the side with the man page of the particular command or murex builtin plus a cheatsheet doc for common usages. Or if it is a function, it will print the source code of the function. So you can easily see references without leaving the interactive prompt. The reason this has expanded into a fully fledged scripting language is because naturally you'd want to write dynamic auto-completions, events, the prompt message and other dynamic components in the same language as the interactive prompt. Thus I then added features like - smarter error handling (eg `try` / `catch`) - testing framework for debugging, catching regressions, etc - namespacing so code can be written as smaller functional components without filling up the global namespace with functions that aren't intended to be called directly - modules so that I can redistribute sane defaults as a base but have an easy way to import and redistribute extended features that might be seen as bloat to other users. I'd still recommend Perl or Python for solving problems that need more powerful / flexible semantics - even if that problem is still a "write many read once" kind of problem. But this shell does bridge the gap between bash and Python while offering a convenient experience inspired by popular IDEs. It's evolved from every pet peeve I've had while working in the command line (if something bothered me then I'd write some code to fix it). So it might not be to everyone's tastes but it does solve real world problems for me as it's been my primary shell for several years now. YMMV
linkdd 6y ago
Calling other programs from any other language than Shell ones is a pain. Piping the output of one program to another without a "pipe" operator is a pain. Redirecting stdin/stdout/stderr is also a pain without ">>" or "<<" or ">&2" etc... When I need to run many commands in a pipeline, and work with their outputs, I'll use a shell script anytime. Bash is very good at it, but its syntax and simplicity can also be a pain that this project could solve.

hnlmorg 6y ago

Not the OP but maybe I can answer this by describing the history of murex and how the shell evolved: This shell actually started out as a non-REPL tool (like grep, sort, jq, etc) for better log parsing were logs were structured data rather than flat test file. You can see some of the earlier influences with my Apache log parsers also on Github (eg https://github.com/lmorg/firesword https://github.com/lmorg/firesword). But I increasingly wanted to group, count, etc records and not just Apache logs but other structured data. I wrote a few tools that used sqlite3 but I wanted something a little more generic. So I wrote a tool that could parse structured data and supported smarter iteration syntax (`foreach` to iterate through items in an array rather than just lines in a file, `formap` to iterate through items in a hash/map). A lot of this stuff could have been written in Perl, but Perl is slow and I'd often want to parse through several million records of data. Before I knew it, I'd written enough functionality for it to be a shell in it's own right. So the next problem I thought to solve was just how crappy bash is from a UI/UX perspective. I mean I'd had ~20 years of experience using bash so I wasn't scared nor confused by it. But I wanted something that could: - parse man pages to populate auto-completions - something that was easier to template out basic completions - provided meaningful descriptions alongside the auto-completion suggestions - had meaningful context sensitive hints on every keystroke - syntax highlighting - something that could perform fzf-like searches through the completions without having to install and configure numerous additional tools - something with sane defaults Basically the convenience of an IDE in a shell. I've since added other features like: - spell checking - colourised errors (STDERR is written in red so they stand out) - events (so you can define hotkeys, trigger scripts on file system changes, etc) - plugins for smarter tmux integration. eg if I hit "F1" inside tmux the murex will open another pane to the side with the man page of the particular command or murex builtin plus a cheatsheet doc for common usages. Or if it is a function, it will print the source code of the function. So you can easily see references without leaving the interactive prompt. The reason this has expanded into a fully fledged scripting language is because naturally you'd want to write dynamic auto-completions, events, the prompt message and other dynamic components in the same language as the interactive prompt. Thus I then added features like - smarter error handling (eg `try` / `catch`) - testing framework for debugging, catching regressions, etc - namespacing so code can be written as smaller functional components without filling up the global namespace with functions that aren't intended to be called directly - modules so that I can redistribute sane defaults as a base but have an easy way to import and redistribute extended features that might be seen as bloat to other users. I'd still recommend Perl or Python for solving problems that need more powerful / flexible semantics - even if that problem is still a "write many read once" kind of problem. But this shell does bridge the gap between bash and Python while offering a convenient experience inspired by popular IDEs. It's evolved from every pet peeve I've had while working in the command line (if something bothered me then I'd write some code to fix it). So it might not be to everyone's tastes but it does solve real world problems for me as it's been my primary shell for several years now. YMMV

linkdd 6y ago

Calling other programs from any other language than Shell ones is a pain. Piping the output of one program to another without a "pipe" operator is a pain. Redirecting stdin/stdout/stderr is also a pain without ">>" or "<<" or ">&2" etc... When I need to run many commands in a pipeline, and work with their outputs, I'll use a shell script anytime. Bash is very good at it, but its syntax and simplicity can also be a pain that this project could solve.