ValueError: invalid literal for int() ...

[jan-matejka]

sometimes cram just crashes with

Traceback (most recent call last):
  File "/home/yac/.local/bin/cram", line 7, in <module>
    sys.exit(cram.main(sys.argv[1:]))
  File "/home/yac/.local/lib/python3.6/site-packages/cram/_main.py", line 197, in main
    refout, postout, diff = test()
  File "/home/yac/.local/lib/python3.6/site-packages/cram/_cli.py", line 90, in testwrapper
    refout, postout, diff = test()
  File "/home/yac/.local/lib/python3.6/site-packages/cram/_run.py", line 73, in test
    testname=path)
  File "/home/yac/.local/lib/python3.6/site-packages/cram/_test.py", line 230, in testfile
    cleanenv=cleanenv, debug=debug)
  File "/home/yac/.local/lib/python3.6/site-packages/cram/_test.py", line 169, in test
    ret = int(cmd.split()[1])
ValueError: invalid literal for int() with base 10: b'$?'

I was able to find the problem with my test via patching cram/_test.py to print cmd and out on line 157 but I was unable to produce a sscce though.

[fiapps]

One case that causes this error (on line 167 with cram 0.7 and python 3.8) is a test where the command is followed by lines intended to be fed to it on stdin, e.g.,

  $ cat
  > foo
  foo

Try a here document as a workaround:

  $ cat << EOF
  > foo
  > EOF
  foo

[eichin]

Getting rid of my only > input-lines test (which was already a Here Document) doesn't change anything (ubuntu 20.10 "groovy", python3-cram Version: 0.7-4 ) but turning on --debug (though not --verbose) does, at the cost of 400 lines of output.)

[eichin]

(opened https://bugs.launchpad.net/ubuntu/+source/cram/+bug/1901372 mostly as a precursor to requesting packaging if this gets fixed here, since this is the upstream that ubuntu is using.)

[eichin]

Just accidentally discovered that if you add

    $ set -v

to a cram 0.6/python2 test, you also get

Traceback (most recent call last):
  File "/usr/bin/cram", line 4, in <module>
    sys.exit(cram.main(sys.argv[1:]))
  File "/usr/lib/python2.7/dist-packages/cram.py", line 505, in main
    patchcmd, answer, opts.indent)
  File "/usr/lib/python2.7/dist-packages/cram.py", line 322, in run
    refout, postout, diff = test(abspath, shell, indent)
  File "/usr/lib/python2.7/dist-packages/cram.py", line 221, in test
    ret = int(line.split()[2])
ValueError: invalid literal for int() with base 10: '$?"'

and then, to my confusion, discovered that taking out the set -v also got it working again in cram3 (I'd added it to debug another non-cram-specific mystery problem.)

[aiiie]

The crash is caused by invoking cat without any arguments.

Given a test script:

  $ cat
  foo

Under the hood, cram generates a shell script looking something like this:

echo CRAM1640379829.06 0 $?
cat
echo CRAM1640379829.06 2 $?

and pipes that to the shell's stdin. This causes the shell to assume the input after the cat command is meant for its stdin, so the output erroneously becomes:

CRAM1640379829.06 0 0
echo CRAM1640379829.06 2 $?

That second line is being misinterpreted by Cram as its internal output, causing the crash.

I'm not really sure what the right fix is here. Invoking cat without in any arguments in a test doesn't make much sense, but I'm not sure what I'd expect it to do. It also breaks anything in the test that comes after it.

[fiapps]

I was actually using pandoc when I experienced the crash. I used cat in the bug report instead as a standard command that reads stdin and writes to stdout (this is its documented behavior on macOS when it is invoked without arguments). I got the same error with pandoc, but I've switched to a different test harness and no longer have cram installed, so I can't offer you an example of the ValueError with pandoc.

[greg-minshall]

i just ran into this (boiled down to the above $ cat). i don't have any idea of all the ways the code might produce commands. but, the second salt appears to be trying to return the exit status of the user commands. is it possible that leaving out that second salt, then retcode would contain the correct exit status? (then, at least in my case, i think this error wouldn't occur.)

another suggestion -- if the above wouldn't work -- would be to at least trap the error, and say something to the user, maybe point at this bug.

let me know if i can help in any way.