Subject: Promote Screen? Include .screenrc!

From: [email-masked]
Date: Fri, 26 Sep 2008 10:47:30 +0200

Hi,

I've been using screen for many years now, and find it indispensable.  Still,
I know quite some people, who never managed to get a hold of it. The initial
learning curve is too steep for them, I guess...

Some years ago, I tried several Linux-Distros (Debian, SuSe, Fedora) and found
the initial .screenrc-configuration-file quite, umm, minimalistic. 
(I don't know if that is still the case? Can anyone confirm?)

It took me a long time to adapt the .screenrc to my needs. In most cases, I
searched the web as well as this mailinglist (+archive) to find out what I needed...

So, my idea was:  Why not use the combined knowledge of the people
on this mailinglist to compile a user-friendly, yet powerful initial
.screenrc-configuration and ship it to the individual package-maintainers?
(The screen-wiki already links to some dotfiles which could be used for starters.)

I would be glad to hear your comments on this idea...

Best wishes,

Holger 

_______________________________________________
screen-users mailing list
[email-masked]
http://lists.gnu.org/mailman/listinfo/screen-users

---

From: "Thomas Adam" <[email-masked]>
Date: Sat, 27 Sep 2008 13:41:53 +0100

Hello --

> (The screen-wiki already links to some dotfiles which could be used for starters.)

It's a nice idea.  See:

http://savannah.gnu.org/bugs/index.php?24387

-- Thomas Adam

---

From: Mauro Lizaur <[email-masked]>
Date: Sat, 27 Sep 2008 12:04:22 -0300

> http://savannah.gnu.org/bugs/index.php?24387

It's a really good idea, also i think that a small example of how to use the hardstatus 
line (plus the backtick option) on the .screenrc would be great too.

Regards,
Mauro

-- 
JID: [email-masked]
http://lusers.com.ar/
2B82 A38D 1BA5 847A A74D  6C34 6AB7 9ED6 C8FD F9C1

---

From: "Eric S. Johansson" <[email-masked]>
Date: Tue, 30 Sep 2008 08:55:09 -0400

> learning curve is too steep for them, I guess...

I use screen because I have to, not because I want to. What I value most about
screen is the ability to preserve a running session should I lose my connection.
 What I value second is the ability to share a session.    What I value least is
the multiple windows stuff and all that crap... err, those features.

I found dtach which is 90% of what I need and I created a wrapper (Boleyn) to
try automatically reestablish connections on login but, I ran into some problems
and I haven't had time to revisit it.

If I were a code god (which I most certainly am not), I would give screen a mode
where it does nothing but share and preserve connections and reestablish a
connection automatically if one is available.  Although it probably be easier to
start with dtach if I can ever figure out how to differentiate between a "in
use" connection versus a detached connection.

However, if you're trying to push screen adoption, your suggestions are good
ones.  You could probably help matters/adoption if you created a "GUI" tool
usign dialogue with an eye to easing the option discovery process.

---

From: Mark Eichin <[email-masked]>
Date: Tue, 30 Sep 2008 13:29:23 -0400

Yeah, I don't quite see how a screenrc would help either; mine is
nine lines, but 5 of them are trivial choices, and the others are
arguably workarounds for screen bugs:

	vbell off
	escape ^\a
	# let prompts appear in the titlebar
	# any xterm, change xterm, change screen...
	termcapinfo xterm* hs:ts=\E]0;:fs=^G:ds=\E]0;^G hs:ts=\E]0;:fs=^G:ds=\E]0;^G 
	hardstatus on
	bind q windows
	# let xterm scrollback behave
	termcapinfo xterm* te@:ti@
	unsetenv DISPLAY
	unsetenv WINDOWID
	defscrollback 1000

and most of the time I go to a new machine, I only bother with the
escape setting.  (I do have a few uses of screen as an "end-user init"
where it runs a bunch of processes, but practically application
development, it isn't useful to beginners either...)

The real issue I've found getting people to use it is that you mostly
need to *show* them; the man page is a fine reference (it's one of the
ones that I reread every couple of years to look for new things to
use) but I'm a unix geek - I suspect a well done *screencast* would be
more useful than a screenrc...

---

From: Micah Cowan <[email-masked]>
Date: Wed, 01 Oct 2008 15:59:15 -0700

> (I don't know if that is still the case? Can anyone confirm?)

I think the main problem with this discussion is no one really has a
particularly clear understanding of what it is we're talking about
having. At least, I know I don't. I think it'd be more fruitful to
mention specific deficiencies or improvements that may be made to the
current example screenrc and/or etc/screenrc (from our sources,
obviously, and not any that might be packager-specific). A diff against
the currently-shipped screenrc, or even a wholly new one, with
justifications for why it's an improvement over its predecessor, would
help greatly.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/

---

From: [email-masked] (Trent W. Buck)
Date: Wed, 01 Oct 2008 11:18:40 +1000

[email-masked] writes:

> Some years ago, I tried several Linux distros and found /etc/screenrc
> quite minimalistic.  It took me a long time to adapt the .screenrc to
> my needs.

Screen definitely has a big problem with discoverability.  Very often,
I'll be chatting to someone and they'll say "oh wow, screen can do that?
I never knew!"  And "that" could be anything from auto-naming windows
with :shelltitle to connecting to talking to serial ttys (replacing
minicom) to entering latin-1 characters using :digraph.

(Incidentally Micah, implementing all the digraphs documented in the RFC
would be a neat Unicode-related enhancement.)

> .screenrc-configuration and ship it to the individual package-maintainers?

I'm strongly against integrators shipping their favourite customizations
as the default configuration.  Let me give an example: a few months ago,
RMS decided that the colour red was too hard to read on his terminal, so
he changed the DEFAULT emacs configuration so that comments have the
same colour as normal text on the terminal.  To get the old behaviour
back, I have to add about 30 lines to my .emacs -- whereas RMS could
have just added a single line to *his* emacs to turn that color off.

Summary: fixing unwanted changes to distro-specific on-by-default
features is difficult and annoying.  Don't make distro-specific tweaks
unless you have a REALLY good reason.

IMO a better approach would be to have a documentation resource that has
a number of articles that explain how to use Screen features in "real
world" scenarios.  For example, rather than just saying "use ^A^M to
turn monitoring on", you'd start with a problem "how do I know when
people are talking in IRC, using irssi?" and then discuss how to
implement it effectively -- which would include not only discussion of
:monitor, but also how to do things like turning off the clock in irssi,
so you don't get "spurious" activity every minute when it changes.

(I started writing a "Screen Hacks" book along these lines, but got
distracted appallingly quickly.)

If you just dump a bunch of .screenrcs somewhere with the (typically
limited) commentary to explain what each part does, all you'll end up
with is the scenario where people just copy-and-paste other people's
.screenrcs wholesale, with no understanding of what they do.  This tends
to cause regressions -- for example, someone might accidentally copy my
"sorendition = dd" line when they are trying to get my hardstatus
configuration, and then complain that their hardstatus line doesn't have
colour anymore.

---

From: [email-masked]
Date: Sun, 5 Oct 2008 14:50:41 +0200

Hi,

first of all:
Thanks to all for the positive feedback!

What became clear to me is that indeed it might be a tedious task to create a
full-fledged .screenrc that fits every user's needs.  This is just impossible as
the tasks that screen is used for are diverse.

But the most important point of this discussion is the reason that made me start
it:  Screen lacks hints for the initial user. Like said, the screen-newbie is
greeted with a minimal welcome message about legal issues, whereas IMHO he
should be told e.g. the most important key commands...

The second most important feature would be a reasonable caption line that
displays the list of screens and highlights the current one (as suggested by
Aaron Davies).

The caption need not be too fancy, like
____________________________________________________________________________________________________

caption always "%{rk}%H %{wk}%n %{gk}%c %{yk}%M%d %{wk}%?%-Lw%?%{bw}%n*%f %t%?(%u)%?%{wk}%?%+Lw%?"
____________________________________________________________________________________________________

but it should present at least the screen titles.
So I propose a minimal configuration like this:
____________________________________________________________________________________________________

caption always "%-Lw%{= W}%50>%n%f* %t%{-}%+Lw%<"
startup_message on
screen -t top 0 top 
screen -t bash 1 
____________________________________________________________________________________________________

The "top" window is created, so that the user can test the <CTRL>-<A>,<A>
functionality...

Additionally, the startup notification could also include the most important
key-bindings. Such as:
____________________________________________________________________________________________________

 Press <CTRL>-<A> <A> to switch to the last used screen window\n\
 Press <CTRL>-<A> <C> to create a new screen window\n\
 Press <CTRL>-<A> <w> to see a list of screen windows\n\
 Press <CTRL>-<A> <?> to see a short help page\n\
 \n\
 Also see the screen man page for extensive documentation\n\
____________________________________________________________________________________________________

PS: A good screencast would be a very good idea and a helful ressource. Right
    now, I don't have the time to do it, but if someone can recommend a good
    screenrecorder, I might look into this in a couple of months...

PPS:I once gave a short introductory talk about screen to my colleagues, and
    especially the reconnect feature was of interest to them. A couple of days
    later, I saw one colleague running several instances of screen on the server so
    that she could reconnect to several shell instances running batch jobs (instead
    of using ONE screen instance with several windows ;-> )

Best wishes,

Holger Dinkel

---

From: [email-masked] (Trent W. Buck)
Date: Mon, 06 Oct 2008 09:53:36 +1100

> The caption need not be too fancy, like

Here's a thought: maybe the hardstatus could be on by default, but set
to a "quick help" string like nano has.  E.g.

hardstatus string '^Ac: new window  ^An: next window  ^Ad: disconnect'

---

From: Mark Eichin <[email-masked]>
Date: Mon, 06 Oct 2008 14:20:00 -0400

>     of using ONE screen instance with several windows ;-> )

Eh, for some applications, multiple windows is wrong - if you're going
to have to "screen -x" multiple connections to them anyway, it's
actually cleaner to be able to manage them with names and "screen
-ls".  (This approach is particularly useful with, for example, a
"builder" account that runs autobuilders but different people may need
to check on...)

That said, yes, windows are a more "advanced" feature than just
attach/detach... but that doesn't actually mean they're *necessary*.