Re: gnu screen and resizing terminal window

[Tim Woodall]

On Wed, 26 Jan 2022, Bijan Soleymani wrote:


On 2022-01-26 5:55 p.m., Bijan Soleymani wrote:
Actually apparently putty does support remote resizing. It just seems that 
our systems lack the right termcap entries.


I managed to resize the putty window by running the command:
resize -s height width

so:
resize -s 24 80

Also adding this:
termcapinfo xterm WS=\E[8;%d;%dt

to:
/etc/screenrc

Allows screen to resize the putty session (with the :width and :height 
commands).


But when quitting/restarting screen it puts the putty and the screen session 
back to the original size.




Thanks, that gives me something to investigate. At the moment, adding
that causes the screen to resize to 80x24 when I attach or detatch which
is not what I want but it gives me something to explore.

Tim.

Re: gnu screen and resizing terminal window

[Tim Woodall]

On Wed, 26 Jan 2022, Bijan Soleymani wrote:




On 2022-01-26 1:45 p.m., Tim Woodall wrote:

I have to use PuTTY to connect to a debian server. For reasons that are
outwith my control the ssh session disconnects every 24 hrs.

Therefore I run screen so after reconnecting I can recover to whereever
I was at.

However, the PuTTY window does not resize to whatever it was previously.
I can find lots of questions asking how to turn this feature off but
nothing on why it doesn't work for me.


As far as I know this is not a screen feature. Putty controls the window 
size, it is determined by the default or whatever is saved for that session. 
You can change what happens when you resize the putty window on the machine 
running putty. There is no way for you to change the putty screen from the 
debian side.


Screen does provide commands to resize the virtual terminal, however neither 
putty nor xterm seem to support the termcap commands (apparently it is Z0 and 
Z1).


What happens when you try to resize the screen using screen's windowing 
commands:


^a : width 50
^a : height 15

(control-a, then colon, then width 50, then enter)

In my case I get a message that
Your termcap does not specify how to change the terminal's width to 50
and
Your termcap does not specify how to change the terminal's height to 15

That is with TERM set to xterm.



Thanks, that seems to be it.

I also get: (from outside screen)

$ resize 80 50
resize: Can't set window size under VT100 emulation

which I'm sure I already tested and it worked but I must have been doing
something different!

Re: gnu screen and resizing terminal window

[Bijan Soleymani]

On 2022-01-26 5:55 p.m., Bijan Soleymani wrote:
Actually apparently putty does support remote resizing. It just seems 
that our systems lack the right termcap entries.


I managed to resize the putty window by running the command:
resize -s height width

so:
resize -s 24 80

Also adding this:
termcapinfo xterm WS=\E[8;%d;%dt

to:
/etc/screenrc

Allows screen to resize the putty session (with the :width and :height 
commands).


But when quitting/restarting screen it puts the putty and the screen 
session back to the original size.


Bijan

Re: gnu screen and resizing terminal window

[Bijan Soleymani]

On 2022-01-26 5:42 p.m., Bijan Soleymani wrote:
As far as I know this is not a screen feature. Putty controls the window 
size, it is determined by the default or whatever is saved for that 
session. You can change what happens when you resize the putty window on 
the machine running putty. There is no way for you to change the putty 
screen from the debian side.


Actually apparently putty does support remote resizing. It just seems 
that our systems lack the right termcap entries.


Bijan

Re: gnu screen and resizing terminal window

[Bijan Soleymani]

On 2022-01-26 1:45 p.m., Tim Woodall wrote:

I have to use PuTTY to connect to a debian server. For reasons that are
outwith my control the ssh session disconnects every 24 hrs.

Therefore I run screen so after reconnecting I can recover to whereever
I was at.

However, the PuTTY window does not resize to whatever it was previously.
I can find lots of questions asking how to turn this feature off but
nothing on why it doesn't work for me.


As far as I know this is not a screen feature. Putty controls the window 
size, it is determined by the default or whatever is saved for that 
session. You can change what happens when you resize the putty window on 
the machine running putty. There is no way for you to change the putty 
screen from the debian side.


Screen does provide commands to resize the virtual terminal, however 
neither putty nor xterm seem to support the termcap commands (apparently 
it is Z0 and Z1).


What happens when you try to resize the screen using screen's windowing 
commands:


^a : width 50
^a : height 15

(control-a, then colon, then width 50, then enter)

In my case I get a message that
Your termcap does not specify how to change the terminal's width to 50
and
Your termcap does not specify how to change the terminal's height to 15

That is with TERM set to xterm.

Bijan

Re: gnu screen and resizing terminal window

[Andrei POPESCU]

On Mi, 26 ian 22, 18:45:41, Tim Woodall wrote:
> I have to use PuTTY to connect to a debian server. For reasons that are
> outwith my control the ssh session disconnects every 24 hrs.
> 
> Therefore I run screen so after reconnecting I can recover to whereever
> I was at.
> 
> However, the PuTTY window does not resize to whatever it was previously.
> I can find lots of questions asking how to turn this feature off but
> nothing on why it doesn't work for me.
> 
> I'm not wedded to screen - about the only feature I'm using is the
> scrollback buffer - so a change change to tmux is possible if that will
> help but I'd really like the resizing to work. Does this work for
> anyone?

As far as I recall the screen window size is limited to the smallest 
terminal that is connected to the particular session.

Maybe screen thinks there are other connections still present?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

gnu screen and resizing terminal window

[Tim Woodall]

I have to use PuTTY to connect to a debian server. For reasons that are
outwith my control the ssh session disconnects every 24 hrs.

Therefore I run screen so after reconnecting I can recover to whereever
I was at.

However, the PuTTY window does not resize to whatever it was previously.
I can find lots of questions asking how to turn this feature off but
nothing on why it doesn't work for me.

I'm not wedded to screen - about the only feature I'm using is the
scrollback buffer - so a change change to tmux is possible if that will
help but I'd really like the resizing to work. Does this work for
anyone?

(long term I'm hoping to get permission to install cygwin and then use a
X server and xterms and ssh from inside them or, even better, a debian
laptop, but for now I'm stuck with putty)

Tim.

Re: Keyboard prevents screensaver & scrolling terminal window

[Jeff]

Hi Thomas,

On 19/10/2021 22:31, Thomas Schmitt wrote:

Seems to be considered a firmware bug of the keyboard which might become
repairable in the future:
   https://bbs.archlinux.org/viewtopic.php?id=267365


Oh, yes. Even better. Worked a treat.

Thanks again

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Re: Keyboard prevents screensaver & scrolling terminal window

[Thomas Schmitt]

Hi,

Jeff wrote:
> KeyPress event, [...]
>   keycode 248

Seems to be considered a firmware bug of the keyboard which might become
repairable in the future:
  https://bbs.archlinux.org/viewtopic.php?id=267365


> https://forums.linuxmint.com/viewtopic.php?t=105326

Such old wisdom will probably fade away with the demise of X.
I wonder if the udev rule in above bbs.archlinux.org thread will survive
longer.


Have a nice day :)

Thomas

Re: Keyboard prevents screensaver & scrolling terminal window

[Jeff]

Hi Thomas,

Thanks for your suggestion.

On 17/10/2021 13:53, Thomas Schmitt wrote:

If your suspicion is right, xev should show lots of such Key* events
as soon as its receiver window gets the focus, without you pressing any
key at the keyboard. In that case, end xev and look at the messages
on the terminal window or in file  /tmp/xev.log .


Yup:

KeyPress event, serial 68, synthetic NO, window 0x661,
 root 0x238, subw 0x0, time 3095352, (168,-22), root:(1030,437),
 state 0x110, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
 XLookupString gives 0 bytes:
 XmbLookupString gives 0 bytes:
 XFilterEvent returns: False

Which sent me here:

https://forums.linuxmint.com/viewtopic.php?t=105326

In my case, there were multiple devices called "Cherry Keyboard", so I 
used the following to disable the one sending the spurious events:


Section "InputClass"
Identifier "disable cherry key"
MatchDevicePath "/dev/input/event4"
Option "Ignore" "on"
EndSection

Thanks for the help!

Regards

Jeff



OpenPGP_signature
Description: OpenPGP digital signature

Re: Keyboard prevents screensaver & scrolling terminal window

[Thomas Schmitt]

Hi,

due to the lack of other proposals i now come up with something ancient.
If you are still running the X Window System, then there should be a
program named xev.
Start it in a dedicated terminal window which will get its verbous
text output. Redirect a copy of that output to a file:

  xev | tee -i /tmp/xev.log

xev will pop up a small window, of which it will report the received
X events. Among them are input events of keyboard and mouse.
So give this small window the input focus. (I.e. move mouse cursor into
it. Maybe you need to click at it. Whatever your desktop expects.)

You will see a little storm of events like

  PropertyNotify event, serial 8, synthetic NO, window 0x1141,
  atom 0x27 (WM_NAME), time 382397390, state PropertyNewValue

  ... more window setup events ...

  MotionNotify event, serial 40, synthetic NO, window 0x1141,
  root 0xa4, subw 0x0, time 382398675, (59,148), root:(390,245),
  state 0x0, is_hint 0, same_screen YES

  ... more mouse events ...

Next take your hands off mouse and keyboard.
At some point - at least for me - xev stops to report new events and i
can make key tests. E.g. i press "Shift" and see

  KeyPress event, serial 40, synthetic NO, window 0x1141,
  root 0xa4, subw 0x0, time 382860609, (81,134), root:(412,231),
  state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
  XLookupString gives 0 bytes:
  XmbLookupString gives 0 bytes:
  XFilterEvent returns: False

  KeyRelease event, serial 40, synthetic NO, window 0x1141,
  root 0xa4, subw 0x0, time 382860680, (81,134), root:(412,231),
  state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
  XLookupString gives 0 bytes:
  XFilterEvent returns: False

In order to end the program, i put the input focus on the terminal
window, where it reports its events, and press Ctrl+C.

If your suspicion is right, xev should show lots of such Key* events
as soon as its receiver window gets the focus, without you pressing any
key at the keyboard. In that case, end xev and look at the messages
on the terminal window or in file  /tmp/xev.log .


Have a nice day :)

Thomas

Keyboard prevents screensaver & scrolling terminal window

[Jeff]

Hallo!

I picked up a second-hand Cherry MX 3 keyboard some time ago. The feel 
is very good, but when it is plugged in, I can no longer scroll the 
active terminal window, and the screensaver no longer activates.


I can scroll inactive terminal windows, and everything returns to normal 
if I unplug it.


It is as if the keyboard is constantly sending invisible keystrokes 
(e.g. shift or control), but otherwise it works fine.


Is this a fault with the keyboard, or am I missing a setting somewhere?

Regards

Jeff

Please keep me in cc, as I am not subscribed to the list.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Terminal window shrinks into title bar.....

[Greg Wooledge]

On Tue, Nov 10, 2020 at 07:46:37AM -0500, Greg Wooledge wrote:
> So, if you comment out the "Mouse 4" and "Mouse 5" lines there (and
> restart fvwm), I bet that would disable the WindowShade binding to
> the scroll wheel.  You could still activate or deactivate it through
> the menus, assuming you leave those in place.

In case it wasn't clear, when I say "comment out", what I really
mean is "copy this config file to ~/.fvwm/config if you haven't already,
and then edit ~/.fvwm/config".

Don't make changes to /usr/share/fvwm/*.

Re: Terminal window shrinks into title bar.....

[Greg Wooledge]

On Tue, Nov 10, 2020 at 11:31:22PM +1100, David wrote:
> I did a quick search for a fvwm manpage and found:
>   https://manpages.debian.org/buster/fvwm/fvwm.1.en.html
> """
> WindowShade [bool]
>   Toggles the window shade feature for titled windows.
>   Windows in the shaded state only display a title-bar.
> """
> so I guess you need to unbind whatever changes that
> state from your mouse button and key bindings.

Very interesting.  A whole entire feature that I never knew about because
I'm using my legacy fvwm config file (which predates this feature and
doesn't make use of it), and because my mouse doesn't have a scroll
wheel in the first place.

Looking at what I believe to be the default Debian fvwm config file
(/usr/share/fvwm/default-config/config) I find this chunk:

#   TitleBar: Click to Raise, Move, Double Click to Maximize
# Mouse Wheel Up/Down to WindowShade On/Off
#   Borders: Click to raise, Move to Resize
#   Root Window: Left Click - Main Menu
#Right Click - WindowOps Menu
#Middle Click - Window List Menu
#   Right click TitleBar/Borders for WindowOps Menu
Mouse 1 TA RaiseMoveX Move Maximize
Mouse 1 FS   A RaiseMove Resize
Mouse 4 TA WindowShade True
Mouse 5 TA WindowShade False
Mouse 1 RA Menu MenuFvwmRoot
Mouse 2 RA WindowList
Mouse 3 RA Menu MenuWindowOpsLong
Mouse 1 IA RaiseMoveX Move "Iconify off"
Mouse 3 TA Menu MenuWindowOps
Mouse 3 IA Menu MenuIconOps

So, if you comment out the "Mouse 4" and "Mouse 5" lines there (and
restart fvwm), I bet that would disable the WindowShade binding to
the scroll wheel.  You could still activate or deactivate it through
the menus, assuming you leave those in place.

Re: Terminal window shrinks into title bar.....

[David]

On Tue, 10 Nov 2020 at 18:21, Charlie  wrote:

> FVWM window manager

On Tue, 10 Nov 2020 at 22:55, Carl Fink  wrote:
> On 11/10/20 1:58 AM, Charlie wrote:

> > Sometimes I press some key combination by accident and the terminal
> > window shrinks back into the title bar.

> > I must have the terminology wrong, because am unable to discover how to
> > reverse this behaviour. no matter what wordage is used to google.

> > If anyone has an idea, it would be appreciated.

> It's called "roll window up" and "roll window down," by the way.

I don't usually talk about things that I'm completely ignorant of
(I don't use fvwm) but here we go ...

I did a quick search for a fvwm manpage and found:
  https://manpages.debian.org/buster/fvwm/fvwm.1.en.html
"""
WindowShade [bool]
  Toggles the window shade feature for titled windows.
  Windows in the shaded state only display a title-bar.
"""
so I guess you need to unbind whatever changes that
state from your mouse button and key bindings.

Re: Terminal window shrinks into title bar.....

[Carl Fink]

On 11/10/20 1:58 AM, Charlie wrote:

Sometimes I press some key combination by accident and the terminal
window shrinks back into the title bar.

I must have the terminology wrong, because am unable to discover how to
reverse this behaviour. no matter what wordage is used to google.

If anyone has an idea, it would be appreciated.


When I annoy myself by doing that, it's by accidentally using the
mouse scroll wheel over the title bar. Scroll down over the title
bar to reverse.

It's called "roll window up" and "roll window down," by the way.
--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Terminal window shrinks into title bar.....

[Keith Bainbridge]

On 10/11/20 5:58 pm, Charlie wrote:


From my keyboard:

Debian Bulleye 5.8.0-2-amd64
FVWM window manager

Sometimes I press some key combination by accident and the terminal
window shrinks back into the title bar.

I must have the terminology wrong, because am unable to discover how to
reverse this behaviour. no matter what wordage is used to google.

If anyone has an idea, it would be appreciated.

TIA
Charlie

East Gippsland Wildlife Rehabilitators Inc..
http://www.egwildlife.com.au/




Sounds like you have a keyboard shortcut set to minimise your current
window.

Generic answer: Search keyboard in your menu and look through the
'window' options.   If you need more, perhaps search 'keyboard shortcuts
FVWM'


When are you opening? Looks like we may be able to visit you shortly.
We're due to visit RI shortly.

--
Keith Bainbridge

ke1thozgro...@gmx.com

Terminal window shrinks into title bar.....

[Charlie]

From my keyboard:

Debian Bulleye 5.8.0-2-amd64
FVWM window manager

Sometimes I press some key combination by accident and the terminal
window shrinks back into the title bar.

I must have the terminology wrong, because am unable to discover how to
reverse this behaviour. no matter what wordage is used to google.

If anyone has an idea, it would be appreciated.

TIA
Charlie

East Gippsland Wildlife Rehabilitators Inc..
   http://www.egwildlife.com.au/

-- 
Registered Linux User:- 329524

***

Don’t explain your philosophy. Embody it. Epictetus

***
Debian GNU/Linux - Magic indeed.

-

Re: terminal window returns prompt (was: dash/bash: exec behaviour change on Buster)

[John Crawley]

On 2019-07-18 10:29, John Crawley wrote:

Hi tomas and Thomas, thanks for your input.
I think I have a basic idea of what exec does.
However, try running in a terminal:
echo $$
exec 
#Then, in the new terminal:
echo $$

The two PIDs are different! (or were here)

On 2019-07-17 17:37, Thomas Schmitt wrote:

John Crawley wrote:

In Buster, the launching dash shell dies *immediately* and the bash
prompt returns, even while the new window is still open.

tomas wrote:

that most probably is due to a change
in behaviour of "x-terminal-emulator".

My suspicion too. If the x-terminal-emulator puts itself into background,
then the starting terminal ends immediately.


The Debian alternative system is just a series of symlinks.
/usr/bin/x-terminal-emulator points to 
/etc/alternatives/x-terminal-emulator which in turn points to (on my 
system) /usr/bin/urxvt.

It's hard to imagine a stretch>buster change in behaviour, really.


What happens if you run
   x-terminal-emulator
without "exec". Does the shell prompt come back immediately ?


No. Not on Stretch. x-terminal-emulator, or a specific terminal call, in 
every case the prompt waits till the called window is closed.

---
But... on Buster it depends on exactly what terminal it's currently 
pointing to. I've tried a few that were on my test system and:


gnome-terminal or gnome-terminal.wrapper and lxterminal both return the 
prompt immediately. (*.wrapper scripts are for x-terminal-emulator 
compatibility, but don't seem to affect this issue.)


urxvt, xterm, mate-terminal{,.wrapper}, xfce4-terminal{,.wrapper} and 
terminator all hold the prompt till the window is closed.

---

On my test system, at the time, x-terminal-emulator pointed to 
lxterminal, so it looks as if "exec" has nothing to do with this.


I'll have to do a bit of googling about why lxterminal and 
gnome-terminal's behaviour has changed like this, though. Unless you 
folks have any ideas?


I'd like my scripts to work the same regardless of what terminal a user 
has set as x-terminal-emulator.




It seems gnome-terminal has a complicated server-client setup, but the 
immediate prompt return can be avoided with 'gnome-terminal --wait':

https://bugzilla.gnome.org/show_bug.cgi?id=707899

Lxterminal (which I was more interested in) says "all instances of the 
terminal are sharing a single process" which explains that, but it can 
be bypassed with '--no-remote'.


So a check if x-terminal-emulator points to lxterminal and if so adding 
'--no-remote' should cover my needs. Sorry for the noise.


--
John

Re: How to forcibly abort a command in a terminal window?

[Vincent Lefevre]

On 2016-09-05 09:27:06 -0700, Charlie Kravetz wrote:
> Psychological or not, it certainly works for me. By killing the job
> number, it forces it to stop on my computer. 

Yes, on *your* computer. But for the OP, it appears that the
process was not killable (yet), probably because it was in
kernel mode.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How to forcibly abort a command in a terminal window?

[Nicolas George]

Le decadi 20 fructidor, an CCXXIV, Dutch Ingraham a écrit :
> > SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
> > default. But both have the same default action of interrupting the process.
> The last sentence is inaccurate and imprecise.  See man 7 signal, and esp. 
> under
> the column "Action."

I indeed misremembered the number for SIGINT; thanks for noticing. With that
mistake fixed, I think my sentence becomes exact.


signature.asc
Description: Digital signature

Re: How to forcibly abort a command in a terminal window?

[Charlie Kravetz]

On Mon, 5 Sep 2016 17:19:38 +0200
Nicolas George  wrote:

>Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
>> I open a second terminal, then use ps -A to find the command. I can
>> kill it with "sudo kill " which kills the job number. It is not
>> always instant, but faster than ctrl-c for some things, including rsync
>> and cp .  
>
>Not true.
>
>The only difference between your method and kill is that kill will send
>SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
>default. But both have the same default action of interrupting the process.
>
>cp does not handle signals explicitly, leaving them to their default
>behaviour. rsync catches signals, but with the same handler for SIGINT and
>SIGTERM. Therefore, the effect of Ctrl-C and kill on both is exactly the
>same. The difference you observe is certainly only psychological.
>
>Note that the same does not apply to "kill -9": SIGKILL, number 9, can not
>be caught by processes. Yet, since cp does not catch signals, Ctrl-C, kill
>or kill -9 will have the same effect. On rsync, "kill -9" will prevent it
>from cleaning up temp files, which can be a life saver if you forgot the -P
>option and already copied a big chunk of data over a slow link.
>
>Also note that other applications may behave differently. I have noticed
>that Python applications using Qt ignore SIGINT for no apparent reason
>except annoy developers. Knowing ^\, i.e. SIGQUIT, is useful in that kind of
>cases, even though this is not the purpose of SIGQUIT.
>
>Regards,
>

Psychological or not, it certainly works for me. By killing the job
number, it forces it to stop on my computer. 

-- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

Re: How to forcibly abort a command in a terminal window?

[Dutch Ingraham]

On Mon, Sep 05, 2016 at 05:19:38PM +0200, Nicolas George wrote:
> Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
> SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
> default. But both have the same default action of interrupting the process.

The last sentence is inaccurate and imprecise.  See man 7 signal, and esp. under
the column "Action."

Re: How to forcibly abort a command in a terminal window?

[Nicolas George]

Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
> I open a second terminal, then use ps -A to find the command. I can
> kill it with "sudo kill " which kills the job number. It is not
> always instant, but faster than ctrl-c for some things, including rsync
> and cp .

Not true.

The only difference between your method and kill is that kill will send
SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
default. But both have the same default action of interrupting the process.

cp does not handle signals explicitly, leaving them to their default
behaviour. rsync catches signals, but with the same handler for SIGINT and
SIGTERM. Therefore, the effect of Ctrl-C and kill on both is exactly the
same. The difference you observe is certainly only psychological.

Note that the same does not apply to "kill -9": SIGKILL, number 9, can not
be caught by processes. Yet, since cp does not catch signals, Ctrl-C, kill
or kill -9 will have the same effect. On rsync, "kill -9" will prevent it
from cleaning up temp files, which can be a life saver if you forgot the -P
option and already copied a big chunk of data over a slow link.

Also note that other applications may behave differently. I have noticed
that Python applications using Qt ignore SIGINT for no apparent reason
except annoy developers. Knowing ^\, i.e. SIGQUIT, is useful in that kind of
cases, even though this is not the purpose of SIGQUIT.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: How to forcibly abort a command in a terminal window?

[Charlie Kravetz]

On Mon, 5 Sep 2016 09:06:27 -0500
Richard Owlett  wrote:

>On 9/5/2016 8:35 AM, Jonathan Dowland wrote:
>> On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:  
>>> Thank you.
>>> Sometimes harware reset is the only thing.
>>> The cp command was crudded up by human error ;/  
>>
>> Your ^C would eventually be honoured by cp. The result will be an incomplete
>> copy, but the filesystem should be in a consistent state. Performing a 
>> hardware
>> reset could result in filesystem corruption (which a journalled filesystem
>> would correct: but not something like FAT32 as commonly used on USB sticks).
>>  
>
> promptness of abort was higher priority than file system 
>integretity.
>I date from 8085 being a new device ;/
>
>

I open a second terminal, then use ps -A to find the command. I can
kill it with "sudo kill " which kills the job number. It is not
always instant, but faster than ctrl-c for some things, including rsync
and cp .

-- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

Re: How to forcibly abort a command in a terminal window?

[Richard Owlett]

On 9/5/2016 8:35 AM, Jonathan Dowland wrote:

On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:

Thank you.
Sometimes harware reset is the only thing.
The cp command was crudded up by human error ;/


Your ^C would eventually be honoured by cp. The result will be an incomplete
copy, but the filesystem should be in a consistent state. Performing a hardware
reset could result in filesystem corruption (which a journalled filesystem
would correct: but not something like FAT32 as commonly used on USB sticks).



 promptness of abort was higher priority than file system 
integretity.

I date from 8085 being a new device ;/

Re: How to forcibly abort a command in a terminal window?

[Jonathan Dowland]

On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:
> Thank you.
> Sometimes harware reset is the only thing.
> The cp command was crudded up by human error ;/

Your ^C would eventually be honoured by cp. The result will be an incomplete
copy, but the filesystem should be in a consistent state. Performing a hardware
reset could result in filesystem corruption (which a journalled filesystem
would correct: but not something like FAT32 as commonly used on USB sticks).


signature.asc
Description: Digital signature

Re: How to forcibly abort a command in a terminal window?

[Richard Owlett]

On 9/5/2016 7:28 AM, Henrique de Moraes Holschuh wrote:

On Mon, 05 Sep 2016, Richard Owlett wrote:

I realized I had miss-specified options. As data was multiple GB and target
was a USB connected flash drive I wished an immediate termination.


Usually there is no clean way to do this, and you have to wait for the
process to notice the signal, and abort.


It seems there should be a better option?


There is none, at least for "cp" and just about everything else that
does normal writes (i.e. not direct I/O bypassing the kernel page
cache).

Maybe doing direct I/O using "dd o=direct" with a suitable (not too big)
buffer size would work differently, but I am not sure about that at all.

Anyway, from what you described, a lot of data to write was already
submitted by "cp" to the kernel, and the "cp" process would be in "D"
(uninterruptible sleep) state because it accumulated too many dirty
pages (pending writes) already and was still trying to queue up more
writes.

Eventually, the kernel would have flushed enough data to the device and
would decide to waken "cp" up to get more data to write, at which point
"cp" would notice the SIGINT from ^C, and abort.  The kernel would
continue to flush the remaining data that had already been submitted for
writing, though, so device writes would not immediately stop.



Thank you.
Sometimes harware reset is the only thing.
The cp command was crudded up by human error ;/

Re: How to forcibly abort a command in a terminal window?

[Henrique de Moraes Holschuh]

On Mon, 05 Sep 2016, Richard Owlett wrote:
> I realized I had miss-specified options. As data was multiple GB and target
> was a USB connected flash drive I wished an immediate termination.

Usually there is no clean way to do this, and you have to wait for the
process to notice the signal, and abort.

> It seems there should be a better option?

There is none, at least for "cp" and just about everything else that
does normal writes (i.e. not direct I/O bypassing the kernel page
cache).

Maybe doing direct I/O using "dd o=direct" with a suitable (not too big)
buffer size would work differently, but I am not sure about that at all.

Anyway, from what you described, a lot of data to write was already
submitted by "cp" to the kernel, and the "cp" process would be in "D"
(uninterruptible sleep) state because it accumulated too many dirty
pages (pending writes) already and was still trying to queue up more
writes.

Eventually, the kernel would have flushed enough data to the device and
would decide to waken "cp" up to get more data to write, at which point
"cp" would notice the SIGINT from ^C, and abort.  The kernel would
continue to flush the remaining data that had already been submitted for
writing, though, so device writes would not immediately stop.

-- 
  Henrique Holschuh

How to forcibly abort a command in a terminal window?

[Richard Owlett]

The problem occurred when using cp to copy contents of one 
partition to another.
I realized I had miss-specified options. As data was multiple GB 
and target was a USB connected flash drive I wished an immediate 
termination.


Cntl-C had no apparent result.
Closing terminal window apparently did not abort operation - as 
indicated by activity light on flash drive continuing to blink.

Unmounting device worked.

It seems there should be a better option?
TIA

Chrome grabs focus from terminal window

[Joel Roth]

Hi List,

I'm running sid with i3 as window manager.
With Google chrome running, every few minutes,
the focus jumps to chrome. 

Too bad, as chrome has been excellent
in other ways.

Is that a bug or the future?
-- 
Joel Roth
  


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131219112443.GA30838@sprite

Re: Chrome grabs focus from terminal window

[Bob Proulx]

Joel Roth wrote:
 I'm running sid with i3 as window manager.
 With Google chrome running, every few minutes,
 the focus jumps to chrome. 

Is it really chrome or really chromium?

 Too bad, as chrome has been excellent in other ways.

Are you running an extension that might be popping up a window or
otherwise interacting with the window manager every few minutes?  Try
running chrome without any extensions to verify that it is bare chrome
and not an extension.  Is it really something in i3?  Try running a
different window manager for testing and see if the problem follows
chrome or follows the window manager.

 Is that a bug or the future?

I am using awesome (another tiling window manager) with chromium and I
do not see the behavior you are seeing.

Bob


signature.asc
Description: Digital signature

Re: Chrome grabs focus from terminal window

[Joel Roth]

Bob Proulx wrote:
 Joel Roth wrote:
  I'm running sid with i3 as window manager.
  With Google chrome running, every few minutes,
  the focus jumps to chrome. 
 
 Is it really chrome or really chromium?

Got it! I was inadvertently activating the Windows-key
semicolon combination which is a key binding of i3.

Thanks 
 
  Too bad, as chrome has been excellent in other ways.
 
 Are you running an extension that might be popping up a window or
 otherwise interacting with the window manager every few minutes?  Try
 running chrome without any extensions to verify that it is bare chrome
 and not an extension.  Is it really something in i3?  Try running a
 different window manager for testing and see if the problem follows
 chrome or follows the window manager.
 
  Is that a bug or the future?
 
 I am using awesome (another tiling window manager) with chromium and I
 do not see the behavior you are seeing.
 
 Bob



-- 
Joel Roth
  


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131220062519.GA28003@sprite

Re: Cmd Line not wrapping in gnome terminal window

[Kenneth Karlsen]

Sridhar M.A. wrote:

On Thu, Jan 29, 2009 at 10:43:08PM -0600, Dennis Wicks wrote:
  
The mouse will make the window bigger, but it doesn't change the font 
size!!



You could try to hold down shift and use the + and - on the numerical 
keypad to change the font and windowsize.

It works for me in enlightenment.
Regards Kenneth


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Solved Re: Cmd Line not wrapping in gnome terminal window

[Andrew Sackville-West]

On Sat, Jan 31, 2009 at 01:05:48AM -0600, Ron Johnson wrote:
 On 01/30/2009 11:58 PM, Daniel Burrows wrote:
 On Fri, Jan 30, 2009 at 02:51:35PM -0600, Dennis Wicks w...@mgssub.com was 
 heard to say:
 Thanks for the insight! I'll remember to use TERM when I have to kill 
 so errant process. It might save me a headache in the future!

   The difference between TERM and KILL, btw, is that TERM asks the
 program to shut down, whereas KILL just stops it instantly.  So
 programs killed with TERM can run cleanup actions before they shut
 down,

 I 'kill -15' iceweasel whenever I need to log out but want to retain all 
 my windows and tabs.

you may already know this, but iceweasel 3 does this for you. ctrl-q
and then enter (I think it's the default option, save session for
next time).

A


signature.asc
Description: Digital signature

Re: Cmd Line not wrapping in gnome terminal window

[Daniel Burrows]

On Thu, Jan 29, 2009 at 09:21:21PM -0600, Dennis Wicks w...@mgssub.com was 
heard to say:
 I have just discovered that the command line in a gnome terminal window 
 doesn't wrap correctly. Instead of doing a line feed and continuing on 
 the next line it just returns to the beginning of the current line and 
 writes over it.

  That sounds like something left your terminal in a bad state.  Does
running reset help?

  Daniel


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Solved Re: Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Daniel Burrows wrote the following on 01/30/2009 09:46 AM:

On Thu, Jan 29, 2009 at 09:21:21PM -0600, Dennis Wicks w...@mgssub.com was 
heard to say:
I have just discovered that the command line in a gnome terminal window 
doesn't wrap correctly. Instead of doing a line feed and continuing on 
the next line it just returns to the beginning of the current line and 
writes over it.


  That sounds like something left your terminal in a bad state.  Does
running reset help?

  Daniel




Daniel;

No, reset didn't do it, but your comment gave me an idea.

I opened a new terminal window and it worked just fine!

I had eight terminal windows open in various workspaces and 
they all malfunctioned the same way. After your suggestion I 
opened another terminal window, didn't close the others, and 
it worked! Just on a hunch I tried one of the others, and 
now they *all* work as they should! Exceeding strange! But I 
am now a happy camper, or would that be happy hacker?


Any way, thanks for the help and suggestions Ron and Daniel!

Good Luck!!
Dennis


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Solved Re: Cmd Line not wrapping in gnome terminal window

[Ken Irving]

On Fri, Jan 30, 2009 at 10:28:03AM -0600, Dennis Wicks wrote:
 Daniel Burrows wrote the following on 01/30/2009 09:46 AM:
 On Thu, Jan 29, 2009 at 09:21:21PM -0600, Dennis Wicks w...@mgssub.com was 
 heard to say:
 I have just discovered that the command line in a gnome terminal 
 window doesn't wrap correctly. Instead of doing a line feed and 
 continuing on the next line it just returns to the beginning of the 
 current line and writes over it.

   That sounds like something left your terminal in a bad state.  Does
 running reset help?

 No, reset didn't do it, but your comment gave me an idea.

 I opened a new terminal window and it worked just fine!

 I had eight terminal windows open in various workspaces and they all 
 malfunctioned the same way. After your suggestion I opened another 
 terminal window, didn't close the others, and it worked! Just on a hunch 
 I tried one of the others, and now they *all* work as they should! 
 Exceeding strange! But I am now a happy camper, or would that be happy 
 hacker?

It might be useful to compare the terminal settings in the `bad' vs `good'
cases, e.g., using stty -a  bad, etc..   You might be able to find something
to tweak to fix that particular problem.

Well behaved programs should return the terminal to its original state,
but maybe that didn't happen.  Killing programs with the KILL (-9)
signal would probably have this effect, vs using the default TERM (-15). 

-- 
Ken Irving


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Solved Re: Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Ken Irving wrote the following on 01/30/2009 01:30 PM:



It might be useful to compare the terminal settings in the `bad' vs `good'
cases, e.g., using stty -a  bad, etc..   You might be able to find something
to tweak to fix that particular problem.

Well behaved programs should return the terminal to its original state,
but maybe that didn't happen.  Killing programs with the KILL (-9)
signal would probably have this effect, vs using the default TERM (-15). 

All of the terminal windows are bash sessions started with 
the same shortcut. As far as I can tell they all started 
malfunctioning at the same time and all started working 
again at the same time. Of course not every command that I 
type takes more than one line so it would be hard to tell 
exactly when the problem started. I do know that 
starting/opening another window fixed the problem in all of 
the open windows/sessions.


More likely opening another window fetched a clean version 
of some module or control file that they all use.


Thanks for the insight! I'll remember to use TERM when I 
have to kill so errant process. It might save me a headache 
in the future!



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Sridhar M.A.]

On Thu, Jan 29, 2009 at 10:43:08PM -0600, Dennis Wicks wrote:

 The mouse will make the window bigger, but it doesn't change the font 
 size!!

xterm has a neat feature. Ctrl-right lick of the mouse in an xterm will
pop up a menu where you can choose the font size, etc. In case you need
to make them permanent, you have to put the settings in ~/.Xdefaults or
~/.Xresources. Mine has the following :

XTerm*foreground: black
XTerm*background: grey
XTerm*VT100.font: 10x20
XTerm*LoginShell: true
XTerm*ScrollBar:  true
XTerm*colorMode: on

rxvt.font: 9x15
rxvt.loginShell: true
rxvt.background: black
rxvt.foreground: white
rxvt.cursorColor: green

Aterm.font: 9x15
Aterm*scrollBar: false
Aterm*loginShell: true
ATerm*background: grey
Aterm*font: -misc-fixed-medium-r-normal-*-14-*-*-*-c-*-iso8859-15
Aterm*geometry: 80x40

Regards,

-- 
Sridhar M.A. GPG KeyID : F6A35935
  Fingerprint: D172 22C4 7CDC D9CD 62B5  55C1 2A69 D5D8 F6A3 5935

BOFH excuse #256:

You need to install an RTFM interface.


signature.asc
Description: Digital signature

Re: Solved Re: Cmd Line not wrapping in gnome terminal window

[Daniel Burrows]

On Fri, Jan 30, 2009 at 02:51:35PM -0600, Dennis Wicks w...@mgssub.com was 
heard to say:
 Thanks for the insight! I'll remember to use TERM when I have to kill so 
 errant process. It might save me a headache in the future!

  The difference between TERM and KILL, btw, is that TERM asks the
program to shut down, whereas KILL just stops it instantly.  So
programs killed with TERM can run cleanup actions before they shut
down, but programs killed with KILL don't get a chance.  (this also
means that programs can ignore TERM, for instance because they've
crashed really badly -- KILL is really meant for situations where that
has happened)

  Daniel


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Solved Re: Cmd Line not wrapping in gnome terminal window

[Ron Johnson]

On 01/30/2009 11:58 PM, Daniel Burrows wrote:

On Fri, Jan 30, 2009 at 02:51:35PM -0600, Dennis Wicks w...@mgssub.com was 
heard to say:
Thanks for the insight! I'll remember to use TERM when I have to kill so 
errant process. It might save me a headache in the future!


  The difference between TERM and KILL, btw, is that TERM asks the
program to shut down, whereas KILL just stops it instantly.  So
programs killed with TERM can run cleanup actions before they shut
down,


I 'kill -15' iceweasel whenever I need to log out but want to retain 
all my windows and tabs.



   but programs killed with KILL don't get a chance.  (this also
means that programs can ignore TERM, for instance because they've
crashed really badly -- KILL is really meant for situations where that
has happened)


--
Ron Johnson, Jr.
Jefferson LA  USA

I am not surprised, for we live long and are celebrated poopers.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Greetings;

I have just discovered that the command line in a gnome 
terminal window doesn't wrap correctly. Instead of doing a 
line feed and continuing on the next line it just returns to 
the beginning of the current line and writes over it.


As you might suspect, this does not result in a valid 
command line!


Anybody have any ideas??

Many TIA!!

Dennis


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Ron Johnson]

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal window 
doesn't wrap correctly. Instead of doing a line feed and continuing on 
the next line it just returns to the beginning of the current line and 
writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?

--
Ron Johnson, Jr.
Jefferson LA  USA

I am not surprised, for we live long and are celebrated poopers.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Ron Johnson wrote the following on 01/29/2009 09:36 PM:

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal 
window doesn't wrap correctly. Instead of doing a line feed and 
continuing on the next line it just returns to the beginning of the 
current line and writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?



No, if I launch an xterm it behaves normally.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Ron Johnson]

On 01/29/2009 09:52 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:36 PM:

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal 
window doesn't wrap correctly. Instead of doing a line feed and 
continuing on the next line it just returns to the beginning of the 
current line and writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?



No, if I launch an xterm it behaves normally.


Then use xterm???  :P

--
Ron Johnson, Jr.
Jefferson LA  USA

I am not surprised, for we live long and are celebrated poopers.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Ron Johnson wrote the following on 01/29/2009 09:56 PM:

On 01/29/2009 09:52 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:36 PM:

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal 
window doesn't wrap correctly. Instead of doing a line feed and 
continuing on the next line it just returns to the beginning of the 
current line and writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?



No, if I launch an xterm it behaves normally.


Then use xterm???  :P



I'd try that. Where is the doc for setting colors, font, 
window size and all that stuff? Right now I get a little 
tiny window about the size of a postage stamp in bw!




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Ron Johnson]

On 01/29/2009 10:00 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:56 PM:

On 01/29/2009 09:52 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:36 PM:

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal 
window doesn't wrap correctly. Instead of doing a line feed and 
continuing on the next line it just returns to the beginning of the 
current line and writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?



No, if I launch an xterm it behaves normally.


Then use xterm???  :P



I'd try that. Where is the doc for setting colors, font, window size and 
all that stuff?


You mean initial window size (--geometry), and potential colors (it 
starts black and white, but color apps -- like 'make menuconfig' are 
in color like they are supposed to be)?


Here's the Command that I have in an icon on my Tray:

urxvt -sl 1 -bg white -fg black
   -font -*-fixed-medium-r-*-*-14-*-*-*-*-*-*-r

The font string I generated using xfontsel (from package x11-utils, 
in menu location Foot-Debian-Applications-System-Administration).


The rest I deduced from reading the man page.

This gives me a window with a scroll buffer of 10,000 lines, black 
text on a white background using the fixed font with medium 
thickness in 14 point size.


 Right now I get a little tiny window about the size of a 
postage stamp in bw!


Resize the window with the mouse?

--
Ron Johnson, Jr.
Jefferson LA  USA

I am not surprised, for we live long and are celebrated poopers.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Dennis Wicks]

Ron Johnson wrote the following on 01/29/2009 10:33 PM:

On 01/29/2009 10:00 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:56 PM:

On 01/29/2009 09:52 PM, Dennis Wicks wrote:

Ron Johnson wrote the following on 01/29/2009 09:36 PM:

On 01/29/2009 09:21 PM, Dennis Wicks wrote:

Greetings;

I have just discovered that the command line in a gnome terminal 
window doesn't wrap correctly. Instead of doing a line feed and 
continuing on the next line it just returns to the beginning of 
the current line and writes over it.


As you might suspect, this does not result in a valid command line!

Anybody have any ideas??


Does bash exhibit this same problem in xterm?



No, if I launch an xterm it behaves normally.


Then use xterm???  :P



I'd try that. Where is the doc for setting colors, font, window size 
and all that stuff?


You mean initial window size (--geometry), and potential colors (it 
starts black and white, but color apps -- like 'make menuconfig' are in 
color like they are supposed to be)?


Here's the Command that I have in an icon on my Tray:

urxvt -sl 1 -bg white -fg black
   -font -*-fixed-medium-r-*-*-14-*-*-*-*-*-*-r

The font string I generated using xfontsel (from package x11-utils, in 
menu location Foot-Debian-Applications-System-Administration).


The rest I deduced from reading the man page.

This gives me a window with a scroll buffer of 10,000 lines, black text 
on a white background using the fixed font with medium thickness in 14 
point size.


 Right now I get a little tiny window about the size 
of a postage stamp in bw!


Resize the window with the mouse?



The mouse will make the window bigger, but it doesn't change 
the font size!!


Thanks for that info. I think I can probably figure out a 
workable config from that.


Thanks again!!
Dennis


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Cmd Line not wrapping in gnome terminal window

[Tzafrir Cohen]

On Thu, Jan 29, 2009 at 09:21:21PM -0600, Dennis Wicks wrote:
 Greetings;

 I have just discovered that the command line in a gnome terminal window 
 doesn't wrap correctly. Instead of doing a line feed and continuing on 
 the next line it just returns to the beginning of the current line and 
 writes over it.

 As you might suspect, this does not result in a valid command line!

 Anybody have any ideas??

The (remote?) system does not know the terminal type ($TERM) you use?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Dead Terminal Window

[Thomas H. George]

I created a chroot etch with xorg, gdm and gnome as described in Debian 
Reference - Debian Tips sections 8.6.35.1 through 8.6.38.4.  Everything 
I've tested seems to work except when I open a terminal window its dead 
and the xorg.conf  I use with my wacom tablet works only with the 
stylus, not the mouse. 



Any suggestions?

Tom


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Re: Files used when a terminal window opens

[Charles Blair]

 Thank you.  The bare cd trick was what I needed.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Files used when a terminal window opens

[Charles Blair]

   After logging in on a gnome window, I often go to Accessories
and root terminal.  I have several shell variable setting and
some other small tasks at the beginning.  When I first set the
system up, I had a file that did these things for me.  However,
I want to change a few things and I've forgotten what file is supposed
to be  edited.

   I've tried /etc/.profile and /root/.bashrc, among other things,
but I'm still getting the same behavior as before.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Files used when a terminal window opens

[s. keeling]

Charles Blair [EMAIL PROTECTED]:
 After logging in on a gnome window, I often go to Accessories
  and root terminal.  I have several shell variable setting and
  some other small tasks at the beginning.  When I first set the
  system up, I had a file that did these things for me.  However,
  I want to change a few things and I've forgotten what file is supposed
  to be  edited.
 
 I've tried /etc/.profile and /root/.bashrc, among other things,
  but I'm still getting the same behavior as before.

Your login startup scripts are where you ought to be looking.
Assuming bash is your login shell, see $HOME/.bashrc,
$HOME/.bash_profile, and $HOME/.profile.  Anything in there will
override/clobber whatever's defined by /etc stuff.

As for root terminals, see the same in $HOME while logged in as root.

FYI, bare cd takes you $HOME.  set will show you what's defined.

Perhaps you ought to supply a better description of the problem.  HTH.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://www.spots.ab.ca/~keeling  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.
   Spammers! http://www.spots.ab.ca/~keeling/emails.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Scrollable Terminal Window

[Johann Spies]

On Wed, Jun 09, 2004 at 08:47:38AM -0500, Barry Skidmore wrote:

 I am using WindowMaker with Debian (woody), and do not like the fact
 that the 

 terminal windows are not scrollable.
 
 Could someone please recommend a terminal package that has this feature?

rxvt, wterm and xterm can do it.  

Use the  -sb switch to enable the scroll bar.

Johann

-- 
Johann Spies  Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

 I love them that love me; and those that seek me early
  shall find me.   Proverbs 8:17


signature.asc
Description: Digital signature

Scrollable Terminal Window

[Barry Skidmore]

I am using WindowMaker with Debian (woody), and do not like the fact that the 
terminal windows are not scrollable.

Could someone please recommend a terminal package that has this feature?

Thanks,
Barry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Scrollable Terminal Window

[William Ballard]

On Wed, Jun 09, 2004 at 08:47:38AM -0500, Barry Skidmore wrote:
 I am using WindowMaker with Debian (woody), and do not like the fact that the 
 terminal windows are not scrollable.
 
 Could someone please recommend a terminal package that has this feature?

Since you are using KMail, why not konsole?  I use gnome-terminal.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Scrollable Terminal Window

[Barry Skidmore]

Thanks, I am not using kde, but installed konsole as a separate package.

Barry

On Wednesday 09 June 2004 08:55, William Ballard wrote:
 On Wed, Jun 09, 2004 at 08:47:38AM -0500, Barry Skidmore wrote:
  I am using WindowMaker with Debian (woody), and do not like the fact that
  the terminal windows are not scrollable.
 
  Could someone please recommend a terminal package that has this feature?

 Since you are using KMail, why not konsole?  I use gnome-terminal.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Scrollable Terminal Window

[H. S.]

Apparently, _Barry Skidmore_, on 06/09/04 09:47,typed:
I am using WindowMaker with Debian (woody), and do not like the fact that the 
terminal windows are not scrollable.

Could someone please recommend a terminal package that has this feature?
Thanks,
Barry


How about a simple xterm and enabling it's scrollbar? BTW, if this 
doesn't answer your query, I have misunderstood your message. If so, 
forgive me and please clarify.

-HS
--
(Remove all underscores,_if any_, from my email address to get the 
correct one. Apologies for the inconvenience, but this is to reduce spam.)

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Change size of terminal window?

[will trillich]

On Wed, Apr 04, 2001 at 05:48:08PM -0500, Nathan E Norman wrote:
 On Wed, Apr 04, 2001 at 09:27:30PM +0100, Rory Campbell-Lange wrote:
  I'd like to change the size of the terminal window shown on screen.
  
  I'm a Debian newbie. I've got Debian installed on our rather nice new
  VALinux rackmount box and I've got it hooked up to a Mitsubishi TFT
  flatscreen monitor. I don't have X running, and I'm doing everything in
  text mode.
  
  At the moment, while the Intel picture on startup uses the whole screen
  fine, as soon as Lilo loads linux, the console fills only about 1/4 of the
  area of the screen.
 
 WAG: try the framebuffer console?

/lurk okay, what's a framebuffer console?

I've been using SVGATextMode to reasonably good effect, changing
font size and rows/columns grow/contract to match... don't know
about this framebuffer term, tho.

And wasn't Rory asking about an xterm window? Does framebuffer
apply to that, too?

-- 
does a brain cell think?

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

Change size of terminal window?

[Rory Campbell-Lange]

I'd like to change the size of the terminal window shown on screen.

I'm a Debian newbie. I've got Debian installed on our rather nice new
VALinux rackmount box and I've got it hooked up to a Mitsubishi TFT
flatscreen monitor. I don't have X running, and I'm doing everything in
text mode.

At the moment, while the Intel picture on startup uses the whole screen
fine, as soon as Lilo loads linux, the console fills only about 1/4 of the
area of the screen.

Sorry about the newbie question.

Rory

Change size of terminal window?

[Rory Campbell-Lange]

I'd like to change the size of the terminal window shown on screen.

I'm a Debian newbie. I've got Debian installed on our rather nice new
VALinux rackmount box and I've got it hooked up to a Mitsubishi TFT
flatscreen monitor. I don't have X running, and I'm doing everything in
text mode.

At the moment, while the Intel picture on startup uses the whole screen
fine, as soon as Lilo loads linux, the console fills only about 1/4 of the
area of the screen.

Sorry about the newbie question.

Rory

Re: Change size of terminal window?

[Nathan E Norman]

On Wed, Apr 04, 2001 at 09:27:30PM +0100, Rory Campbell-Lange wrote:
 I'd like to change the size of the terminal window shown on screen.
 
 I'm a Debian newbie. I've got Debian installed on our rather nice new
 VALinux rackmount box and I've got it hooked up to a Mitsubishi TFT
 flatscreen monitor. I don't have X running, and I'm doing everything in
 text mode.
 
 At the moment, while the Intel picture on startup uses the whole screen
 fine, as soon as Lilo loads linux, the console fills only about 1/4 of the
 area of the screen.

WAG: try the framebuffer console?

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpzvPSz6yTag.pgp
Description: PGP signature

Re: terminal window

[shaul]

1) I never used pppconfig but I think it strange that username/password is all 
it can handle.
2) Perhaps configure the chatscript by hand ?
3) xisp has the ability to open a terminal. But then again, I never needed 
this terminal.

 hello
 I need to open a terminal window for my dial-up ppp connection. I have
 to pass more than just the username/password. I used pppconfig, but it
 wasn't enough for the extras.  How do I open a terminal window for
 dial-up connections?
 thanks

Re: terminal window

[Robert V. MacQuarrie]

On Wed, 9 Dec 1998, shaul wrote:

1) I never used pppconfig but I think it strange that username/password is all 
it can handle.
2) Perhaps configure the chatscript by hand ?
3) xisp has the ability to open a terminal. But then again, I never needed 
this terminal.

 hello
 I need to open a terminal window for my dial-up ppp connection. I have
 to pass more than just the username/password. I used pppconfig, but it
 wasn't enough for the extras.  How do I open a terminal window for
 dial-up connections?
 thanks

Install and run the minicom communication program. It's easy to setup (2
minutes), and when you dial in it shows you exactly what is sent from the
the remote system. 

terminal window

[Mark Cantrell]

hello
I need to open a terminal window for my dial-up ppp connection. I have
to pass more than just the username/password. I used pppconfig, but it
wasn't enough for the extras.  How do I open a terminal window for
dial-up connections?
thanks
Mark

--

A man talking sense to himself is no madder than a man talking nonsense
not to himself. Or just as mad.
 - Tom Stoppard