8 ms·

The split personalities of shell usage

54 points by hnlmorg 5y ago

satyanash 5y ago
from TFA: > Perhaps the only language I've used which translates well both for terse REPLs and lengthier scripts is LISP. Why not just use a lisp then?
- adrian_b 5y ago
  Actually there exists a shell, "scsh", which uses the Scheme language, i.e. a LISP variant. "scsh" is less convenient for interactive use than bash or zsh, because it is more verbose, but it was quite good for scripts, certainly more convenient as a replacement for shell scripts than Python or the like (because it had a better syntax for the equivalent of a POSIX command list, with pipes, and/or lists, redirections and parameter expansions). Many years ago, I have written and used with good results a lot of "scsh" scripts, for things deemed to be too complex for POSIX shell scripts. However, AFAIK, "scsh" has not been updated in recent years, so I do not know how good it would still be today.
- isr 5y ago
  Gauche scheme is a very "scripting-focussed" implementation, with some niceties inspired from scsh. I've used it's repl as a shell of sorts for a short while, just to see if I could. Janet is a new lisp (heavily inspired by Lua, not surprising given its author had previously started fennel, a lisp which compiles to Lua) which fits a smiliar "scripting" niche. An extension has been made for it (janetsh) to make it suitable as a shell replacement. In a similar vein, racket has rash. And if you consider tcl as a "lisp for strings", then it's almost a shell right out of the box. I've used jimtcl (again, like gauche, with a heavily customised shell-focussed lib of my own) as an interactive shell. Lot's of choices out there, if one is willing to roll one's sleeves up ;-)
- LanternLight83 5y ago
  Murex comes across kinda lisp-y with the keyword-less, prefix-notation #'if statement. Emacs also offers a unique (and very lisp-y) shell syntax within #'eshell.
1vuio0pswjnm7 5y ago
Downloaded murex to try it out. It was really janky, unusually so, with red colored text that is difficult to see on a black console. Requires libpthreads. Interesting first impressions. I will be dead before anything like this ever replaces the Bourne shell. There is little incentive to switch and lots of incentive to continue toward mastery of the ubiquitous shell, the one I have to use on POSIX-like OS, on computers of all sizes, like it or not.
- hnlmorg 5y ago
  > with red colored text that is difficult to see on a black console. Thanks for your honest feedback. It's only errors that appear in red and you can disable that feature if you want[1]. However it's pretty standard these days for DevOps tools to output errors in red but I appreciate that is still not to everyone's tastes. [1] https://murex.rocks/docs/user-guide/interactive-shell.html https://murex.rocks/docs/user-guide/interactive-shell.html It should also be noted that I'm honouring the terminal emulators colour palette. So if a colour isn't readable then it's the terminal emulator you're running that has caused that issue. Personally I recommend the Solarized colour themes because all 16 colours are equally readable but your preferences might differ. > There is little incentive to switch and lots of incentive to continue toward mastery of the ubiquitous shell, the one I have to use on POSIX-like OS, on computer of all sizes, like it or not. I do get that sentiment but more and more these days most of the console work is done on your local machine and you rarely SSH onto remote hosts (some orgs even go as far as to disable SSH access entirely since everything should be managed via Ansible/Puppet/Chef/SSM/etc). The problem murex attempts to solve is to be a better shell for local development / DevOps tooling. There's no point trying to get murex pushed as a default shell on servers because no security team would authorise it. But for local tooling there are still a lot of gains to be made. This is why you'll see features like errors highlighted in red and spelling errors underlined. murex takes as many cues from IDEs (local development) as it does from POSIX-shells.
  - 1vuio0pswjnm7 5y ago
    It's cool project it's just not for me. I am too comfortable with a basic Bourne shell, VGA textmode, no UTF-8, TERM=vt100. If it were possible to "improve" on this basic environment, I would want the new shell to be something less, not more; simpler, not more complex. Anyway, ignore the negative feedback. I am not the target audience for murex.
deleted 5y ago
[deleted]
gbrown 5y ago
Interesting article, though for me an acceptable middle ground is to just use bash and friends as an interface, as described, and to write any larger and more complicated scripts in Python with argparse (or similar). I don’t see why the shell must be both nice to program in and a concise textual interface.
- Steltek 5y ago
  Shell scripts are the automation and extension of repetitive, tedious manual tasks. Why wouldn't you want to take your shell history and wrap it in some getopt-ish stuff? Or to put it another way, why would you wish to throw away your debugged and working code for a rewrite in another language?
  - gbrown 5y ago
    Shell scripts are one way to do this, but I don’t have a library of shell scripts because I always have access to actual scripting languages. To each their own, but writing bash scripts that get more complex than moving a few files around and sucks (imho), so I don’t bother.
    - Steltek 5y ago
      You're missing a step. You originally wrote "I don’t see why the shell must be both nice to program in and a concise textual interface." I attempted to demonstrate how evolving a CLI session into a script is very beneficial. That bash is not great for that purpose is exactly the point of the article. A better shell language would mean not throwing away your organic, working code for a rewrite. Unless you're trying to say that you rarely use the command line to explore a system and operate mostly through scripts. I think I would burn a lot of time in writing boiler plate when "curl | grep" would do the job for human consumption in less than 50 keystrokes.
      - gbrown 5y ago
        I see what you mean now. I still draw the line differently - I don’t think I’ve ever interactively worked through conditional logic, control loops, or user prompts, so I’d happily make simple bash scripts from basic commands, but I wouldn’t choose to write more complex programs that way.
AnthonBerg 5y ago
The author might be interested in fish shell and its excellent design document: https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html
- hnlmorg 5y ago
  I have used Fish before, though we are talking 10-ish years ago, and there is a lot to like about it. However it didn't resonate with me personally. I guess you could describe my feelings towards it as sort of an "uncanny valley" where it was too different to Bash to be compatible while being too similar to Bash to be worth the effort learning. So the whole experience felt more jarring than enlightening. Again, this is just a personal feeling and not a comment on their technical accomplishments. For example I was always impressed by just how polished Fish's interactive shell is. When designing murex (the shell I now use daily) I wanted to go one step further and say "If I'm abandoning Bash compatibility then what new things can I bring to the table". This will no doubt alienate a lot of new users that might prefer Fish's "like Bash but better" approach though. Which is fine, there's more than enough room for both shells to exist.
  - adrian_b 5y ago
    Obviously, syntax preferences in programming languages are very personal, so what someone considers to be simple and beautiful, someone else may consider as complex and ugly. Nevertheless, in my opinion, the right way to improve the "if ... fi" POSIX shell syntax is not by adding tons of superfluous curly braces, but by removing the redundant square brackets and the redundant semicolon (all of which have historical reasons for their presence). With those changes, you have the minimal fully-bracketed syntax for a conditional statement, e.g. (if ... then ... elif ... then ... else ... fi). If you do not like these keywords, that is fine, you should replace them with other keywords or symbols. For example, I like concise syntax, so I replace those keywords with certain Unicode symbols, i.e. mathematical angular brackets instead of if and fi, section sign instead of elif and else, and left arrow instead of then. It does not matter what keywords or symbols you like, but both the ease of writing and the ease of reading are improved when each kind of program control structure uses distinct delimiters, not just the same curly braces for everything, and also when there are no redundant delimiters, e.g. in C and derived languages there are a very large number of redundant parentheses, which are needed because the curly braces are optional. Had the curly braces been mandatory in C, the parentheses from if, switch, while, for would have been deleted, which would have lead to easier to read and write programs in the common case, when braces are used. The final syntax presented has an almost double number of delimiters than needed, presumably because the curly braces are reused for various other purposes in the complete murex shell syntax. Trying to use too few distinct symbols or keywords is guaranteed to increase the number of redundant delimiters. Maybe the Algol 68 method of inventing keywords like fi, esac, od, was not the most inspired, but the principle of using different kinds of delimiters for each distinct purpose was, and is, sound.
chasil 5y ago
The author makes an interesting claim: "Microsoft had the benefit of being able to start from a clean room. They didn't need to inherit 50+ years of UNIX legacy when they wrote Powershell. So their approach was naturally to base their shell on .NET." The POSIX shell had a specific requirement: when compiled, it had to fit within the Xenix 64k text segment. This is something that Powershell will never, ever do.
throwaway20371 5y ago
> if { = 0 == 1 } then { What in the heck is that first '=' for?
- hnlmorg 5y ago
  Everything is a function. So = is a function name for logical and mathematical operations. https://murex.rocks/docs/commands/equ.html https://murex.rocks/docs/commands/equ.html
- bccdee 5y ago
  I assume `=` is the equivalent of `test` — it's a function invocation, and `[0, ==, 1]` are its arguments.
- tzot 5y ago
  A renamed `expr` of the shell.

54 points by hnlmorg 5y ago

from TFA: > Perhaps the only language I've used which translates well both for terse REPLs and lengthier scripts is LISP. Why not just use a lisp then?

adrian_b 5y ago
Actually there exists a shell, "scsh", which uses the Scheme language, i.e. a LISP variant. "scsh" is less convenient for interactive use than bash or zsh, because it is more verbose, but it was quite good for scripts, certainly more convenient as a replacement for shell scripts than Python or the like (because it had a better syntax for the equivalent of a POSIX command list, with pipes, and/or lists, redirections and parameter expansions). Many years ago, I have written and used with good results a lot of "scsh" scripts, for things deemed to be too complex for POSIX shell scripts. However, AFAIK, "scsh" has not been updated in recent years, so I do not know how good it would still be today.
isr 5y ago
Gauche scheme is a very "scripting-focussed" implementation, with some niceties inspired from scsh. I've used it's repl as a shell of sorts for a short while, just to see if I could. Janet is a new lisp (heavily inspired by Lua, not surprising given its author had previously started fennel, a lisp which compiles to Lua) which fits a smiliar "scripting" niche. An extension has been made for it (janetsh) to make it suitable as a shell replacement. In a similar vein, racket has rash. And if you consider tcl as a "lisp for strings", then it's almost a shell right out of the box. I've used jimtcl (again, like gauche, with a heavily customised shell-focussed lib of my own) as an interactive shell. Lot's of choices out there, if one is willing to roll one's sleeves up ;-)
LanternLight83 5y ago
Murex comes across kinda lisp-y with the keyword-less, prefix-notation #'if statement. Emacs also offers a unique (and very lisp-y) shell syntax within #'eshell.

1vuio0pswjnm7 5y ago

Downloaded murex to try it out. It was really janky, unusually so, with red colored text that is difficult to see on a black console. Requires libpthreads. Interesting first impressions. I will be dead before anything like this ever replaces the Bourne shell. There is little incentive to switch and lots of incentive to continue toward mastery of the ubiquitous shell, the one I have to use on POSIX-like OS, on computers of all sizes, like it or not.

hnlmorg 5y ago
> with red colored text that is difficult to see on a black console. Thanks for your honest feedback. It's only errors that appear in red and you can disable that feature if you want[1]. However it's pretty standard these days for DevOps tools to output errors in red but I appreciate that is still not to everyone's tastes. [1] https://murex.rocks/docs/user-guide/interactive-shell.html https://murex.rocks/docs/user-guide/interactive-shell.html It should also be noted that I'm honouring the terminal emulators colour palette. So if a colour isn't readable then it's the terminal emulator you're running that has caused that issue. Personally I recommend the Solarized colour themes because all 16 colours are equally readable but your preferences might differ. > There is little incentive to switch and lots of incentive to continue toward mastery of the ubiquitous shell, the one I have to use on POSIX-like OS, on computer of all sizes, like it or not. I do get that sentiment but more and more these days most of the console work is done on your local machine and you rarely SSH onto remote hosts (some orgs even go as far as to disable SSH access entirely since everything should be managed via Ansible/Puppet/Chef/SSM/etc). The problem murex attempts to solve is to be a better shell for local development / DevOps tooling. There's no point trying to get murex pushed as a default shell on servers because no security team would authorise it. But for local tooling there are still a lot of gains to be made. This is why you'll see features like errors highlighted in red and spelling errors underlined. murex takes as many cues from IDEs (local development) as it does from POSIX-shells.
- 1vuio0pswjnm7 5y ago
  It's cool project it's just not for me. I am too comfortable with a basic Bourne shell, VGA textmode, no UTF-8, TERM=vt100. If it were possible to "improve" on this basic environment, I would want the new shell to be something less, not more; simpler, not more complex. Anyway, ignore the negative feedback. I am not the target audience for murex.

deleted 5y ago

[deleted]

gbrown 5y ago

Interesting article, though for me an acceptable middle ground is to just use bash and friends as an interface, as described, and to write any larger and more complicated scripts in Python with argparse (or similar). I don’t see why the shell must be both nice to program in and a concise textual interface.

Steltek 5y ago
Shell scripts are the automation and extension of repetitive, tedious manual tasks. Why wouldn't you want to take your shell history and wrap it in some getopt-ish stuff? Or to put it another way, why would you wish to throw away your debugged and working code for a rewrite in another language?
- gbrown 5y ago
  Shell scripts are one way to do this, but I don’t have a library of shell scripts because I always have access to actual scripting languages. To each their own, but writing bash scripts that get more complex than moving a few files around and sucks (imho), so I don’t bother.
  - Steltek 5y ago
    You're missing a step. You originally wrote "I don’t see why the shell must be both nice to program in and a concise textual interface." I attempted to demonstrate how evolving a CLI session into a script is very beneficial. That bash is not great for that purpose is exactly the point of the article. A better shell language would mean not throwing away your organic, working code for a rewrite. Unless you're trying to say that you rarely use the command line to explore a system and operate mostly through scripts. I think I would burn a lot of time in writing boiler plate when "curl | grep" would do the job for human consumption in less than 50 keystrokes.
    - gbrown 5y ago
      I see what you mean now. I still draw the line differently - I don’t think I’ve ever interactively worked through conditional logic, control loops, or user prompts, so I’d happily make simple bash scripts from basic commands, but I wouldn’t choose to write more complex programs that way.

AnthonBerg 5y ago

The author might be interested in fish shell and its excellent design document: https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html

hnlmorg 5y ago
I have used Fish before, though we are talking 10-ish years ago, and there is a lot to like about it. However it didn't resonate with me personally. I guess you could describe my feelings towards it as sort of an "uncanny valley" where it was too different to Bash to be compatible while being too similar to Bash to be worth the effort learning. So the whole experience felt more jarring than enlightening. Again, this is just a personal feeling and not a comment on their technical accomplishments. For example I was always impressed by just how polished Fish's interactive shell is. When designing murex (the shell I now use daily) I wanted to go one step further and say "If I'm abandoning Bash compatibility then what new things can I bring to the table". This will no doubt alienate a lot of new users that might prefer Fish's "like Bash but better" approach though. Which is fine, there's more than enough room for both shells to exist.
- adrian_b 5y ago
  Obviously, syntax preferences in programming languages are very personal, so what someone considers to be simple and beautiful, someone else may consider as complex and ugly. Nevertheless, in my opinion, the right way to improve the "if ... fi" POSIX shell syntax is not by adding tons of superfluous curly braces, but by removing the redundant square brackets and the redundant semicolon (all of which have historical reasons for their presence). With those changes, you have the minimal fully-bracketed syntax for a conditional statement, e.g. (if ... then ... elif ... then ... else ... fi). If you do not like these keywords, that is fine, you should replace them with other keywords or symbols. For example, I like concise syntax, so I replace those keywords with certain Unicode symbols, i.e. mathematical angular brackets instead of if and fi, section sign instead of elif and else, and left arrow instead of then. It does not matter what keywords or symbols you like, but both the ease of writing and the ease of reading are improved when each kind of program control structure uses distinct delimiters, not just the same curly braces for everything, and also when there are no redundant delimiters, e.g. in C and derived languages there are a very large number of redundant parentheses, which are needed because the curly braces are optional. Had the curly braces been mandatory in C, the parentheses from if, switch, while, for would have been deleted, which would have lead to easier to read and write programs in the common case, when braces are used. The final syntax presented has an almost double number of delimiters than needed, presumably because the curly braces are reused for various other purposes in the complete murex shell syntax. Trying to use too few distinct symbols or keywords is guaranteed to increase the number of redundant delimiters. Maybe the Algol 68 method of inventing keywords like fi, esac, od, was not the most inspired, but the principle of using different kinds of delimiters for each distinct purpose was, and is, sound.

chasil 5y ago

The author makes an interesting claim: "Microsoft had the benefit of being able to start from a clean room. They didn't need to inherit 50+ years of UNIX legacy when they wrote Powershell. So their approach was naturally to base their shell on .NET." The POSIX shell had a specific requirement: when compiled, it had to fit within the Xenix 64k text segment. This is something that Powershell will never, ever do.

throwaway20371 5y ago

> if { = 0 == 1 } then { What in the heck is that first '=' for?

hnlmorg 5y ago
Everything is a function. So = is a function name for logical and mathematical operations. https://murex.rocks/docs/commands/equ.html https://murex.rocks/docs/commands/equ.html
bccdee 5y ago
I assume `=` is the equivalent of `test` — it's a function invocation, and `[0, ==, 1]` are its arguments.
tzot 5y ago
A renamed `expr` of the shell.