On Tue, Jun 28, 2005 at 06:52:54AM -0500, Will Maier wrote:
> Why, though, does assigning the same escape from within screen cause the
> expected
> behavior (ie overrule bindings specified in *screenrc)? If the (only) problem
> were the 'bind' clauses that I found in my $SYSSCREENRC, I would expec
On Tue, Jun 28, 2005 at 11:15:07AM +0200, Michael Schroeder wrote:
> You probably have
>
> bind ^\
> bind \\
>
> somewhere in your (or the system's) screenrc file. Our example
> file contains this line because the default binding of the keys
> was to quit screen and so many users complain
On Jun 27, 05 21:49:20 -0500, Will Maier wrote:
> > > Also, a quick bonus question: any way to create a window as a zombie?
Hmm, isn't that a shell script wrapper waiting for a key press, then
starting the real application?
> I imagine I could do this with a little 'stuff'ing, but it's hardly wo
On Mon, 27 Jun 2005, Will Maier wrote:
Well, again, the thought of using /bin/true as a "locker" comes up (this
is settable as an an environment variable, $LOCKPRG, but apparently not
as a builtin, that way there would be only one prompt.
The unusual thing that the manpage mentions is that ap
On Mon, Jun 27, 2005 at 08:25:01PM -0400, Dan Mahoney, System Admin wrote:
> I'm having an issue of minor annoyance with screen and idle locking.
>
> I've got "idle 600 lockscreen" set in my .screenrc
> I also have a "password teH0wLIpW0gyQ" set (that's test, crypted).
>
> My problem is when the
On Mon, Jun 27, 2005 at 05:45:38PM -0500, Will Maier wrote:
> The escape characters set for the nested screens work -- sort of. Pressing
> CTRL-\ *does* allow me to go to the previous/next window, etc as normal.
> However, the key sequence I use to go to the most recent region (not just
> next/prev
