"Inappropriate ioctl for device" problem using latest cygwin as a shell within native (non-cygwin) GnuEmac

"Inappropriate ioctl for device" problem using latest cygwin as a shell within native (non-cygwin) GnuEmac

[Jack Profit]

After upgrading my cygwin environment this morning to version
1.7.11-1, I am no longer able to use cygwin bash as a shell within
native GnuEmacs (Windows).

When I invoke M-x shell, I now get the following output in the shell window:

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

The shell window is functional, but as the error message suggests, I
have no Ctrl-C, Ctrl-Z or other job control functions.

Here are my shell related .emacs settings:
(setq explicit-shell-file-name "c:/cygwin/bin/bash.exe")

I am using:
GnuEmacs version 23.4.1 (latest)
Bash version 4.1.10-4
also Bash version 3.2.51-24 (removes error message, but job control
still doesn't work)

I also tried the cygwin1.dll from the 3/10 snapshot and saw no
difference in behavior.

Jack

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: "Inappropriate ioctl for device" problem using latest cygwin as a shell within native (non-cygwin) GnuEmac

[Ken Brown]

On 3/11/2012 3:19 PM, Jack Profit wrote:
> After upgrading my cygwin environment this morning to version
> 1.7.11-1, I am no longer able to use cygwin bash as a shell within
> native GnuEmacs (Windows).
>
> When I invoke M-x shell, I now get the following output in the shell window:
>
> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> bash: no job control in this shell
> $
>
> The shell window is functional, but as the error message suggests, I
> have no Ctrl-C, Ctrl-Z or other job control functions.
>
> Here are my shell related .emacs settings:
> (setq explicit-shell-file-name "c:/cygwin/bin/bash.exe")
>
> I am using:
> GnuEmacs version 23.4.1 (latest)
> Bash version 4.1.10-4
> also Bash version 3.2.51-24 (removes error message, but job control
> still doesn't work)
>
> I also tried the cygwin1.dll from the 3/10 snapshot and saw no
> difference in behavior.

I doubt if the Cygwin developers are going to be able to track this down 
unless you can find a way to reproduce the problem without using native 
emacs.  Can you look into the emacs source for the native build and see 
how it is creating the bash process?  Maybe you can extract a simple 
test case from it.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: "Inappropriate ioctl for device" problem using latest cygwin as a shell within native (non-cygwin) GnuEmac

[Ken Brown]

On 3/11/2012 3:42 PM, Ken Brown wrote:
> On 3/11/2012 3:19 PM, Jack Profit wrote:
>> After upgrading my cygwin environment this morning to version
>> 1.7.11-1, I am no longer able to use cygwin bash as a shell within
>> native GnuEmacs (Windows).
>>
>> When I invoke M-x shell, I now get the following output in the shell
>> window:
>>
>> bash: cannot set terminal process group (-1): Inappropriate ioctl for
>> device
>> bash: no job control in this shell
>> $
>>
>> The shell window is functional, but as the error message suggests, I
>> have no Ctrl-C, Ctrl-Z or other job control functions.
>>
>> Here are my shell related .emacs settings:
>> (setq explicit-shell-file-name "c:/cygwin/bin/bash.exe")
>>
>> I am using:
>> GnuEmacs version 23.4.1 (latest)
>> Bash version 4.1.10-4
>> also Bash version 3.2.51-24 (removes error message, but job control
>> still doesn't work)
>>
>> I also tried the cygwin1.dll from the 3/10 snapshot and saw no
>> difference in behavior.
>
> I doubt if the Cygwin developers are going to be able to track this down
> unless you can find a way to reproduce the problem without using native
> emacs. Can you look into the emacs source for the native build and see
> how it is creating the bash process? Maybe you can extract a simple test
> case from it.

Another (easier) thing you could do is try various snapshots between 
versions 1.7.10 and 1.7.11 of cygwin1.dll and pinpoint exactly when the 
problem first occurred.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re:

[Jack]

Ken Brown <kbrown <at> cornell.edu> writes:

> 
> Another (easier) thing you could do is try various snapshots between 
> versions 1.7.10 and 1.7.11 of cygwin1.dll and pinpoint exactly when the 
> problem first occurred.
> 
> Ken
> 
> 

Sadly, even the oldest cygwin1.dll snapshot (from 7/30/11) seems to have this 
issue. There is a pointer on the emacs lists (for MacOS) that says I should 
recompile with #define DONT_REOPEN_PTYS to avoid the "inappropriate ioctl for 
device" problem. I was hoping to avoid recompiling emacs but I guess I'll give 
that a try. :)

Thanks for the ideas Ken.

Jack



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re:

[Trey Greer]

Jack <jack.profit <at> gmail.com> writes:

> 
> Ken Brown <kbrown <at> cornell.edu> writes:
> 
> > 
> > Another (easier) thing you could do is try various snapshots between 
> > versions 1.7.10 and 1.7.11 of cygwin1.dll and pinpoint exactly when the 
> > problem first occurred.
> > 
> > Ken
> > 
> > 
> 
> Sadly, even the oldest cygwin1.dll snapshot (from 7/30/11) seems to have this 
> issue. There is a pointer on the emacs lists (for MacOS) that says I should 
> recompile with #define DONT_REOPEN_PTYS to avoid the "inappropriate ioctl for 
> device" problem. I was hoping to avoid recompiling emacs but I guess I'll give 
> that a try. :)
> 
> Thanks for the ideas Ken.
> 
> Jack
> 
> 

Looking through the native (Windows) emacs 23.4.1 source, I don't
see how cygwin bash job control could ever have worked.  When I
do a ctrl-C ctrl-Z (emacs speak for suspend job) in the bash
shell in shell mode, emacs gives me the message 'No SIGTSTP
support'.  Poking through the source, this appears to be because
there is no SIGTSTP defined in windows, or at least not in the
configuration header emacs-23.4/src/s/ms-w32.h.

Emacs in windows does not have PTYS (HAVE_PTYS is not defined in
s/ms-w32.h) so shell-mode opens the cygwin bash shell with input
and output pipes instead of ptys.  A recent change to bash (as of
bash-4.1-alpha) causes bash to refuse job control if the
controlling terminal is not a tty.  See item jj. in the
bash-4.0-alpha entry in the changelog
bash-4.1.10-4/src/bash-4.1/CHANGES.

It looks to me like suspend (ctrl-C ctrl-Z) never worked for
cygwin bash within native windows gnu emacs, but I certainly
could be wrong.

I did try defeating the tty test mentioned above (in jobs.c in
the bash source).  Indeed, I was able to spawn jobs in the
background and kill them.  Just no signals from emacs.

-- Trey


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: "Inappropriate ioctl for device" problem using latest cygwin as a shell within native (non-cygwin) GnuEmac

[Trey Greer]

Ken Brown <kbrown <at> cornell.edu> writes:

> 
> On 3/11/2012 3:42 PM, Ken Brown wrote:
> > On 3/11/2012 3:19 PM, Jack Profit wrote:
> >> After upgrading my cygwin environment this morning to version
> >> 1.7.11-1, I am no longer able to use cygwin bash as a shell within
> >> native GnuEmacs (Windows).
> >>
> >> When I invoke M-x shell, I now get the following output in the shell
> >> window:
> >>
> >> bash: cannot set terminal process group (-1): Inappropriate ioctl for
> >> device
> >> bash: no job control in this shell
> >> $
> >>
> >> The shell window is functional, but as the error message suggests, I
> >> have no Ctrl-C, Ctrl-Z or other job control functions.
> >>
> >> Here are my shell related .emacs settings:
> >> (setq explicit-shell-file-name "c:/cygwin/bin/bash.exe")
> >>
> >> I am using:
> >> GnuEmacs version 23.4.1 (latest)
> >> Bash version 4.1.10-4
> >> also Bash version 3.2.51-24 (removes error message, but job control
> >> still doesn't work)
> >>
> >> I also tried the cygwin1.dll from the 3/10 snapshot and saw no
> >> difference in behavior.
> >
> > I doubt if the Cygwin developers are going to be able to track this down
> > unless you can find a way to reproduce the problem without using native
> > emacs. Can you look into the emacs source for the native build and see
> > how it is creating the bash process? Maybe you can extract a simple test
> > case from it.
> 
> Another (easier) thing you could do is try various snapshots between 
> versions 1.7.10 and 1.7.11 of cygwin1.dll and pinpoint exactly when the 
> problem first occurred.
> 
> Ken
> 
> 

Looking through the native (Windows) emacs 23.4.1 source, I don't
see how cygwin bash job control could ever have worked.  When I
do a ctrl-C ctrl-Z (emacs speak for suspend job) in the bash
shell in shell mode, emacs gives me the message 'No SIGTSTP
support'.  Poking through the emacs source, this appears to be
because there is no SIGTSTP defined in windows, or at least not
in the configuration header emacs-23.4/src/s/ms-w32.h.

Emacs in windows does not have PTYS (HAVE_PTYS is not defined in
s/ms-w32.h) so shell-mode opens the cygwin bash shell with input
and output pipes instead of ptys.  A recent change to bash (as of
bash-4.1-alpha) causes bash to refuse job control if the
controlling terminal is not a tty.  See item jj. in the
bash-4.0-alpha entry in the changelog
bash-4.1.10-4/src/bash-4.1/CHANGES.

It looks to me like suspend (ctrl-C ctrl-Z) never worked for
cygwin bash within native windows gnu emacs, but I certainly
could be wrong.  

I did try defeating the tty test mentioned above (in jobs.c in
the bash source).  Indeed, I was able to spawn jobs in the
background and kill them.  Just no signals from emacs.

-- Trey



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple