8 ms·

Alternative Shells

186 points by chubot 6y ago

JNRowe 6y ago
chubot, I have to say I really admire your dedication! I only follow oilshell to the extent that I read your articles and dip in to the wiki, but even that is a joyful learning experience.
- chubot 6y ago
  :) Glad to hear it! Tell your friends about Oil. There are many shell users in the world and most of them haven't heard of it!
njacobs5074 6y ago
You can also run the Ammonite Scala REPL as a shell. See http://ammonite.io/#Ammonite-Shell http://ammonite.io/#Ammonite-Shell
- chubot 6y ago
  It's on the sister page linked at the top, because it's embedded in Scala: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell Feel free to fix up the link/description to be more useful/accurate.
akho 6y ago
I suspect Emacs’s eshell sees more use than many of those that made this list. Doesn’t run without Emacs, though, which maybe disqualifies it? Cool list though.
- chubot 6y ago
  It's on the sister page linked at the top, because it's embedded in Elisp AFAIK: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell
- dj_mc_merlin 6y ago
  And arguably one of the best windows shells if you don't count Emacs as an OS.
chubot 6y ago
BTW I refactored/edited this wiki page as part of this update of the FAQ, which compares Oil to other shells: http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#comparisons http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#co...
- wodenokoto 6y ago
  On that page you write that “you _can_ use oil in production but ...” which sounds like you recommend against it. Later you write that oil is best for automation and fish is better for interactive usage. This got me confused. Do you recommend that I run fish in my terminal, rewrite my one liners to oil when they outgrow their one line, but use bash in production? With that being said I really appreciate how honestly you write about the limitations of oil and benefits of competing shells. Few project seems to be as open minded about their competitors and aware of their own short comings as oil, which in my opinion is what you want out of something you put your trust in.
  - chubot 6y ago
    Yeah I would like Oil to be the best of both worlds, but realistically it won't be in 2021. That dichotomy is sort of explained at the top of the FAQ: shell as a language vs. shell as a UI. (I plan to use bash interactively and Oil for scripting for awhile, which is natural because Oil runs bash scripts. Others may want to use fish; fish is too incompatible for me.) However in 2021 I hope to remove the qualifier about slowness. That's the only reason I don't use it in production now! (There are several Oil-only features that I want to use in production, like better tracing.) --- I've written several times on the blog about how the scope of the project is too big, especially in the last year :) So the goal is really to have Oil be the best for ONE use case, and I think that's "cloud automation". I will run Oil's own extensive continuous build to Oil as part of this. And once people are using it for that, it should attract contributors, which will address the "scope" problem. Oil is very compatible with bash -- the most compatible by a mile. It's very modular, and I mentioned in this thread how you could do things with it you can't do with bash. So basically everything about the project is working, but it takes a long time. The thesis from the beginning has panned out -- otherwise I would have stopped working on it already :) It turns out it really is the best thing for what I want to do, and I'm confident that will generalize. Shell is becoming more important, not less important! (I have some upcoming posts about this, i.e. regarding distributed systems and "the YAML problem".) We need a better shell -- that's a smooth upgrade from POSIX shell and bash.
dj_mc_merlin 6y ago
+1 for fish, the autocompletion alone makes it my daily driver. You can get the same in any reputable shell, but I like that it is designed into it from the ground up (the zsh autocompletion plugin brands itself as "fish-like"). It's also compatible-enough with POSIX for most purposes, and supported as an alternative for lots of software (venv comes to mind).
- xthetrfd 6y ago
  One area where fish is excellent is IMO interactive shell scripting. No more case..esac and friends. Fish adopts a python-like syntax that makes it ridiculously easy to write loops fast in the terminal.
  - bool3max 6y ago
    It's an absolute godsend. Scripting in it feels really intuitive compared to POSIX shells. I find it such a shame that we probably won't get rid of POSIX shells for at least a couple more decades... if that.
    - O_H_E 6y ago
      Well, oilshell has been positioning itself as an upgrade path forward.
  - beagle3 6y ago
    You can have real Python scripting with xonsh. It combines Python ness and shellness very nicely. I agree that fish is a sweet middle ground spot.
  - saurik 6y ago
    So I read this and thought "wow, indentation would be so stupid to manage in a terminal... even typing python into python's repl is brutal" but then I looked up the syntax for a for loop in fish and it is exactly the same as the syntax in bash except it uses the word "end" instead of "done" and doesn't have "do"... what am I missing?
- 6y ago
lloeki 6y ago
I’ve been trying many of those but failing to switch because I’m too brainwashed by bash (even zsh trips me up when some non-bashisms happen to trigger) and ended up writing one toy shell for me to peruse. Goals/Plans/Ideas/Experiments: - interactive, compatible with the subset of bash I use the most - written in Ruby, forks only when necessary (e.g for subshells uses Ruby threads and pipes to spawn and connect new Shell instances) - extensible via Ruby (i.e can define new functions in Ruby, accessible more or less directly from the shell) - fzf support - can be built against mruby to embed a Ruby VM + code in a single binary and not require any Ruby installed - can be assembled into a single .rb to easily curl it into any machine where there’s a Ruby already - no dependencies - some sort of concurrent/async evaluation for fast start, prompt, autocompletion... Still a long way to go, but I find the experience rewarding even if it ends up going nowhere.
kitd 6y ago
One more: Rash is a Racket-powered shell with "lispy" scripting. https://docs.racket-lang.org/rash/index.html https://docs.racket-lang.org/rash/index.html
yewenjie 6y ago
Okay, can anyone point out some real day-to-day use case for which I should ditch fish and move to something else? I need all the niceties of fish and something more.
nyellin 6y ago
I'm working on creating a modern terminal interface with Electron where you can use the mouse to modify the command line, each command sends output to a separate "output block" (think Jupyter notebook), you have global autocompletion from history regardless of which machine you are sshed into or how many shells deep you are, and where every time you start typing a command the man page automatically appears in a sidebar. This is surprisingly hard to implement. If you just run bash unmodified as the backend then you can't multiplex the output from different commands and therefore you can't display output from different commands in different blocks. If you run each command in a separate shell then you lose automatic tracking of environment variables and working directories... (There are other challenges but they are a little easier to work around.) Does anyone have creative ideas for how to work around this?
- rogual 6y ago
  Bit hacky but you could keep a long-running Bash process and use PROMPT_COMMAND to notify you to start a new block? I love this kind of thing, by the way. I'm sure terminal emulators are not the best we can do, CLI-wise.
  - sime2009 6y ago
    The shell integration in [Extraterm](http://extraterm.org/features.html http://extraterm.org/features.html) and [iTerm2](https://iterm2.com/documentation-shell-integration.html https://iterm2.com/documentation-shell-integration.html) both work via 'hooks' related to the command prompt and command execution.
- pletnes 6y ago
  Jupyter already let you run shell so at least have a look for inspiration - and limitations that would be nice to lift (e.g faster output)
- dan-robertson 6y ago
  I think something like this would be good, but I don’t think I’d base it on bash. Some of the things I would have are: 1. When someone writes a command like foo | bar, instead of making a single pipe from one to the next, put your own lightweight program that works a bit like pv in the middle. In the standard case this is a pretty cheap program: it just needs to call splice to move from stdin to stdout, but you could have some mechanism to eg view the data going through a pipe or the rate of data: one could tell if the program is doing anything 2. Typical interactive shell use involves writing commands, inspecting output, then modifying the commands. A notebook format may be better for that. I think I’d want some mechanism to say “these commands will generate some output. I want to inspect it then write the next stage in the pipeline so hang onto that output instead of rerunning the command.” And why not make some “interactive grep” and interactive versions of other commands so that one can get immediate feedback when modifying the regex. 3. It’s hard to know if a command will have side effects but I feel like it matters a lot. Maybe something could be done to detect it somehow.
jbotz 6y ago
Some more... Rash is a shell embedded in Racket that was presented in a paper at GPCE18[1]. Oil is cited in the paper, so Andy really should include it in the list as well ;-). There are also a few others mentioned in the "Risky review of related work" section of the paper that aren't on Andy's list yet, see the paper. Another, similar and minimalist "shell language" is janet-sh[2]. Also, this suggests a slightly different form of categorization for Andy's page, i.e. new shell languages vs. "embdedded" shell languages which are libraries that add just enough functionality to a parent language that it becomes useful as both an interactive shell and a scripting language. Xonsh would go into this category then instead of the somewhat poorly defined "interactive shells" category, since Python with Xonsh is a better shell scripting language than Python by itself. [1] https://dl.acm.org/doi/10.1145/3278122.3278129 https://dl.acm.org/doi/10.1145/3278122.3278129 [2] https://acha.ninja/blog/dsl_for_shell_scripting https://acha.ninja/blog/dsl_for_shell_scripting
- chubot 6y ago
  I just added a note at the top that embedded DSLs go here :) https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell Rash is already there -- feel free to make the link/description more accurate, and add janet-sh, etc.
  - joveian 6y ago
    Thanks for the list! For completeness, I think the active older POSIX shells include at least NetBSD's sh, dash, and bash. Not sure if there are any others. Edit: zsh, ksh, mksh also.
XorNot 6y ago
Tried an alternate shell for a while, ran into the basic problem that the moment I SSH'd somewhere else it was gone, and my instincts for how to get things done expediently were degrading. If I was going to use an alternate shell, it's got to have some solution for this problem that's transparent - something I can load into any sh/bash environment to get it running remotely.
- pletnes 6y ago
  This is one reason I like zsh - they are extremely compatible. I also have a different prompt so I immediately notice if I’m inside zsh.
  - circularfoyers 6y ago
    This is why I ended up sticking with zsh after I tried fish for a period. I liked some of fish's features, so I used the two plugins fast-syntax-highlighting and zsh-autosuggestions to get the same features in zsh.
- antihero 6y ago
  It'd be cool if there was something like VSCode's model where it set up some sort of daemon that provided a shell environment (instead of an editor) remotely. Perhaps mosh can do something like that? Or even just a script which could quickly bootstrap a shell and dotfiles on a system.
- bandie91 6y ago
  something like Plan9's cpu server would help here: you "mount" your shell/IDE environment from your computer and "mount" the other computer's cpu, memory, and fs over ssh. "mount" is in quotation because in Plan9 you not only can mount fs but cpu, network interfaces, desktop windows and what not too.
- Frost1x 6y ago
  This is the core problem with so many software efforts now, there are just too many efforts that portability suffers. I remember years ago mucking around with my home computing environment, making it so convenient, custom UI shell, monitoring widgets, highly customized bash environment with all sorts of fancy utilities that were just so handy, and all sorts of nifty features everywhere to tackle any problem I encountered. Alas, the second I went anywhere else to do something--some friend or business's system, none of that underlying infrastructure existed. I lamented, "oh if only these other people followed my model I could just use X right now," life would be better. At some point in my career I realized I was just wasting a whole lot of time customizing my native environment because those features were non-portable and the more I dealt with working in other people's environment, the more I realized I should just focus on learning the best way to do things in the popularly adopted environments because it meant my knowledge transferred almost everywhere.
smlckz 6y ago
> Tcl — Everything is a string. A scripting language and interactive shell that has been described as a bastard child of Bash and Lisp. lol
- gpanders 6y ago
  As someone who has to use Tcl fairly often as part of an FPGA tool chain, this description is accurate.
MichaelMoser123 6y ago
i think they are all wrong - a next gen shell needs to focus on structured data - hacks like jq and yq need to be made redundant as being part of the shell. I didn't manage to pursuade redhat that this is going to be a priority (i used to work for them); i still think that this is going to be a priority in the near future.
- CodesInChaos 6y ago
  There are a couple which attempt this. I think nushell works that way. And powershell, though it sacrifices language independence by using .net objects as its structure.
  - mrshu 6y ago
    nushell does indeed work exactly like this. You can check out the demo at https://www.nushell.sh/demo/ https://www.nushell.sh/demo/
- hnlmorg 6y ago
  There are shells in that list which do exactly that, inc my own shell (murex). It’s very hard to describe a shell in a short paragraph because it’s a tool that crosses a range of domains, such as - interactive development environment (autocompletion, et al) - REPL environment / one liners - programming language - plus support for miscellaneous POSIX features such as job management
- lukeschlather 6y ago
  I've been working in a Windows shop for 2 years and I'm to the point where I just tell people to rewrite things in Powershell. It has native json support so yes, jq is obsolete. On this list, I've looked at elvish before, it seems like it also is designed to make jq obsolete, and it is much more posixy than Powershell (though I think parts of posix really hold shells like Oil back from being as powerful as Powershell is and something like elvish may be.)
  - eterm 6y ago
jmclnx 6y ago
A bit pedantic, but I think this statement "Probably the most popular non-POSIX shell" about fish may need this qualifier "For Linux Systems ...." tcsh is the default in FreeBSD, and csh/ksh is very popular on proprietary UNIX systems. Practically no one proprietary systems move outside of the default (I see this a lot in AIX, which defaults to ksh).
- yakubin 6y ago
  > A bit pedantic, but I think this statement "Probably the most popular non-POSIX shell" about fish may need this qualifier "For Linux Systems ...." Both versions are true, given the chasm between the popularity of Linux vs other Unix clones.
- chubot 6y ago
  Good point, I added the qualifier! csh is now there too.
andrew_ 6y ago
Not to be confused with Windows Alternative shells. I always enjoy dropping these links for folks who didn't know previously that this was a thing at a point in time, and that at one point the definition of "shell" between Windows and *nix was a bit different: - http://shellfront.org/ http://shellfront.org/ - https://www.online-tech-tips.com/software-reviews/7-best-windows-alternative-shell-replacement-programs/ https://www.online-tech-tips.com/software-reviews/7-best-win... - https://en.wikipedia.org/wiki/List_of_alternative_shells_for_Windows https://en.wikipedia.org/wiki/List_of_alternative_shells_for... (surprisingly incomplete)
kaba0 6y ago
I have been thinking about an alternative to bash/POSIX style shells, and I find powershell kind of genius in this regard. What could potentially work for the linux world is perhaps dbus objects between piped programs (they are easy to read/write even from lower level languages) and some way for programs to communicate whether they are capable of interpreting objects, or should fall back to string based communication. And at the boundaries there could be automatic translations (though object to string is easier) with something like toString. So for example `ls -la | filter f -> f.date > 2021-01-01 | grep something` would either shadow ls to a new shell-aware implementation or patch it /interpret automagically the table layout and then the resulting list of objects could be filtered and at the end reconverted to an object “toString” per each line which can be operated on by grep
- geophile 6y ago
  In marcel: M 0.12.7 jao@cheese ~$ import datetime datetime M 0.12.7 jao@cheese ~$ ls | select (f: f.mtime > datetime(2021, 1, 1).timestamp()) | grep py .marcel.py .python_history ls is builtin (and has -la behavior by default), select is provided by marcel, and grep is from the host OS. Note that the python function datetime.datetime is imported so that it can be used in the select predicate.
- svnpenn 6y ago
  PowerShell works with Linux...
  - kaba0 6y ago
    Yeah I know. It is not really a first-class citizen though.
    - electricEmu 6y ago
      POSIX commands are available on *nix platforms and PowerShell provides native functions or POSIX wrappers for most tasks. About the biggest issue is speed, but there's always POSIX or .NET Core in the rare instance tons of performance is required. If I may, PS is a first-class citizen on Linux, macOS, and Windows. PowerShell is a spectacular cross-platform shell that provides an object oriented paradigm and it's available today.
mkovach 6y ago
rc shell is still maintained for Plan9 (in both 9legacy and 9front) and for UNIX in plan9port. I have used it has my daily shell for almost a decade now. There are also native UNIX ports available, usually based on https://github.com/rakitzis/rc https://github.com/rakitzis/rc. I enjoy the simple syntax and I wouldn't call it dormant by any means. It kept simple on purpose and doesn't require many changes.
ktm5j 6y ago
I used elvish for as my daily shell for a while, and loved a lot about it! Eventually made the switch to fish, which is also wonderful.. can't remember exactly why I stopped using elvish. Ultimately ended up moving to zsh because posix compliance is convenient.
taviso 6y ago
One obscure shell not listed is Ch, https://www.softintegration.com/docs/ch/shell/ https://www.softintegration.com/docs/ch/shell/ Ch is actually proprietary software, if it was free software, I would probably use it as my login shell. I spent some time writing scripts and customizing my .chrc and really enjoyed it. It's actually a C interpreter, but with shell features.
baruchel 6y ago
I try to stick to https://suckless.org/rocks/ https://suckless.org/rocks/ and mostly use mksh https://www.mirbsd.org/mksh.htm https://www.mirbsd.org/mksh.htm
bennysonething 6y ago
Genuine question: I thought that operating systems only have one shell, but that can be accessed by multiple terminals? So this should be alternative terminals? I'm not trying to be a pedant I just thought I understood something, now Im not so sure.
- drewg123 6y ago
  A unix/linux OS can have multiple shells. The shell you land in at login is determined by the shell listed in your account's /etc/passwd entry and can often be changed via chsh command.
- snarfy 6y ago
  A terminal is a device. It can be physical like the console or a vt100 or similar, or virtual. It represents an input an display. A shell is a program that opens this device and performs IO with it.
- rmorey 6y ago
  in my understanding: “shell” is kind of a loosely defined term in this context, but i just think of it as a textual interface to the whole system. really it’s just a program that accepts text commands (or scripts) and performs actions on the system or launches other programs, and manipulates and displays the results. eg: sh bash zsh fish xonsh “terminal” is pretty well defined as a graphical UI program which presents you with the shell of your choosing (historically related to teletype or whatever) eg: xterm Terminal.app Konsole iTerm alacritty for the most part you can use any terminal with any shell, so the terms kind of coalesce into the more generic idea of a “command line” also all of this is for unix-like systems, eg linux macos bsd. windows is... well windows hope this makes sense!
- indymike 6y ago
  Good question. Depends on the OS. In the case of Linux (and other Unixish OSes), getty is the program that makes a terminal or console session work on the host side. Getty usually launches a program, login, that takes your username and password, retrieves your account's settings and launches your interactive shell (something like bash, zsh, fish or oil) when you successfully authenticate. Incidentally, tools like screen and byobu allow multiple terminals to attach to the same shell by multiplexing the terminal (not the shell).
drewg123 6y ago
Its funny to think of csh/tcsh as an "alternate" shell, as Its been my shell since my first *nix account in 1989..
BurningFrog 6y ago
Pseudo hijack: Is there a way to make command line editing on my Mac work the same way as standard Mac text editing? Things like alt+<arrow key> jumps entire words, click to move cursor etc. I'm using iTerm2.
ibraheemdev 6y ago
I am really confused about oilshell. Is it ready for me to install and become my daily driver? What does it do better? Is the syntax different? It would be really nice to see code snippets on the front page like fish shell's website. Even the "How is Oil different than bash or zsh?" section doesn't really tell me anything about it: > Oil is taking shell seriously as a programming language, rather than treating it as a text-based UI that can be abused to write programs.
ilyash 6y ago
Hi! Author of NGS here. TL;DR about NGS: * NGS is programming language first, as opposed to most (or all?) alternatives. A language designed specifically for Ops. In practice it means geared towards particular use cases - https://github.com/ngs-lang/ngs/wiki/Use-Cases https://github.com/ngs-lang/ngs/wiki/Use-Cases . * Your day-to-day pain factored out: how many times you are supposed to define warn(), die(), log(), retry() and what not? * The language is in OK shape, we use it at work. * The work on the shell (CLI) is just starting. The shell will be in NGS language itself. ... and you are all welcome to the NGS meetup (on Tuesday, May 4, 2021 6:30 PM to 8:00 PM GMT+3) - https://www.meetup.com/lifemichael/events/275961221/ https://www.meetup.com/lifemichael/events/275961221/

186 points by chubot 6y ago

chubot, I have to say I really admire your dedication! I only follow oilshell to the extent that I read your articles and dip in to the wiki, but even that is a joyful learning experience.

chubot 6y ago
:) Glad to hear it! Tell your friends about Oil. There are many shell users in the world and most of them haven't heard of it!

njacobs5074 6y ago

You can also run the Ammonite Scala REPL as a shell. See http://ammonite.io/#Ammonite-Shell http://ammonite.io/#Ammonite-Shell

chubot 6y ago
It's on the sister page linked at the top, because it's embedded in Scala: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell Feel free to fix up the link/description to be more useful/accurate.

akho 6y ago

I suspect Emacs’s eshell sees more use than many of those that made this list. Doesn’t run without Emacs, though, which maybe disqualifies it? Cool list though.

chubot 6y ago
It's on the sister page linked at the top, because it's embedded in Elisp AFAIK: https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell
dj_mc_merlin 6y ago
And arguably one of the best windows shells if you don't count Emacs as an OS.

chubot 6y ago

BTW I refactored/edited this wiki page as part of this update of the FAQ, which compares Oil to other shells: http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#comparisons http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#co...

wodenokoto 6y ago
On that page you write that “you _can_ use oil in production but ...” which sounds like you recommend against it. Later you write that oil is best for automation and fish is better for interactive usage. This got me confused. Do you recommend that I run fish in my terminal, rewrite my one liners to oil when they outgrow their one line, but use bash in production? With that being said I really appreciate how honestly you write about the limitations of oil and benefits of competing shells. Few project seems to be as open minded about their competitors and aware of their own short comings as oil, which in my opinion is what you want out of something you put your trust in.
- chubot 6y ago
  Yeah I would like Oil to be the best of both worlds, but realistically it won't be in 2021. That dichotomy is sort of explained at the top of the FAQ: shell as a language vs. shell as a UI. (I plan to use bash interactively and Oil for scripting for awhile, which is natural because Oil runs bash scripts. Others may want to use fish; fish is too incompatible for me.) However in 2021 I hope to remove the qualifier about slowness. That's the only reason I don't use it in production now! (There are several Oil-only features that I want to use in production, like better tracing.) --- I've written several times on the blog about how the scope of the project is too big, especially in the last year :) So the goal is really to have Oil be the best for ONE use case, and I think that's "cloud automation". I will run Oil's own extensive continuous build to Oil as part of this. And once people are using it for that, it should attract contributors, which will address the "scope" problem. Oil is very compatible with bash -- the most compatible by a mile. It's very modular, and I mentioned in this thread how you could do things with it you can't do with bash. So basically everything about the project is working, but it takes a long time. The thesis from the beginning has panned out -- otherwise I would have stopped working on it already :) It turns out it really is the best thing for what I want to do, and I'm confident that will generalize. Shell is becoming more important, not less important! (I have some upcoming posts about this, i.e. regarding distributed systems and "the YAML problem".) We need a better shell -- that's a smooth upgrade from POSIX shell and bash.

dj_mc_merlin 6y ago

+1 for fish, the autocompletion alone makes it my daily driver. You can get the same in any reputable shell, but I like that it is designed into it from the ground up (the zsh autocompletion plugin brands itself as "fish-like"). It's also compatible-enough with POSIX for most purposes, and supported as an alternative for lots of software (venv comes to mind).

xthetrfd 6y ago
One area where fish is excellent is IMO interactive shell scripting. No more case..esac and friends. Fish adopts a python-like syntax that makes it ridiculously easy to write loops fast in the terminal.
- bool3max 6y ago
  It's an absolute godsend. Scripting in it feels really intuitive compared to POSIX shells. I find it such a shame that we probably won't get rid of POSIX shells for at least a couple more decades... if that.
  - O_H_E 6y ago
    Well, oilshell has been positioning itself as an upgrade path forward.
- beagle3 6y ago
  You can have real Python scripting with xonsh. It combines Python ness and shellness very nicely. I agree that fish is a sweet middle ground spot.
- saurik 6y ago
  So I read this and thought "wow, indentation would be so stupid to manage in a terminal... even typing python into python's repl is brutal" but then I looked up the syntax for a for loop in fish and it is exactly the same as the syntax in bash except it uses the word "end" instead of "done" and doesn't have "do"... what am I missing?
6y ago

lloeki 6y ago

I’ve been trying many of those but failing to switch because I’m too brainwashed by bash (even zsh trips me up when some non-bashisms happen to trigger) and ended up writing one toy shell for me to peruse. Goals/Plans/Ideas/Experiments: - interactive, compatible with the subset of bash I use the most - written in Ruby, forks only when necessary (e.g for subshells uses Ruby threads and pipes to spawn and connect new Shell instances) - extensible via Ruby (i.e can define new functions in Ruby, accessible more or less directly from the shell) - fzf support - can be built against mruby to embed a Ruby VM + code in a single binary and not require any Ruby installed - can be assembled into a single .rb to easily curl it into any machine where there’s a Ruby already - no dependencies - some sort of concurrent/async evaluation for fast start, prompt, autocompletion... Still a long way to go, but I find the experience rewarding even if it ends up going nowhere.

kitd 6y ago

One more: Rash is a Racket-powered shell with "lispy" scripting. https://docs.racket-lang.org/rash/index.html https://docs.racket-lang.org/rash/index.html

yewenjie 6y ago

Okay, can anyone point out some real day-to-day use case for which I should ditch fish and move to something else? I need all the niceties of fish and something more.

nyellin 6y ago

I'm working on creating a modern terminal interface with Electron where you can use the mouse to modify the command line, each command sends output to a separate "output block" (think Jupyter notebook), you have global autocompletion from history regardless of which machine you are sshed into or how many shells deep you are, and where every time you start typing a command the man page automatically appears in a sidebar. This is surprisingly hard to implement. If you just run bash unmodified as the backend then you can't multiplex the output from different commands and therefore you can't display output from different commands in different blocks. If you run each command in a separate shell then you lose automatic tracking of environment variables and working directories... (There are other challenges but they are a little easier to work around.) Does anyone have creative ideas for how to work around this?

rogual 6y ago
Bit hacky but you could keep a long-running Bash process and use PROMPT_COMMAND to notify you to start a new block? I love this kind of thing, by the way. I'm sure terminal emulators are not the best we can do, CLI-wise.
- sime2009 6y ago
  The shell integration in [Extraterm](http://extraterm.org/features.html http://extraterm.org/features.html) and [iTerm2](https://iterm2.com/documentation-shell-integration.html https://iterm2.com/documentation-shell-integration.html) both work via 'hooks' related to the command prompt and command execution.
pletnes 6y ago
Jupyter already let you run shell so at least have a look for inspiration - and limitations that would be nice to lift (e.g faster output)
dan-robertson 6y ago
I think something like this would be good, but I don’t think I’d base it on bash. Some of the things I would have are: 1. When someone writes a command like foo | bar, instead of making a single pipe from one to the next, put your own lightweight program that works a bit like pv in the middle. In the standard case this is a pretty cheap program: it just needs to call splice to move from stdin to stdout, but you could have some mechanism to eg view the data going through a pipe or the rate of data: one could tell if the program is doing anything 2. Typical interactive shell use involves writing commands, inspecting output, then modifying the commands. A notebook format may be better for that. I think I’d want some mechanism to say “these commands will generate some output. I want to inspect it then write the next stage in the pipeline so hang onto that output instead of rerunning the command.” And why not make some “interactive grep” and interactive versions of other commands so that one can get immediate feedback when modifying the regex. 3. It’s hard to know if a command will have side effects but I feel like it matters a lot. Maybe something could be done to detect it somehow.

jbotz 6y ago

Some more... Rash is a shell embedded in Racket that was presented in a paper at GPCE18[1]. Oil is cited in the paper, so Andy really should include it in the list as well ;-). There are also a few others mentioned in the "Risky review of related work" section of the paper that aren't on Andy's list yet, see the paper. Another, similar and minimalist "shell language" is janet-sh[2]. Also, this suggests a slightly different form of categorization for Andy's page, i.e. new shell languages vs. "embdedded" shell languages which are libraries that add just enough functionality to a parent language that it becomes useful as both an interactive shell and a scripting language. Xonsh would go into this category then instead of the somewhat poorly defined "interactive shells" category, since Python with Xonsh is a better shell scripting language than Python by itself. [1] https://dl.acm.org/doi/10.1145/3278122.3278129 https://dl.acm.org/doi/10.1145/3278122.3278129 [2] https://acha.ninja/blog/dsl_for_shell_scripting https://acha.ninja/blog/dsl_for_shell_scripting

chubot 6y ago
I just added a note at the top that embedded DSLs go here :) https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell https://github.com/oilshell/oil/wiki/Internal-DSLs-for-Shell Rash is already there -- feel free to make the link/description more accurate, and add janet-sh, etc.
- joveian 6y ago
  Thanks for the list! For completeness, I think the active older POSIX shells include at least NetBSD's sh, dash, and bash. Not sure if there are any others. Edit: zsh, ksh, mksh also.

XorNot 6y ago

Tried an alternate shell for a while, ran into the basic problem that the moment I SSH'd somewhere else it was gone, and my instincts for how to get things done expediently were degrading. If I was going to use an alternate shell, it's got to have some solution for this problem that's transparent - something I can load into any sh/bash environment to get it running remotely.

pletnes 6y ago
This is one reason I like zsh - they are extremely compatible. I also have a different prompt so I immediately notice if I’m inside zsh.
- circularfoyers 6y ago
  This is why I ended up sticking with zsh after I tried fish for a period. I liked some of fish's features, so I used the two plugins fast-syntax-highlighting and zsh-autosuggestions to get the same features in zsh.
antihero 6y ago
It'd be cool if there was something like VSCode's model where it set up some sort of daemon that provided a shell environment (instead of an editor) remotely. Perhaps mosh can do something like that? Or even just a script which could quickly bootstrap a shell and dotfiles on a system.
bandie91 6y ago
something like Plan9's cpu server would help here: you "mount" your shell/IDE environment from your computer and "mount" the other computer's cpu, memory, and fs over ssh. "mount" is in quotation because in Plan9 you not only can mount fs but cpu, network interfaces, desktop windows and what not too.
Frost1x 6y ago
This is the core problem with so many software efforts now, there are just too many efforts that portability suffers. I remember years ago mucking around with my home computing environment, making it so convenient, custom UI shell, monitoring widgets, highly customized bash environment with all sorts of fancy utilities that were just so handy, and all sorts of nifty features everywhere to tackle any problem I encountered. Alas, the second I went anywhere else to do something--some friend or business's system, none of that underlying infrastructure existed. I lamented, "oh if only these other people followed my model I could just use X right now," life would be better. At some point in my career I realized I was just wasting a whole lot of time customizing my native environment because those features were non-portable and the more I dealt with working in other people's environment, the more I realized I should just focus on learning the best way to do things in the popularly adopted environments because it meant my knowledge transferred almost everywhere.

smlckz 6y ago

> Tcl — Everything is a string. A scripting language and interactive shell that has been described as a bastard child of Bash and Lisp. lol

gpanders 6y ago
As someone who has to use Tcl fairly often as part of an FPGA tool chain, this description is accurate.

MichaelMoser123 6y ago

i think they are all wrong - a next gen shell needs to focus on structured data - hacks like jq and yq need to be made redundant as being part of the shell. I didn't manage to pursuade redhat that this is going to be a priority (i used to work for them); i still think that this is going to be a priority in the near future.

CodesInChaos 6y ago
There are a couple which attempt this. I think nushell works that way. And powershell, though it sacrifices language independence by using .net objects as its structure.
- mrshu 6y ago
  nushell does indeed work exactly like this. You can check out the demo at https://www.nushell.sh/demo/ https://www.nushell.sh/demo/
hnlmorg 6y ago
There are shells in that list which do exactly that, inc my own shell (murex). It’s very hard to describe a shell in a short paragraph because it’s a tool that crosses a range of domains, such as - interactive development environment (autocompletion, et al) - REPL environment / one liners - programming language - plus support for miscellaneous POSIX features such as job management
lukeschlather 6y ago
I've been working in a Windows shop for 2 years and I'm to the point where I just tell people to rewrite things in Powershell. It has native json support so yes, jq is obsolete. On this list, I've looked at elvish before, it seems like it also is designed to make jq obsolete, and it is much more posixy than Powershell (though I think parts of posix really hold shells like Oil back from being as powerful as Powershell is and something like elvish may be.)
- eterm 6y ago

jmclnx 6y ago

A bit pedantic, but I think this statement "Probably the most popular non-POSIX shell" about fish may need this qualifier "For Linux Systems ...." tcsh is the default in FreeBSD, and csh/ksh is very popular on proprietary UNIX systems. Practically no one proprietary systems move outside of the default (I see this a lot in AIX, which defaults to ksh).

yakubin 6y ago
> A bit pedantic, but I think this statement "Probably the most popular non-POSIX shell" about fish may need this qualifier "For Linux Systems ...." Both versions are true, given the chasm between the popularity of Linux vs other Unix clones.
chubot 6y ago
Good point, I added the qualifier! csh is now there too.

andrew_ 6y ago

Not to be confused with Windows Alternative shells. I always enjoy dropping these links for folks who didn't know previously that this was a thing at a point in time, and that at one point the definition of "shell" between Windows and *nix was a bit different: - http://shellfront.org/ http://shellfront.org/ - https://www.online-tech-tips.com/software-reviews/7-best-windows-alternative-shell-replacement-programs/ https://www.online-tech-tips.com/software-reviews/7-best-win... - https://en.wikipedia.org/wiki/List_of_alternative_shells_for_Windows https://en.wikipedia.org/wiki/List_of_alternative_shells_for... (surprisingly incomplete)

kaba0 6y ago

I have been thinking about an alternative to bash/POSIX style shells, and I find powershell kind of genius in this regard. What could potentially work for the linux world is perhaps dbus objects between piped programs (they are easy to read/write even from lower level languages) and some way for programs to communicate whether they are capable of interpreting objects, or should fall back to string based communication. And at the boundaries there could be automatic translations (though object to string is easier) with something like toString. So for example `ls -la | filter f -> f.date > 2021-01-01 | grep something` would either shadow ls to a new shell-aware implementation or patch it /interpret automagically the table layout and then the resulting list of objects could be filtered and at the end reconverted to an object “toString” per each line which can be operated on by grep

geophile 6y ago
In marcel: M 0.12.7 jao@cheese ~$ import datetime datetime M 0.12.7 jao@cheese ~$ ls | select (f: f.mtime > datetime(2021, 1, 1).timestamp()) | grep py .marcel.py .python_history ls is builtin (and has -la behavior by default), select is provided by marcel, and grep is from the host OS. Note that the python function datetime.datetime is imported so that it can be used in the select predicate.
svnpenn 6y ago
PowerShell works with Linux...
- kaba0 6y ago
  Yeah I know. It is not really a first-class citizen though.
  - electricEmu 6y ago
    POSIX commands are available on *nix platforms and PowerShell provides native functions or POSIX wrappers for most tasks. About the biggest issue is speed, but there's always POSIX or .NET Core in the rare instance tons of performance is required. If I may, PS is a first-class citizen on Linux, macOS, and Windows. PowerShell is a spectacular cross-platform shell that provides an object oriented paradigm and it's available today.

mkovach 6y ago

rc shell is still maintained for Plan9 (in both 9legacy and 9front) and for UNIX in plan9port. I have used it has my daily shell for almost a decade now. There are also native UNIX ports available, usually based on https://github.com/rakitzis/rc https://github.com/rakitzis/rc. I enjoy the simple syntax and I wouldn't call it dormant by any means. It kept simple on purpose and doesn't require many changes.

ktm5j 6y ago

I used elvish for as my daily shell for a while, and loved a lot about it! Eventually made the switch to fish, which is also wonderful.. can't remember exactly why I stopped using elvish. Ultimately ended up moving to zsh because posix compliance is convenient.

taviso 6y ago

One obscure shell not listed is Ch, https://www.softintegration.com/docs/ch/shell/ https://www.softintegration.com/docs/ch/shell/ Ch is actually proprietary software, if it was free software, I would probably use it as my login shell. I spent some time writing scripts and customizing my .chrc and really enjoyed it. It's actually a C interpreter, but with shell features.

baruchel 6y ago

I try to stick to https://suckless.org/rocks/ https://suckless.org/rocks/ and mostly use mksh https://www.mirbsd.org/mksh.htm https://www.mirbsd.org/mksh.htm

bennysonething 6y ago

Genuine question: I thought that operating systems only have one shell, but that can be accessed by multiple terminals? So this should be alternative terminals? I'm not trying to be a pedant I just thought I understood something, now Im not so sure.

drewg123 6y ago
A unix/linux OS can have multiple shells. The shell you land in at login is determined by the shell listed in your account's /etc/passwd entry and can often be changed via chsh command.
snarfy 6y ago
A terminal is a device. It can be physical like the console or a vt100 or similar, or virtual. It represents an input an display. A shell is a program that opens this device and performs IO with it.
rmorey 6y ago
in my understanding: “shell” is kind of a loosely defined term in this context, but i just think of it as a textual interface to the whole system. really it’s just a program that accepts text commands (or scripts) and performs actions on the system or launches other programs, and manipulates and displays the results. eg: sh bash zsh fish xonsh “terminal” is pretty well defined as a graphical UI program which presents you with the shell of your choosing (historically related to teletype or whatever) eg: xterm Terminal.app Konsole iTerm alacritty for the most part you can use any terminal with any shell, so the terms kind of coalesce into the more generic idea of a “command line” also all of this is for unix-like systems, eg linux macos bsd. windows is... well windows hope this makes sense!
indymike 6y ago
Good question. Depends on the OS. In the case of Linux (and other Unixish OSes), getty is the program that makes a terminal or console session work on the host side. Getty usually launches a program, login, that takes your username and password, retrieves your account's settings and launches your interactive shell (something like bash, zsh, fish or oil) when you successfully authenticate. Incidentally, tools like screen and byobu allow multiple terminals to attach to the same shell by multiplexing the terminal (not the shell).

drewg123 6y ago

Its funny to think of csh/tcsh as an "alternate" shell, as Its been my shell since my first *nix account in 1989..

BurningFrog 6y ago

Pseudo hijack: Is there a way to make command line editing on my Mac work the same way as standard Mac text editing? Things like alt+<arrow key> jumps entire words, click to move cursor etc. I'm using iTerm2.

ibraheemdev 6y ago

I am really confused about oilshell. Is it ready for me to install and become my daily driver? What does it do better? Is the syntax different? It would be really nice to see code snippets on the front page like fish shell's website. Even the "How is Oil different than bash or zsh?" section doesn't really tell me anything about it: > Oil is taking shell seriously as a programming language, rather than treating it as a text-based UI that can be abused to write programs.

ilyash 6y ago

Hi! Author of NGS here. TL;DR about NGS: * NGS is programming language first, as opposed to most (or all?) alternatives. A language designed specifically for Ops. In practice it means geared towards particular use cases - https://github.com/ngs-lang/ngs/wiki/Use-Cases https://github.com/ngs-lang/ngs/wiki/Use-Cases . * Your day-to-day pain factored out: how many times you are supposed to define warn(), die(), log(), retry() and what not? * The language is in OK shape, we use it at work. * The work on the shell (CLI) is just starting. The shell will be in NGS language itself. ... and you are all welcome to the NGS meetup (on Tuesday, May 4, 2021 6:30 PM to 8:00 PM GMT+3) - https://www.meetup.com/lifemichael/events/275961221/ https://www.meetup.com/lifemichael/events/275961221/