Why Sponsor Oils? | blog | oilshell.org

Oil's Stricter Semantics Solve Real Problems

I keep a text file full of future topics for this blog. Unfortunately, it's getting longer and longer because I haven't written much lately. To solve this problem, I'm trying a new strategy for the next two posts:

1. Spill my ideas onto #oil-discuss on Zulip.
2. Link to those informal comments here, with summaries.

Somehow, this makes the words flow more easily. I have two posts planned:

1. This post shows two problems "in the wild" that are answered by Oil's stricter semantics.
2. The next post explains the design of the Oil language.

I also hope this style will get more people to comment on Zulip. Implementing the Oil language requires resolving many design decisions, and I go back and forth about in my head. Explaining the tradeoffs to somebody else often helps.

(Zulip requires you to login, but you don't have to create a new password. You can use your Github or Google account.)

shopt -s strict-control-flow (thread)

Last week, I encountered this tweet about a shell corner case:

How has it taken me over 20 years to find out that you can't "break" from a shell script case statement? Do I even know anything at all? How many shell scripts out there are silently broken (bash/zsh warn about it, ash derivatives and ksh93 do not)? Happy Monday!

— Jonathan Perkin (@jperkin) August 5, 2019

My response: Oil has an execution option shopt -s strict-control-flow that makes such scripts fail nosily. I explain this in more detail in this Zulip thread.

Moreoever, OSH lets you turn on all strict options with one statement:

shopt -s all:strict

Scripts that need to be portable to other shells can use:

shopt -s all:strict 2>/dev/null || true

This is documented in the new OSH manual.

Stricter Array Semantics That Are Still Bash-Compatible (thread)

In the recent announcement of OSH 0.7.pre1, I mentioned that I overhauled array and associative array semantics.

David on the help-bash@ mailing list was confused by bash's complex and seemingly buggy rules:

[Help-bash] Expansions in associative array subscripts

My answer: Rather than trying to memorize what bash does, use OSH and see if it works.

OSH implements a sane subset of bash, so if your script works under OSH, it should also work under bash. This Zulip thread has more details.

Conclusion

This post mentioned two places where OSH is stricter, but there are many more. For example, I mentioned shopt -s strict-argv in February's announcement OSH 0.6.pre15 Does Not Crave Chaos and Destruction.

The shell language is full of surprises, but OSH aims to be less surprising.

The next post will be interesting to long-time readers. It finally gives details on the Oil language! If you're impatient, feel free to review the threads already on #oil-discuss and ask me questions.

Appendix: Awk vs. R

I also had a response to this (sarcastic) tweet, but it's about future work, unlike the last two threads.

Tidy R makes learning HARDER for non-coders. Consider an example.

mtcars %>%
group_by(cyl) %>%
summarise(mpg.mean = mean(mpg))

but in awk it's

awk -F, 'NR>1{mpg[$3]+=$2;len[$3]++}BEGIN{print "cyl\tmpg.mean"}END{for (i in mpg) print i, mpg[i]/len[i]}' OFS='\t' mtcars.txt

— Jonathan Carroll (@carroll_jono) August 8, 2019

I wrote about #awk a few years ago, but unfortunately haven't gotten to that work. I also wrote about the #r-language recently.

If you want to help me prioritize this work, grab an issue here:

• #help-wanted
• #good-first-issue

I'm constantly updating those issue labels. Feel free to ask questions on #oil-dev!