search

actions / runner

The Runner for GitHub Actions :rocket:
https://github.com/features/actions
MIT License
4.76k stars 925 forks source link

Not a tty #241

Open eine opened 4 years ago

eine commented 4 years ago

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?

alecpl commented 3 years ago

This is essential for https://github.com/pear/Crypt_GPG. Right now I can not test GnuPG v2. It was working with Travis.

stewartie4 commented 2 years ago

On bash I can force TTY with the following hack

shell: 'script --return --quiet --command "bash {0}"'
run: |
 <command requiring TTY>
abathur commented 2 years ago

@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:

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.

Slackadays commented 1 year ago

It's been over three years now, and this is still an ongoing issue. We shouldn't need hack workarounds just for Bash in order to make programs think there's a tty. With that said, I hope we see some progress baked into GHA soon.

Slackadays commented 1 year ago

I just made a workaround that should eliminate the Not a TTY problem on all platforms every time. However, it involves modifying the underlying code to check for an environment variable that overrides any false isatty checks. Here's an implementation of it in C++: https://github.com/Slackadays/Clipboard/commit/d80c6b380242ae52d876edee8500bd4bf944ce0c

Slackadays commented 1 year ago

This issue is messing with my tests again, and it's getting so annoying to have not one or two but three manual workarounds to think about when writing new ones (one is the mechanism inside the project, two is the invocation of this mechanism, three is specifying a custom action due to first workaround)

mgood7123 commented 9 months ago

I just made a workaround that should eliminate the Not a TTY problem on all platforms every time. However, it involves modifying the underlying code to check for an environment variable that overrides any false isatty checks. Here's an implementation of it in C++: Slackadays/Clipboard@d80c6b3

please dont state this as a "workaround"

your version simply "pretends" it is a tty when infact it is not an actual tty

Slackadays commented 9 months ago

please dont state this as a "workaround"

your version simply "pretends" it is a tty when infact it is not an actual tty

That's literally what a workaround is

mgood7123 commented 9 months ago

Still, pretending to be a tty is probably not a good thing :3

On Sat, 2 Dec 2023, 11:06 pm Jackson Huff, @.***> wrote:

please dont state this as a "workaround"

your version simply "pretends" it is a tty when infact it is not an actual tty

That's literally what a workaround is

— Reply to this email directly, view it on GitHub https://github.com/actions/runner/issues/241#issuecomment-1837144504, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGLITH6MIE75ET4IMBJ27CTYHMRUNAVCNFSM4J5K766KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTG4YTINBVGA2A . You are receiving this because you commented.Message ID: @.***>

consideRatio commented 5 months ago

This seems like the workaround I need, based on https://github.com/actions/runner/issues/241#issuecomment-842566950 by adding defaults.run.shell in the workflow file.

# SEE UPDATE BELOW
defaults:
  run:
    # GitHub Actions run without a TTY device. This is a workaround to get one,
    # based on https://github.com/actions/runner/issues/241#issuecomment-842566950.
    shell: 'script -q -e -c "bash --noprofile --norc -eo pipefail {0}"'

Update

When shell isn't specified on Linux/Mac, the default is not bash --noprofile --norc -eo pipefail {0}", but rather bash -e {0}.

image

Also, without specifying --log-out /dev/null we get a file created called typescript with the stdout output I think.

Due to that, the minimal change to get a TTY should be this I think:

defaults:
  run:
    # GitHub Actions run without a TTY device. This is a workaround to get one,
    # based on https://github.com/actions/runner/issues/241#issuecomment-2019042651
    shell: 'script --return --quiet --log-out /dev/null --command "bash -e {0}"'
marcransome commented 5 months ago

macOS-based runners use the BSD version of the script command, which accepts different command-line options to those suggested in @consideRatio's suggestion. Instead, the following should work (tested on macos-11, macos-12, macos-13, and macos-14 runners):

shell: 'script -q /dev/null bash -e {0}'

n.b. bash -e {0} should not be quoted, or it will be treated as a single argument and cause the step to fail with a No such file or directory error.