Problems with terminal echo
Aaron W. Hsu
Sometimes, when I am using Elm in an xterm, I sometimes find that Elm
has not established a non-echoing terminal. Instead, I see all the
keys that I type, and they don't register until I send the line with
enter, which of course sends at least the character and the final
linefeed.
Somtimes sending a ^L with the enter will make things work,
but as often as not, this does not work. Is there some way to fix
this?
Aaron W. Hsu
--
A professor is one who talks in someone else's sleep.
Kari Hurtta
> Hello,
>
> Sometimes, when I am using Elm in an xterm, I sometimes find that Elm
> has not established a non-echoing terminal. Instead, I see all the
> keys that I type, and they don't register until I send the line with
> enter, which of course sends at least the character and the final
> linefeed.
>
> Somtimes sending a ^L with the enter will make things work,
> but as often as not, this does not work. Is there some way to fix
> this?
Can you describe your situation and environment on more detail?
If I remember correctly, I have succeed to do that only
when I first suspend Elm with Ctrl-Z and then put
it background with bg on shell.
That causes that Elm is suspended again, but after that
Elm's state of terminal is screwed and using fg on
shell does not cause that Elm run terminal one character
at time mode -- but instead terminal is line buffered.
> Aaron W. Hsu
> --
> A professor is one who talks in someone else's sleep.
/ Kari Hurtta
Aaron W. Hsu
Yes, I get that message some times. When I quit, I sometimes get a
message saying that Elm was backgrounded, and that you might need to
redraw to get things to work again. However, I don't background
Elm, so I do not know why this would occur.
I'm running on a Slackware64 13.0 box with Stumpwm and Xterm
as my window manager and terminal. I'm running the LANG=en_US.UTF-8
and I have a 10646 IBM Courier font that I'm using.
The Slackware64 box is fairly vanilla, and I haven't really changed
too much on it outside of installing lots of new software. I haven't
hacked around with the kernel or the terminal software, for sure.
I am running a Dual-head layout, but this occurs whether I have
both heads attached or not.
What's weird is that usually, if this happens, I just run Elm a
bunch more times, and eventually it reverts itself.
If there is any other environment information that you need, just
let me know. I can get you just about any of that information.
To be honest, I don't know what other environmental variables could
be causing this.
Kari Hurtta
> Kari Hurtta <hur...@Hurtta06k.keh.iki.fi> writes:
>
> >Aaron W. Hsu <arc...@sacrideo.us> writes:
>
> >> Sometimes, when I am using Elm in an xterm, I sometimes find that Elm
> >> has not established a non-echoing terminal. Instead, I see all the
> >> keys that I type, and they don't register until I send the line with
> >> enter, which of course sends at least the character and the final
> >> linefeed.
> >>
> >> Somtimes sending a ^L with the enter will make things work,
> >> but as often as not, this does not work. Is there some way to fix
> >> this?
>
> >Can you describe your situation and environment on more detail?
>
> >If I remember correctly, I have succeed to do that only
> >when I first suspend Elm with Ctrl-Z and then put
> >it background with bg on shell.
>
> >That causes that Elm is suspended again, but after that
> >Elm's state of terminal is screwed and using fg on
> >shell does not cause that Elm run terminal one character
> >at time mode -- but instead terminal is line buffered.
Command "bg" causes that Elm gets SIGCONT signal so it
is restarted, but it does not get ownership of terminal
so IO to terminal causes that it is suspended again.
Command "fg" gives ownership of terminal and sends SIGCONT signal.
> Yes, I get that message some times. When I quit, I sometimes get a
> message saying that Elm was backgrounded, and that you might need to
> redraw to get things to work again. However, I don't background
> Elm, so I do not know why this would occur.
Which Elm ?
(on my version of Elm you normally do not actually see that message,
because it (Elm ME+ -- at least most of time) does redraw itself.
Message
Back in ELM. (You might need to explicitly request a redraw.)
is printed when Elm gets SIGCONT signal.
Message
Stopped. Use "fg" to return to ELM
is printed when Elm gets SIGTSTP signal (because of ^Z).
> I'm running on a Slackware64 13.0 box with Stumpwm and Xterm
> as my window manager and terminal. I'm running the LANG=en_US.UTF-8
> and I have a 10646 IBM Courier font that I'm using.
I do not know what Slackware consists (execept that it is one Linux
distribution).
> The Slackware64 box is fairly vanilla, and I haven't really changed
> too much on it outside of installing lots of new software. I haven't
> hacked around with the kernel or the terminal software, for sure.
>
> I am running a Dual-head layout, but this occurs whether I have
> both heads attached or not.
>
> What's weird is that usually, if this happens, I just run Elm a
> bunch more times, and eventually it reverts itself.
These signals are part of job control. Creat part of job control
is managed by shell.
( Things goes definately strange if Elm is not started from shell,
which manages job control.
I have some terminals windows running which have Elm ME+ directly
started without shell. In that case if I press Ctrl-Z, I just
get
Stopped. Use "fg" to return to ELM
and it stopped responing. That is because it is assumed that shell
takes control -- but there is no shell which takes it. So
it is no possible to enter
fg
on that case. Only way to recover this is give
kill -CONT <pid>
on some other window (from shell).
)
When shell sees that its child process is stopped (suspended) because
of job control, it takes ownership of terminal.
> If there is any other environment information that you need, just
> let me know. I can get you just about any of that information.
>
> To be honest, I don't know what other environmental variables could
> be causing this.
>
> Aaron W. Hsu
/ Kari Hurtta
elm @elmme-mailer.org
Aaron W. Hsu
>Which Elm ?
2.5.8.
> Back in ELM. (You might need to explicitly request a redraw.)
This is the message I sometimes see, but only after I have quit Elm.
>I do not know what Slackware consists (execept that it is one Linux
>distribution).
I using the Ksh shell with Elm 2.5.8.
>These signals are part of job control. Creat part of job control
>is managed by shell.
Yes, however, I am not explicitly or intentionally using any job
control on Elm. I don't background it or bring it back to the fore
ground except in the sense of moving focus away from and back to
my Xterm window. The problem is:
1) Start up Elm, it works normally.
2) Quit elm, it quits fine.
3) Try to start Elm again, this time there is terminal echo.
4) Repeatedly restart Elm until terminal echo suddenly disappears.
Aaron W. Hsu
Kari Hurtta
> Kari Hurtta <hur...@Hurtta06k.keh.iki.fi> writes:
>
> >Which Elm ?
>
> 2.5.8.
>
> > Back in ELM. (You might need to explicitly request a redraw.)
>
> This is the message I sometimes see, but only after I have quit Elm.
Strange. That message is one which Elm prints when it gets signal
which usually is related to job control.
However I think that xterm keeps two buffer. And when Elm use control
"enable cursor control" / "disable cursor control" xterm switches
buffer.
So that message may be stale.
That "enable cursor control" / "disable cursor control" are related
to elm's command line option (-t) -- "TiTe - don't use termcap/terminfo
ti/te entries."
> >I do not know what Slackware consists (execept that it is one Linux
> >distribution).
>
> I using the Ksh shell with Elm 2.5.8.
>
> >These signals are part of job control. Creat part of job control
> >is managed by shell.
>
> Yes, however, I am not explicitly or intentionally using any job
> control on Elm. I don't background it or bring it back to the fore
> ground except in the sense of moving focus away from and back to
> my Xterm window. The problem is:
>
> 1) Start up Elm, it works normally.
> 2) Quit elm, it quits fine.
> 3) Try to start Elm again, this time there is terminal echo.
> 4) Repeatedly restart Elm until terminal echo suddenly disappears.
Sorry. I think I can not help. I have not seen this behauviour
and that version of Elm is not familiar to me. (Also ksh is not
familiar to me.)
Try
elm -h
There perhaps is debug (-d) option.
> Aaron W. Hsu
/ Kari Hurtta
elm @elmme-mailer.org
> --
Aaron W. Hsu
>Sorry. I think I can not help. I have not seen this behauviour
>and that version of Elm is not familiar to me. (Also ksh is not
>familiar to me.)
Actually, I discovered something just recently, which boggles me.
It appears that when I see this behavior, if I background the Elm
process and then subsequently bring the program back into the foreground,
the problem disappears inexplicably.
Aaron W. Hsu