False OS X Unit Test Failures - e.g. ut_seash_help.py

[awwad]

There are some utf test failures when I run utf on seash on OS X that seem to be in error. In particular, the produced and expected output both seem to be blank (and therefore equal).

Per this UTF doc, when utf detects something pushed to std out or std error, the test fails (exceptions exist). On OS X, some tests are indicating failure but showing nothing (perhaps a newline?) produced to std out or std error, and nothing expected.

Here are some examples from Travis-CI (links are to convenient build excerpts - yay!):

• ut_seash_help.py on OS X (compare: Linux)
• ut_seash_loadkeys.py on OS X (compare: Linux)

I also replicated the seash_help.py result on my OS X laptop, and confirmed that the actual comparison between the help output and expected help output looks equal. (diff test_results.txt help_test_results.txt returns nothing)

While I see more errors on OS X than Linux on other modules as well, I haven't seen these kinds of seemingly-blank errors in repy_v2, which I checked for comparison.

[aaaaalbert]

Oh, fun! I replaced utf.py's output-on-error (i.e. the "prodced/expected" thing) to show reprs of what the unit test case returns, rather than strs.

480,481c480,481
<       print "."*30 + "Produced" + "."*30 + "\n" + str(produced_val)
<       print "."*30 + "Expected" + "."*30 + "\n" + str(expected_val)
---
>       print "."*30 + "Produced" + "."*30 + "\n" + repr(produced_val)
>       print "."*30 + "Expected" + "."*30 + "\n" + repr(expected_val)

Et voila,

    Running: ut_seash_help.py                                   [ FAIL ]
--------------------------------------------------------------------------------
Standard out :
..............................Produced..............................
'\x1b[?1034h'
..............................Expected..............................
None
--------------------------------------------------------------------------------

An ANSI escape code it seems. Further reading

• https://bugs.python.org/issue11390
• http://stackoverflow.com/questions/21135991/finding-ansi-escapes-in-raw-terminal-output-not-making-sense

[awwad]

/: Yeah, you're right: that's the same output I get when it's set to repr instead of str. So there's an ASCII escape code popping out in the output that shouldn't be there.
On my macbook, I have $TERM set to "xterm-256color". If I change it to "vt100" or "linux" first, the test passes.

In particular, if the term setting specifies an smm value, that value gets spit out at some point into std out. (Possibly at import of the readline library? Ref)

If a term setting is selected that lacks smm, this bug will not arise. The issue is a combination of term settings plus readline library issues, I suppose. I'm not sure how unreasonable it is for readline to do this.

I'm running Python 2.7.11 on my laptop and having this problem.
The Linux VMs on Travis are running 2.6.9 and 2.7.9 and not having this problem.
The OS X Travis-CI VMs having this problem are running Python 2.6.9 and 2.7.5.

So it's not something that varies in recent Python (2) history.

I'm going to toy with TERM values on the Travis-CI VMs and see what happens.

[awwad]

Values of TERM on Travis-CI are all "xterm" (OS X and Linux both); however, setting TERM to "linux" averts the issue....

This feels a bit silly. Do we need to tell people to set their terminals to a particular value, or should we adjust utf to disregard escape characters like this? (Maybe just this one?)

[aaaaalbert]

Can you remove readline.so.mac from your test dir and retry? (It was added as an ugly patch for command-line editing in seash on Mac, which was never a good idea in the first place.)

On a side note, I had problems sshing into machines as they would not work with my xterm-256color setting.

[awwad]

Hah. I wish I'd noticed that. Yes: removing that readline resolves the issue for me under Python 2.7.11 - which is to say that the readline that comes with 2.7.11 doesn't have this issue or python 2.7.11 paired with the readline included with it (some patch?) doesn't have this issue.

Here's a solid discussion of the issue in readline from python's perspective .

It looks like readline 6.3 may fix this (item 6.3 1.d in the changelog?) given a comment in that thread.

[awwad]

I now wish this were an issue in the utf project instead. /:
Shame issue movement hasn't gone anywhere and github-issue-mover doesn't provide much.

[awwad]

So: what impact does it have to remove that exactly? Do people use command-line editing in seash on a Mac? Is there some alternative? (What exactly is command-line editing in seash?)

[aaaaalbert]

1. I think it is a seash issue really.
2. https://seattle.poly.edu/changeset/6046 --- this is used for tab completion in interactive seash sessions. Remove it, and tab completion vanishes as well. Try with e.g. loadkeys /dir/to/a/user/key/...
3. I use it a lot :-(

[awwad]

1- Hmm. Fair point, but that readline version is a valid one that exists out there.... Even if we take it out of seash, someone still has it on some python version. It may just fall to utf to be able to handle a known not-really-output piece of output. (Thus utf issue?)

2&3. Yeah, ok. Possibly clunky, but not meriting removal if it has that impact.

So utf patch like the above? (but more complete :P)

[aaaaalbert]

Consider this little experiment:

albert$ python -c "import seash" | hexdump
0000000 1b 5b 3f 31 30 33 34 68                        
0000008
albert$ python -c "import readline" | hexdump
albert$ mv readline.so.mac readline.so.mac.OUT_OF_MY_WAY
albert$ python -c "import seash" | hexdump
albert$ 

It is the readline that we ship that's the problem.

[aaaaalbert]

Maybe you can try and remove the patching-around-existing readline from seash for a test. I don't remember the exact details why the default installed version didn't suffice for our purposes.

[JustinCappos]

If I remember correctly, it didn't let you tab complete or use the arrow
keys to view previous commands. It may even be that backspace didn't work.

On Thu, Feb 4, 2016 at 11:21 AM, aaaaalbert notifications@github.com
wrote:

Maybe you can try and remove the patching-around-existing readline from
seash for a test. I don't remember the exact details why the default
installed version didn't suffice for our purposes.

—
Reply to this email directly or view it on GitHub
#99 (comment)
.

[aaaaalbert]

Tab is broken. The other things work.

[aaaaalbert]

Further reading and fixing: http://stackoverflow.com/questions/7116038/python-tab-completion-mac-osx-10-7-lion