7 ms·

A Tour of the Oil Language

159 points by dmart 5y ago

otoburb 5y ago
Note that the Oil shell is also bash-compatible [1]. This project (new shell intepreter and shell language) is not lacking in ambition, that's for sure. Not a heavy shell user myself but will be trying oilshell on some sandbox instances in the near future. [1] https://www.oilshell.org/cross-ref.html?tag=osh-language#osh-language https://www.oilshell.org/cross-ref.html?tag=osh-language#osh...
- nerdponx 5y ago
  I would be especially interested in a comparison with Zsh, which is also very much a "better Bash".
  - zamadatix 5y ago
    I know you're looking for a comparison of the "new" syntax of zsh and oil but I think it's worth noting the biggest difference is probably going to be Zsh is an extended sh shell with a bash (well ksh) emulation mode capability whereas oil is a shell where the language is a superset of bash syntax. Zsh tries to be similar to bash but it has no problem not aiming to be 100% bash in normal mode. Osh wants you to be able to replace #!/bin/bash with #!/bin/osh and run your script without setting the mode to something special. Then when you're ready to extend it you can write either bash or osh without toggling emulation mode or worrying about which syntax or behavior differences you'll run into not being in emulation mode.
kungfufrog 5y ago
I see Oil and oilshell posted here somewhat regularly. Is anyone using it and can relay their experiences? Is it ready to be used as a daily driver?
- chubot 5y ago
  (author here) I'd say it's better now for people who feel comfortable contributing (or just want to test it out and send feedback). Some parts of the project are mature (OSH language) but others are less mature (Oil language). Long reply in this thread that gives details: https://news.ycombinator.com/item?id=28547185 https://news.ycombinator.com/item?id=28547185
  - pxc 5y ago
    > Some parts of the project are mature (OSH language) but others are less mature (Oil language). In a way you've placed the opposite of the bet of most of your 'colleagues' in the field of pioneering new shells. To me, the other way around is more tempting because novelty is fun for you, the developer, and innovation here is the main attraction. Not to mention that lots of people might've burned out in the 'Osh phase', as it were. I hope that taking the long way around pays off for you, because I know it's been arduous! One advantage it might give Oil, given the attention you seem to pay to other projects in the same space, is that with the Oil language you can now also draw from other next-gen shell languages which have had opportunities to grow small communities and undergo revision in light of their use in the tome job were focusing on Osh. I really like some of those other projects, so of course I hope there's a place for them going forward as well (maybe as my own login shell, even!). But I'd love to see Osh earn an installed-by-default place on some major operating systems/distributions some day, and in that way open the door to widely distributed shell scripts in a more modern shell language in Oil. I look forward to really digging in to this new doc and writing some toy scripts. :)
    - chubot 5y ago
      Yes Oil is the only shell that's a graceful upgrade from POSIX sh and bash :) If it were done the other way around, that would have been impossible. As long as the implementation makes enough progress, I have no doubt it will pay off. I think this is "obvious" if you look at the history of technology, but I guess I have to publish this blog post draft called Don't Break X (Why Oil is a Long-Winded Project) - Don't Break Windows apps. https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... - Don't break JavaScript and the web. From HOPL IV. https://hopl4.sigplan.org/details/hopl-4-papers/10/JavaScript-The-First-20-Years https://hopl4.sigplan.org/details/hopl-4-papers/10/JavaScrip... . Wirfs-Brock and Brendan Eich discuss whether the JS standards committee did the WRONG THING for 10 years. - Don't break the Linux kernel interface. https://unix.stackexchange.com/questions/235335/why-is-there-a-linux-kernel-policy-to-never-break-user-space https://unix.stackexchange.com/questions/235335/why-is-there... (there is probably a better link for this one; there's one with a lot of profanity and insults from Linus Torvalds that I'm not sure I want to use) Similarly, Oil doesn't break shell, and we definitely need a shell like that. Other alternative, incompatible shells are valuable, but there's absolutely no question that there needs to be a compatible upgrade. Just like C++ has made huge leaps while Rust was being developed. (Crucially, Oil is different than C++ as it actually deprecates some legacy with parsing and runtime options.) ------ There's a distortion where all the people interested in Oil now are by definition interested in new stuff. That is, in reality 95% of people are more interested in OSH than Oil, because they don't care about new languages and they just want things to work. But the people I hear from are the 5% who care about new stuff. (which is good, but it's not representative). A similar distortion is that there are probably 10x to 50x more people working on C++ than Rust (e.g. at least 10,000 people at Google alone; I'd surprised if more than 100 or 1000 do any Rust for work. Also consider older companies like Oracle.). But if you were to go by this corner of the Internet, you might think Rust is the more popular language. In reality C++ is the far bigger and more capable ecosystem, if you care about robotics, embedded, AI, GPU, native desktop apps, information retrieval and data structures, etc.
munk-a 5y ago
For google-ability did you really need to occupy Oil Shell when Shell Oil is very much already a thing?
- notriddle 5y ago
  Seems like search engines are smart enough to distinguish them. https://duckduckgo.com/?q=oil+shell https://duckduckgo.com/?q=oil+shell
  - bscphil 5y ago
    I can't tell if you're joking, all of the results except the top one show "Shell oil" results for me. Not hard to imagine that this impacts searchability if you're looking for something specific.
    - ironmagma 5y ago
      Heck, sometimes I search for oil shell when I’m looking for shell oil. I wouldn’t even want a search engine to know about order.
    - notriddle 5y ago
      Yes, but the first result for this one is oil shell, whereas if I search the other way around it isn’t even on page 1.
- booleandilemma 5y ago
  I wonder if people will end up googling it as oillang (or even oilang), similar to what happened with golang.
  - ironmagma 5y ago
    Wouldn’t it be oillang?
  - leoc 5y ago
    Let's hope so, because 'oil language' is also going to be problematic: https://www.google.com/search?q=oil+language https://www.google.com/search?q=oil+language https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl . I came here half-expecting an article about medieval French.
bscphil 5y ago
I'm interested in and excited about oil, but three things have stopped me every time I've tried to give it a go. 1. The complete and utter lack of useful documentation. There's not even a link to any docs from the main page of the shell's site. You have to get to the docs from the release page, [1] but I had to find this out by Googling. Given the number of blog-post-like entries in the docs, seems like it would have been less effort and more effective just to write standardized and complete documentation from the start. Just as an example: can anyone tell me what built-ins Oil has, how to use them, and where they are documented? I'll give you a hint. I found out from one of the blog posts that oil has "min" and "max" commands. The following is valid Oil code: const x = min(1, 2) But what other commands does Oil have, and how do I use them? I have no idea. Some of the doc pages 404 so maybe they're supposed to be there. I have found some pages listing built-ins which are mostly undocumented, but none of them list min or max, so I know they're not complete. 2. It's still pretty buggy and lots of features are missing. Development has seemingly moved slowly over the last several years. If it ever did get to the point where I could make it a daily driver then I'd be willing to track down and report bugs, of course. 3. I'm a little concerned by how much emphasis is put on POSIX / Bash compatibility. Unless there's going to be a way to fully disable what Oil considers "legacy" language support in a script, then that is going to leave a ton of footguns for people who want to write "modern" Oil code. It's not clear to me whether that's the plan or not (I haven't read every one of the blog posts), but it seems like a mistake to me to sacrifice possible syntax improvements on the altar of compatibility. To be clear, I realize this is basically someone's solo project, and I am impressed by how far it's been taken, just clarifying why I don't think it's ready for general use yet. [1] https://www.oilshell.org/release/latest/doc/ https://www.oilshell.org/release/latest/doc/
- brundolf 5y ago
  Is its goal to be "a shell language that's decent to program in"?
  - chubot 5y ago
    Yes, the home page says that it's for Python and JavaScript users that avoid shell: https://www.oilshell.org/ https://www.oilshell.org/ Also see The Simplest Explanation of Oil https://www.oilshell.org/blog/2020/01/simplest-explanation.html https://www.oilshell.org/blog/2020/01/simplest-explanation.h... In addition to being "decent" / familiar / learnable, it's also more powerful, as bash is showing its age and lacking features many users would like (recursive data structures, JSON, etc.)
frazbin 5y ago
Super duper excited about this and have been for the past five years. Awesome to see things coming together.. good things take time! This guy is singlehandledly trying to elevate shell, revealing its secret beauty and immense power. My favorite thing is his obsession with bash backwards compatibility-- it has led him to get super deep into the bash parser. Unrelated but useful by the same person: Bernstein chaining of ssh and su: https://www.oilshell.org/blog/2017/01/31.html https://www.oilshell.org/blog/2017/01/31.html
omgitsabird 5y ago
var person = 'alice' echo "hi $person, $(echo bye)" # => hi bob, bye This is a strange language that turns alice strings into bob strings (quoted from article)
- thewakalix 5y ago
  It’s the trans agenda!
- Stratoscope 5y ago
  Is it possible that this is a typo in the example?
- chubot 5y ago
  Thanks to Paul for fixing this just now :) https://github.com/oilshell/oil/pull/988 https://github.com/oilshell/oil/pull/988
jimmyed 5y ago
The tech aside, this is horrendous naming! The oil language puts in my mind the image of "oily greasy hair", commonly associated with someone sly and contriving.
- deleted 5y ago
  [deleted]
- goto11 5y ago
  I take it you are not a fan of Scheme and Racket?
  - jimmyed 5y ago
    Haha, and python too? But no, those all I don't have a problem with. With Oil, maybe Harry Potter (Snape) has something to do with it.
- greatpatton 5y ago
  As HN is covering so many different subjects, I thought that it was related to these oil languages :) https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl
- chubot 5y ago
  This might help: http://www.oilshell.org/blog/2019/06/17.html#why-is-the-project-named-oil http://www.oilshell.org/blog/2019/06/17.html#why-is-the-proj...
fmakunbound 5y ago
Will oilshell have job control? I couldn’t quite tell. A lot of small shell projects seem to neglect it.
- chubot 5y ago
  It has basic job control, e.g. Ctrl-Z and fg work. Full job control will probably have to wait for a contributor (I use tmux instead of job control, and job control is very hairy). If the rest of Oil becomes popular I'm sure that will happen.
chartpath 5y ago
Oups, title wasn't an English translation of langues d'oïl!
teleforce 5y ago
The progress of Oil Shell is looking really good and hopefully it can reach the stable 1.0 version soon. I've been following Oil Shell for several years now by reading the blog articles. The fact that it has managed to adopt and adapt some of the best features of other popular (mostly) dynamic programming languages into a cohesive scripting language and at the same time being backward compatible with Bash is amazing. Recently there was an HN post and discussions on Linux Router unified command written entirely in Bash [1]. When reading the discussions, the first thing that come to my mind was that it will great if this can be somehow re-written in Oil Shell. But why stop there? What I'd like eventually is a seamless wrapper that maps the native related Linux tools in Oil Shell that can provide similar Cisco IOS like commands, configs and interfaces. It can then fashion the Linux kernel into a glorious network OS without writing extensive separate native networking system services as Quagga, LiSA or Cisco NX-OS. Heck the entire NX-OS can probably be cloned with Oil Shell on top of vanilla Linux kernel and eBPF. Before someone pointed out that what so special about Cisco IOS, it is by far the most popular network OS conventions to the networking professionals, and most of them are very familiar with the configs and commands. Due to the increasingly popularity of containers and Kubernetes, robust Linux networking configuration and automation tools will be at the center of this latest trend. Always remember that Linux once started life as a poor's man clone to the very popular UNIX System V itself. [1]https://news.ycombinator.com/item?id=28512768 https://news.ycombinator.com/item?id=28512768
- chubot 5y ago
  Hm interesting, yup that is exactly the kind of program that might get "too big" for bash, and running it under Oil is a good idea. You can then incrementally upgrade to Oil -- no big bang rewrite required! Other huge shell programs here: https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Programs-in-the-World https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Progr... And yes Oil should be suitable for writing command line tools (although it needs a modern flag parser, not the ancient getopt builtin that shell has.) Often the right thing to do is to write a tiny bit of C to interface with the kernel, and then call that from shell. That is very useful for Linus container syscalls, and I can also see it being useful for low level networking. I would love to see a project in that direction :) I'm writing some posts now about project plans! Thanks for the support.

159 points by dmart 5y ago

Note that the Oil shell is also bash-compatible [1]. This project (new shell intepreter and shell language) is not lacking in ambition, that's for sure. Not a heavy shell user myself but will be trying oilshell on some sandbox instances in the near future. [1] https://www.oilshell.org/cross-ref.html?tag=osh-language#osh-language https://www.oilshell.org/cross-ref.html?tag=osh-language#osh...

nerdponx 5y ago
I would be especially interested in a comparison with Zsh, which is also very much a "better Bash".
- zamadatix 5y ago
  I know you're looking for a comparison of the "new" syntax of zsh and oil but I think it's worth noting the biggest difference is probably going to be Zsh is an extended sh shell with a bash (well ksh) emulation mode capability whereas oil is a shell where the language is a superset of bash syntax. Zsh tries to be similar to bash but it has no problem not aiming to be 100% bash in normal mode. Osh wants you to be able to replace #!/bin/bash with #!/bin/osh and run your script without setting the mode to something special. Then when you're ready to extend it you can write either bash or osh without toggling emulation mode or worrying about which syntax or behavior differences you'll run into not being in emulation mode.

kungfufrog 5y ago

I see Oil and oilshell posted here somewhat regularly. Is anyone using it and can relay their experiences? Is it ready to be used as a daily driver?

chubot 5y ago
(author here) I'd say it's better now for people who feel comfortable contributing (or just want to test it out and send feedback). Some parts of the project are mature (OSH language) but others are less mature (Oil language). Long reply in this thread that gives details: https://news.ycombinator.com/item?id=28547185 https://news.ycombinator.com/item?id=28547185
- pxc 5y ago
  > Some parts of the project are mature (OSH language) but others are less mature (Oil language). In a way you've placed the opposite of the bet of most of your 'colleagues' in the field of pioneering new shells. To me, the other way around is more tempting because novelty is fun for you, the developer, and innovation here is the main attraction. Not to mention that lots of people might've burned out in the 'Osh phase', as it were. I hope that taking the long way around pays off for you, because I know it's been arduous! One advantage it might give Oil, given the attention you seem to pay to other projects in the same space, is that with the Oil language you can now also draw from other next-gen shell languages which have had opportunities to grow small communities and undergo revision in light of their use in the tome job were focusing on Osh. I really like some of those other projects, so of course I hope there's a place for them going forward as well (maybe as my own login shell, even!). But I'd love to see Osh earn an installed-by-default place on some major operating systems/distributions some day, and in that way open the door to widely distributed shell scripts in a more modern shell language in Oil. I look forward to really digging in to this new doc and writing some toy scripts. :)
  - chubot 5y ago
    Yes Oil is the only shell that's a graceful upgrade from POSIX sh and bash :) If it were done the other way around, that would have been impossible. As long as the implementation makes enough progress, I have no doubt it will pay off. I think this is "obvious" if you look at the history of technology, but I guess I have to publish this blog post draft called Don't Break X (Why Oil is a Long-Winded Project) - Don't Break Windows apps. https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... - Don't break JavaScript and the web. From HOPL IV. https://hopl4.sigplan.org/details/hopl-4-papers/10/JavaScript-The-First-20-Years https://hopl4.sigplan.org/details/hopl-4-papers/10/JavaScrip... . Wirfs-Brock and Brendan Eich discuss whether the JS standards committee did the WRONG THING for 10 years. - Don't break the Linux kernel interface. https://unix.stackexchange.com/questions/235335/why-is-there-a-linux-kernel-policy-to-never-break-user-space https://unix.stackexchange.com/questions/235335/why-is-there... (there is probably a better link for this one; there's one with a lot of profanity and insults from Linus Torvalds that I'm not sure I want to use) Similarly, Oil doesn't break shell, and we definitely need a shell like that. Other alternative, incompatible shells are valuable, but there's absolutely no question that there needs to be a compatible upgrade. Just like C++ has made huge leaps while Rust was being developed. (Crucially, Oil is different than C++ as it actually deprecates some legacy with parsing and runtime options.) ------ There's a distortion where all the people interested in Oil now are by definition interested in new stuff. That is, in reality 95% of people are more interested in OSH than Oil, because they don't care about new languages and they just want things to work. But the people I hear from are the 5% who care about new stuff. (which is good, but it's not representative). A similar distortion is that there are probably 10x to 50x more people working on C++ than Rust (e.g. at least 10,000 people at Google alone; I'd surprised if more than 100 or 1000 do any Rust for work. Also consider older companies like Oracle.). But if you were to go by this corner of the Internet, you might think Rust is the more popular language. In reality C++ is the far bigger and more capable ecosystem, if you care about robotics, embedded, AI, GPU, native desktop apps, information retrieval and data structures, etc.

munk-a 5y ago

For google-ability did you really need to occupy Oil Shell when Shell Oil is very much already a thing?

notriddle 5y ago
Seems like search engines are smart enough to distinguish them. https://duckduckgo.com/?q=oil+shell https://duckduckgo.com/?q=oil+shell
- bscphil 5y ago
  I can't tell if you're joking, all of the results except the top one show "Shell oil" results for me. Not hard to imagine that this impacts searchability if you're looking for something specific.
  - ironmagma 5y ago
    Heck, sometimes I search for oil shell when I’m looking for shell oil. I wouldn’t even want a search engine to know about order.
  - notriddle 5y ago
    Yes, but the first result for this one is oil shell, whereas if I search the other way around it isn’t even on page 1.
booleandilemma 5y ago
I wonder if people will end up googling it as oillang (or even oilang), similar to what happened with golang.
- ironmagma 5y ago
  Wouldn’t it be oillang?
- leoc 5y ago
  Let's hope so, because 'oil language' is also going to be problematic: https://www.google.com/search?q=oil+language https://www.google.com/search?q=oil+language https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl . I came here half-expecting an article about medieval French.

bscphil 5y ago

I'm interested in and excited about oil, but three things have stopped me every time I've tried to give it a go. 1. The complete and utter lack of useful documentation. There's not even a link to any docs from the main page of the shell's site. You have to get to the docs from the release page, [1] but I had to find this out by Googling. Given the number of blog-post-like entries in the docs, seems like it would have been less effort and more effective just to write standardized and complete documentation from the start. Just as an example: can anyone tell me what built-ins Oil has, how to use them, and where they are documented? I'll give you a hint. I found out from one of the blog posts that oil has "min" and "max" commands. The following is valid Oil code: const x = min(1, 2) But what other commands does Oil have, and how do I use them? I have no idea. Some of the doc pages 404 so maybe they're supposed to be there. I have found some pages listing built-ins which are mostly undocumented, but none of them list min or max, so I know they're not complete. 2. It's still pretty buggy and lots of features are missing. Development has seemingly moved slowly over the last several years. If it ever did get to the point where I could make it a daily driver then I'd be willing to track down and report bugs, of course. 3. I'm a little concerned by how much emphasis is put on POSIX / Bash compatibility. Unless there's going to be a way to fully disable what Oil considers "legacy" language support in a script, then that is going to leave a ton of footguns for people who want to write "modern" Oil code. It's not clear to me whether that's the plan or not (I haven't read every one of the blog posts), but it seems like a mistake to me to sacrifice possible syntax improvements on the altar of compatibility. To be clear, I realize this is basically someone's solo project, and I am impressed by how far it's been taken, just clarifying why I don't think it's ready for general use yet. [1] https://www.oilshell.org/release/latest/doc/ https://www.oilshell.org/release/latest/doc/

brundolf 5y ago
Is its goal to be "a shell language that's decent to program in"?
- chubot 5y ago
  Yes, the home page says that it's for Python and JavaScript users that avoid shell: https://www.oilshell.org/ https://www.oilshell.org/ Also see The Simplest Explanation of Oil https://www.oilshell.org/blog/2020/01/simplest-explanation.html https://www.oilshell.org/blog/2020/01/simplest-explanation.h... In addition to being "decent" / familiar / learnable, it's also more powerful, as bash is showing its age and lacking features many users would like (recursive data structures, JSON, etc.)

frazbin 5y ago

Super duper excited about this and have been for the past five years. Awesome to see things coming together.. good things take time! This guy is singlehandledly trying to elevate shell, revealing its secret beauty and immense power. My favorite thing is his obsession with bash backwards compatibility-- it has led him to get super deep into the bash parser. Unrelated but useful by the same person: Bernstein chaining of ssh and su: https://www.oilshell.org/blog/2017/01/31.html https://www.oilshell.org/blog/2017/01/31.html

omgitsabird 5y ago

var person = 'alice' echo "hi $person, $(echo bye)" # => hi bob, bye This is a strange language that turns alice strings into bob strings (quoted from article)

thewakalix 5y ago
It’s the trans agenda!
Stratoscope 5y ago
Is it possible that this is a typo in the example?
chubot 5y ago
Thanks to Paul for fixing this just now :) https://github.com/oilshell/oil/pull/988 https://github.com/oilshell/oil/pull/988

jimmyed 5y ago

The tech aside, this is horrendous naming! The oil language puts in my mind the image of "oily greasy hair", commonly associated with someone sly and contriving.

deleted 5y ago
[deleted]
goto11 5y ago
I take it you are not a fan of Scheme and Racket?
- jimmyed 5y ago
  Haha, and python too? But no, those all I don't have a problem with. With Oil, maybe Harry Potter (Snape) has something to do with it.
greatpatton 5y ago
As HN is covering so many different subjects, I thought that it was related to these oil languages :) https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl https://en.wikipedia.org/wiki/Langues_d%27o%C3%AFl
chubot 5y ago
This might help: http://www.oilshell.org/blog/2019/06/17.html#why-is-the-project-named-oil http://www.oilshell.org/blog/2019/06/17.html#why-is-the-proj...

fmakunbound 5y ago

Will oilshell have job control? I couldn’t quite tell. A lot of small shell projects seem to neglect it.

chubot 5y ago
It has basic job control, e.g. Ctrl-Z and fg work. Full job control will probably have to wait for a contributor (I use tmux instead of job control, and job control is very hairy). If the rest of Oil becomes popular I'm sure that will happen.

chartpath 5y ago

Oups, title wasn't an English translation of langues d'oïl!

teleforce 5y ago

The progress of Oil Shell is looking really good and hopefully it can reach the stable 1.0 version soon. I've been following Oil Shell for several years now by reading the blog articles. The fact that it has managed to adopt and adapt some of the best features of other popular (mostly) dynamic programming languages into a cohesive scripting language and at the same time being backward compatible with Bash is amazing. Recently there was an HN post and discussions on Linux Router unified command written entirely in Bash [1]. When reading the discussions, the first thing that come to my mind was that it will great if this can be somehow re-written in Oil Shell. But why stop there? What I'd like eventually is a seamless wrapper that maps the native related Linux tools in Oil Shell that can provide similar Cisco IOS like commands, configs and interfaces. It can then fashion the Linux kernel into a glorious network OS without writing extensive separate native networking system services as Quagga, LiSA or Cisco NX-OS. Heck the entire NX-OS can probably be cloned with Oil Shell on top of vanilla Linux kernel and eBPF. Before someone pointed out that what so special about Cisco IOS, it is by far the most popular network OS conventions to the networking professionals, and most of them are very familiar with the configs and commands. Due to the increasingly popularity of containers and Kubernetes, robust Linux networking configuration and automation tools will be at the center of this latest trend. Always remember that Linux once started life as a poor's man clone to the very popular UNIX System V itself. [1]https://news.ycombinator.com/item?id=28512768 https://news.ycombinator.com/item?id=28512768

chubot 5y ago
Hm interesting, yup that is exactly the kind of program that might get "too big" for bash, and running it under Oil is a good idea. You can then incrementally upgrade to Oil -- no big bang rewrite required! Other huge shell programs here: https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Programs-in-the-World https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Progr... And yes Oil should be suitable for writing command line tools (although it needs a modern flag parser, not the ancient getopt builtin that shell has.) Often the right thing to do is to write a tiny bit of C to interface with the kernel, and then call that from shell. That is very useful for Linus container syscalls, and I can also see it being useful for low level networking. I would love to see a project in that direction :) I'm writing some posts now about project plans! Thanks for the support.