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>