[ANNOUNCEMENT] Updated: patch-2.6.1-1

[Corinna Vinschen]

I just updated the patch utility to the latest stable upstream
version 2.6.1.

The Cygwin package contains a few patches in terms of binary vs.
textmode handling.  It seems to work fine in my testing, but if you
encounter some strangeness, please report to the mailing list
cygwin AT cygwin DOT com.

This package is now also packed using cygport.


To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leadercygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

1.7.13/1.7.14: Issue with command prompt not returning when forking process

[Rob Burgers]

Hi,

I am having trouble with a not returning command prompt after termination of a 
process when this process forked another process. In such case the return of 
the command prompt is bound to life time of the forked process i.e. when the 
forked process terminates the command prompt returns.

The problem seems to have appeared in more recent versions of Cygwin and 
appearing both on Vista and Windows 7. I do have systems with and without this 
problem.
All systems without the problem have either kernel version 1.7.9(0.237/5/3) 
2011-03-29 10:10 or 1.7.10(0.259/5/3) 2012-02-05 12:36
All systems showing the problem have either kernel version 1.7.13(0.260/5/3) 
2012-04-05 12:43 or 1.7.14(0.260/5/3) 2012-04-24 17:22

The attached test application demonstrates the issue. By running "java 
Launcher" java process is started, which itself forks another java process. 
This second process runs for 2 minutes until it terminates. On systems without 
the problem the command prompt returns immediately, whereas on troubled systems 
it takes 2 minutes to return.
Running the same command from a dos prompt causes the command prompt to return 
immediately.

Running "ps" on a troubled system while waiting for the prompt to return still 
shows the java process running the Launcher, while the Windows task-manager and 
resource monitor do longer show this process (but only the Server).

A system originally not showing this issue, started showing the issue when new 
packages (openssh, rsync, libxslt and unzip) were installed. As part of this 
the kernel version was updated from 1.7.10 to 1.7.14. Removal of those packages 
had no effect on the problem; the kernel version remained at 1.7.14.

Test application
% javac *.java
% java Launcher
===
Lancher.java
---
public class Launcher {
  public static void main(String[] args) throws Exception {
System.out.println("Launching Server");
Runtime.getRuntime().exec(new String[] { "javaw", "Server" });
System.out.println("Launched Server");
}}
===
Server.java
---
public class Server {
  public static void main(String[] args) throws Exception { 
System.out.println("Started: " + Server.class.getName());
Thread.sleep(12);
}}
===

% uname -srv
CYGWIN_NT-6.0 1.7.14(0.260/5/3) 2012-04-25 09:41

% cygcheck -cd
Cygwin Package Information
Package  Version
_autorebase  50-1
_update-info-dir 01046-1
alternatives 1.3.30c-10
base-cygwin  3.1-1
base-files   4.1-1
bash 4.1.10-4
bzip21.0.6-2
coreutils8.15-1
crypt1.1-1
csih 0.9.6-1
cygrunsrv1.40-2
cygutils 1.4.10-2
cygwin   1.7.14-2
cygwin-doc   1.7-1
dash 0.5.7-1
diffutils3.2-1
dos2unix 5.3.3-1
editrights   1.01-2
file 5.11-1
findutils4.5.9-2
gawk 4.0.1-1
gettext  0.18.1.1-2
grep 2.6.3-1
groff1.21-2
gzip 1.4-1
ipc-utils1.0-1
less 444-1
libasn1_81.5.2-2
libattr1 2.4.43-1
libbz2_1 1.0.6-2
libcom_err2  1.41.14-1
libedit0 20090923-1
libgcc1  4.5.3-3
libgcrypt11  1.4.6-1
libgmp3  4.3.2-1
libgpg-error01.10-1
libgssapi3   1.5.2-2
libheimbase1 1.5.2-2
libheimntlm0 1.5.2-2
libhx509_5   1.5.2-2
libiconv21.14-2
libintl8 0.18.1.1-2
libkafs0 1.5.2-2
libkrb5_26   1.5.2-2
liblzma5 5.0.2_20110517-1
libncurses10 5.7-18
libncursesw105.7-18
libopenssl1001.0.1b-2
libpcre0 8.21-2
libpopt0 1.6.4-4
libreadline7 6.1.2-2
libroken18   1.5.2-2
libsigsegv2  2.10-1
libsqlite3_0 3.7.3-1
libssp0  4.5.3-3
libstdc++6   4.5.3-3
libwind0 1.5.2-2
libwrap0 7.6-21
libxml2  2.7.8-3
libxslt  1.1.26-3
login1.10-10
man  1.6g-1
mintty   1.0.3-1
openssh  6.0p1-1
rebase   4.1.0-1
rsync3.0.9-1
run  1.1.13-1
sed  4.2.1-1
tar  1.25-1
terminfo 5.7_20091114-14
texinfo  4.13-4
tzcode   2012b-1
unzip6.0-10
which2.20-2
xz   5.0.2_20110517-1
zlib01.2.5-1


Best regards,
Rob Burgers


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Fine-tuning cygrunsrv

[Fedin Pavel]

 Is it possible to configure cygrunsrv to supply command line option to 
daemons being started? If yes, how ?

 I've got sick of NFS problems and want to debug them myself.

--
 Kind regards
 Pavel Fedin
 Expert engineer, Samsung Moscow research center


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Fine-tuning cygrunsrv

[Mark Geisert]

Fedin Pavel writes:
>   Is it possible to configure cygrunsrv to supply command line option to 
> daemons being started? If yes, how ?

According to 'cygrunsrv --help', Yes and It's In There.

..mark


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: eventlog-0.2.12-2

[Corinna Vinschen]

I've just updated the version of the eventlog package to 0.2.12-2.

No changes, just an update to the cygport packaging method.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developercygwin AT cygwin DOT com
Red Hat, Inc.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Question about kill

[eric_justin_al...@cfl.rr.com]

Hey I'm not sure what version of cygwin I am using but I can't seem to 
kill a server program with kill and I was hoping someone here might be 
able to shine some light on the subject.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.13/1.7.14: Issue with command prompt not returning when forking process

[Earnie Boyd]

On Fri, May 4, 2012 at 3:19 AM, Rob Burgers  wrote:
> Hi,
>
> I am having trouble with a not returning command prompt after termination of 
> a process when this process forked another process. In such case the return 
> of the command prompt is bound to life time of the forked process i.e. when 
> the forked process terminates the command prompt returns.
>

Try:

run foo

Why isn't this in the FAQ?  At least I'm not finding it.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about kill

[marco atzeri]

On 5/4/2012 2:25 PM, eric_justin_al...@cfl.rr.com wrote:

Hey I'm not sure what version of cygwin I am using


see
 uname -a


but I can't seem to
kill a server program with kill and I was hoping someone here might be
able to shine some light on the subject.


cygwin program or MS program ?
cygwin kill is for cygwin programs.

Usually
  kill -9 your_program_name

works very well



Problem reports: http://cygwin.com/problems.html

for further reading

Regards
Marco

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: attr-2.4.46-1

[Corinna Vinschen]

I just updated the attr package and the included libattr1 and
libattr-devel packages to version 2.4.46-1.

This is the latest upstream version with all relevant patches as in
Fedora 16.  The Cygwin package required a couple of additional patches,
especially in terms of the installation procedure.  The Makefiles and
installer scripts are a crude mix of autoconf+libtool+handmade in a
rather fragile way.

This package now uses the cygport packaging method.


To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leadercygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about kill

[Corinna Vinschen]

On May  4 13:51, marco atzeri wrote:
> On 5/4/2012 2:25 PM, eric_justin_al...@cfl.rr.com wrote:
> >Hey I'm not sure what version of cygwin I am using
> 
> see
>  uname -a
> 
> >but I can't seem to
> >kill a server program with kill and I was hoping someone here might be
> >able to shine some light on the subject.
> 
> cygwin program or MS program ?
> cygwin kill is for cygwin programs.
> 
> Usually
>   kill -9 your_program_name
> 
> works very well

Additionally check if you have the permissions to kill the process.  If
you're running under an admin account on Vista and later, make sure to
run the shell with full permissions ("run as administrator").


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about kill

[Eric Blake]

On 05/04/2012 05:51 AM, marco atzeri wrote:

> 
> Usually
>   kill -9 your_program_name
> 
> works very well

Usually 'kill -9 your_program' is overkill; it forcefully terminates the
program with SIGKILL, which means the program has no chance to clean up
after itself, and can leave your file system in a mess for the next time
you attempt to run the program.  You should reserve this for a
last-ditch effort, only after the nicer 'kill your_program' (SIGTERM) or
'kill -s INT' (SIGINT) both result in no action.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Question about kill

[marco atzeri]

On 5/4/2012 2:11 PM, Eric Blake wrote:

On 05/04/2012 05:51 AM, marco atzeri wrote:



Usually
   kill -9 your_program_name

works very well


Usually 'kill -9 your_program' is overkill; it forcefully terminates the
program with SIGKILL, which means the program has no chance to clean up
after itself, and can leave your file system in a mess for the next time
you attempt to run the program.  You should reserve this for a
last-ditch effort, only after the nicer 'kill your_program' (SIGTERM) or
'kill -s INT' (SIGINT) both result in no action.



I had the impression he needs the last resort...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Question about kill

[eric_justin_al...@cfl.rr.com]

Well kill program_name didn't work and kill -9 is pretty much what I am 
looking for.

Does it matter if you are gonna overwrite the program if you use kill -9?


marco atzeri wrote:

On 5/4/2012 2:11 PM, Eric Blake wrote:

On 05/04/2012 05:51 AM, marco atzeri wrote:



Usually
   kill -9 your_program_name

works very well


Usually 'kill -9 your_program' is overkill; it forcefully terminates the
program with SIGKILL, which means the program has no chance to clean up
after itself, and can leave your file system in a mess for the next time
you attempt to run the program.  You should reserve this for a
last-ditch effort, only after the nicer 'kill your_program' (SIGTERM) or
'kill -s INT' (SIGINT) both result in no action.



I had the impression he needs the last resort...

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

'cmd /C start cmd' no longer non-blocking (base-cygwin 3.1-1), but used to work (in base-cygwin 3.0-1)

[Petrisor Eddy-Marian-B36037]

Hello,

I am using at work cygwin on various machines (XP and Windows 7) and made 
several scripts that use gnu utilities from cygwin. One of those is a script 
that starts in paralel instances of cmd various parts of a build system through 
a sh script that invokes 'cmd /C start ...' to start those parts of the build 
system in a non-blocking fashion.

Recently, on one of the machines which had its cygwin installation upgraded, I 
have observed that the cmd instances do not start in a non-blocking fashion 
anymore, but instead wait for the process to finish.


To be more precise, following the following steps should lead to two 
interactive windows, one with the sh prompt and one with the cmd prompt, both 
waiting for user input:
1 - start a cygwin (or sh) command window
2 - type "cmd /C start cmd"

Expected result:
Two interactive and usable windows, one with the sh prompt, one with the cmd 
prompt, both waiting for user input.

Actual result:
Two windows, one with sh and one with cmd, Cygwin/sh window blocked and waiting 
for the cmd window to finish.



On another machine that hasn't had its cygwin install upgraded, the behaviour 
is the expected one. Here are the versions of the relevant packages that are 
found by the setup.exe to be upgradable on the working machine and the versions 
of the same packages on the non-working machine:

Working machine package versions:
base-cygwin 3.0-1
csih 0.9.5-1
cygutils 1.4.8-1
cygwin 1.7.11-1
rebase 4.0.1-1

Non-working machine package versions:
base-cygwin 3.1-1
csih 0.9.6-1
cygutils 1.4.10-2
cygwin 1.7.14-2
rebase 4.1.0-1

Note: There are other packages which could be upgraded on the working machine, 
but they are irrelevant: diffutils, file, gawk, groff sed and tzcode.


Any help would be appreciated.

P.S.: Please CC me, I am not subscribed.

Eddy



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Short gdb question.

[Reid Thompson]

On Fri, 2012-05-04 at 00:45 -0700, eric_justin_al...@cfl.rr.com wrote:
> Alright if I download and compile it can I just mv gdb.exe into /bin
> and 
> overwrite gdb.exe?
> 

use
./configure --prefix=/
make
make install

and it should end up in the right place

Re: Short gdb question.

[Reid Thompson]

On Fri, 2012-05-04 at 14:37 +, Reid Thompson wrote:
> On Fri, 2012-05-04 at 00:45 -0700, eric_justin_al...@cfl.rr.com wrote:
> > Alright if I download and compile it can I just mv gdb.exe into /bin
> > and 
> > overwrite gdb.exe?
> > 
> 
> use
> ./configure --prefix=/
> make
> make install
> 
> and it should end up in the right place
> 

I actually usually use

./configure --prefix=/usr


and everything ends up in the correct place

Re: Short gdb question.

[Ryan Johnson]

On 04/05/2012 8:39 AM, Reid Thompson wrote:

On Fri, 2012-05-04 at 14:37 +, Reid Thompson wrote:

On Fri, 2012-05-04 at 00:45 -0700, eric_justin_al...@cfl.rr.com wrote:

Alright if I download and compile it can I just mv gdb.exe into /bin
and
overwrite gdb.exe?


use
./configure --prefix=/
make
make install

and it should end up in the right place


I actually usually use

./configure --prefix=/usr


and everything ends up in the correct place
I always put stuff like this in ~/apps/$APP_NAME-$VERSION and add the 
appropriate bits to PATH, LD_LIBRARY_PATH and MANPATH... then later when 
I decide to upgrade/change/revert it's a simple matter of changing 
environment veriables...


Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 'cmd /C start cmd' no longer non-blocking (base-cygwin 3.1-1), but used to work (in base-cygwin 3.0-1)

[marco atzeri]

On 5/4/2012 3:43 PM, Petrisor Eddy-Marian-B36037 wrote:

Hello,

I am using at work cygwin on various machines (XP and Windows 7) and made 
several scripts that use gnu utilities from cygwin. One of those is a script 
that starts in paralel instances of cmd various parts of a build system through 
a sh script that invokes 'cmd /C start ...' to start those parts of the build 
system in a non-blocking fashion.

Recently, on one of the machines which had its cygwin installation upgraded, I 
have observed that the cmd instances do not start in a non-blocking fashion 
anymore, but instead wait for the process to finish.


To be more precise, following the following steps should lead to two 
interactive windows, one with the sh prompt and one with the cmd prompt, both 
waiting for user input:
1 - start a cygwin (or sh) command window
2 - type "cmd /C start cmd"


try
cmd /C start cmd &




Expected result:
Two interactive and usable windows, one with the sh prompt, one with the cmd 
prompt, both waiting for user input.

Actual result:
Two windows, one with sh and one with cmd, Cygwin/sh window blocked and waiting 
for the cmd window to finish.



On another machine that hasn't had its cygwin install upgraded, the behaviour 
is the expected one. Here are the versions of the relevant packages that are 
found by the setup.exe to be upgradable on the working machine and the versions 
of the same packages on the non-working machine:

Working machine package versions:
base-cygwin 3.0-1
csih 0.9.5-1
cygutils 1.4.8-1
cygwin 1.7.11-1
rebase 4.0.1-1

Non-working machine package versions:
base-cygwin 3.1-1
csih 0.9.6-1
cygutils 1.4.10-2
cygwin 1.7.14-2
rebase 4.1.0-1

Note: There are other packages which could be upgraded on the working machine, 
but they are irrelevant: diffutils, file, gawk, groff sed and tzcode.


Any help would be appreciated.

P.S.: Please CC me, I am not subscribed.

Eddy




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: 'cmd /C start cmd' no longer non-blocking (base-cygwin 3.1-1), but used to work (in base-cygwin 3.0-1)

[Petrisor Eddy-Marian-B36037]

> On 5/4/2012 3:43 PM, Petrisor Eddy-Marian-B36037 wrote:
> > Hello,
> >
> > I am using at work cygwin on various machines (XP and Windows 7) and
> made several scripts that use gnu utilities from cygwin. One of those is
> a script that starts in paralel instances of cmd various parts of a build
> system through a sh script that invokes 'cmd /C start ...' to start those
> parts of the build system in a non-blocking fashion.
> >
> > Recently, on one of the machines which had its cygwin installation
> upgraded, I have observed that the cmd instances do not start in a non-
> blocking fashion anymore, but instead wait for the process to finish.
> >
> >
> > To be more precise, following the following steps should lead to two
> interactive windows, one with the sh prompt and one with the cmd prompt,
> both waiting for user input:
> > 1 - start a cygwin (or sh) command window
> > 2 - type "cmd /C start cmd"
> 
> try
> cmd /C start cmd &
>
[Petrisor Eddy] 

I know about how to work around the issue, but the problem is that cygwin 
somehow interacts with start and renders it useless. If 'cmd /C some_command' 
has the same effect as 'cmd /C start some_command' under sh/cygwin, while 
working as expected in pure cmd, then cygwin is behaving badly and this issue 
is the one to be addressed especially since it is a regression.

> 
> >
> > Expected result:
> > Two interactive and usable windows, one with the sh prompt, one with
> the cmd prompt, both waiting for user input.
> >
> > Actual result:
> > Two windows, one with sh and one with cmd, Cygwin/sh window blocked and
> waiting for the cmd window to finish.
> >
> >
> >
> > On another machine that hasn't had its cygwin install upgraded, the
> behaviour is the expected one. Here are the versions of the relevant
> packages that are found by the setup.exe to be upgradable on the working
> machine and the versions of the same packages on the non-working machine:
> >
> > Working machine package versions:
> > base-cygwin 3.0-1
> > csih 0.9.5-1
> > cygutils 1.4.8-1
> > cygwin 1.7.11-1
> > rebase 4.0.1-1
> >
> > Non-working machine package versions:
> > base-cygwin 3.1-1
> > csih 0.9.6-1
> > cygutils 1.4.10-2
> > cygwin 1.7.14-2
> > rebase 4.1.0-1
> >
> > Note: There are other packages which could be upgraded on the working
> machine, but they are irrelevant: diffutils, file, gawk, groff sed and
> tzcode.
> >
> >
> > Any help would be appreciated.
> >
> > P.S.: Please CC me, I am not subscribed.
> >
> > Eddy
> >
> 



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 'cmd /C start cmd' no longer non-blocking (base-cygwin 3.1-1), but used to work (in base-cygwin 3.0-1)

[Christopher Faylor]

On Fri, May 04, 2012 at 04:41:12PM +, Petrisor Eddy-Marian-B36037 wrote:
>
>> On 5/4/2012 3:43 PM, Petrisor Eddy-Marian-B36037 wrote:
>> > Hello,
>> >
>> > I am using at work cygwin on various machines (XP and Windows 7) and
>> made several scripts that use gnu utilities from cygwin. One of those is
>> a script that starts in paralel instances of cmd various parts of a build
>> system through a sh script that invokes 'cmd /C start ...' to start those
>> parts of the build system in a non-blocking fashion.
>> >
>> > Recently, on one of the machines which had its cygwin installation
>> upgraded, I have observed that the cmd instances do not start in a non-
>> blocking fashion anymore, but instead wait for the process to finish.
>> >
>> >
>> > To be more precise, following the following steps should lead to two
>> interactive windows, one with the sh prompt and one with the cmd prompt,
>> both waiting for user input:
>> > 1 - start a cygwin (or sh) command window
>> > 2 - type "cmd /C start cmd"
>> 
>> try
>> cmd /C start cmd &
>>
>[Petrisor Eddy] 
>
>I know about how to work around the issue, but the problem is that
>cygwin somehow interacts with start and renders it useless.  If 'cmd /C
>some_command' has the same effect as 'cmd /C start some_command' under
>sh/cygwin, while working as expected in pure cmd, then cygwin is
>behaving badly and this issue is the one to be addressed especially
>since it is a regression.

How about if I make it official: The change in behavior is due to some
changes in 1.7.1* which were required to improve stability with execed
processes.

So, please use the workaround.  We make no guarantees about how the
start command in CMD will interoperate with Cygwin but we do guarantee
that "&" will always create a background process.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

permission denied while executing files which have execute permission

[Jeff Janes]

Twice in the last week I've run into a problem where I can't execute
programs which have the correct execute permissions set under both
chmod and setfacl.

It took me a long time to track it down to the issue described here:
http://social.msdn.microsoft.com/forums/en-US/windowssecurity/thread/73f86e9e-928f-40b7-8dd5-27e40db6997e/

The presence of error 740 in the strace seems be pathognomonic for this problem.

strace: error creating process
C:\cygwin\home\jjanes\patch-2.6.1\src\patch.exe, (error 740)

This persists up to DLL version 1.7.14-2

Given how hard this was to track down, could a note be added in the
cygwin FAQs about this?

I ran into this problem trying to build an updated patch.exe (which I
needed to build coreutils, but which I see I no longer need as an
upgrade for patch.exe was released this morning), and also in trying
to build coreutils from the upstream source due to the ginstall.exe
file.

For the curious, the reason I'm trying to build coreutils from source
is to figure out why "cut" is so slow.  On Linux, setting LANG=C makes
cut much faster, but on cygwin this setting does not result in a speed
up for 'cut'.  But first things first.

Cheers,

Jeff

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: permission denied while executing files which have execute permission

[Eric Blake]

On 05/04/2012 11:24 AM, Jeff Janes wrote:
> I ran into this problem trying to build an updated patch.exe (which I
> needed to build coreutils, but which I see I no longer need as an
> upgrade for patch.exe was released this morning), and also in trying
> to build coreutils from the upstream source due to the ginstall.exe
> file.

Are you starting from coreutils as downloaded from setup.exe and which
includes coreutils.cygport that will create the necessary
install.exe.manifest needed to work around the naming issues of
install.exe?  Or are you trying to build upstream coreutils.git, in
which case you are missing out on several cygwin-specific patches in the
cygwin distro of coreutils that might prove important in your
investigation of cut?

> 
> For the curious, the reason I'm trying to build coreutils from source
> is to figure out why "cut" is so slow.  On Linux, setting LANG=C makes
> cut much faster, but on cygwin this setting does not result in a speed
> up for 'cut'.  But first things first.

In general, packages built by cygport should already have the manifest
files created for the problematic names, so that you should be able to
work around the UAC brain-dead name filtering.  It's hard to call it a
FAQ if you are only running into the problem on self-built files, rather
than files that are part of the distro.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: gdb problem

[Ken Brown]

On 5/3/2012 11:10 PM, Christopher Faylor wrote:

On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:

On 10/23/2011 5:47 PM, Ken Brown wrote:

On 10/23/2011 3:04 PM, Christopher Faylor wrote:

On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:

The attached testcase illustrates a problem with `gdb -i=mi'. I've
tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
several recent snapshots (including 2011-10-22).

Under some circumstances, if gdb -i=mi is started and given several
input lines at once, it only prints part of the output before stopping.
I've been able to reproduce this once in a while while working
interactively (by copying and pasting the whole bunch of input lines);
in this case one can press Return to get the rest of the output. But
the problem happens consistently with the attached test case, which runs
gdb in a subprocess. One has to kill the gdb process before the main
program exits.

The STC runs as expected on Linux.


Thanks for the STC. I had to tweak it to actually see how it was supposed
to work on Linux since only a limited number of lines from the pty were
being output. I've included the revised test case below.

I made a simple change to Cygwin which will probably cause subtle
problems somewhere down the line. At least for now it seems to make gdb
operate as expected.

I'm building a new snapshot now.


Thanks, that fixes it (as well as the emacs problem that originally led
to this report). In case there are emacs users wondering what this is
about, I've been testing emacs-24, which uses gdb -i=mi instead of the
obsolete gdb --annotate=3 used by emacs-23.


I'm replying to this old thread because the problem is back again in
cygwin-1.7.14-2.  I haven't checked to see exactly when it first
reappeared (but I'll do this if it would help.)  The same STC as before
exhibits the problem; I'm attaching it for convenience.


Thanks for the heads up.  This should be fixed in the next snapshot.


Confirmed.  Thanks.

Ryan, if you're reading this, the problems you were seeing with M-x gdb 
in emacs should be fixed now.



Incidentally, I've started putting longer explications of what I've
debugged and how I debugged it in a "DevNotes" file in the source:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes?cvsroot=src

I hope to keep this up-to-date with extended rationales for why things
were done a certain way and with descriptions about the steps that I
used to track down a problem.

This file is not a substitute for comments (we've been trying to be more
diligent about commenting changes in the source) or a ChangeLog but I
hope that it will help me in the future when I have to figure out "Why
the heck did I make that change?"


Great idea.  It's also useful for people like me who like to understand 
what caused a problem they reported and how it got fixed.


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

1.7.14: bind host crash

[Igor Kostenko]

I'm using experimental packages. After today's update host utility from bind
package stopped working with "dst_lib_init: openssl failure" error. Found
advise to install openssl package here -
http://sourceware.org/ml/cygwin/2012-04/msg00217.html

Now host crashes with both available bind packages (9.9.0-3 & 9.9.0-2):

$ uname -a
CYGWIN_NT-6.1-WOW64 GBD09501436 1.7.14(0.260/5/3) 2012-04-25 09:41 i686
Cygwin

$ host localhost
Host localhost not found: 3(NXDOMAIN)
/usr/src/ports/bind/bind-9.9.0-3/src/bind-9.9.0/lib/isc/mem.c:1099:
INSIST(ctx->stats[i].gets == 0U) failed.
Aborted (core dumped)

WBR, Igor
-- 
View this message in context: 
http://old.nabble.com/1.7.14%3A-bind-host-crash-tp33763473p33763473.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

[Ken Brown]

On 5/3/2012 4:10 PM, Ryan Johnson wrote:

On 03/05/2012 10:45 AM, Ken Brown wrote:

On 5/2/2012 5:02 PM, Ryan Johnson wrote:

On 02/05/2012 1:16 PM, Ryan Johnson wrote:
The gdb-mi integration also seems to work reasonably well, with a few
exceptions:

[...]

(This was fixed once and was a Cygwin bug, so I think it won't be hard
for me to resurrect my test case and get it fixed again.)


This is now fixed (http://cygwin.com/ml/cygwin/2012-05/msg00084.html).


One last note: I normally use emacs in terminal mode, but couldn't do
that inside gdb (for obvious reasons). Some of the behaviors I observed
before -- including seg faults -- may be terminal-specific, and some of
the new strangeness I'm pointing out now may be X11-specific... or it
might just be the difference between -O0 and -O2.


What do you mean by "terminal mode"? Do you mean you run emacs under
mintty? Or do you run it under xterm with the -nw switch? And could
you elaborate on the "obvious reasons"? I don't see why you can't run
emacs in a terminal under gdb; or attach to it from a different
terminal if that's more convenient.

I usually run under mintty with -nw. When following the instructions in
that /etc/DEBUG file you pointed me at, the .gdbinit included
breakpoints and other pre-main intializations to perform that would not
happen if I merely attached to a running emacs. However, that will
probably be my next attempt, since the X11 route didn't pan out (and I
dislike using the graphical version).


I'm not sure why you're using the -nw switch when you start emacs in 
mintty.  As far as I can tell from the documentation, -nw shouldn't do 
anything if you're not running under X.  But it also shouldn't do any 
harm.  In any case, I still don't see why you can't run emacs under gdb 
in mintty:


$ cd emacs-24.0.95/src/
$ gdb ./emacs.exe
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from 
terminal]

Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x4ded26: file emacs.c, line 394.
Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855.
(gdb) r -Q
[...]

Now if it crashes, won't you be returned to gdb where you can get a 
backtrace?


And attaching from another mintty also works; gdb processes the .gdbinit 
file just fine as long as you start gdb from the emacs src directory:


$ gdb --pid=13144
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
.
Attaching to process 5672
[New Thread 5672.0xd24]
[New Thread 5672.0x2dec]
[New Thread 5672.0x2b08]
[New Thread 5672.0x13c0]
[New Thread 5672.0x2cd4]
[New Thread 5672.0x2de4]
[New Thread 5672.0x2818]
[New Thread 5672.0x33d0]
Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from 
terminal]

Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x4ded26: file emacs.c, line 394.
Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855.
(gdb) c
Continuing.

Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.14: bind host crash

[Yaakov (Cygwin/X)]

On 2012-05-04 14:22, Igor Kostenko wrote:

Now host crashes with both available bind packages (9.9.0-3&  9.9.0-2):

$ uname -a
CYGWIN_NT-6.1-WOW64 GBD09501436 1.7.14(0.260/5/3) 2012-04-25 09:41 i686
Cygwin

$ host localhost
Host localhost not found: 3(NXDOMAIN)
/usr/src/ports/bind/bind-9.9.0-3/src/bind-9.9.0/lib/isc/mem.c:1099:
INSIST(ctx->stats[i].gets == 0U) failed.
Aborted (core dumped)


WFM:

$ host localhost
localhost has address 127.0.0.1


Yaakov

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: readline-6.1.2-3, libreadline7-6.1.2-3

[Eric Blake (cygwin)]

A new release 6.1.2-3 for readline and libreadline7, is available for
download, replacing 6.1.2-2 as current.  6.0.3-2 remains as previous.

NEWS:
=
This is a minor rebuild, updating to take advantage of newer cygwin
features and dropping the dynamicbase flag from dlls now that
'rebaseall' is able to do a better job.  See also the upstream
documentation in /usr/share/doc/readline/.

NOTES:
==
Be aware that an issue with offering libreadline as both a static and
dynamic library has been identified - some functions, such as
rl_function_of_keyseq, cannot work correctly with both library styles
without some additional __declspec decoration in the dynamic case.  This
release caters to static compilation (and packages like bash that use
the problematic functions from dynamic readline have to add a minimal
workaround); it is possible that a future package will either be
dynamic-only, or that compiling against the static readline-6.0 will
require the declaration of a preprocessor macro, so that dynamic linking
works without requiring patches to every client.

DESCRIPTION:

The readline library will read a line from the terminal and return it,
allowing the user to edit the line with emacs or vi editing keys.  It
also allows a history feature, for editing previous entries, making
command line interfaces easier-to-use and more intuitive.

libreadline7 provides the .dlls needed for readline and history
expansion for dynamic linking in other programs, including bash and gdb;
it is required for a minimal cygwin installation.  The 7 in libreadline7
distinguishes incompatible API changes made to the prior libreadline5
and libreadline6 libraries still available on the mirrors. readline
provides the documentation and the static libraries required for static
linking; you should only need it if you plan on compiling an application
that links with -lreadline or -lhistory.

UPDATE:
===
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system. Save it and run setup, answer the questions and pick up
'libreadline7' from the 'Base' category (it should already be selected),
or 'readline' in the 'Devel' category.  Since this is an experimental
release, you will need to use the 'Exp' radio button to get access to
this version.  Be sure that you do not have any cygwin programs running
during the upgrade.

DOWNLOAD:
=
Note that downloads from cygwin.com aren't allowed due to bandwidth
limitations.  This means that you will need to find a mirror which has
this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin readline package maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



signature.asc
Description: OpenPGP digital signature

1.7.14-2: bash not accepting "~" (tilde) from keyboard in Console (WIN7)

[Chris Brouwer]

Hello,

I have just installed Cygwin 1.17.14-2 using the setup.exe.

I use Console (portable; from Portableapp.Com) as my entry to bash. I 
created an extra tab definition for Console, which starts cygwin.bat. 
Works as expected, so far.
The odd thing is, if I want to use, eg cd ~, the tilde is not shown, but 
the backtick "`" is.


I have tried this when calling cygwin.bat from Explorer, effectively 
starting cygwin from cmd.exe, and then the "~" works as expected.


Does anyone else experience this ?

Does anyone have a solution for this ?

Thanks in advance.

Chris.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7.14: bind host crash

[Adrian Fita]

On 04/05/12 23:24, Yaakov (Cygwin/X) wrote:

On 2012-05-04 14:22, Igor Kostenko wrote:

Now host crashes with both available bind packages (9.9.0-3& 9.9.0-2):

$ uname -a
CYGWIN_NT-6.1-WOW64 GBD09501436 1.7.14(0.260/5/3) 2012-04-25 09:41 i686
Cygwin

$ host localhost
Host localhost not found: 3(NXDOMAIN)
/usr/src/ports/bind/bind-9.9.0-3/src/bind-9.9.0/lib/isc/mem.c:1099:
INSIST(ctx->stats[i].gets == 0U) failed.
Aborted (core dumped)


WFM:

$ host localhost
localhost has address 127.0.0.1


Works here also.

Please try to run host under strace like so:

  strace -o host_strace.log host localhost

and then investigate the resulting file, host_strace.log. First look at 
the end for any error, then, if there's no obvious error, look up for 
anything suspicious.


PS: The "dst_lib_init: openssl failure" issue is indeed still not solved.

--
Fita Adrian

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

screen goes messy in vi

[Marilo]

Here are 2 screenshots of me trying to read a readme.txt file for a program

I have the same problem for other files too.

It looks fine when I open it.. 

(in vi)
http://i45.tinypic.com/n6rxu1.jpg

(after exiting vi)
http://i49.tinypic.com/126dxmx.jpg

Like when I try to read sshd_config
it looks messy too.

http://i46.tinypic.com/357py1l.jpg

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gdb problem

[Ryan Johnson]

On 04/05/2012 1:19 PM, Ken Brown wrote:

On 5/3/2012 11:10 PM, Christopher Faylor wrote:

On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:

On 10/23/2011 5:47 PM, Ken Brown wrote:

On 10/23/2011 3:04 PM, Christopher Faylor wrote:

On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:

The attached testcase illustrates a problem with `gdb -i=mi'. I've
tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well 
as with

several recent snapshots (including 2011-10-22).

Under some circumstances, if gdb -i=mi is started and given several
input lines at once, it only prints part of the output before 
stopping.

I've been able to reproduce this once in a while while working
interactively (by copying and pasting the whole bunch of input 
lines);

in this case one can press Return to get the rest of the output. But
the problem happens consistently with the attached test case, 
which runs

gdb in a subprocess. One has to kill the gdb process before the main
program exits.

The STC runs as expected on Linux.


Thanks for the STC. I had to tweak it to actually see how it was 
supposed
to work on Linux since only a limited number of lines from the pty 
were

being output. I've included the revised test case below.

I made a simple change to Cygwin which will probably cause subtle
problems somewhere down the line. At least for now it seems to 
make gdb

operate as expected.

I'm building a new snapshot now.


Thanks, that fixes it (as well as the emacs problem that originally 
led

to this report). In case there are emacs users wondering what this is
about, I've been testing emacs-24, which uses gdb -i=mi instead of the
obsolete gdb --annotate=3 used by emacs-23.


I'm replying to this old thread because the problem is back again in
cygwin-1.7.14-2.  I haven't checked to see exactly when it first
reappeared (but I'll do this if it would help.)  The same STC as before
exhibits the problem; I'm attaching it for convenience.


Thanks for the heads up.  This should be fixed in the next snapshot.


Confirmed.  Thanks.

Ryan, if you're reading this, the problems you were seeing with M-x 
gdb in emacs should be fixed now.

Sorry, do you mean the problems with emacs-23 -annotate=3 or emacs-24 -mi?

Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

[Ryan Johnson]

On 04/05/2012 1:39 PM, Ken Brown wrote:

On 5/3/2012 4:10 PM, Ryan Johnson wrote:

On 03/05/2012 10:45 AM, Ken Brown wrote:

On 5/2/2012 5:02 PM, Ryan Johnson wrote:

On 02/05/2012 1:16 PM, Ryan Johnson wrote:
The gdb-mi integration also seems to work reasonably well, with a few
exceptions:

[...]

(This was fixed once and was a Cygwin bug, so I think it won't be hard
for me to resurrect my test case and get it fixed again.)


This is now fixed (http://cygwin.com/ml/cygwin/2012-05/msg00084.html).

Ack.




One last note: I normally use emacs in terminal mode, but couldn't do
that inside gdb (for obvious reasons). Some of the behaviors I 
observed
before -- including seg faults -- may be terminal-specific, and 
some of

the new strangeness I'm pointing out now may be X11-specific... or it
might just be the difference between -O0 and -O2.


What do you mean by "terminal mode"? Do you mean you run emacs under
mintty? Or do you run it under xterm with the -nw switch? And could
you elaborate on the "obvious reasons"? I don't see why you can't run
emacs in a terminal under gdb; or attach to it from a different
terminal if that's more convenient.

I usually run under mintty with -nw. When following the instructions in
that /etc/DEBUG file you pointed me at, the .gdbinit included
breakpoints and other pre-main intializations to perform that would not
happen if I merely attached to a running emacs. However, that will
probably be my next attempt, since the X11 route didn't pan out (and I
dislike using the graphical version).


I'm not sure why you're using the -nw switch when you start emacs in 
mintty.  As far as I can tell from the documentation, -nw shouldn't do 
anything if you're not running under X.
I have DISPLAY defined for things like gnuplot, but don't want emacs to 
use it even when X is available...



I still don't see why you can't run emacs under gdb in mintty:

$ cd emacs-24.0.95/src/
$ gdb ./emacs.exe
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "i686-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/emacs-24.0.95/src/emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not 
from terminal]

Environment variable "DISPLAY" not defined.
TERM = xterm
Breakpoint 1 at 0x4ded26: file emacs.c, line 394.
Temporary breakpoint 2 at 0x4f8970: file sysdep.c, line 855.
(gdb) r -Q
[...]

Now if it crashes, won't you be returned to gdb where you can get a 
backtrace?
I guess that might work, since I wouldn't do anything but grab the 
backtrace. It just doesn't work well to mix gdb and curses-using apps in 
the same terminal.


And attaching from another mintty also works; gdb processes the 
.gdbinit file just fine as long as you start gdb from the emacs src 
directory:
Duh... I hadn't thought to specify the --pid switch; I usually just 
attach inside gdb, and that's too late for the purposes of .gdbinit.


Thanks!
Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

OpenSSH using root for the .ssh directory?

[Chris Sutcliffe]

I've recently installed the latest Cygwin packages (as of 05/04/2012)
to a Windows 7 machine and when using ssh I couldn't figure out why it
couldn't find my private key in ~/.ssh/.  Executing ssh with -vvv I
see:

debug1: Trying private key: /.ssh/id_rsa
debug3: no such identity: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug3: no such identity: /.ssh/id_dsa
debug1: Trying private key: /.ssh/id_ecdsa
debug3: no such identity: /.ssh/id_ecdsa

I'm at a loss as to why it's looking in the root directory.  Sure
enough moving my private key there worked, but that's a security hole.
 Checking my system for an errant HOME value, all seems to be inline:

$ echo $HOME
/home/csutclif

Any ideas why ssh is looking in the root directory?

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: OpenSSH using root for the .ssh directory?

[Fedin Pavel]

On 05.05.2012 7:06, Chris Sutcliffe wrote:

I'm at a loss as to why it's looking in the root directory.


 Look at your /etc/passwd. Here, on my machine,home directory is empty 
for my username. Perhaps mkpasswd's bug. You can fix it by manually 
setting the right path in /etc/passwd.


--
 Kind regards
 Pavel Fedin
 Expert engineer, Samsung Moscow research center


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple