Description of problem: In Xemacs on Fedora 22 I get this error when I open a shell, Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell. This error is specific to tcsh on Fedora 22, Fedora 21 and earlier work fine and bash shells work fine. I've posted this to the Xemacs Bugzilla and to the Xemacs mailing list, everyone is stumped. What changed between Fedora 21 and Fedora 22 in tcsh that might account for this problem? BTW Xemacs hasn't had an update since 2013 so it's not a change there. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This problem is still present in F23. Has anyone looked at it yet? BTW regular Emacs doesn't have this issue.
Hello Joshua! Sorry for not looking into it yet. I joined Red Hat in July and I have taken over the tcsh package, but I'm still learning to adapt. And unfortunately, I don't know the code of tcsh yet, so I can't provide an answer immediately. But I will try to look at it when I can. Best regards, David
Have you had a chance to look at this yet, it's a really crippling problem.
Mailing list mentioned in comment #1: http://list-archive.xemacs.org/pipermail/xemacs-beta/2015-September/025798.html
So, I had finally time to look into this. Sorry for being so late, but previously I was mostly busy preparing the DevConf 2016, and after that I was engaged in my key responsibilites for Red Hat. =============== IMPORTANT NOTE: I would like to point out that the problem being described here is that <CTRL-C> key combination is not working in 'xemacs', if 'tcsh' is set as a login shell (in /etc/passwd). It was described in BZ #1222897, not here. Step to reproduce: ------------------ 1) Install F23 into virtual machine, run 'dnf upgrade' afterwards. 2) Install Mate desktop by running: > 'sudo dnf install @MATE' 3) Install these packages: > tcsh xemacs xemacs-common xemacs-filesystem xemacs-packages-base 4) Set user's login shell in /etc/passwd to '/bin/tcsh'. 5) Reboot the virtual machine. 6) Login via the user, launch new terminal, and launch 'xemacs' 7) In the xemacs, press <Alt-X> key combination, write 'shell' and press <Enter>. 8) You will see this warning message: > Warning: no access to tty (Inappropriate ioctl for device). > Thus no job control in this shell. 9) In tcsh launch via xemacs, run this command: > sleep 10 And press <Ctrl-C> at least 2 times. Nothing will happen, the sleep will not be interrupted. 10) Exit the xemacs. Now, you can try it again with bash - edit /etc/passwd so the user's login shell is set to '/bin/bash', logout of GUI session, and start over at point 6). You will see that the sleep will be interruptible if you use <Ctrl-C>. ----------- So, during my investigation I have found these facts: 1) The problem happens with both old (6.17.06) and latest upstream version (6.19.01 candidate). In other words, downgrading to older version of 'tcsh' *does not* solve the issue. 2) The problem is caused because tcsh in xemacs does not have process group properly set. TCSH is trying to retrieve the process group for the terminal by using ioctl() [tc.os.c:1015], but it fails. Since it does not have any info about the process group, it is not able to handle the <CTRL-C> key combination (and probably some other key combinations as well). 3) After downgrading to xemacs from F21, the tcsh *started to work correctly again* in xemacs. You can get the old packages for F21 from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=496355 4) I included some testing outputs in tcsh during testing. They showed me that tcsh is working correctly regarding this issue, in sense there's not much it can do. The fail happens in system function ioctl(), not tcsh itself, and tcsh handles the error correctly. As a result of this testing I have to conclude that this is problem of environment of xemacs from where the tcsh is being launched. Or it can be a problem in a way how the tcsh is being launched from xemacs. In either case, *this is a problem of xemacs*, not a problem of tcsh. Therefore I'm reassigning this BZ to xemacs. Best regards, Dee'Kej
Thanks for finnally looking at it. This is a pretty painful problem for me.
Joshua, you're welcome. And I'm really sorry I couldn't get to it sooner, and I do not have a solution for you. :(
xemacs-21.5.34-13.20160507hgd5b51c618ef8.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-61b5826385
xemacs-21.5.34-16.20160507hgd5b51c618ef8.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d104d3608c
xemacs-21.5.34-13.20160507hgd5b51c618ef8.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-61b5826385
xemacs-21.5.34-16.20160507hgd5b51c618ef8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d104d3608c
Has in been pushed to F23?
(In reply to Joshua Rosen from comment #13) > Has in been pushed to F23? It has been pushed to the F23 testing repository. See comment 11.
xemacs-21.5.34-16.20160507hgd5b51c618ef8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
xemacs-21.5.34-13.20160507hgd5b51c618ef8.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.