Skip to content

stdout width inconsistent #1208

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
riesentoaster opened this issue May 28, 2025 · 5 comments
Open

stdout width inconsistent #1208

riesentoaster opened this issue May 28, 2025 · 5 comments

Comments

@riesentoaster
Copy link

When running the tests of Fandango, specifically test_cli.test_help, I'm getting a weird error. The test looks as follows:

import os
import shlex
import shutil
import subprocess
import unittest

from fandango.cli import get_parser


class test_cli(unittest.TestCase):

    def run_command(self, command):
        proc = subprocess.Popen(
            command,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
        )
        out, err = proc.communicate()
        return out.decode(), err.decode(), proc.returncode

    def test_help(self):
        command = shlex.split("fandango --help")
        out, err, code = self.run_command(command)
        parser = get_parser(True)
        self.maxDiff = 100000
        self.assertEqual(0, code)
        self.assertEqual(out, parser.format_help())
        self.assertEqual(err, "")

Now, if I run pytest -k test_help, the test succeeds. If I however specify -n {1,auto}, I get the following error:

E       AssertionError: 'usag[45 chars]uiet] {fuzz,parse,shell,help,copyright,version[927 chars]n.\n' != 'usag[45 chars]uiet]\n                {fuzz,parse,shell,help,[944 chars]n.\n'
E       - usage: fandango [-h] [--version] [--verbose | --quiet] {fuzz,parse,shell,help,copyright,version} ...
E       + usage: fandango [-h] [--version] [--verbose | --quiet]
E       +                 {fuzz,parse,shell,help,copyright,version} ...
E         
E         The access point to the Fandango framework
E         
E         options:
E           -h, --help            show this help message and exit
E           --version             show version number
E           --verbose, -v         increase verbosity. Can be given multiple times (-vv)
E           --quiet, -q           decrease verbosity. Can be given multiple times (-qq)
E         
E         commands:
E           {fuzz,parse,shell,help,copyright,version}
E                                 the command to execute
E             fuzz                produce outputs from .fan files and test programs
E             parse               parse input file(s) according to .fan spec
E             shell               run an interactive shell (default)
E             help                show this help and exit
E             copyright           show copyright
E             version             show version
E         
E         Use `fandango help` to get a list of commands.
E         Use `fandango help COMMAND` to learn more about COMMAND.
E         See https://fandango-fuzzer.github.io/ for more information.

Seems like the stdout width is different between the two implementations? I assume this is a bug?

@RonnyPfannschmidt
Copy link
Member

This is a necessary details

Xdist replaces stdio with io pipes for its protocol

@riesentoaster
Copy link
Author

riesentoaster commented May 28, 2025

Is there a way to reconfigure those have the same terminal width as is used in subcommands?

parser.format_help() formats itself to this width - 2 according to shutil.get_terminal_size().columns: implementation details

@RonnyPfannschmidt
Copy link
Member

Id recommend to impose expected widths with monkeypatching

@riesentoaster
Copy link
Author

Would it be possible/a good idea to add a note about this in the docs somewhere? Or did I miss something? That's not behavior I'd instinctively expect from changing the test driver, even if there may be good reasons for the limitation.

@RonnyPfannschmidt
Copy link
Member

I vaguely recall that there are some notes on the dtdio behavior

Perhaps additional keywords are needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants