New GitHub issue #93139 from allisonkarlitskaya:<br>

<hr>

<pre>
**Bug report**

This straddles the line between bug report and feature request.

I've searched for related issues or PRs but I wasn't able to find anything directly related.  I'm sorry if this has been raised and discussed before.

Normally, if stdin is not a TTY, then `python3` tries to read a script from stdin, terminating with EOF, and then runs the script.  This effectively means that the script itself can't read more stdin, because EOF was already sent.  A way to work around this is to use `python3 -i`, which then causes the interpreter to behave more like the POSIX shell, evaluating commands as it receives them.

The commandline parameter `-i` is documented:

> When a script is passed as first argument or the -c option is used, enter interactive mode after executing the script or the command.

The scenario that `python3 -i` may be run without other flags isn't mentioned, but it works.

In particular, this mechanism gives me a really nice way to connect to a host with ssh, inject a script (via stdin), and then run it and interact with it.  I could do the same with an extremely large `-c` parameter, but I'd prefer not to spam the output of `ps` with a gigantic script, if possible[^1].

This is all already working wonderfully.  There is one strange issue, though: possibly as a side effect of #46221, on the stderr I get a whole lot of output looking like:

```
>>> >>> >>> >>> >>> >>> >>> >>> ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... >>> >>> 
```

This is, of course `sys.ps1` and `sys.ps2` being displayed for each line in my script.  First a bunch of imports (`ps1`), then a block defining a class (`sys.ps2`), then the lines to instantiate and execute a method in that class (more `sys.ps1`).

I don't want to simply redirect stderr to `/dev/null` because my script (or the Python interpreter, in case of exceptions) could produce error output and I'd like to receive it.

There are a few other ways that I could hack around this.  Something ugly like:

```
python3 -ic '"cockpit-bridge"; __import__('sys').ps1=""'
```

would do the trick (and is probably what I'll do for now), but it would be nice if this wasn't necessary.

So the ask is simple: in the case that stdin is not a tty, then `sys.ps1` and `sys.ps2` should either be set to empty, or not shown.

I tested a couple of POSIX shells (bash, dash) for comparison and each of them seems to do *both*.  Specifically, when reading from a non-tty, `$PS1` is unset, and is also ignored, even if I do set it to something.

Here's a simple reproducer:
```
sh$ python3 -qi <<EOF
print('x')
print('y')
print('z')
EOF
>>> x
>>> y
>>> z
>>> 
```

You can see that the prompts are going on stderr by redirecting:
```
bash-5.1$ python3 -qi 2>/dev/null <<EOF
> print('x')
> print('y')
> print('z')
> EOF
x
y
z
```

The output I'd like to see looks like:
```
# NB: This is not currently possible
sh$ python3 -qi <<EOF
print('x')
print('y')
print('z')
EOF
x
y
z
```

**Your environment**

```
Python 3.10.3 (main, Mar 18 2022, 00:00:00) [GCC 12.0.1 20220308 (Red Hat 12.0.1-0)] on linux
```

aka `python3-3.10.3-1.fc36.x86_64`.

[^1]: indeed, I intend to (ab)use `-c` to display the name of the script, using an (ignored) string literal like so:

    `ssh somehost python3 -ic '"cockpit-bridge"'`

    Using `-c` like this also means that the interactive banner gets suppressed, which means that I don't need to specify `-q` to do that.

</pre>

<hr>

<a href="https://github.com/python/cpython/issues/93139">View on GitHub</a>
<p>Labels: type-bug</p>
<p>Assignee: </p>