1. 32
  1.  

  2. 8

    It’s been really fun watching this project develop, thanks for continuing to make time for blog posts!

    1. 2

      Thanks, glad you’re enjoying it! Now I really hope the project reaches its stated goal, at least the OSH portion :) Otherwise I will feel silly.

      By the way, I’m serious about what I wrote in these comments – if somehow Python + re2c + ASDL turns out to be a dead-end, then I think all the docs I provided will make it significantly easier for a few people to come along and replace bash in a more “normal” way.

      That is, rewrite the OSH algorithms and data structures in C++ or Rust. They can take advantage of the enormous and well-tested lexer, and the type definitions for the syntax tree. (I think C++ and Rust are the main languages that make sense.)

      I should write a meta- blog post linking to the everything. It’s probably 60-80% documented!

      https://www.reddit.com/r/ProgrammingLanguages/comments/anbjag/oil_success_with_the_interactive_shell/efscqu4/

      https://www.reddit.com/r/ProgrammingLanguages/comments/anbjag/oil_success_with_the_interactive_shell/eft5nkb/

    2. 5

      Heh, with Yori I started using it as my interactive shell about six weeks after starting the project. It helped that CMD wasn’t a terribly high bar to pass, and the initial versions just invoked it to execute things they couldn’t do natively. Dogfooding has been really useful at setting direction, because when you’re using something you’re free to dream about how to fix every annoyance you’ve ever had before, which is much more liberating and fun than trying to replicate some existing product. Half of the things I did in the last year I wasn’t expecting I’d ever do, but they make the environment a lot nicer to work with.

      1. 11

        Yeah in a way I’m embarrassed that it took so long to start using myself every day. But my reason for starting the project was mostly to have a solid foundation of Linux distros (motivated by experiences building containers from scratch, pre-Docker, and I still don’t like Docker.)

        Ironically even principled distributions like Nix have horrible shell scripts at the bottom. IIRC Nix’s are significantly worse than Debian’s or Alpine’s.

        And I also used shell a lot for reproducible data science pipelines, and maintaining distributed systems. So I didn’t care as much about the interactive shell at first.


        I should have emphasized the second reason for the delay in the post: running completion scripts is the hardest job OSH has to do in terms of weird language features. That is, many batch scripts attempt to use some sane subset of bash. But the completion scripts basically go hog wild and use all the nooks and crannies (especially dynamic scope, eval, dynamic assignment, extended globs, all manner of quoting and dequoting features).

        So basically you need to implement a very complete shell interpreter to run bash completion scripts. The code is really a lot worse than I expected, and that’s coming from someone who has stared at way too many shell scripts :) I did delete a whole bunch of code, without losing functionality, which I’ll describe in subsequent posts.

        1. 5

          Ironically even principled distributions like Nix have horrible shell scripts at the bottom. IIRC Nix’s are significantly worse than Debian’s or Alpine’s.

          We certainly do have some gnarly scripts in there. This would terrify me, if it wasn’t executed within the confines of Nix. I find a lot of solace in:

          • how well the available inputs, and possible outputs are very tightly restricted
          • the scripts are always able to be rerun as many times as you want without special attention in how to write the scripts

          In other words, before the script runs and after the script runs, it is as if it wasn’t even bash at all.

          1. 2

            Thanks for the info – that does make sense.

            IMO the shell is a natural way for controlling the environment of other programs like that (whether they are shell scripts, or programs in C or Python)

            I was using a small C program called linux-user-chroot to build distro packages in a controlled environment. These days it looks like systemd-nspawn fills that role. I hope Oil can provide some syntactic sugar for a container definition, which basically evaluates to a bunch of flags to such a wrapper program.

      2. 1

        I’ve been looking forward to trying to use oilshell as my daily driver for many months now. If you’re giving it a shot, I’ll do the same later this week.

        1. 2

          Great! Here’s some more info about testing:

          https://github.com/oilshell/oil/issues/161

          One script I stumbled across but didn’t get a chance to test is nix-env.sh. I was trying to build a C++ project that used Nix.

          If anyone happens to be a Nix user, or if you’re a user of some unique distro like Void Linux, there are bound to be many weird and wonderful shell scripts found there :)