shopt parse_equals should only be on in config mode

[andychu]

• Oil mode should use const.
• config mode can be "cows" or "hay"

[andychu]

A user brought this same issue up here. So I agree we need to address this

https://oilshell.zulipchat.com/#narrow/stream/121540-oil-discuss/topic/Require.20the.20.60const.60.20keyword

[andychu]

Current behavior

bin/osh

a=42
const a = 42
a = 42  # not what you think: runs the command a

bin/oil

a=42  # disallowed for compatibility
const a = 42 

a = 42  # equivalent to `const a = 42` right now

Proposal

• bin/oil can be identical to bin/osh in this regard: a = 42 is NOT special
• LATER: bin/oven is for configuration, and has shopt -s parse_equals, which allows a = 42 as an alias for const

So does that mean we need shopt -s oven:all or something?

Does it enforce some kind of sandboxing? I think it can change the "first word lookup" #453

Maybe command ls is REQUIRED in this case

[andychu]

Another Idea: Only allow it within blocks ? #631

So it's disallowed at the top level and within procs.

But we could silently turn the option on for

server www.example.com { 
  port = 80
}

However then it's also on in

shopt --unset errexit {
  ls /
  ls / bin
  x = 42
}

That's perhaps confusing

---

I wonder if we can do

shopt --set parse_equals {
  server www.example.com { 
    port = 80
  }
}

Is that awkward?

[andychu]

Another issue: const has static checks within proc.

So maybe we should

• turn off parse_equals in bin/oil. Save it for bin/oven and some kind of eval --config (myfile) (eval builtin can take a block #1025 )
• and also remove the static check. So you can do:

proc myrules(name) {

  rule "$name-python" {
     kind = 'python'
  }

  rule "$name-cc" {
     kind = 'cc'
  }

}

The kind variable should not conflict! The proc can be used for parameterization, like

myrules foo
myrules bar

[andychu]

Released http://www.oilshell.org/blog/2022/05/release-0.10.0.html