Misbehavior of "read" or ...?

Misbehavior of "read" or ...?

[Bart Schaefer]

On Jan 18,  1:19am, Bart Schaefer wrote to zsh-users:
}
} function xterm-ask {
}   local esc
}   unset REPLY reply
}   1=get_${1#get_}
}   xterm-tell $1
}   case $1 in
}   (get_(label|title))
}       read -t 2 -rk 3 esc || return 1
}       read -rsd $'\e'
}       read -rk 1 esc
}       ;;
}   (get_*)
}       read -t 2 -rk 2 esc || return 1
}       IFS=';' read -Arsd t
}       (( $#reply > 2 )) && shift reply
}       ;;
}   esac
}   return 0
} }

The above works flawlessly in 4.2.6, but in 4.3.4-dev-7 I can't seem to
stop it from echoing the terminal's response in a way that the user can
see it.  Even wrapping the whole thing in "stty -echo" doesn't help.

If I run

    xterm-tell get_position; IFS=';' read -Arsd t

from the command line, it works as expected.  It's only when running
it in a shell function that it misbehaves.  I've tried changing from
"-rk" to "-rsk" in each place it's used; doesn't seem to matter.

I've also redirected the output of "case ... esac" to /dev/null with
no better result.  The response IS getting seen by "read":

schaefer<524> xterm-ask get_position
^[[3;1016;546t%
schaefer<525> print $reply
1016 546
schaefer<526> unset reply
schaefer<527> xterm-tell get_position; IFS=';' read -Arsd t
schaefer<528> print $reply
1016 546

If I "set -x" the output appears immediately after the trace prints that
"read" is going to be executed, so *something* that "read" is doing is
causing the output to be echoed, I think:

: xterm-ask:5:case; case get_iconify (get_*)
: xterm-ask:9:case; read -t 2 -rsk 2 esc
^[[1t^[[1t: xterm-ask:10:case; IFS=';' : xterm-ask:10:case; read -Arsd t
: xterm-ask:11:case; ((  1 > 2  ))
: xterm-ask:13; return 0

I've tried removing the -t 2, skipping the "read -rk", etc.  No change.

This is really annoying.

Re: Misbehavior of "read" or ...?

[Peter Stephenson]

Bart Schaefer wrote:
> The above works flawlessly in 4.2.6, but in 4.3.4-dev-7 I can't seem to
> stop it from echoing the terminal's response in a way that the user can
> see it.  Even wrapping the whole thing in "stty -echo" doesn't help.

What terminal are you using?  It seems to work for me in xterm,
gnome-terminal, konsole on a Fedora Something i386 system.

pws

Re: Misbehavior of "read" or ...?

[Bart Schaefer]

On Jan 18,  6:05pm, Peter Stephenson wrote:
} Subject: Re: Misbehavior of "read" or ...?
}
} What terminal are you using?  It seems to work for me in xterm,
} gnome-terminal, konsole on a Fedora Something i386 system.

Plain 'ol xterm on CentOS 4 (RHEL4u6).

schaefer[568] xterm -e Src/zsh -f

torch% cd Functions/Misc 
torch% . ./xtermctl 
torch% xterm-ask position
^[[3;855;634t%
torch% 

My resources:

XTerm*cutToBeginningOfLine: false
XTerm*cutNewline: false
XTerm*LoginShell: true
XTerm*ReverseWrap: true
XTerm*Curses: true
XTerm*MultiScroll: true
XTerm*ScrollBar: true
XTerm*SaveLines: 1024
XTerm*ttyModes: erase ^?
XTerm*backarrowKey: false

schaefer[570] rpm -q xterm
xterm-192-8.el4


-- 

Re: idea for new feature (was: Re: sticky-note and zle bindings)

[Steven Lumos]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> On 1/17/08, Andy Spiegl <zsh.Andy@spiegl.de> wrote:
>> > The upshot is that this isn't a zsh feature -- it's a cooperative
>> > feature that requires effort from both the shell and whatever other
>> > user interface environment it's running inside.
>> Right, so let's start. :-)
>
> Here's something that may be of use.  Recent xterm has adopted window
> control sequences from dtterm, according to
> http://www.xfree86.org/current/ctlseqs.html, so zsh might have a
> chance at saving/restoring some window state.  I haven't tried Konsole
> but Gnome-terminal pays attention to a subset of this.  Other
> terminals I don't know.

I guess "recent" may be relative (Sun 1 you say?), but I've been using
the following for at least 7 years.  I do something like

  % xtctl size 100 60 move 0 0

all the time on XTerm, rxvt (cygwin no less), OSX Terminal.app, and
PuTTY.  That ctlseqs.ms certainly does get around....

(If it looks naive, it's because I was limiting it to Bourne shell,
mostly for fun.  At some point while implementing 'get' I gave up and
switched to bash, but it's been so long now that I don't remember why.)

Err, Gnus helpfully informed me that there was a literal ^[ and ^G in
there (Bourne shell...), so here's a link instead:
http://www.isri.unlv.edu/~slumos/hacks/xtctl.  It's mostly a curiosity
at this point anyway...

Steve