Related from 3 months ago: https://news.ycombinator.com/item?id=24871762
1 year ago: https://news.ycombinator.com/item?id=22150603
Why Create a New Unix Shell?
31–40 of 63 posts
Re: Why Create a New Unix Shell?
#32Sometimes 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.
Yeah 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
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 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.
Re: Why Create a New Unix Shell?
#33Others' 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.
This 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).
Re: Why Create a New Unix Shell?
#34It'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 t…
How does fish compare to zsh? I just switched from bash to zsh and am loving it.
Fish’s strength is in having good defaults that makes it work well out of the box. Fish’s downside is not being POSIX compatible [1] though its creators would argue they deliberately avoided POSIX weaknesses.
If you already have Zsh configured well then Fish probably wouldn’t offer a huge advantage.
[1]: https://en.wikipedia.org/wiki/Fish_(Unix_shell)#Bash/fish_tr...
Re: Why Create a New Unix Shell?
#35It'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 t…
Interesting, it seems a 3x productivity boost to all programmers and admins would be a no brainer for the industry.
If all programmers and admins had the same needs then that would be a logical conclusion. But we don't, so I'll stick to ksh.
Re: Why Create a New Unix Shell?
#36It'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 t…
I am a huge fan of fish. Oil shell seems kind of different in aim from fish. Fish is trying primarily to be a great interactive shell and have code which is easy to understand but not necessarily compact of efficient to write. But for me it doesn’t matter. For longer things I use Julia or Go anyway.
Re: Why Create a New Unix Shell?
#37It'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 t…
It always surprises me that people get so much productivity gain out of their editors, shells and keyboards and such. I write maybe a few dozen lines of code on a good day.
(Fish doesn't make me 3x more productive, but...) I think a good analogy would be having sharp tools. If you don't have to exert yourself to do simple things, then menial tasks use less mental energy which you can save for your actual work.
Fish manages to pull this off without _any_ configuration burden (I use it completely stock), which is exciting because usually to benefit from shortcuts or macros or other "productivity hacks" you have to become a power user.
Re: Why Create a New Unix Shell?
#38It'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 t…
I 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.
I 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?
Re: Why Create a New Unix Shell?
#39It'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 t…
It always surprises me that people get so much productivity gain out of their editors, shells and keyboards and such. I write maybe a few dozen lines of code on a good day.
Well. We all do different kinds of work. I'm a scientist, i spend all day looking at and parsing data in a zillion formats. Not to mention writing papers in latex. My productivity directly depends on my ability to ingest and make sense of text files and code and every day is different. A more efficient shell... or more importantly a shell that frees up brain space for other tasks... makes a huge difference.
I often work with colleagues who ask how j get results so fast. They're very surprised when I say "remote emacs and a solid foundation with shell workflows".
When everything you work with is a text file, getting efficient with the shell just makes sense. Ask a carpenter about their tools and organization and you'll get a similar response.
Re: Why Create a New Unix Shell?
#40Greetings! 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…
(author here) Thanks for the comment! I do think you hit on something interesting, and it partly explains why the project is so big :) To me, shell and Python/JS feel kind of similar, and that was sort of the thesis at the start of the project. But if you just incrementally add features to Bourne shell, you basically get Korn shell, which is where bash got all the "bashisms" that people don't like. This paper was sur…
>"It's a lot more work to make something like Python or JS! Garbage collection is one issue; shells don't have it because they don't have recursive compound data structures or true functions."
An excellent point!
>"Yes pipelines are a big deal and the runtime is solid now so they can be enhanced."
Maybe synchronous (aka, guaranteed linear) and asynchronous (no guarantees) are better ways to look at it...
For example, a simple shell command like 'echo' could be run either synchronously or asynchronously, but if we're assigning the result of it to some variable, it makes sense to run it synchronously, to get that result into the variable before proceeding to the next line of the program...
But, if we're running a disk defragmenting tool, or other process that we don't know when it's going to complete, then it makes sense to run it asynchronously.
Shell commands that are chained together via pipelines may run asynchronously, but the shell may wait for everything to complete to scoop up the output; so you've sort of have the entire line that was sent to the shell running synchronously (if you're assigning the result to a variable), even though parts of it are running asynchronously (with respect to one another)...
And of course, via ampersand, you could have the entire line run asynchronous to your program...
See, I'd almost say that one of the problems is that shell scripting languages almost have no knowledge (and correct me if I am wrong, I might be!) about the pipes they create inside of commands -- an ideal shell language would be able to know about these and hook these for various purposes, and specify what would be ran synchronously and asynchronously...
Or, another weird corner case -- what if you have a shell script that launches other shell scripts asynchronously (in subshells) and they launch other shell scripts also asynchronously -- in deeper level subshells?
How would your language/shell track/handle that case?
How do you communicate/track/determine when/where to assign results to things?
It's sort of like the language/shell -- must be able to :
A) Explicitly say what is asynchronous and what is synchronous...
B) For asynchronous things, be able to communicate with them, track their status, get results from them when they complete, etc., etc.
Now, of all of the programming languages in existence, I think Go is a good candidate for understanding synchronous vs. non-synchronous -- but you don't exactly get an "easily scriptable" beginner-friendly shell-scripting language with Go...
Python seems to be the right balance between "ease of use" and "gives you control".
So I'm agreed with all that you've said about Python, and your use of Python in code...