-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
New pyrepl gives a traceback on exit with "dumb" terminal #119102
Comments
Looks like the Line 525 in 65de194
def write_history():
try:
if os.getenv("PYTHON_BASIC_REPL"):
readline.write_history_file(history)
else:
_pyrepl.readline.write_history_file(history)
except (FileNotFoundError, PermissionError):
# home directory does not exist or is not writable
# https://bugs.python.org/issue19891
pass It clearly needs to get more clever to detect whether pyrepl is actually in use. Maybe it can just look at the |
@danielhollas Maybe: We set PYTHON_BASIC_REPL to true if TERM is set to "dumb"? |
@eugenetriguba if you look at the I tried to fix this by checking CAN_USE_PYREPL in the |
The following patch indeed fixes the issue, happy to make a PR if this seems like a right approach diff --git a/Lib/_pyrepl/__main__.py b/Lib/_pyrepl/__main__.py
index c598019e7c..40cdd6d9fe 100644
--- a/Lib/_pyrepl/__main__.py
+++ b/Lib/_pyrepl/__main__.py
@@ -39,6 +39,7 @@ def interactive_console(mainmodule=None, quiet=False, pythonstartup=False):
trace(msg)
print(msg, file=sys.stderr)
CAN_USE_PYREPL = False
+ os.environ["PYTHON_BASIC_REPL"] = "true"
if run_interactive is None:
return sys._baserepl()
return run_interactive(mainmodule) |
@danielhollas I worked with @lysnikolaou during PyCon sprints on this one, we came to the same conclusion but he said this is not the best practice to export the env variable to the system. He said he will take a deeper look as to why this might be happening |
Maybe add a |
I can do this if it's ok |
Move CAN_USE_PYREPL variable from _pyrepl.__main__ to _pyrepl and use it in the site module to decide if _pyrepl.write_history_file() can be used.
Move CAN_USE_PYREPL variable from _pyrepl.__main__ to _pyrepl and rename it to _CAN_USE_PYREPL. Use the variable in the site module to decide if _pyrepl.write_history_file() can be used.
Move CAN_USE_PYREPL variable from _pyrepl.__main__ to _pyrepl and rename it to _CAN_USE_PYREPL. Use the variable in the site module to decide if _pyrepl.write_history_file() can be used.
I proposed PR gh-119269 to fix this issue. |
Use CAN_USE_PYREPL of _pyrepl.__main__ in the site module to decide if _pyrepl.write_history_file() can be used.
Use CAN_USE_PYREPL of _pyrepl.__main__ in the site module to decide if _pyrepl.write_history_file() can be used.
Use CAN_USE_PYREPL of _pyrepl.__main__ in the site module to decide if _pyrepl.write_history_file() can be used. (cherry picked from commit 73f4a58) Co-authored-by: Victor Stinner <vstinner@python.org>
Leaving this open since #119269 did not fix the problem. |
The site module gets the __main__ module to get _pyrepl.__main__.
The site module gets the __main__ module to get _pyrepl.__main__.
Please check my second fix: PR gh-119332. |
The site module gets the __main__ module to get _pyrepl.__main__.
The site module gets the __main__ module to get _pyrepl.__main__. (cherry picked from commit de8f530) Co-authored-by: Victor Stinner <vstinner@python.org>
This time, it should be fixed. |
Use CAN_USE_PYREPL of _pyrepl.__main__ in the site module to decide if _pyrepl.write_history_file() can be used.
The site module gets the __main__ module to get _pyrepl.__main__.
Bug report
Bug description:
I was experimenting with terminal types:
It notices that the terminal is unsuitable, but then tries to use it on exit.
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs
The text was updated successfully, but these errors were encountered: