doctest Hassles!

[Bengt Richter]

On 12 Mar 2002 09:28:11 -0800, doug at pobox.com (Douglas Garstang) wrote:

>I posted a question yesterday about how to get doctest to interpret
>output from the execution of an external program. It was suggested I
>use:
>
>ls=os.popen("/bin/ls","r").read()
>
>instead of trying to use spawnv. Well, when I print the value of ls, I
>get:
Are you accounting for the newline that print supplies at the end?
>
>'
>    example.py
>    example.pyc
>    tester.py
>
>'
>
>Notice the blank line at the end. Where did that come from? There
>isn't a file with no name in my directory, so why would it print an
>empty line? Also, why is the output in ONE column instead of across
>the screen (as in a normal ls) when spawnv is used? All I did was
>print the output of the ls command, but the output is different.
You opened a pipe with popen to read the output of ls. Non-terminal
output defaults to single column. If you type 'ls | cat' in the shell
you will get one column too, unless you type 'ls -C | cat' to force
multicolumns.

>
>Now, in my code I have:
>
>def tester3():
>    """
>    >>> import os
>    >>> ls=os.popen("/bin/ls","r").read()
>    >>> print ls
>    example.py
>    example.pyc
>    tester.py
>
>    """
>
>It ignores the blank line at the end, as the docs say it will. On a
 ^^--what ignores what blank line? There's no executable code above.

try 'ls | hexdump -c' to see the data your pipe is getting fed.

>side note, I've had this problem before with python, trying to read
>text config files. As soon as it hit an empty line, reading would
>stop! Huh?
>
Post the actual code that behaves that way, and you may get an explanation.

>So, as a result, it ignores the empty line on the expect, but gets it
>on the output, and the test fails!
>
>What am I missing here? I would imagine that executing external
>programs is central to testing, but it seems to be _really_ difficult.

Posting specific actual failing code is the best way to get specific help.
Copy and paste from an interactive session, don't type an approximation.

Regards,
Bengt Richter