Bug 1222897

My initial attempts at reproducing this problem have been ineffective.  M-x shell works normally for me on a Fedora 22 x86_64 box.  Do you get the same result if you start xemacs with -vanilla?  If not, tell me more about your environment.  Which xemacs package provides the binary you are using: xemacs, xemacs-nox, or xemacs-xft?  Are you running on a bare TTY, a GNOME desktop, a KDE desktop, etc.?

-vanillia doesn't fix anything. I'm using Mate with a tcsh shell. The installed xemacs packages are,

emacs.x86_64                          21.5.34-10.20150420hg23178aa71f8b.fc22
                                                                 @System       
xemacs-common.x86_64                   21.5.34-10.20150420hg23178aa71f8b.fc22
                                                                 @System       
xemacs-filesystem.noarch               21.5.34-10.20150420hg23178aa71f8b.fc22
                                                                 @System       
xemacs-packages-base.noarch            20150413-1.fc22           @System       
xemacs-packages-extra.noarch           20150413-1.fc22           @System

Created attachment 1027486 [details]
.xemacs directory

Created attachment 1027753 [details]
RPM list

I've attached a complete list of my installed RPMS

The problem appears to be tcsh-specific.  I see it for M-x gdb as well as M-x shell when running under tcsh.  Running strace -ff -o xemacs xemacs, I see that tcsh is started up with three open file descriptors, 0, 1, and 2, all pipes connected back to the parent XEmacs process.  Then tcsh does this:

dup2(0, 16)                             = 16
fcntl(16, F_SETFD, FD_CLOEXEC)          = 0
dup2(1, 17)                             = 17
fcntl(17, F_SETFD, FD_CLOEXEC)          = 0
dup2(2, 18)                             = 18
fcntl(18, F_SETFD, FD_CLOEXEC)          = 0
dup2(16, 19)                            = 19
fcntl(19, F_SETFD, FD_CLOEXEC)          = 0
ioctl(18, TCGETS, 0x7ffca0f332b0)       = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(17, TCGETS, 0x7ffca0f332b0)       = -1 ENOTTY (Inappropriate ioctl for device)
ioctl(16, TCGETS, 0x7ffca0f33150)       = -1 ENOTTY (Inappropriate ioctl for device)

and it is those ENOTTY responses that prompt the warnings and misbehavior.

Incidentally, M-x eshell seems to work, so the problem appears to be specific to the M-x shell code.  I think I'll need some upstream help for this one.

Joshua, does this help at all?

(setq process-connection-type nil)

Putting (setq process-connection-type nil) into my init.el file not only doesn't help the problem in tcsh, it also causes sh to break in the same way. Specifically if I change 

(setq explicit-shell-file-name "tcsh")

to 

(setq explicit-shell-file-name "sh") 

it doesn't display the problem, however if I add the process-connection-type nil then sh behaves the same way

(setq explicit-shell-file-name "sh")
(setq process-connection-type nil)

sh: cannot set terminal process group (-1): Inappropriate ioctl for device
sh: no job control in this shell
sh-4.3$

Is anything happening here? I rolled back to Fedora 21 for a few months because of this bug but now I've updated one of my systems to F22 with the hopes that this would have been addressed (It's now Aug 31, I file this bug in May). It appears that it's still broken.

Sorry, Joshua, but 2015 has not been kind to me in terms of spare time.  Multiple Real Life factors have converged to severely reduce the time I have to spend on Fedora issues over previous years.  If you want more timely help, I think this is a case where talking directly to upstream could be effective.  Try sending an email to xemacs-beta with all of the details.  If someone there comes up with a solution, I will apply it to the Fedora package.

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

I think I finally figured out the nature of the problem.  Please try the updates listed in comment 10 and comment 11 and leave karma if they fix the problem for you.

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

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.

Looks good, it's working for me on all of my machines.

I'm glad to hear it.  Sorry it took me so long to figure out the problem.  In other news, the latest NSS update breaks xemacs due to bug 1342158.  It looks like another NSS update is on its way to fix the problem, but I'm going to push an xemacs-side fix as well to avoid future problems.