mutt and bash and control-Z

[blmblm.m...@gmail.com]

I recently noticed an interesting(?) problem when I invoke mutt
from a shell script and then press control-Z to (try to!) suspend
both mutt and the script. The "suspend" part works fine and takes
me back to the bash prompt, but when I type "fg" to try to get
back to where I was, well ....

On *one* of the systems where I've tried it, it works fine; on
the others, mutt sort of starts up again (in that whatever it was
displaying shows up again), but then it doesn't respond correctly
to keyboard input -- it seems to basically ignore most keystrokes,
with the exception of <CR> and control-C, though I can exit with
"xx<CR>" and "qq<CR>" (which I discovered more or less by accident).

All the systems where I've tried this are running some sort of
RedHat-derived Linux, with bash versions ranging from 3.00.16(1)
to 4.1.7(1), and mutt versions ranging from 1.4.2.1i to 1.5.21.
The one where things work fine is of course the one with the oldest
version of both programs. ("Of course" because that's the most
annoying possibility. :-)? )

I thought the problem might be related to bash rather than mutt,
but if I install a recent mutt on the system where things work,
I get -- the problem.

I also thought maybe changing the mutt configuration variable
"suspend" (to be not-set) might help, but unsetting it -- well,
if I invoke mutt directly from an interactive bash session it does
have an effect, but not when I invoke it from a shell script.

Test shell script (requires the name of an mbox file as a parameter):

#!/bin/sh
echo "hello"
mutt -f $1
echo "goodbye"

Anyone have any idea what's going wrong and how to fix it or work
around it? I don't know that I *have* to have this functionality,
but I'm so used to suspending things with control-Z that I'm apt
to forget that if I do that when running mutt from a script Bad
Stuff Happens (essentially, I can't get back to mutt to do whatever
kind of exit I had planned).


--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

[Jorgen Grahn]

On Wed, 2012-07-25, blmblm myrealbox.com wrote:
>
> I recently noticed an interesting(?) problem when I invoke mutt
> from a shell script and then press control-Z to (try to!) suspend
> both mutt and the script. The "suspend" part works fine and takes
> me back to the bash prompt, but when I type "fg" to try to get
> back to where I was, well ....
>
> On *one* of the systems where I've tried it, it works fine; on
> the others, mutt sort of starts up again (in that whatever it was
> displaying shows up again), but then it doesn't respond correctly
> to keyboard input -- it seems to basically ignore most keystrokes,
> with the exception of <CR> and control-C, though I can exit with
> "xx<CR>" and "qq<CR>" (which I discovered more or less by accident).
>
> All the systems where I've tried this are running some sort of
> RedHat-derived Linux, with bash versions ranging from 3.00.16(1)
> to 4.1.7(1), and mutt versions ranging from 1.4.2.1i to 1.5.21.
> The one where things work fine is of course the one with the oldest
> version of both programs. ("Of course" because that's the most
> annoying possibility. :-)? )

[...]

I can reproduce this on Debian stable, in an xterm. More specifically,
my first 'fg' brings up the mutt display, but overlayed on it another
shell prompt. Another 'fg' there, and I'm inside Mutt alright --
except it's messed up like you describe.

Really weird -- job control normally seems to Just Work.

It's not the shell's fault because a zsh script behaves the same way
(and I bet csh would too).

/Jorgen

PS. Nowadays I get terminal corruption when Mutt reclaims control
after using w3m to display HTML mail, or gpg to sign a mail.
Perhaps there's a connection.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jim Diamond]

Yup, I just wrote a csh script and got the same issue.

This has annoyed me for a while (on a variety of Slackware systems)
when I use grepm (which uses grepmail to search through some mail
boxes, in case anyone here doesn't know about it).

I notice that (in some cases, not all, maybe there is some race
condition) that the tty modes are incorrect when "fg" doesn't work
properly.

My tty modes when shell is waiting for a command (note I use ^X for
suspend, not ^Z):

speed 38400 baud; rows 57; columns 80; line = 0;
intr = ^C; quit = <undef>; erase = ^?; kill = ^U; eof = ^Z; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = <undef>;
rprnt = ^R; werase = ^W; lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

My tty modes when mutt is running:

speed 38400 baud; rows 57; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^Z; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^X; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff
-iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

and finally, my tty modes when when I did "fg" but got an incorrectly
restarted mutt:

speed 38400 baud; rows 57; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^Z; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^X; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

I wonder if mutt traps the SIGTSTP to restore the terminal modes, but
somehow the change of tty modes when starting back up this doesn't
always cooperate with the shell's setting of terminal modes (when mutt
is called from a shell script).


Any mutt maintainers / hackers listening? If so, any words of wisdom?

Cheers.
Jim

[gregor herrmann]

On 25 Jul 2012 19:48:15 GMT, Jorgen Grahn wrote:

> I can reproduce this on Debian stable, in an xterm. More specifically,
> my first 'fg' brings up the mutt display, but overlayed on it another
> shell prompt. Another 'fg' there, and I'm inside Mutt alright --
> except it's messed up like you describe.

What works here is:

#v+
% cat mutt.sh
#!/bin/bash

exec mutt
#v-

gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Rolling Stones: Wild Horses

[blmblm.m...@gmail.com]

In article <31m6e9x...@news.comodo.priv.at>,

gregor herrmann <gregor+us...@comodo.priv.at> wrote:
> On 25 Jul 2012 19:48:15 GMT, Jorgen Grahn wrote:
>
> > I can reproduce this on Debian stable, in an xterm. More specifically,
> > my first 'fg' brings up the mutt display, but overlayed on it another
> > shell prompt. Another 'fg' there, and I'm inside Mutt alright --
> > except it's messed up like you describe.
>
> What works here is:
>
> #v+
> % cat mutt.sh
> #!/bin/bash
>
> exec mutt
> #v-

Works [*] for me too -- which is not a total surprise given that
"exec" works by, what, replacing the shell-script process with
the thing being exec'd (mutt here), rather than by executing it
as a dependent process.

[*] "Works" in the sense that it doesn't produce the bad behavior.
However, it doesn't return control to the script, and in my actual
use case(s), that's a problem.

Possibly a reportable bug in mutt?

[Jorgen Grahn]

On Thu, 2012-07-26, blmblm myrealbox.com wrote:
...

> Possibly a reportable bug in mutt?

Certainly should be reported!

If you can replace mutt in the script with other things full-screen
(vi, emacs -nw, slrn, rtorrent ...) and make the problem go away, then
you have a pretty solid case.

/Jorgen

[blmblm.m...@gmail.com]

In article <slrnk137rl.p...@frailea.sa.invalid>,

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Thu, 2012-07-26, blmblm myrealbox.com wrote:
> ...
> > Possibly a reportable bug in mutt?
>
> Certainly should be reported!
>
> If you can replace mutt in the script with other things full-screen
> (vi, emacs -nw, slrn, rtorrent ...) and make the problem go away, then
> you have a pretty solid case.
>

I tried vim and "emacs -nw" and observed no problems.

So, probably time to find out how to report a bug .... (The man
pages says point a browser at http://bugs.mutt.org, and from there
one hopes it will be straightforward!)

[blmblm.m...@gmail.com]

In article <a7do1q...@mid.individual.net>,

blm...@myrealbox.com <blmblm.m...@gmail.com> wrote:
> In article <slrnk137rl.p...@frailea.sa.invalid>,
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
> > On Thu, 2012-07-26, blmblm myrealbox.com wrote:
> > ...
> > > Possibly a reportable bug in mutt?
> >
> > Certainly should be reported!
> >
> > If you can replace mutt in the script with other things full-screen
> > (vi, emacs -nw, slrn, rtorrent ...) and make the problem go away, then
> > you have a pretty solid case.
> >
>
> I tried vim and "emacs -nw" and observed no problems.
>
> So, probably time to find out how to report a bug .... (The man
> pages says point a browser at http://bugs.mutt.org, and from there
> one hopes it will be straightforward!)

And it was, more or less .... Very belatedly, for the record or
something:

http://dev.mutt.org/trac/ticket/3595

No follow-up / response, but maybe good to have it reported?

[Jorgen Grahn]

On Thu, 2012-10-25, blmblm myrealbox.com wrote:
> Very belatedly, for the record or
> something:
>
> http://dev.mutt.org/trac/ticket/3595
>
> No follow-up / response, but maybe good to have it reported?

Definitely good! The first step to fixing a bug is to
have it reported and named.