You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X #57840
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/ronaldoussoren'closed_at=<Date2018-05-17.07:33:38.025>created_at=<Date2011-12-19.04:05:36.802>labels= ['OS-mac', '3.8', 'type-bug', '3.7']
title='readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X'updated_at=<Date2018-05-17.07:33:38.022>user='https://github.com/zvezdan'
The changes in r87356 for py3k and r87358 for python-2.7 described in bpo-9907 have broken parsing of the initialization file .editrc under editline emulation of readline on Mac OS X.
Background
==========
Both readline and editline allow settings customized per program.
For example, .inputrc file for readline::
$if Python
set editing-mode vi
$endif
will be applied only to Python processes.
Similarly, .editrc file for editline::
python:bind -v
python:bind ^I rl_complete
will be applied only to Python processes on Mac OS X.
This works fine on python-2.6.
It's broken on 2.7 and 3.2 and later because the change in bpo-9907 moved the rl_initialize() call towards the beginning of the setup function.
Solution
========
The rl_readline_name variable must be set to "python" **before** the call to rl_initialize(). Attached are patches for 2.7 and 3.2.
Thanks for the analysis and patch. Have you tested that your patch does not break the readline module when linking against GNU readline? If not, I can do it.
I applied your patch and built the readline module against libreadline and imported it successfully. (I did not try the special parsing feature, but I don’t think it’s needed.)
It appears that Apple's update to editline in OS X 10.9 Mavericks has also broken this patch; with refreshing, it still works with the system editline in 10.8. So, like the fix for bpo-18458, we need to make sure that the fix works with either version of a dynamically loaded libedit.
New changeset c2f082e by Ned Deily (Zvezdan Petkovic) in branch 'master': bpo-13631: Fix the order of initialization for readline libedit on macOS. (GH-6915) c2f082e
New changeset d504108 by Ned Deily (Miss Islington (bot)) in branch '3.7': bpo-13631: Fix the order of initialization for readline libedit on macOS. (GH-6915) (GH-6928) d504108
Activity
zvezdan commentedon Dec 19, 2011
Problem
=======
The changes in r87356 for py3k and r87358 for python-2.7 described in bpo-9907 have broken parsing of the initialization file .editrc under editline emulation of readline on Mac OS X.
Background
==========
Both readline and editline allow settings customized per program.
For example, .inputrc file for readline::
will be applied only to Python processes.
Similarly, .editrc file for editline::
will be applied only to Python processes on Mac OS X.
This works fine on python-2.6.
It's broken on 2.7 and 3.2 and later because the change in bpo-9907 moved the rl_initialize() call towards the beginning of the setup function.
Solution
========
The rl_readline_name variable must be set to "python" **before** the call to rl_initialize(). Attached are patches for 2.7 and 3.2.
merwok commentedon Jan 9, 2012
Thanks for the analysis and patch. Have you tested that your patch does not break the readline module when linking against GNU readline? If not, I can do it.
zvezdan commentedon Jan 9, 2012
I did not test against a readline build.
merwok commentedon Jan 12, 2012
I applied your patch and built the readline module against libreadline and imported it successfully. (I did not try the special parsing feature, but I don’t think it’s needed.)
ronaldoussoren commentedon Jul 15, 2013
I can confirm the problem and that the patch fixes the issue.
I'll try to commit a fix later this week.
ned-deily commentedon Jun 2, 2014
It appears that Apple's update to editline in OS X 10.9 Mavericks has also broken this patch; with refreshing, it still works with the system editline in 10.8. So, like the fix for bpo-18458, we need to make sure that the fix works with either version of a dynamically loaded libedit.
Zvezdan, it would be good if you would be willing to sign the Python contributor agreement for your patch: https://www.python.org/psf/contrib/contrib-form/
zvezdan commentedon Jun 4, 2014
Ned,
I just signed the contributor agreement form.
ned-deily commentedon May 17, 2018
New changeset c2f082e by Ned Deily (Zvezdan Petkovic) in branch 'master':
bpo-13631: Fix the order of initialization for readline libedit on macOS. (GH-6915)
c2f082e
ned-deily commentedon May 17, 2018
New changeset d504108 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-13631: Fix the order of initialization for readline libedit on macOS. (GH-6915) (GH-6928)
d504108
ned-deily commentedon May 17, 2018
Thanks for the patch and PR, Zvezdan! Merged for 3.7.0 and 3.8.0.