parse error after integer overflow

[ale5000-git]

Oils 0.23.0 installed with brew install --quiet oils-for-unix.

Hi, there is something in my script that is causing Oils to go crazy and throw random errors. This is the script: https://github.com/micro5k/microg-unofficial-installer/blob/main/tools/bits-info.sh

The scripts works perfectly in all other shells (even rare ones) and it also works perfectly in Oils 0.6.pre11 ( it is here: https://tio.run/#osh ).

Example of errors in Oils 0.23.0:

  ps!!!
  ^~
bits-info.sh:1401: 'ps!!!' not found (OILS-ERR-100)
    fi
    ^~
bits-info.sh:1403: Unexpected word when parsing command

[andychu]

Ah OK I think this is the same bug as #2107

Because when I run your script with the latest version, after fixing that bug, I get:

$ time _bin/cxx-asan/osh bits-info.sh 
      if tmp_var="$(printf 2> /dev/null "%u\n" "${_num}")" && test "${tmp_var}" = "${_num}"; then
                                        ^
bits-info.sh:1120: fatal: Integer too big: 9223372036854775808
        if _num="$(inc_num "${_max}")" && tmp_var="$(printf 2> /dev/null "%u\n" "${_num}")" && test "${tmp_var}" = "${_num}"; then
                                                                         ^
bits-info.sh:1123: fatal: Integer too big: 9223372036854775808
Bits info v1.5.13

Shell: osh
Shell applet: osh
Shell version: 0.23.0

[andychu]

So you can try with a new tarball here, we make one at every commit:

https://op.oilshell.org/uuu/github-jobs/8159/

https://op.oilshell.org/uuu/github-jobs/8159/cpp-tarball.wwz/_release/oils-for-unix.tar

I think you should get the same results now, it will no longer go crazy!

I think it was an integer overflow bug

the ps!!! comes from a comment in the line -- something got corrupted

[ale5000-git]

I'm on Windows and using Oils via GitHub workflow, so I can't try unless there is a precompiled version that I can download from a GitHub workflow.

[ale5000-git]

@andychu In my script overflows are intended and detected (since I test the limits) and in every shell the error message can be hidden with 2> /dev/null ( like this: printf 2> /dev/null "%u\n" "${_num}" ) but it seems they aren't hidden in Oils.

Is there another way to do it? Or a runtime option to make them less fatal? Like in set, setopt, shopt, etc.

To maintain compatibility with old shells I cannot use command grouping { cmd; } inside functions or subshell ( cmd ) .

[andychu]

Ah OK this is a good point

The errors can be "confined" to printf

shells are not really consistent about this - e.g. there doesn't seem to be a way to recover from this bash error:

$ bash -c 'printf -v "x[1/0]" "%d\n" 123; echo hi'
bash: line 1: 1/0: division by 0 (error token is "0")

But yes OSH is doing more fatal/unrecoverable errors, instead of having printf just return 1

I think for printf it does make sense for it to return 1

[andychu]

I made a new issue for this

• 2114

[ale5000-git]

I have tried this command: brew install --quiet --build-from-source 'oils-for-unix' and it seems to compile correctly. Unfortunately the parse errors still exist ( it doesn't like my comments :-) ). Maybe the issue is only on macOS.

PS: Why the --version doesn't report the git commit? It is difficult to know what is the version installed.

[andychu]

I doubt brew has been updated since last night

I am not sure why your build doesn't report the git commit -- if you compile from source it will

So if you can't compile from source, then you'll have to wait until the next release to verify the fix

[ale5000-git]

I have missed the flag --HEAD but now it say No head is defined for oils-for-unix.

[ale5000-git]

I have managed to compile it inside a GitHub workflow using this: https://op.oilshell.org/uuu/github-jobs/8206/cpp-tarball.wwz/_release/oils-for-unix.tar And I confirm that the problem is fixed, thanks.