False OS X Unit Test Failures - e.g. ut_seash_help.py #99
Comments
|
Oh, fun! I replaced 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, An ANSI escape code it seems. Further reading |
|
/: 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. 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. 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. |
|
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?) |
|
Can you remove On a side note, I had problems |
|
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. |
|
I now wish this were an issue in the utf project instead. /: |
|
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?) |
|
|
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) |
|
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 |
|
Maybe you can try and remove the patching-around-existing |
|
If I remember correctly, it didn't let you tab complete or use the arrow On Thu, Feb 4, 2016 at 11:21 AM, aaaaalbert notifications@github.com
|
|
Tab is broken. The other things work. |
|
Further reading and fixing: http://stackoverflow.com/questions/7116038/python-tab-completion-mac-osx-10-7-lion |
|
I use homebrew to install python on OS X, not native Xcode, so I installed using Xcode just now (which is probably still the most common method) and checked to see....
The winner is of course installing python properly, but, basically, we cannot exclude the readline.so in seash, no, if we want people with Xcode-installed python to be able to use tab completion. We can still upgrade it to readline 6.3...? |
|
Great, thanks for checking this out in detail! Now building on the StackOverflow bit mentioned earlier, it looks like half of the problem (viz. tab completion of # Via Ned Deily in Python issue 10666, http://bugs.python.org/issue10666
import readline
import rlcompleter
# This is for Python installs whose `readline` uses BSD libedit
readline.parse_and_bind("bind ^I rl_complete")
# For `readline`s using GNU readline
readline.parse_and_bind("tab: complete")Seems that one For tab-completing directory and file names, we probably need to amend our |
|
The logic in seash.py around the readline import is strange to me. Why do we go to the trouble of renaming a library back and forth if we can just import as...? (I ask in case there's something I'm not understanding before I try making changes. (: ) EDIT: Moving on (: |
…moval of tab_completion code, swapping in of rlcompleter library
|
Submitted PR #100. All tests that should pass pass locally (3 failures: ut_seash_getrelease.py, ut_seash_getrelease_insecure.py, ut_seash_moduleconflicterror.py - just as with vanilla). I no longer get the blank false failures on my OS X laptop. If PR #98 were merged, the tests via AppVeyor and Travis would occur and show up here. |
|
PR #100 also breaks tab completion of local files / folders (only preserving tab completion of command names), which I hadn't previously understood. /:
should provide completion but does not there. Will have to try fixing the code to work with it and issue another PR. (Confusion stemmed from fact that filename tab completion is only available following a command, not on bare line - e.g. |
…prives OS X native Xcode python 2.7 users of file/directory tab completion (though command tab completion will still work)
|
When you type
The prefixes provided by the libraries aren't the same - editline is just providing the current word, while readline provides the whole line. Therein lies the problem, since Off the top of my head, there are a few ways we could work around this (other than just shipping a modern GNU readline, which might be a licensing issue (GPL) aside from being a somewhat distasteful procedure...?):
|
|
Yeah, editline seems to be ignoring It's not just that it's not happy with the empty string, either - it ignores |
|
While I didn't see some better alternative binding for editline, I do almost have it working correctly through the use of readline.get_line_buffer() to replace the shortened prefix. File tab completion now works, along with tildes, using that, on editline, but... ... I'm getting some odd behavior I haven't quite figured out yet - prefixes are repeating in a way that readline doesn't do when I apply exactly the same code to it. There seems to be some other difference in what the libraries are doing. Still working on it. I don't see any other impact yet, even though it feels a little weird to be doing. Code diff here: master...awwad:readline_clean_take_2 |
|
On a tangent: Have you seen this? I got the idea from https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax , and indeed if I |
See SeattleTestbed/seash#99 for further info
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!):
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.txtreturns 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.
The text was updated successfully, but these errors were encountered: