I really want this to succeed¹, but I struggle to use it. How are people that are testing/using it coping without the normal niceties of their regular setup? I'm wondering if there are just some tricks I'm missing.
Off the top of my head, things I'm thinking of include:
* Just a minute ago realising that without zsh globs I have to remember find syntax, and then have to figure out how to sort the results(probably decorate
→sort(1) → undecorate). My laziness led me to just C-d and execute my task with zsh.
* No context sensitive completion; I don't realise how much I rely on this until it is gone. Using bash-completion gets some completion, but it is a big step backwards.
* No programmable input, you can fake some with ~/.inputrc hacks but only basic text support(no macros). (Edit to add: The guard name is "oil" not "osh", if you're looking to do this yourself.)
There is a document in the wiki², but it doesn't really cover much. I'd be interested in seeing the configs of people who are using it.
--
Should say I really like the idea of hijacking '#!/bin/sh' to inject osh, it feels like a really good way to round out testing of scripts you'd otherwise forget about. I wonder if a LD_PRELOAD'able solution that would work outside osh would be a good idea.
¹ Strong déjà vu on this comment, but if it is real it is because I truly like the goals set out for oil.
> without zsh globs I have to remember find syntax
My "solution" to this is using https://github.com/sharkdp/fd (even when in zsh and having glob support). I'm not sure if using a tool that's not present by default would be suitable for your use cases, but if you're considering alternate shells, I suspect you might be
I do use `fd` in simple cases as it is sooooo fast, but it has quite limited functionality compared to zsh's extended glob syntax¹. I must add that `fd` is one-billion times more readable when you're flipping back through your history or extracting a short script with `fc`.
1) I think you mean stuff like **/*.py from zsh, which bash now emulates with shopt -s globstar.
This has come up several times, and we should have it. But I'm actually not entirely sure how ** behaves -- if someone can write an exhaustive shell script that shows what it does (e.g. a bunch of mkdir and touch commands and output), we can copy it in our spec tests:
We can definitely use help with that, and it's relatively self-contained.
3) What exactly do you mean by "programmable input" ? We support GNU readline so everything there should work (maybe the ./configure detection didn't find it for you?)
---
But there is a bigger reason for the "struggle" -- the main focus of the project now is YSH, the language with data tYpes, influenced by pYthon, JavaScript, Lisp, etc.
The theory was/is that the language is not only important for the system level tasks, but also a good foundation for the UI, e.g. like Emacs is written in Emacs Lisp
So I think structured data (in the form of languages/protocols) in YSH is really the killer feature of Oils, that will hopefully bring many other people into the project, who can help with filling out the interactive features you mention, e.g. polishing completion.
As mentioned in this post, the biggest risk is that we don't have enough help. All the technical pieces are there now, and the risks are about project management, not the code.
I appreciate everyone who contributed while the codebase was undergoing this big transformation to native code -- this was kind of risky and the most unusual part of the project, but I think it paid off!
Instead of going with the strained datatYpes and pYthon reasoning, perhaps you could just say that YSH(and I call it y shell in my head) is WHY you are doing all of this in the first place. The end goal so to speak.
1) In the specific instance I hit when I wrote that comment I wanted a variant of `**/*(.Om)`, which gives me files sorted by mtime. I think I'd probably have ended up with a `find ... | xargs stat -c '%Y-%n' | sort -n | sed "s,^[0-9]\+-,,"` construct if I'd kept at it, but I'm sure there are some more reasonable ways I'm struggling to think of right now with my extended glob blinkers on.
2)
Yeah, I'd go the fish route if I had to do the work too ;) It is a huge step up from bash-completion, whilst still being easy to understand.
zsh's completion is unbelievably powerful, but also exceedingly complex once you move beyond basic file completion. Anything beyond even the most basic example tends to be littered with other zsh-isms too(said with the love of someone who submits such monstrosities to projects on a semi-regular basis).
[Edit: I just spotted a patch I submitted to bash-completion almost twenty years ago², I've been chasing this "perfect tooling" tail for a long time.]
3)
zsh allows fully customisable interactions by defining custom widgets within ZLE¹. Like many things with zsh they're super powerful once you work your way through the learning curve.
I have added a few `$if oil` blocks to my ~/.inputrc to workaround a few of the edit sequences I like to have available, but beyond the built-in readline functions and basic mappings readline feels quite limited to someone accustomed to zle. I'd just have to get used to some of the other functionality needing to be external tooling, and extracting things out of the shell would probably make a lot of sense anyway.
--
Also -- if you made it this far -- let me reiterate how much I appreciate the work you're doing. I've learnt heaps reading through both your posts in the blog and your comments here!
Off the top of my head, things I'm thinking of include:
* Just a minute ago realising that without zsh globs I have to remember find syntax, and then have to figure out how to sort the results(probably decorate →sort(1) → undecorate). My laziness led me to just C-d and execute my task with zsh.
* No context sensitive completion; I don't realise how much I rely on this until it is gone. Using bash-completion gets some completion, but it is a big step backwards.
* No programmable input, you can fake some with ~/.inputrc hacks but only basic text support(no macros). (Edit to add: The guard name is "oil" not "osh", if you're looking to do this yourself.)
There is a document in the wiki², but it doesn't really cover much. I'd be interested in seeing the configs of people who are using it.
--
Should say I really like the idea of hijacking '#!/bin/sh' to inject osh, it feels like a really good way to round out testing of scripts you'd otherwise forget about. I wonder if a LD_PRELOAD'able solution that would work outside osh would be a good idea.
¹ Strong déjà vu on this comment, but if it is real it is because I truly like the goals set out for oil.
² https://github.com/oilshell/oil/wiki/How-To-Test-OSH