headers
Micah Cowan | 6 Mar 08:17
Gravatar

Why not nonblock by default?


Does anyone know, is there any particular reason why we don't make
nonblock the default? It's an annoyance to users when a display gets
hung and any windows connected with it get stuck, especially since
novice users are unlikely to realize that "nonblock 1" won't affect the
buggered display, and may not think to do C-a : at % nonblock on

I'd like to propose that the default value for defnonblock be changed
from "off" to something like, I dunno, 8 ? Or lower, if there's no
particular reason why we shouldn't.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
Permalink | Reply | 0 comments |
headers
Enrico Weigelt | 6 Mar 20:36
Picon

Cleanups branch


Hi folks,

I've did some cleanups (eg. fixing const char* warnings, missing
includes, etc):

    git://git.metux.de/screen-metux.git/ -> METUX.cleanup

cu
--

-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Juergen Weigert | 13 Mar 15:25
Picon
Gravatar

Re: Why not nonblock by default?

Uh, 
difficult matter....

In case of a slow line, e.g. dialup line (bandwidth) or overloaded line 
(high latency) we'd like screen to wait a bit and try to get the display right.

It is also an annoyance to users, when the scrollback buffer of their 
xterm/konsole/gnome-terminal does not contain *all* text. 
This requires 'nonblock off'.

(On the other hand:
 The current full blocking default also has the downside that as soon as an
 application becomes I/O-bound, screen becomes quite nonresponsive.
 $ cat hugefile
 CTRL-C
 CTRL-C
 ...
 may be difficult to interrupt.
)

I believe that nonblock is not the correct solution for fixing 
hung write() calls.  

I'd suggest screen should have an alarm() over each write()
and switch to nonblock, when the alarm() fires.
With a prominent Msg() saying so, as soon as the display works again.

        cheers,
                JW-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas | 15 Mar 13:19

Security bug - Password ignored


Hi!

Because this problem was found in the screen-users mailing list in 2004,
again 2008, and is still present, I'm writing to screen-devel:
I'm using screen in a ssh-Terminal (Putty)

.screenrc:
password
-> starting screen says "/home/Andreas/.screenrc: password: window required"

.screenrc:
password sg-md5-crypted
--> Screen asks for a password, but I can reattach with any/empty
password! (Screen asks for a a password!!)
So the user (typically typing in the correct password) believes,
that his sessions are secured, but they aren't!
Please tell me what to do ALSO via Email!
  andreas2 ((AT)) logic.univie.ac.at	(My Reply-to Header is Nobody!!)

Thanks, Andrew
Permalink | Reply | 0 comments |
headers
Micah Cowan | 17 Mar 18:19
Gravatar

Re: Security bug - Password ignored

Andreas wrote:
> Hi!
> 
> Because this problem was found in the screen-users mailing list in 2004,
> again 2008, and is still present, I'm writing to screen-devel:
> I'm using screen in a ssh-Terminal (Putty)
> 
> .screenrc:
> password
> -> starting screen says "/home/Andreas/.screenrc: password: window required"
> 
> .screenrc:
> password sg-md5-crypted
> --> Screen asks for a password, but I can reattach with any/empty
> password! (Screen asks for a a password!!)

I can't reproduce this in the current development sources (in fact, I
seem to get the opposite problem: no password is accepted).

--

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
Permalink | Reply | 0 comments |
headers
Micah Cowan | 17 Mar 18:23
Gravatar

Re: Security bug - Password ignored


(Sent to Andreas via Bcc, and screen-devel)

Andreas wrote:
> Please tell me what to do ALSO via Email!
>   andreas2 ((AT)) logic.univie.ac.at	(My Reply-to Header is Nobody!!)

This is too much to ask. If you don't provide a real email address in
the headers, this means we must type it in manually each time. Not only
that, but we must send the same mail twice each time, as just adding you
in the To or Cc fields will reveal your address on the list (which you
are presumably going to lengths to avoid). If you are not willing to
publish the address, you'll have to read the list (I have responded there).

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
Permalink | Reply | 0 comments |
headers
Ethan Mallove | 18 Mar 20:27
Picon

Terminal VIM run from xargs closes my GNU Screen window

Hello,

The below command causes my Screen window to close:

  $ touch a b c && ls -1 a b c | xargs vim
  Vim: Warning: Input is not from a terminal
  [then Screen window closes!]

There is no problem if I do the above outside of Screen (e.g., my
terminal window does not exit). And if I take xargs out of the
equation my Screen window does not close, e.g., this works fine:

  $ vim a b c

I'm not sure if this is a VIM, GNU Screen, and/or xargs issue (or
combination of one or more programs). It mostly affects my usage of
Screen, so I posted to this Screen list.

  $ screen --version
  Screen version 4.00.03 (FAU) 23-Oct-06
  $ uname -a
  SunOS ... 5.10 Generic_127111-07 sun4v sparc SUNW,Sun-Fire-T200
  $ vim --version
  VIM - Vi IMproved 7.2
  ...

Regards,
Ethan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Falor | 18 Mar 21:09
Picon
Gravatar

Re: Terminal VIM run from xargs closes my GNU Screen window

On Wed, Mar 18, 2009 at 02:27:27PM -0500, Ethan Mallove wrote:
> Hello,
> 
> The below command causes my Screen window to close:
> 
>   $ touch a b c && ls -1 a b c | xargs vim
>   Vim: Warning: Input is not from a terminal
>   [then Screen window closes!]

I would suspect that this has to do with xargs' handling of STDIN with
respect to fork().  It appears to me that xargs closes and reopens
STDIN to a different file descriptor before forking Vim.

Whenver Vim detects that STDIN is not connected to the terminal, it
freaks.  I've never gotten Vim to work interactively when on the
receiving end of a pipe. You can pipe it a string of normal mode
commands, as well as :command-line commands, and it will act as though
you typed those at the keyboard interactively.

Now, when I try to reproduce this, (within and without of screen) Vim
nags me about the input's origin, then lets me edit the files
interactively.  After I quit Vim, the terminal doesn't echo my
keystrokes back at me, and I have to issue a `reset` to get it back to
normal.

I get identical behavior in and out of screen, so I am not inclined to
blame it on screen.

Incidentally:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Micah Cowan | 18 Mar 21:33
Gravatar

[OT] Vim and stdin [Re: Terminal VIM run from xargs...]

Erik Falor wrote:
> I've never gotten Vim to work interactively when on the
> receiving end of a pipe.

Try "<something> | vim -". Vim will interpret stdin as a file to be
read, and attempt to look elsewhere for the controlling term.

--

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
Permalink | Reply | 0 comments |
headers
Micah Cowan | 18 Mar 21:39
Gravatar

Re: Terminal VIM run from xargs closes my GNU Screen window


Ethan Mallove wrote:
> Hello,
> 
> The below command causes my Screen window to close:
> 
>   $ touch a b c && ls -1 a b c | xargs vim
>   Vim: Warning: Input is not from a terminal
>   [then Screen window closes!]

FWIW, I can't produce this with Ubuntu's version of screen 4.0.3jw4 and
vim 7.1. However, after exiting vim, the terminal window is left in a
strange state (CR is no longer echoed locally, at least).

Is it only the screen window that closes, or the whole session? That is,
if you had multiple windows in screen (created via C-a c or similar), do
you then switch to a different screen window, or does the entire session
end and drop you to the parent shell? What happens when you try this
with "zombie qr" in your ~/.screenrc?

Also, what shell are you using, and is it the same in screen as it is
outside of it (do you have "shell" or "screen" commands in your
~/.screenrc)?

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane