5 ms·
Why Create a New Unix Shell?
- saagarjha 6y ago> GNU bash is the most popular shell implementation in the world. It was first released in 1989, and implements the POSIX standard plus many extensions. It's the default shell on most Linux distributions, runs on BSD Unix variants, used to ship on Mac OS X, and runs on Windows. Note that macOS still ships bash.
- edgyquant 6y agoI haven’t had a Mac in a few years but iirc they ship zsh* nowadays not bash
- robin_reala 6y agoThey ship a few shells, but the default is zsh these days.
- judofyr 6y agoMac never stopped shipping Bash. What they did was to no longer use it as the default interactive shell. Zsh is now the new default shell. As far as I know, Mac has never shipped with Fish.
- myrandomcomment 6y agoDefault shell is zsh. They ship old version pre-GPL3 bash. I just “brew install bash” and then change my user shell in the system preferences to point at it.
- lawl 6y agoI think the author realized something important. There's the bash as a CLI users and bash as a scripting language users. I'm firmly in camp one and I think it's an important difference to realize. I don't want my CLI to be a REPL for a scripting language. It's something I really disliked about PowerShell when I tried it. It just felt like a dotnet scripting language and not like a CLI. If Oil provides a scripting interface with structured types etc. I'm all for it. I just don't want to have to deal with it when using the shell interactively. I love it when writing scripts and programs, but not for interactive shell use.
- giancarlostoro 6y agoReason I use fish is purely for OOTB shell defaults that are nice. I wouldnt script for Fish though its not a standard shell on most OS.
- quantified 6y agoWhat if the language is “shell”-ish? Reading the piece, the idea of shell as a REPL seemed attractive.
- lawl 6y agoFor me: No. I feel like powershell tried exactly that and i don't like it. That may be in the end just depend on execution though. But powershell e.g. prints errors that look like stacktraces (it's been a few years i don't remember exactly) with type information. And while that may be desirable to some, when using bash i'm using a UI as a user and not programming and i don't want to read a stacktrace. I want an error message in english telling me what's wrong.
- little_panda 6y agoThere is a try/catch/finally mechanism in powershell: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_try_catch_finally?view=powershell-7.1 https://docs.microsoft.com/en-us/powershell/module/microsoft... However, it is quirky to set up and I don't remember the details now, it doesn't handle the errors out of the box for sure. I would still prefer powershell over bash (or god forbid, cmd) any day.
- quantified 6y agoSure. Is that how all REPLs behave? I have a feeling there is a lot of latitude for tuning the ergonomics.
- aidenn0 6y agore: "are you reinventing perl" Oil feels much more like TCL to me than it does perl.
- chubot 6y agoI address that a bit here! https://www.oilshell.org/release/0.8.7/doc/language-influences.html https://www.oilshell.org/release/0.8.7/doc/language-influenc...
- earthscienceman 6y agoIt's only tangential but switching to fish shell made me about 3 times more productive. Being able to easily recall commands, to have completions displayed as I type, and to have interactivity be a first class citizen of the environment... made working in the shell so so so so much nicer. Fish has its own quirks, some of which seem unnecessary, but it was a godsend. There is definitely still room for improvement of the old tools, a. lot. of. room.
- CameronNemo 6y agoMy least favorite fish quirk is that you cannot use stty to remap Ctrl-C. You need to use stty in another shell, then exec into fish to remap it.
- mongol 6y agoWhy do you remap Ctrl-C?
- CameronNemo 6y agoWhy wouldn't I remap ctrl-c? It is the shortcut for copy. The letter c is nowhere in the word interrupt.
- faho 6y agoGood news: In the upcoming 3.2 release, fish will be less insistent on resetting terminal modes, so things like this (and enabling flow control) will be possible. (I'm the fish dev who implemented that)
- gdsimoes 6y agoI was always reluctant to change my shell, but recently I switched to fish and It’s been a pleasure from day one. I wish I did it sooner.
- socialdemocrat 6y agoI have used fish for many years and always been puzzled why it is not more popular. If you want an easy and effective shell that gets out of your way then it is should have been an obvious choice. Do you have any thoughts on why people don’t try it out? Where u also reluctant?
- peter_d_sherman 6y agoGreetings! First off, any person who would write either a language or a shell, now or in the future, should read your page, and in fact, should read everything about your Oil shell/language... It's a laudable effort! This page is going to my HN favorites, for future review. What follows next are my thoughts about selected excerpts of text on the page (please don't interpret as criticism, that's not the intent): >"You can think of a Unix shell in two ways: 1. As a text-based user interface. You communicate with the operating system by typing commands. 2. As a language. It has variables, functions, and loops. Shell programs are text files that start with #!/bin/sh." [...] >"Are you reinventing Perl? It's true that Perl is closer to shell than Python and Ruby are. For example, the perl -pie idiom can take the place of awk and sed. However, Perl isn't an acceptable shell either: o It doesn't have true pipelines (of processes). I believe you have to "shell out" for this. o It doesn't have a concept of file descriptor state. How do you write the equivalent of my_shell_func 2> err.txt, where my_shell_func can invoke both functions and external commands? o Perl has a function called grep(), but the real grep is better for many problems." PDS: This touches upon a historic problem, which is basically that either: A) Shell designers work their way "up" to a programming language, in which case some elegant programming language features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly / "non-orthagonally", AKA a "Kludge". Or: B) Language designers work their way "down" to supporting shell commands / a shell subsystem -- in which case some elegant shell features are either not thought about, or not thought deeply enough about, and thus either not implmented, or implemented poorly / "non-orthagonally", AKA a "Kludge". Also, languages are typically too heavy in what they require typed for shell-scripters, and shells are typically too light in what they allow (and error checking/debugging features) for programmers writing large programs... If someone were to design the most ideal programming language which also can be used for shell scripting, they'd have to look at things from both perspectives, and they'd have to create a language/shell -- completely balanced "down the middle" between these two paradigms... Perhaps the Oil shell/programming language -- is, or will become that middle line... To that extent, I wish you a lot of luck! If I were going to go down this path, I'd look at "first principles" (Elon Musk): The greatest differentiator between shell commands and lines of code in most programming languages is the point you alluded to in your comparison with Perl: "o It doesn't have true pipelines (of processes). I believe you have to "shell out" for this." In other words, in most programming languages (unless you are using threads), you are guaranteed linear execution. In a Unix shell -- because you can run multiple commands that may take varying amounts of time to complete, this guarantee is no longer present... That would be the fundamental thing to keep in mind when writing this future language/shell... (A good program to test when writing this language would be a Web-server -- where the base server is a single script, and then when it detects a connection, passes this over to either a single separate command-line invoked Unix program or script comprising multiple such Unix programs linked with pipes, but the central "server" script has to handle a whole lot of simultaneous I/O from multiple such separate programs (it centralizes database access!), and do this in a simple way that script programmers would be comfortable with, while guaranteeing the correct data flows...) Anyway, wishing you luck in this endeavor!
- gorgoiler 6y agoOil looks interesting. The documentation is compelling. I sleep at night by writing stoic bash. If I encounter anything unexpected in a script I don’t try to handle it, I just report it and then crash. Most of the bash contortions I’ve seen in my life happen when people (myself included) have tried to handle error conditions or ill specified inputs, gracefully. A bash script is like a pre-flight checklist: a list of things that should work to get something going. Most bash scripts are like this: in general they are sequences of commands to change the system from one good state to another, not to recover it from a bad state. In the analogy: if something is not ok with your aircraft it’s beyond the scope of the pre flight check to fix it. Don’t use the checklist as a way of trying to automatically detect what the error is in order to fix it.
- waynesonfire 6y agoGreat analogy. This is exactly how I use bash and have never thought to articulate it this way.
- voiper1 6y agoJust wanted to mention https://github.com/nushell/nushell https://github.com/nushell/nushell which seems to be doing some very cool stuff.
- wpietri 6y agoThis reminds me: why isn't there a good Python shell? Something with, as the author says, a "domain-specific language for dealing with concurrent processes and the file system", but otherwise basically Python? I'm sure people must have tried, so I guess there are fundamental incompatibilities between the two?
- pdmccormick 6y agoYou might be interested in Xonsh: https://xon.sh/ https://xon.sh/
- wpietri 6y agoUh oh. I've always stuck with Bash, because it's guaranteed to be on absolutely everything, and that's valuable for ops work. But this looks so much better! Thanks for pointing it out.
- blackrock 6y agoSometimes I want a more interactive shell. With the native ability to display graphics and view html and PDFs and other docs, without opening a separate GUI program.
- chubot 6y agoYeah I hope people will build stuff like that on top of Oil. Hopefully this year the embedding story will become clearer, and progress can be made on top. Some notes here about interactive shell ideas: https://github.com/oilshell/oil/wiki/Interactive-Shell https://github.com/oilshell/oil/wiki/Interactive-Shell Some people might think Oil is sort of a text-only or retro project ... but it really isn't, it's a SPEED project. I use shell because it's the fastest to get certain things done. But other things are faster when done with GUIs. Actually I wrote the last 5 or 6 blog posts in https://stackedit.io https://stackedit.io because copying and pasting huge swaths of text and links and images is faster with the mouse! I am a die-hard Vim person for code, but I realized that "thinking and writing" is aided by the mouse and by rich GUIs (but not slow ones, which is hard!). Previewing hyperlinks is also very important.
- skissane 6y agoOne thing newbies often ask, is why can't they write a shell script which changes the environment or directory of their running shell. The answer, of course, is that you can't, without sourcing it. People also ask the same question about Windows, and even DOS before it; there you actually could do it from a batch file, since CMD.EXE/COMMAND.COM effectively sources all batch files, it doesn't run them in a subprocess – but the same issue occurs if you write a program in some other language than batch, it runs in a subprocess and so can't modify CMD.EXE/COMMAND.COM's environment. (People resorted to some tricks though, like having a BATCH1.BAT call their program, and then afterwards call BATCH2.BAT, and their program modifies BATCH2.BAT on disk). Actually on DOS, there is a way to modify COMMAND.COM's environment – COMMAND.COM installs an undocumented interrupt, INT 0x2E, which you can use to send commands to COMMAND.COM to run. So you can actually modify COMMAND.COM's environment. (Only the root COMAMND.COM installs a handler for INT 0x2E, nested ones do not.) Of course, due to no memory protection, there are also nasty ways of doing this, like modifying COMMAND.COM's memory. (And changing COMMAND.COM directory isn't an issue, since under DOS, the current directory is system-wide, not per-process.) I was thinking, you could do something like "INT 0x2E" in a Unix shell. Create a Unix domain socket, and the shell listens for commands on it to execute. Put the path to the socket in an environment variable which is inherited by subprocesses, e.g. SHELL_CONTROL. Then, a subprocess can inspect and modify the shell's environment, working directory, functions, aliases, running jobs, etc, by reading/writing the Unix domain socket mentioned in SHELL_CONTROL.
- ahurmazda 6y agoOthers' experiences may vary but personally speaking I have to write a fair amount of shell scripts that run on a range of machines, networks etc. At best its a pita to change shell on these ephemeral boxes, worst case its out of my control. The lowest common denominator ends up being the good ol' bash (or sh)! Sure fish/oil is nice but quite a bit of mental gymnastics to keep them all straight in my head.
- throwawayboise 6y agoThis is why I use the default shell on whatever platform I'm working on. I want to know that my work does not first dependon on installing an alternate shell (often not possible, depending on the environment).
- chubot 6y agoThat's reasonable, but Oil can still be useful to you as a dev tool, since it implements a very large and sane subset of bash. Some details here: http://www.oilshell.org/why.html http://www.oilshell.org/why.html And something I just released is a better "set -x", which no other shell has: https://www.oilshell.org/release/0.8.7/doc/xtrace.html https://www.oilshell.org/release/0.8.7/doc/xtrace.html So you could debug your programs with Oil if bash tracing isn't enough (which it often isn't for me). Oil is also very easy to build and install -- all you need is a compiler, a shell, and make, and make will probably go away at some point.
- crb002 6y agoPerformance or correctness. Giving bash/zsh a performant hash-table would trivially empower them without boiling the ocean.
- dang 6y agoRelated from 3 months ago: https://news.ycombinator.com/item?id=24871762 https://news.ycombinator.com/item?id=24871762 1 year ago: https://news.ycombinator.com/item?id=22150603 https://news.ycombinator.com/item?id=22150603 2018: https://news.ycombinator.com/item?id=16276911 https://news.ycombinator.com/item?id=16276911
- m463 6y agoI would like to know other people's habits. for example, I always close browser windows and only keep a few tabs open at once, and then found out I was weird and many people keep huge amounts of tabs around. My personal habit is to use bash, and always write shell scripts with #!/bin/sh as the first line. Thing is - I've haven't tried other shells (since I was a student) because of "linux superstition". Same superstition that chooses filenames without spaces and prevents putting "." in your path. Thing is - I think maybe decoupling the user interface from the scripting language should be more of a thing. People don't have as much trouble switching out their terminal emulator (a way of taking up the slack). Maybe the way to a better UI while maintaining compatibility would be to choose a good "user interface" shell and maybe exporting SHELL=/bin/bash so scripts run?