On Mon, 2002-11-25 at 08:52, Randall R Schulz wrote:
> If KB 195857 really is the culprit here, then I suppose you could well make
> the case that opening a lot of system handles and then just abandoning them
> is not good programming practice and really should be resolved on its own
> merits.
On Mon, 2002-11-25 at 09:35, Charles Wilson wrote:
> Guys, I'm really surprised nobody has mentioned the obvious culprit (or
> asked the obvious question):
>
> Anti virus software? Was McAfee or Norton (but esp. McAfee) running
> while setup.exe was executed?
Doh. Ok, setup HEAD will now ask a
Robert Collins <[EMAIL PROTECTED]> wrote:
> On Mon, 2002-11-25 at 09:35, Charles Wilson wrote:
>> Guys, I'm really surprised nobody has mentioned the obvious culprit
>> (or asked the obvious question):
>>
>> Anti virus software? Was McAfee or Norton (but esp. McAfee) running
>> while setup.exe was
On Mon, 2002-11-25 at 12:05, Max Bowsher wrote:
> Works for me - quick coding!
Cool. It's just a quick hack. There are some things it highlit about the
property page system. Garrry!
I recall being unhappy about having the list of pages in two places, and
it's obvious why now.
Heres the curren
> >Anti virus software? Was McAfee or Norton (but esp. McAfee) running while
> >setup.exe was executed?
> >
> >I *always* disable McAfee before running setup. Every time I forget, I
> >get a bluescreen. Minidump analysis shows that the fault is in fact
> >McAfee -- which runs in kernel mode -- a
> On Mon, 2002-11-25 at 12:05, Max Bowsher wrote:
>
>
> > Works for me - quick coding!
>
> Cool. It's just a quick hack. There are some things it highlit about the
> property page system. Garrry!
>
Uh-oh! ;-)
> I recall being unhappy about having the list of pages in two places, and
> it's obviou
On Sunday 24 November 2002 14:35, Charles Wilson wrote:
> Guys, I'm really surprised nobody has mentioned the obvious culprit (or
> asked the obvious question):
>
> Anti virus software? Was McAfee or Norton (but esp. McAfee) running
> while setup.exe was executed?
>
> I *always* disable McAfee bef
Since 6/7 months I have 0x000a errors with my PC (Win2K SP3), the
problem is very simple: when XFree is running and there is a write to
/etc I got a blue screen.
Here are the steps I perform:
* start XFree (XWin+WindowMaker+ all that is launched by startxwin.bat);
* open a xterm;
* touch
27;most' users have access to start and stop
services, outside of certain locked down IT departments. And Services
have DACL's, so ...
Anyway, I *ask* the user about disabling it, hopefully that will stop
some enthusiastic but misguided mcaffee person from considering
setup.exe a v
(Danilo: Sorry for accidently sending my previous mail directly to you)
Danilo Turina wrote:
> Since 6/7 months I have 0x000a errors with my PC (Win2K SP3), the
> problem is very simple: when XFree is running and there is a write to
> /etc I got a blue screen.
> Here are
One further clarification. It happens well before the
Installation complete
[OK]
step. It actually happens before any of the post download scripts run.
It happens when it is at (or nearly at) the very end of downloading
the packages. After the blue screen, when I come back in, and just
Hi,
I don't want to be accused of advertising, but we use SOPHOS
in my office, and it doesn't interfere with the download/install
processes or setup.exe at all. I've used it on NT, 2000, and XP.
Just for information.
/John.
_
He
On Sun, 24 Nov 2002, Randall R Schulz wrote:
> Hi, Chuck,
Hi All!
> Do I have to say it?
> D'Oh!
I feel this is really just masking the real problem. In my experiences
doing development and testing under Windows, I feel that fault drivers
are mostly what causes problems (someone else
> Anyone know of a tool (besides Purify) which could track all
> the resource usages of a given program?
Sysinternals has a great collection of tools for this sort
of thing:
Handle v2.01
http://www.sysinternals.com/ntw2k/freeware/handle.shtml
"This handy command-line utility will show you what fi
Peter A. Castro wrote:
And, just to provide a counter example: I always run Norton AntiVirus
with automatic / background scanning enabled. I generally have to,
because of infected machines at work which probe the network whenever we
get hit with the latest rash of viruses :(. I've done all my
On Tue, 2002-11-26 at 03:53, Daniel Armbrust wrote:
> Where can I get this?
>
> >
> >
> > If the NT 4 machine crashes every time, would you be willing to run a
> > special debug version of setup, that will write it's log entries to the
> > event log? They should be visible post install then, and y
arly at) the very end of downloading
> the packages. After the blue screen, when I come back in, and just
> click through the install steps again, it usually redownloads or
> finishes one package, and then moves on to the install step (which works
> fine).
>
>
> Do the
Robert Collins <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-11-26 at 03:53, Daniel Armbrust wrote:
>> Where can I get this?
>>
>>>
>>>
>>> If the NT 4 machine crashes every time, would you be willing to run
>>> a special debug version of setup, that will write it's log entries
>>> to the event log? T
On Tue, 2002-11-26 at 08:56, Max Bowsher wrote:
> Robert Collins <[EMAIL PROTECTED]> wrote:
> > If you don't have McAfee installed, then I'll roll an Event Log based
> > setup for you.
>
> Why not just flush the logs to disc after each line? I've got a patch lying
> around here somewhere to do t
Robert Collins <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-11-26 at 08:56, Max Bowsher wrote:
>> Robert Collins <[EMAIL PROTECTED]> wrote:
>
>
>>> If you don't have McAfee installed, then I'll roll an Event Log
>>> based setup for you.
>>
>> Why not just flush the logs to disc after each line? I'
On Sun, Nov 24, 2002 at 10:16:23AM -0600, you [Daniel Armbrust] wrote:
> Every time that I run the cygwin installer program, when it finishes
> downloading packages, and moves to the install step, it bluescreen
> crashes my Windows XP machine (service pack 1) with the following error:
>
> STOP: 0x
vious mail directly to you)
Danilo Turina wrote:
> Since 6/7 months I have 0x000a errors with my PC (Win2K SP3), the
> problem is very simple: when XFree is running and there is a write to
> /etc I got a blue screen.
> Here are the steps I perform:
>
> * start XFree
On 4/8/2010 4:07 PM, Al G. wrote:
This started happening around March 23, no problems with screen before
then. Since then using GNU screen (4.00.03) and trying to backspace by
hitting the backspace key results in nothing happening. The cursor
doesn't move, the character isn't eras
> From: "Larry Hall (Cygwin)"
> To: cyg...@cygwin.com
> Date: Thu, 08 Apr 2010 16:41:25 -0400
> Subject: Re: 1.7.3: Backspace key not working in GNU screen.
> On 4/8/2010 4:07 PM, Al G. wrote:
>>
>> This started happening around March 23, no problems with sc
3: Backspace key not working in GNU screen.
^^^
And there's really no need for this repeated header information. It's
largely content-free in the mail list thread.
On 4/8/2010 4:07 PM, Al G. wrote:
This started happening ar
Al G.:
> using GNU screen (4.00.03) and trying to backspace by
> hitting the backspace key results in nothing happening. The cursor
> doesn't move, the character isn't erased and the command remains the
> same (if you hit Enter whatever your typo was gets the usual error)
hat's a bug in Cygwin. You really should *not* be setting
CYGWIN=tty for applications like mintty, rxvt, xterm, ssh, screen, etc.,
which use ptys. Really.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: h
gwin. You really should *not* be setting
> CYGWIN=tty for applications like mintty, rxvt, xterm, ssh, screen, etc.,
> which use ptys. Really.
The issue only affects the specific case of 'screen' running in the
console without 'tty' in the CYGWIN settings: the backspac
the setting of the backspace key for ptys
>>then that's a bug in Cygwin. ??You really should *not* be setting
>>CYGWIN=tty for applications like mintty, rxvt, xterm, ssh, screen,
>>etc., which use ptys. ??Really.
>
>The issue only affects the specific case of 'screen&
On Sat, Apr 10, 2010 at 12:16:26PM -0400, Christopher Faylor wrote:
>On Sat, Apr 10, 2010 at 05:00:30PM +0100, Andy Koppe wrote:
>>The issue only affects the specific case of 'screen' running in the
>>console without 'tty' in the CYGWIN settings: the backspace k
On Sat, Apr 10, 2010 at 01:36:07PM -0400, Christopher Faylor wrote:
>On Sat, Apr 10, 2010 at 12:16:26PM -0400, Christopher Faylor wrote:
>>On Sat, Apr 10, 2010 at 05:00:30PM +0100, Andy Koppe wrote:
>>>The issue only affects the specific case of 'screen' running in the
Christopher Faylor wrote:
> I'm not 100% sure that this is the right fix but the new snapshot at
> least works around the problem.
Thanks.
> The problem is that screen explicitly sets VERASE to 0. I believe that
> it does that to mean "there is really no erase characte
mean that
>the user's backspace keycode setting is ignored. Also, 'screen' would
>be expecting what was set in c_cc[VERASE] as the backspace keycode.
Uh, no. I made it send \177 when c_cc[VERASE] is 0. Screen is just
forwarding characters along so it doesn't care.
c
On Apr 10 22:09, Andy Koppe wrote:
> Christopher Faylor wrote:
> > I'm not 100% sure that this is the right fix but the new snapshot at
> > least works around the problem.
>
> Thanks.
>
> > The problem is that screen explicitly sets VERASE to 0. I believe that
On Apr 11 11:33, Corinna Vinschen wrote:
> On Apr 10 22:09, Andy Koppe wrote:
> > Christopher Faylor wrote:
> > > The problem is that screen explicitly sets VERASE to 0. I believe that
> > > it does that to mean "there is really no erase character since I'm
> So, what we really need to implement is what you proposed.
It sounds as though no change is required in screen for this. I trust someone
will let me know if it turns out otherwise.
screen is an ancient program from the dim mists of early terminal days, so I'm
not surprised that it
27;stty erase
^H', to get ^H as the backspace keycode, but then finding that it
would send ^? again when in screen, even though 'stty -a' would still
show ^H. Anyways ...
> So, what we really need to implement is what you proposed. I prepared
> a patch, see below. It see
Andrew Schulman wrote:
> It sounds as though no change is required in screen for this.
Correct.
> screen is an ancient program from the dim mists of early terminal days, so I'm
> not surprised that it has some problems of this kind.
Don't worry, screen isn't doing anyt
>> It sounds as though no change is required in screen for this.
>
>Correct.
>
>> screen is an ancient program from the dim mists of early terminal days, so
>> I'm
>> not surprised that it has some problems of this kind.
>
>Don't worry, screen isn
On 4/12/2010 8:36 AM, Al G. wrote:
It sounds as though no change is required in screen for this.
Correct.
screen is an ancient program from the dim mists of early terminal days, so I'm
not surprised that it has some problems of this kind.
Don't worry, screen isn't doing anyt
Looks like vim isn't the only problem here, nor is screen. I was able
to see some other poor behaviour by looking at a man page and then
searching for a string which didn't exist--whether running 'screen' or
not. It displayed "Pattern not found" on the bottom line,
> > Simplest way to reproduce is this: run 'screen', then run 'vim', then
> > exit with ':q'. My bash prompt is now on the bottom line of my mintty
> > window, but everything I type, and all output after that, stays on the
> > last line,
On May 6 11:09, Shaddy Baddah wrote:
> Hi,
>
> I've just dropped snapshot 2014-05-05 into my 64bit Cygwin install.
>
> I am getting a segmentation fault running ssh from within a screen
> session. Regardless of the arguments passed:
>
> $ ssh -V
> OpenSSH_6.
in the cache.
>
> Screen seems to call getpwuid and then sets some of the pointers in the
> passwd structure it got from the call to NULL, apparently for some sort
> of security, this way overwriting the cached passwd struct for the
Bug in screen. POSIX states:
http://pubs.opengroup.o
the parent process does to the passwd
> > structures in the cache.
> >
> > Screen seems to call getpwuid and then sets some of the pointers in the
> > passwd structure it got from the call to NULL, apparently for some sort
> > of security, this way overwriting the c
is cache to child processes, said
> > > child processes suffer from what the parent process does to the passwd
> > > structures in the cache.
> > >
> > > Screen seems to call getpwuid and then sets some of the pointers in the
> > > passwd structure it g
ementing
> > > > this stuff is, that by propagating this cache to child processes, said
> > > > child processes suffer from what the parent process does to the passwd
> > > > structures in the cache.
> > > >
> > > > Screen seems to call getpw
passwd
> > structures in the cache.
> >
> > Screen seems to call getpwuid and then sets some of the pointers in the
> > passwd structure it got from the call to NULL, apparently for some sort
> > of security, this way overwriting the cached passwd struc
t; child processes suffer from what the parent process does to the passwd
> > > structures in the cache.
> > >
> > > Screen seems to call getpwuid and then sets some of the pointers in the
> > > passwd structure it got from the call to NULL, apparently for some so
> > > The problem, which I totally not realized since I started implementing
>> > > > this stuff is, that by propagating this cache to child processes, said
>> > > > child processes suffer from what the parent process does to the passwd
>> > > &
On May 1 17:32, Stephen John Smoogen wrote:
> I downloaded and installed a copy of Windows 10 on a spare system to
> see how Cygwin works. Most of the applications worked similarly to
> what I was testing on my Windows 7 system. However I have run into a
> problem with the sc
ystem. However I have run into a
>> problem with the screen command.
>>
>> The first time I run screen the command gives me a standard help
>> screen and data. If I type exit to get back to mintty and then
>> type screen again.. I get:
>>
>> Directory
at would typically be
> > the group "users", e.g.
> >
> > chgrp users /tmp/uscreens
> >
> > should work, and then you can chmod it and screen should stop
> > complaining.
> >
>
> Thank you for answering while you are on vacation. I am go
t; permissions are too wide-open.
>>
>> Or, Cygwin sets the group permissions to 0, e.g.
>>
>> rwx---r-x
>>
>> Then, apparently, screen complains.
>>
>> There would be a third way, which is, to spill the "other" permissions
>> into th
Andrew Schulman:
> Instructions for starting screen with 256 color support are in
> /usr/share/doc/screen/README.Cygwin. In brief, you have to invoke screen
> as
>
> TERM=screen-256color screen
I don't think that's quite right. Screen needs to be told what
terminal it i
Andy Koppe gmail.com> writes:
>
> Andrew Schulman:
> > Instructions for starting screen with 256 color support are in
> > /usr/share/doc/screen/README.Cygwin. In brief, you have to invoke screen
> > as
> >
> > TERM=screen-256color screen
>
> I don&#
> > TERM=xterm-256color screen -T screen-256color
>
> Instead of specifying -T screen-256color every time, one can just put
> 'term screen-256color' into .screenrc. I'll update the docs to show this
> when I make the release current.
Is there any reason that
Andrew Schulman:
>> > TERM=xterm-256color screen -T screen-256color
>>
>> Instead of specifying -T screen-256color every time, one can just put
>> 'term screen-256color' into .screenrc. I'll update the docs to show this
>> when I make the release c
> Andrew Schulman:
> >> > TERM=xterm-256color screen -T screen-256color
> >>
> >> Instead of specifying -T screen-256color every time, one can just put
> >> 'term screen-256color' into .screenrc. I'll update the docs to show this
> >
Andrew Schulman:
>>>> Instead of specifying -T screen-256color every time, one can just put
>>>> 'term screen-256color' into .screenrc. I'll update the docs to show this
>>>> when I make the release current.
>>>
>>> Is there a
> > You're talking about setting e.g. TERM=xterm-256color in the environment by
> > default, but I was asking whether it would cause any harm to put 'term
> > screen-256color' into the default /etc/screenrc. Know any reason that I
> > shouldn't?
>
> 'term screen-256color' sets TERM=screen-256color in the
> environment of programs running inside screen, hence any program or
> script that recognises "screen" but not "screen-256color" will no
> longer work as expected.
Btw, a different approach to ena
e solution is fairly easy. This the newbie condition ;-)
:) Gabier
--
View this message in context:
http://old.nabble.com/Copy%2C-paste-and-deleting-characters-in-the-openssh-screen.-tp32811323p32811323.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports:
When I run vim in mintty without screen, the mouse works, but inside
screen it does not.
I tried changing the TERM to xterm before launching vim, but that
doesn't help, my TERM in screen is set to screen-256color and outside it
to xterm-256color.
When I ssh to my linux in mintty and ru
indows machine from a linux machine as follows:
> ssh win_host -t screen -R -D (instead of "-R -D" the option "-x" could
> be used, I tried both: no difference)
>
> 3. After a while terminate the connection in some brutal way (in my case
> the vpn tunn
Hi,
I'm trying to get screen working through sshd. I have installed
screen, and openssh, and configured with ssh-host-config (and set
CYGWIN to tty).
Users with administrator privileges can successfully create, detach,
and reattach a screen session through ssh, but that is not possible
leMode(ENABLE_VIRTUAL_TERMINAL_INPUT)[^3] to behave like
> xterm-256color when supported[^4] (they are not supported in "Legacy
> Console Mode").
>
> I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
> CMD. It's not clear to me if the alte
On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
>> I'm investigating an issue in Git for Windows[^1], which also affects
>> Cygwin. The issue is that, when using CMD (i.e. Command Prompt) on
>> Windows 10 1703 or above with "Legacy Con
ehave like
xterm-256color when supported[^4] (they are not supported in "Legacy
Console Mode").
I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
CMD. It's not clear to me if the alternate screen buffer behaves
differently in CMD than xterm, whether Cygwin has
; >> SetConsoleMode(ENABLE_VIRTUAL_TERMINAL_INPUT)[^3] to behave like
> >> xterm-256color when supported[^4] (they are not supported in "Legacy
> >> Console Mode").
> >>
> >> I'm not too familiar with TTY/PTY handling, much less Cygwin on top of
On Fri, Apr 30, 2021 at 1:31 PM Takashi Yano via Cygwin
wrote:
> Why on earth do you want to set TERM=cygwin?
> If you don't set TERM=cygwin, TERM is automatically set to
> xterm-256color, in which the issue does not occur.
>
Might be because for the longest time, if you didn't set it to cygwin,
Hi,
On Fri, 30 Apr 2021, Kevin Locke wrote:
> On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> >> I'm investigating an issue in Git for Windows[^1], which also affects
> >> Cygwin. The issue is that, when using CMD (i.e. Command P
On Wed, 5 May 2021 15:07:04 +0200 (CEST)
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 30 Apr 2021, Kevin Locke wrote:
>
> > On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> > >> I'm investigating an issue in Git for Windows[^1],
On Thu, 6 May 2021 18:12:38 +0900
Takashi Yano via Cygwin> wrote:
> On Wed, 5 May 2021 15:07:04 +0200 (CEST)
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Fri, 30 Apr 2021, Kevin Locke wrote:
> >
> > > On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > > > On Fri, 30 Apr 2021 08:25:12 -
Errol Smith wrote:
> I'm having a problem with mc's editor.
[...]
> Hitting page-up/page-down doesn't seem to fix it
> - I would have thought this would refresh the screen
> so it would then be in the right place, but it doesn't.
> Basically, once it goes funn
On Sun, 2 May 2004, Errol Smith wrote:
> I'm having a problem with mc's editor (4.6.0-4, also tried
> mc-4.6.0a-20030721 with same issue). (cygwin 1.5.9-1 on 98se)
> If you are editing a file wider than the screen, sometimes
> the display becomes corrupted, with odd parts o
On Sun, 2 May 2004, Frédéric L. W. Meunier wrote:
> On Sun, 2 May 2004, Errol Smith wrote:
>
> > I'm having a problem with mc's editor (4.6.0-4, also tried
> > mc-4.6.0a-20030721 with same issue). (cygwin 1.5.9-1 on 98se)
> > If you are editing a file wider
Hi,
I've recently installed cygwin on an XP box and I am experiencing a
problem that never manifested on my 2000 machine.
When running rxvt and gnu screen, nmake spawns cmd shells into which
stout and sterr are written. Not only is it annoying, but the shells
disappear when builds term
Currently experiencing a weird problem in Cygwin on W2000:
In a rxvt window, both " and ' behave in the same way: pressing either key
results in nothing on the screen, but pressing either key followed by
results in the expected ' or " appearing, without the space.
Explorin
I'm using Windows XP Professional SP1 with all updates.
I also have this problem with plain "Command Prompt", though I
run all applications on Cygwin.
The colors in "Window" mode may be unreadable, while in "Full
Screen" mode they look like on a Linux console
and then
> gave a "make".
> I got the blue screen of death (BSD).
> After iterating through several BSDs, I hunted on the web
> and found a site that said that static linkages were a problem with
> the latest guile and that I must install guile 1.4.1. So I uninstalled
> g
Is there some reason why setup-1.7 has to blow up to full-screen when
the "Select Packages" screen comes up? I prefer the friendlier 1.5
version.
- Jim
--
Jim Reisert AD1C, , http://www.ad1c.us
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://
On 11/9/2011 08:38, gabier wrote:
Hi,
I am experiencing daily frustration because I do not know how to get the
following features to my fingertips while controlling my Freenas/FreeBSD
server from my openssh console on a remote Windows computer.
1) copy from windows document or browser and paste
On 9 November 2011 16:31, Jeremy Bopp wrote:
> On 11/9/2011 08:38, gabier wrote:
>>
>> Hi,
>> I am experiencing daily frustration because I do not know how to get the
>> following features to my fingertips while controlling my Freenas/FreeBSD
>> server from my openssh console on a remote Windows co
On 12/9/2011 8:23 PM, Rafael Kitover wrote:
> When I run vim in mintty without screen, the mouse works, but inside
> screen it does not.
>
> I tried changing the TERM to xterm before launching vim, but that
> doesn't help, my TERM in screen is set to screen-256color and o
To reproduce:
1) Update screen package to current (4.03) version;
2) Run screen inside mintty;
3) Generate enough text to fill the screen and start scrolling
4) Click in the scrollbar, or use the mousewheel
Desired effect
Scrolling
Observed effect
Nothing, wrt scrollbar; history review
Dear friends -- I get the message above when I start cygwin emacs-X11
32-bit while running Cygwin-X. First of all, should I care? And if
I should, what can I do about it? Does this have to do with the
command line parameters when starting the X server, for example?
Regards - Eliot Moss
--
Pro
Hi,
So I've had an issue with screen for some years now. I do remember
noticing its introduction, but I no longer can remember when that
actually happened.
As per the subject, I find that when I detach or exit a screen session
the cursor ends up part way up the restored buffer, intermi
An earlier version of Cygwin I installed starts taking up
the whole screen with multiple shells. The current version
starts with a single terminal window in what appears to be
a "multiwindow" mode.
I have looked at the man pages for xinit and some others,
but have not found how to o
the computer is not locked, "shutdown --exitex 10" does a complete
> shutdown and power off.
>
> If I lock the computer right after running "shutdown 10" (no --exitex) then
> the computer does shutdown, but does not power off. I get the "It is now
> safe to
t
> > exits.
> >
> > When the computer is not locked, "shutdown --exitex 10" does a complete
> > shutdown and power off.
> >
> > If I lock the computer right after running "shutdown 10" (no --exitex) then
> > the computer does shutdo
I created a patch for GNU screen 3.9.15 that will allow it to be compiled
and installed on Cygwin. The patch is attached below, the basic build and
install procedure is:
$ tar xzf {tar-path}/screen-3.9.15.tar.gz
$ cd screen-3.9.15
$ patch -p1 -s <{patch-path}/scr
On Mon, 26 Jan 2004 [EMAIL PROTECTED] wrote:
> Currently experiencing a weird problem in Cygwin on W2000:
>
> In a rxvt window, both " and ' behave in the same way: pressing either key
> results in nothing on the screen, but pressing either key followed by
> res
Hi,
I log in fine, and get my prompt and everyting. sshd rocks!
I'm trying to do e.g.:
me@othermachine :> ssh winmachine word.sh some.doc
And have the word GUI appear on the machine it is actually running. I'm
aware, of course that X-forwarding wont work
Here word.sh contains:
/cygdrive/c/Pr
Environment
CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
Windows 7
Steps to reproduce the issue:
- With vi.exe
Execute the following bash script:
#!/bin/bash
for i in {1..123}; do
echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
head -n1000 /var/log/setup.log
done
vi /var/log/
When I launch screen by typing 'screen' at the basic Cygwin bash prompt,
a screen.exe cmd window launches and stays open for the entire screen
session.
I only see this behavior with Windows 7.
--
Joel Eidsath
--
Problem reports: http://cygwin.com/problem
On Thu, Sep 17, 2009 at 4:42 PM, Jim Reisert AD1C
wrote:
> Is there some reason why setup-1.7 has to blow up to full-screen when
> the "Select Packages" screen comes up? I prefer the friendlier 1.5
> version.
I forgot to mention, that the back/cancel etc. icons at the b
On 09/17/2009 06:42 PM, Jim Reisert AD1C wrote:
Is there some reason why setup-1.7 has to blow up to full-screen when
the "Select Packages" screen comes up? I prefer the friendlier 1.5
version.
Yes, it was changed so that you could easily see all the information in
the packages lis
On Thu, Sep 17, 2009 at 5:18 PM, Larry Hall (Cygwin)
wrote:
> On 09/17/2009 06:42 PM, Jim Reisert AD1C wrote:
>>
>> Is there some reason why setup-1.7 has to blow up to full-screen when
>> the "Select Packages" screen comes up? I prefer the friendlier 1.5
>>
On Thu, Sep 17, 2009 at 06:50:39PM -0600, Jim Reisert AD1C wrote:
>On Thu, Sep 17, 2009 at 5:18 PM, Larry Hall (Cygwin)
> wrote:
>>On 09/17/2009 06:42 PM, Jim Reisert AD1C wrote:
>>>
>>>Is there some reason why setup-1.7 has to blow up to full-screen when
>>&g
501 - 600 of 764 matches
Mail list logo
