Not a tty

Default shells seem to be limited. For example, the following step:

    - run: |
        ps
        echo "$(tty)"

produces:

   PID TTY          TIME CMD
  2587 ?        00:00:02 Runner.Listener
  2611 ?        00:00:02 Runner.Worker
  2763 ?        00:00:00 bash
  2777 ?        00:00:00 ps
not a tty

As a result, multiple tools that can provide pretty coloured logs do not work as expected. This is the case of e.g. colorama or pytest in the Python ecosystem.

A possible workaround is to use docker run --rm -t .... However, this involves installing in the container multiple resources/tools that are already available on the host. Furthermore, I don’t know if windows containers are supported on windows-latest jobs.

---

I tried setting shell: bash -i -l {0}, but I get:

bash: cannot set terminal process group (1291): Inappropriate ioctl for device
bash: no job control in this shell

---

I tried python -c 'import pty; pty.spawn("/bin/sh")' too, but the job wil run for more than 10min with no output.

---

Which is the appropriate syntax to get a TTY?

[abathur]

@dakale @joshmgross @bryanmacfarlane

On the off chance it helps make the case for re-prioritizing: this is continually externalizing work on users and maintainers.

Every person/team/project that encounters this has to burn time (and, often, GH computational resources) on some combination of:

• understanding the issue (and, as the thread illustrates, few people have deep understanding of the relevant behavior)
• flailing around with flags/envs mentioned here or there that may not even help
• hunting down which tool in their toolchain is eating color sequences and figuring out if it has added a flag to force color sequence printing
• collecting information to file issues against other tools and projects requesting special-case behavior
• increasing their ongoing maintenance burden by splitting out macos/linux jobs because the workarounds diverge

Once this cascades over into issues filed on other tools/projects, the developers of those projects also have to burn time understanding the issue, deciding whether it’s right for them to address it, and implementing something.

Without a fix, all of these remain ongoing costs.

[dalehamel]

FYI as a workaround you can use script -e -c $YOUR_USUAL_COMMAND_HERE, but this is obviously a bit of a hack.