Alt-Shift-P freezes XTerm

[Van Snyder]

I have set up Alt-Shift-P as a macro in my editor (nedit) to run pdflatex.

If I accidentally do it when XTerm has keyboard focus, it locks up and the only thing I can do is kill it and restart.

How can I unlock XTerm after doing this?

There are no Alt-Shift sequences listed at https://www.xfree86.org/current/ctlseqs.html (maybe it's only about output sent to XTerm).

Is there a list of Alt-Shift (and Alt-Ctrl and Shift-Ctrl) sequences for XTerm?

Van Snyder

[Van Snyder]

I haven't figured out how to unlock the XTerm after accidentally giving it Alt-Shift-P.

But I did work out how to prevent it. Put

xterm*altIsNotMeta: true

xterm*altSendsEscape: true

in your .Xdefaults (or .Xresources, or link those files together), then

xrdb -merge ~/.Xdefaults

[to...@tuxteam.de]

On Fri, Oct 13, 2023 at 01:06:20PM -0700, Van Snyder wrote:
> On Fri, 2023-10-13 at 12:38 -0700, Van Snyder wrote:
> > I have set up Alt-Shift-P as a macro in my editor (nedit) to run
> > pdflatex.
> > If I accidentally do it when XTerm has keyboard focus, it locks up
> > and the only thing I can do is kill it and restart.
> > How can I unlock XTerm after doing this?
> > There are no Alt-Shift sequences listed at
> > https://www.xfree86.org/current/ctlseqs.html (maybe it's only about
> > output sent to XTerm).
> > Is there a list of Alt-Shift (and Alt-Ctrl and Shift-Ctrl) sequences
> > for XTerm?
> > Van Snyder
>
> I haven't figured out how to unlock the XTerm after accidentally giving
> it Alt-Shift-P.
> But I did work out how to prevent it. Put

> xterm*altIsNotMeta: truexterm*altSendsEscape: true

> in your .Xdefaults (or .Xresources, or link those files together), then
> xrdb -merge ~/.Xdefaults

Interesting. If I do that I see a colon, which disappears if I
hit enter afterwards. Then things are "back to normal".

If I run "od -C" on that term, I see the sequence "1b P", so I
guess the term is just passing "ESC P" to the shell, and the one
doing the magic is actually the shell running in there.

The behaviour is the same if I do "ESC P". Does that "hang your
Xterm", too?

If yes, I'd assume that it's your shell hanging and the Xterm is
"just" translating Meta-P to "ESC P".

So it might be your bash's readline you'll have to complain to
(lo and behold: if I do enter some text after the colon I see
and hit ENTER, readline searches back in the history for the
last entry containing that string [1], so it is just a backward
search: perhaps that part is broken in your setup. What shell
are you using?)

Cheers

[1] I actually didn't know about that readline key binding,
since I was already happy with incremental backward
search, CTRL-R)
--
t

[Greg Wooledge]

On Sat, Oct 14, 2023 at 07:07:57AM +0200, to...@tuxteam.de wrote:
> On Fri, Oct 13, 2023 at 01:06:20PM -0700, Van Snyder wrote:
> > I haven't figured out how to unlock the XTerm after accidentally giving
> > it Alt-Shift-P.

I'm not seeing whatever it is you're seeing here. On Debian 12, if I
launch an xterm (simply "xterm &") with bash running inside it, and
press Alt-P I get this character: ğ

Shift-Alt-P gives me this character: Ğ

This is independent of whether bash is in emacs mode or vi mode.

> > But I did work out how to prevent it. Put
> > xterm*altIsNotMeta: truexterm*altSendsEscape: true
> > in your .Xdefaults (or .Xresources, or link those files together), then
> > xrdb -merge ~/.Xdefaults
>
> Interesting. If I do that I see a colon, which disappears if I
> hit enter afterwards. Then things are "back to normal".
>
> If I run "od -C" on that term, I see the sequence "1b P", so I
> guess the term is just passing "ESC P" to the shell, and the one
> doing the magic is actually the shell running in there.
>
> The behaviour is the same if I do "ESC P". Does that "hang your
> Xterm", too?

Looks like your bash is in emacs (default) mode. Pressing Esc P in
emacs mode triggers this guy:

"\eP": do-lowercase-version

whose description in readline(3readline) says

do-lowercase-version (M-A, M-B, M-x, ...)
If the metafied character x is uppercase, run the command that
is bound to the corresponding metafied lowercase character. The
behavior is undefined if x is already lowercase.

So... apparently it's supposed to act the same as "metafied lowercase p",
which I guess means it's running this guy:

"\ep": non-incremental-reverse-search-history

non-incremental-reverse-search-history (M-p)
Search backward through the history starting at the current line
using a non-incremental search for a string supplied by the
user.

I'm not 100% sure what that means, but maybe you can figure it out if
you continue experimenting with it. I don't normally run bash in emacs
mode myself, so many of these readline features are foreign to me.

Anyway, all of that's an interesting tangent, but I still don't get
a "freeze" in xterm from any of this.

Van Snyder, can you try running this in your xterm:

bind -p | grep P

That should tell us whether you have any unusual readline bindings
involving the letter P (capital) which might be at fault here. In my
shell, I just have these:

unicorn:~$ set -o vi
unicorn:~$ bind -p | grep P
"P": self-insert
unicorn:~$ set -o emacs
unicorn:~$ bind -p | grep P
"\C-xP": do-lowercase-version
"\eP": do-lowercase-version
"P": self-insert

If yours is different, then we have something to investigate.

[to...@tuxteam.de]

On Sat, Oct 14, 2023 at 08:38:22AM -0400, Greg Wooledge wrote:
> On Sat, Oct 14, 2023 at 07:07:57AM +0200, to...@tuxteam.de wrote:
> > On Fri, Oct 13, 2023 at 01:06:20PM -0700, Van Snyder wrote:
> > > I haven't figured out how to unlock the XTerm after accidentally giving
> > > it Alt-Shift-P.
>
> I'm not seeing whatever it is you're seeing here. On Debian 12, if I
> launch an xterm (simply "xterm &") with bash running inside it, and

> press Alt-P I get this character: ð
>
> Shift-Alt-P gives me this character: Ð

Oh, that's interesting. Our setups seem to differ in some way.
What I see with AltGr (not Alt) is Þ, with shift it's þ (this
is Thorn; you are seeing eth)

It seems that your left alt isn't doing Meta and mine does
or something :)

[...]

> > The behaviour [of Alt-Shift-P] is the same if I do "ESC P". Does that "hang your

> > Xterm", too?
>
> Looks like your bash is in emacs (default) mode. Pressing Esc P in
> emacs mode triggers this guy:

It is.

> "\eP": do-lowercase-version

Well, we were talking about the uppercase one (remember: alt-shift),
so it is this:

> "\ep": non-incremental-reverse-search-history
>
> non-incremental-reverse-search-history (M-p)
> Search backward through the history starting at the current line
> using a non-incremental search for a string supplied by the
> user.
>
> I'm not 100% sure what that means, but maybe you can figure it out if
> you continue experimenting with it. I don't normally run bash in emacs
> mode myself, so many of these readline features are foreign to me.

I tried to describe what it does, and yes, this matches the behaviour
pretty well: readline (I suppose) prints a colon (I guess this is meant
as a prompt), you may enter some string, and then it searches back in
the history for the last matching command -- so like an incremental
backward search without the incremental bit :-)

> Anyway, all of that's an interesting tangent, but I still don't get
> a "freeze" in xterm from any of this.

Absolutely. To both.

> Van Snyder, can you try running this in your xterm:
>
> bind -p | grep P
>
> That should tell us whether you have any unusual readline bindings
> involving the letter P (capital) which might be at fault here. In my
> shell, I just have these:
>
> unicorn:~$ set -o vi
> unicorn:~$ bind -p | grep P
> "P": self-insert
> unicorn:~$ set -o emacs
> unicorn:~$ bind -p | grep P
> "\C-xP": do-lowercase-version
> "\eP": do-lowercase-version
> "P": self-insert

That's what I get too. Now curious as to what Van Snyder gets :-)

Cheers
--
t

[Max Nikulin]

On 15/10/2023 02:10, Van Snyder wrote:
> The culprit is tcsh, not XTerm. With bash, Alt-Shift-P produces a colon.

In tcsh the default bindings are almost the same as in bash:

https://manpages.debian.org/bookworm/tcsh/tcsh.1.en.html#history-search-backward

history-search-backward (M-p, M-P)

P.S. I believed that most confusing (while still useful) feature of
terminals is [Ctrl+s]. It takes some time to realize that it has been
hit by mistake, so [Ctrl+q] is required to resume output.

[to...@tuxteam.de]

On Sun, Oct 15, 2023 at 09:52:16AM +0700, Max Nikulin wrote:

[...]

> P.S. I believed that most confusing (while still useful) feature of
> terminals is [Ctrl+s]. It takes some time to realize that it has been hit by
> mistake, so [Ctrl+q] is required to resume output.

Old age gotta have some advantages: I grew up with "real" terms
(VT520 and clones, mostly), so this one is "built in" for me.

Now don't get me started with CTRL-E, the source of many a prank ;-)

Cheers
--
t

[gene heskett]

I can beat that Tomas. At one point in the early 90's we had a PDP-11 to
run a 7 meter C band dish, The VT 220 died and DEC wanted nearly 2G for
a VT-550 but would not guarantee it would work in place of a VT-220. I
was then a fan of the TRS-80 color computer and OS9, an aftermarket OS
that was a mini UNIX. And a fellow named Brian Marquette had written a
VT-100 program that was quite well organized, so well organized that I
was able to make a 100% compatible VT-220 out of it in just a few hours.

So my office coco logged into that PDP-11 and updated the satellite
schedule daily. But that PDP-11 was not stable, crashing several times
daily toward the end. It got to be such a pita, and DEC changed every
part in it except the frame rail engraved with the serial number, w/o
any effect.

Hugo was the network guy at CBS, so he had DEC trade his test mule
serial number for ours, and traded me PDP-11. His Just Worked. But he
was not able to fix mine which put him out of business maintaining the
rest of the CBS networks machines. 2 months later I show up for work,
there's two huge cartons from CBS, he was forced to find a new platform
which was an industrial grade IBM PC, with an ARTIC card for the real
time stuff, he had to convert the whole CBS networks satellite systems.

Here we get into another problem, when the dish was installed, it came
with 4 copies of the site drawings so I had a hole dug, poured the
concrete, quite a few yards of it, all according to the drawings, I find
6 weeks later there was a note in just one of the 4 sets of site docs
that the base was to be oriented to offset the magnetic north diff at
our site, some like 17 degrees, and the sat hardware could not
compensate for that much error w/o re drilling the base jacks attachment
to the post. A big Roland jack about 12 feet long. They took over the
move instructions by a dial up circuit, but because of that base error,
my satellite table looked bogus as can be, but it was exact for my site.
I finally gave up resetting it because they would helpfully fix it, and
disconnected the phone line so I didn't have to screw around for a week
re finding the the satellites again and again. Being a non equatorial
mount, it was an AZ-EL setup, that is not as simple as equatorial, but
more accurate than equatorial. At 40 degrees north, equatorial has an EL
error of over a degree over the span of sat positions because of the
down angle to get to the equatorial orbit positions. Not easily noted on
a 3 meter home dish, but quite important for a 7 meter's much narrower
beam width.

Satellites aren't really stationary, the moon pulls on them so they do a
figure 8 daily and only expend station keeping fuel when they are in
danger of going outside their assigned box, with a 7 meter dishes
accuracy, stations on both coasts had to get another bit of software
that monitored incoming signal strength and if it got too weak, would go
on a half a degree search for a stronger signal. Some satellites moved
so far and fast that a station re-broadcasting the signal w/o a good
time base corrector, were out of FCC specs for color subcarrier's +- 10
hz requirement due to the doppler effect of the satellites motion. The
FCC I suspect looked the other way many times.

Broadcasting can be an interesting business.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

[to...@tuxteam.de]

On Sun, Oct 15, 2023 at 03:34:52AM -0400, gene heskett wrote:

[...]

> I can beat that Tomas. At one point in the early 90's we had a PDP-11 to run
> a 7 meter C band dish, The VT 220 died and DEC wanted nearly 2G for a VT-550

This one keeps tripping me up: the "G" in your "2G" means "grand", yes?
So it would be what others call "K".

I consistently read it as "giga" and then go "wait, what?".

Cheers
--
t

[gene heskett]

On 10/15/23 04:44, to...@tuxteam.de wrote:
> On Sun, Oct 15, 2023 at 03:34:52AM -0400, gene heskett wrote:
>
> [...]
>
>> I can beat that Tomas. At one point in the early 90's we had a PDP-11 to run
>> a 7 meter C band dish, The VT 220 died and DEC wanted nearly 2G for a VT-550
>
> This one keeps tripping me up: the "G" in your "2G" means "grand", yes?
> So it would be what others call "K".
>

Sorry Tomas, Yes of coarse. In our "slanguage", 2G means $2000, a 2
grand price IOW. I keep forgetting that non English slang might be
interpreted differently. My bad. Take care & stay well.

> I consistently read it as "giga" and then go "wait, what?".
>
> Cheers