Re: Ctrl-backspace not working

[Pavel Tsekov]

Hello,

 Original-Nachricht 
> Datum: Thu, 4 Oct 2007 10:03:22 +0100
> Von: "Dom H"
> Betreff: Ctrl-backspace not working

> I'm trying to use the 'hotlist' command in mc but Ctrl-\ doesn't seem
> to work, any ideas? Pressing ctrl-\ doesn't show any signs when
> pressed in cygwin bash or even in a dos prompt for that matter.
> 
>  I'm running the current binary release of cygwin in a dos terminal
> under Windows XP

Cygwin's MC package is missing a patch which enables linux console style 
querying of the keyboard modifiers. A new upstream version of MC is going to be 
released by the end of October (most likely) - it will include the 
missing patch. If you a interested in building MC yourself I can send you the 
patch off-list- it is pretty simplistic.


-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

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

Ctrl-backspace not working

[Dom H]

I'm trying to use the 'hotlist' command in mc but Ctrl-\ doesn't seem
to work, any ideas? Pressing ctrl-\ doesn't show any signs when
pressed in cygwin bash or even in a dos prompt for that matter.

 I'm running the current binary release of cygwin in a dos terminal
under Windows XP


Thanks

Dom

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

screen reattach not working?

[Damjan Lango]

Hi!
What is the current status of screen reattach?
For me it does not work under the default cygwin bash shell, which
uses cmd console afaik and it does not work under cygwin sshd. The
only way it works is under cygwin rxvt. I would most like to use it
under sshd.
What's the magic to make it work? :)
Thanks,
Damjan

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

Debugging with cygwin tools

[Alberto Luaces]

Hello,

I am just starting to learn how to use the debugging tools available in
Cygwin. To do so, I have a test program deliberately designed to crash:

#include 

int main()
{
int *p=0;

*p=9;

return 0;
}

I have compiled it with debugging information:

g++ -g -O0 -o core core.cpp

Then I try to run it with gdb:

gdb core.exe

(gdb) b main
Breakpoint 1 at 0x401175: file core.cpp, line 4.
(gdb) r
Starting program: /home/Demostración/testsC++/core.exe
Error: dll starting at 0x77d41000 not found.
Segmentation fault (core dumped)

As seen, gdb crashes without even start the program.

Then, I am trying to get a core dump:

$ export CYGWIN=error_start=c:\\cygwin\\bin\\dumper.exe
$ ./core
*** starting debugger for pid 2664, tid 544

but the program 'dump.exe' never returns and no core file is generated.

My system is running WinXP-64. I have read on the archives that
dumper.exe should work correctly but it is not.

How can I finally debug my program?

Alberto



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

Re: Home directory

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gmane User on 10/3/2007 10:30 PM:
> 
> 
> I did indeed check that before posting to ask about where release notes can be
> found.  In fact, they can be found peicemeal at http://tinyurl.com/2dxno3, but
> it makes it hard to quickly scan for changes to "mv".  Many software systems
> have cumulative release notes with each new release...

Why not look at the coreutils source repository, then?
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=NEWS

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBNe384KuGfSFAYARAsFTAKCaUOpF/eqfa5Du5mL2aJvyQ66F0gCeMAqX
hq3Odrs7P9moFSiPlzP+B5A=
=h86W
-END PGP SIGNATURE-

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

Bad EXE format (error 193)

[Lynn Winebarger]

   I am trying to get the Larceny Scheme compiler
(http://www.ccs.neu.edu/home/will/Larceny/) to compile (and work)
under the most recent stable Cygwin release.  While I have managed to
get it to produce a file that very closely resembles a PE file, it
apparently is not close enough to satisfy Windows XP Home Edition SP
2.
   Unfortunately, objdump and other file analyzers have no problem
with the file, while none of the debuggers I tried had anything
helpful to say about the problem.  I have compiled other things under
Cygwin (PLT Scheme, for example) that not only produced an executable
image but produced one Windows would actually run.  I have tried doing
a diff against the headers between this and the Larceny image and
cannot see a glaring error (but I am not an expert in either Windows
executables or Larceny's source code).
I cannot find anything helpful on this error in the mailing list
archives.  Is there a tool that would identify the problem, or maybe a
kind expert with some guidance on resolving this issue?

Thanks,
Lynn

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

RE: Bad EXE format (error 193)

[Dave Korn]

On 04 October 2007 14:59, Dave Korn wrote:

> On 04 October 2007 14:56, Dave Korn wrote:
> 
>> On 04 October 2007 14:21, Lynn Winebarger wrote:
>> 
>>>I am trying to get the Larceny Scheme compiler
>>> (http://www.ccs.neu.edu/home/will/Larceny/) to compile (and work)
>>> under the most recent stable Cygwin release.  While I have managed to
>>> get it to produce a file that very closely resembles a PE file, it
>>> apparently is not close enough to satisfy Windows XP Home Edition SP 2.
>>>Unfortunately, objdump and other file analyzers have no problem
>>> with the file, while none of the debuggers I tried had anything
>>> helpful to say about the problem.  I have compiled other things under
>>> Cygwin (PLT Scheme, for example) that not only produced an executable
>>> image but produced one Windows would actually run.  I have tried doing
>>> a diff against the headers between this and the Larceny image and
>>> cannot see a glaring error (but I am not an expert in either Windows
>>> executables or Larceny's source code).
>>> I cannot find anything helpful on this error in the mailing list
>>> archives.  Is there a tool that would identify the problem, or maybe a
>>> kind expert with some guidance on resolving this issue?
>> 
>>   We might be able to make guesses at what was wrong with the compiled
>> program if you told us *in what way* it is "not close enough to satisfy
>> Windows XP".
> 
>   Ah.  And I just took a closer look at the subject line.  So I'm guessing
> you see an error message along those lines, yes?  Hm.  Does it still happen
> if you compile the most basic sort of "hello world" program?  


  It might also be informative to run "cygcheck " on your
compiled executable; that'll display the dependent DLLs for you.  A bit of
googling suggests that 193 can be caused by a corrupt/bogus executable, but
equally by a good executable thatt depends on a DLL which is faulty.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Bad EXE format (error 193)

[Dave Korn]

On 04 October 2007 14:21, Lynn Winebarger wrote:

>I am trying to get the Larceny Scheme compiler
> (http://www.ccs.neu.edu/home/will/Larceny/) to compile (and work)
> under the most recent stable Cygwin release.  While I have managed to
> get it to produce a file that very closely resembles a PE file, it
> apparently is not close enough to satisfy Windows XP Home Edition SP
> 2.
>Unfortunately, objdump and other file analyzers have no problem
> with the file, while none of the debuggers I tried had anything
> helpful to say about the problem.  I have compiled other things under
> Cygwin (PLT Scheme, for example) that not only produced an executable
> image but produced one Windows would actually run.  I have tried doing
> a diff against the headers between this and the Larceny image and
> cannot see a glaring error (but I am not an expert in either Windows
> executables or Larceny's source code).
> I cannot find anything helpful on this error in the mailing list
> archives.  Is there a tool that would identify the problem, or maybe a
> kind expert with some guidance on resolving this issue?

  We might be able to make guesses at what was wrong with the compiled program
if you told us *in what way* it is "not close enough to satisfy Windows XP".



cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Bad EXE format (error 193)

[Dave Korn]

On 04 October 2007 14:56, Dave Korn wrote:

> On 04 October 2007 14:21, Lynn Winebarger wrote:
> 
>>I am trying to get the Larceny Scheme compiler
>> (http://www.ccs.neu.edu/home/will/Larceny/) to compile (and work)
>> under the most recent stable Cygwin release.  While I have managed to
>> get it to produce a file that very closely resembles a PE file, it
>> apparently is not close enough to satisfy Windows XP Home Edition SP 2.
>>Unfortunately, objdump and other file analyzers have no problem
>> with the file, while none of the debuggers I tried had anything
>> helpful to say about the problem.  I have compiled other things under
>> Cygwin (PLT Scheme, for example) that not only produced an executable
>> image but produced one Windows would actually run.  I have tried doing
>> a diff against the headers between this and the Larceny image and
>> cannot see a glaring error (but I am not an expert in either Windows
>> executables or Larceny's source code).
>> I cannot find anything helpful on this error in the mailing list
>> archives.  Is there a tool that would identify the problem, or maybe a
>> kind expert with some guidance on resolving this issue?
> 
>   We might be able to make guesses at what was wrong with the compiled
> program if you told us *in what way* it is "not close enough to satisfy
> Windows XP".  

  Ah.  And I just took a closer look at the subject line.  So I'm guessing you
see an error message along those lines, yes?  Hm.  Does it still happen if you
compile the most basic sort of "hello world" program?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Ctrl-backspace not working

[Pavel Tsekov]

Hello,

 Original-Nachricht 
> Datum: Thu, 4 Oct 2007 14:39:10 +0100
> Von: "Dom H"
> An: "Pavel Tsekov"
> Betreff: Re: Ctrl-backspace not working

> Hi, it's ok I can wait. Thanks for the response. How when the patched
> version is released?

I hope to get it out by the end of October. Initially I hoped for mid-October 
but I think the release will be delayed for a little while.

> On 04/10/2007, Pavel Tsekov <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> >  Original-Nachricht 
> > > Datum: Thu, 4 Oct 2007 10:03:22 +0100
> > > Von: "Dom H"
> > > Betreff: Ctrl-backspace not working
> >
> > > I'm trying to use the 'hotlist' command in mc but Ctrl-\ doesn't seem
> > > to work, any ideas? Pressing ctrl-\ doesn't show any signs when
> > > pressed in cygwin bash or even in a dos prompt for that matter.
> > >
> > >  I'm running the current binary release of cygwin in a dos terminal
> > > under Windows XP
> >
> > Cygwin's MC package is missing a patch which enables linux console style
> querying of the keyboard modifiers. A new upstream version of MC is going
> to be released by the end of October (most likely) - it will include the
> > missing patch. If you a interested in building MC yourself I can send
> you the patch off-list- it is pretty simplistic.
> >
> >
> > --
> > Pt! Schon vom neuen GMX MultiMessenger gehört?
> > Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
> >

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

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

RE: Bad EXE format (error 193)

[Dave Korn]

On 04 October 2007 15:26, Lynn Winebarger wrote:


>>> you see an error message along those lines, yes?  Hm.  Does it still
>>> happen if you compile the most basic sort of "hello world" program?
>> 
>> 
>>   It might also be informative to run "cygcheck " on your
>> compiled executable; that'll display the dependent DLLs for you.  A bit of
>> googling suggests that 193 can be caused by a corrupt/bogus executable, but
>> equally by a good executable thatt depends on a DLL which is faulty.
>> 
> 
> Thanks, Dave.  I did compile a hello-world.c program, and it ran, but
> I had also compiled PLT scheme v360 before (needed to bootstrap
> Larceny) and had run it without problem as well (I had thought this
> might be a permission issue, because what bash actually reports is
> "Access denied" - the underlying error took further investigation)

  Actually, I was trying to ask if you'd compiled a basic "helloworld" with
your new larceny compiler, or indeed if this example of yours is already a
very simple test program; i.e. is it only complex larceny executables that
don't work, or even the very simplest ones.

> $ cygcheck ./larcenybin.exe
> .\larcenybin.exe
>   C:\cygwin\bin\cygwin1.dll
> C:\WINDOWS\system32\ADVAPI32.DLL
>   C:\WINDOWS\system32\ntdll.dll
>   C:\WINDOWS\system32\KERNEL32.dll
>   C:\WINDOWS\system32\RPCRT4.dll

  Unfortunately that all looks completely correct, no clues there.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Bad EXE format (error 193)

[Lynn Winebarger]

(Sorry for the formatting, I belatedly subscribed to the list and got
this as a thread digest)
> From: "Dave Korn" <[EMAIL PROTECTED]>
>
> > On 04 October 2007 14:56, Dave Korn wrote:
> >
> >>   We might be able to make guesses at what was wrong with the compiled
> >> program if you told us *in what way* it is "not close enough to satisfy
> >> Windows XP".
> >
> >   Ah.  And I just took a closer look at the subject line.  So I'm guessing
> > you see an error message along those lines, yes?  Hm.  Does it still happen
> > if you compile the most basic sort of "hello world" program?
>
>
>   It might also be informative to run "cygcheck " on your
> compiled executable; that'll display the dependent DLLs for you.  A bit of
> googling suggests that 193 can be caused by a corrupt/bogus executable, but
> equally by a good executable thatt depends on a DLL which is faulty.
>

Thanks, Dave.  I did compile a hello-world.c program, and it ran, but
I had also compiled PLT scheme v360 before (needed to bootstrap
Larceny) and had run it without problem as well (I had thought this
might be a permission issue, because what bash actually reports is
"Access denied" - the underlying error took further investigation).

$ cygcheck ./larcenybin.exe
.\larcenybin.exe
  C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
  C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\KERNEL32.dll
  C:\WINDOWS\system32\RPCRT4.dll


Thanks,
Lynn

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

Re: Bad EXE format (error 193)

[Lynn Winebarger]

On 10/4/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 04 October 2007 15:26, Lynn Winebarger wrote:
> > Thanks, Dave.  I did compile a hello-world.c program, and it ran, but
> > I had also compiled PLT scheme v360 before (needed to bootstrap
> > Larceny) and had run it without problem as well (I had thought this
> > might be a permission issue, because what bash actually reports is
> > "Access denied" - the underlying error took further investigation)
>
>   Actually, I was trying to ask if you'd compiled a basic "helloworld" with
> your new larceny compiler, or indeed if this example of yours is already a
> very simple test program; i.e. is it only complex larceny executables that
> don't work, or even the very simplest ones.
>
   I did not understand.  No, the larceny binary (runtime
system/interpreter) won't load at all - it doesn't even make it to the
entry point.  I'm more than willing to send the "executable".  It
might be something an expert could quickly spot.  Or the linker map
output, if that would be useful.

Thanks,
Lynn

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

Re: Bad EXE format (error 193)

[Lynn Winebarger]

On 10/4/07, Lynn Winebarger <[EMAIL PROTECTED]> wrote:
> On 10/4/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > On 04 October 2007 15:26, Lynn Winebarger wrote:
> > > Thanks, Dave.  I did compile a hello-world.c program, and it ran, but
> > > I had also compiled PLT scheme v360 before (needed to bootstrap
> > > Larceny) and had run it without problem as well (I had thought this
> > > might be a permission issue, because what bash actually reports is
> > > "Access denied" - the underlying error took further investigation)
> >
> >   Actually, I was trying to ask if you'd compiled a basic "helloworld" with
> > your new larceny compiler, or indeed if this example of yours is already a
> > very simple test program; i.e. is it only complex larceny executables that
> > don't work, or even the very simplest ones.
> >
>I did not understand.  No, the larceny binary (runtime
> system/interpreter) won't load at all - it doesn't even make it to the
> entry point.  I'm more than willing to send the "executable".  It
> might be something an expert could quickly spot.  Or the linker map
> output, if that would be useful.

   Or, if someone knows of a program, or a pointer to what black magic
Windows does to determine that a PE file is "valid".  I have briefly
reviewed the PE documentation MS provides, but nothing has leaped out
at me (e.g. the flags on the sections appear consistent with their
specification).

Lynn

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

RE: Bad EXE format (error 193)

[Dave Korn]

On 04 October 2007 16:04, Lynn Winebarger wrote:

> On 10/4/07, Dave Korn <[EMAIL PROTECTED]> wrote:
>> On 04 October 2007 15:26, Lynn Winebarger wrote:
>>> Thanks, Dave.  I did compile a hello-world.c program, and it ran, but
>>> I had also compiled PLT scheme v360 before (needed to bootstrap
>>> Larceny) and had run it without problem as well (I had thought this
>>> might be a permission issue, because what bash actually reports is
>>> "Access denied" - the underlying error took further investigation)
>> 
>>   Actually, I was trying to ask if you'd compiled a basic "helloworld" with
>> your new larceny compiler, or indeed if this example of yours is already a
>> very simple test program; i.e. is it only complex larceny executables that
>> don't work, or even the very simplest ones.
>> 
>I did not understand.  No, the larceny binary (runtime
> system/interpreter) won't load at all - it doesn't even make it to the
> entry point.

  Oh, my misunderstanding; I thought that we were talking about the compiled
executables /generated by/ the larceny compiler, rather than the actual
larceny compiler itself.

> I'm more than willing to send the "executable".  It
> might be something an expert could quickly spot.  Or the linker map
> output, if that would be useful.

  Yes, why not; feel free to send them both to me, off list.  Can't promise
I'll spot anything, but I'll take a look.  (My first WAG would be that the
sassy assembler does something different from other w32 assemblers and that's
where the trouble is coming from).

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Home directory

[DePriest, Jason R.]

On 10/3/07, Gmane User  wrote:
> Dave Korn wrote:
> > On 02 October 2007 15:26, Gmain User wrote:
> >
> >> Brian Dessent  writes:
> >>> Gmane User wrote:
> >>>
>  it makes it hard to quickly scan for changes to "mv".  Many software
>  systems have cumulative release notes with each new release...would the
>  release notes can be findable in such a form online?
> >>> less /usr/share/doc/Cygwin/coreutils-*.README
> >> Thanks, Brian.  I was actually asking in the context of not updating cygwin
> >> right away.  Whether or not one could access up-to-date accumulation of
> >> release notes, possibly on the web.
> >
> >   Yes, absolutely.  See http://cygwin.com/ml/cygwin-announce/.
>
>
> I did indeed check that before posting to ask about where release notes can be
> found.  In fact, they can be found peicemeal at http://tinyurl.com/2dxno3, but
> it makes it hard to quickly scan for changes to "mv".  Many software systems
> have cumulative release notes with each new release...would the release notes
> can be findable in such a form online?  I am referring to an accumulation of
> release notes for coreutils, all rolled up in one notice.
>

A Google search with
site:cygwin.com inurl:/ml/cygwin-announce mv

turns up useful stuff, too

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

Re: screen reattach not working?

[Gary Johnson]

On 2007-10-04, Damjan Lango wrote:
> Hi!
> What is the current status of screen reattach?
> For me it does not work under the default cygwin bash shell, which
> uses cmd console afaik and it does not work under cygwin sshd. The
> only way it works is under cygwin rxvt. I would most like to use it
> under sshd.
> What's the magic to make it work? :)

I just tested my setup and it works fine.  I didn't set up anything 
specially as far as I know.

   +---+  ++   ++
   | Windows   |  | Solaris|   | Cygwin |
   | +---+ |  rlogin  | ++ |   | ++ |
   | |   | |   VPN| || |  ssh  | || |
   | | PuTTy |--|  ksh   |---|  bash  | |
   | |   | |  | | screen | |   | | screen | |
   | |   | |  | |  ksh   | |   | |  bash  | |
   | +---+ |  | ++ |   | ++ |
   |   |  ||   ||
   +---+  ++   ++

I can detach the screen session running under Cygwin, log out and 
back in, reconnect screen and the screen window looks the same as 
when I detached.

I would not expect screen to work from a console.  What kind of 
terminal are you using when you try to use it "under cygwin sshd"?

Regards,
Gary

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

Re: screen reattach not working?

[Gary Johnson]

On 2007-10-04, Gary Johnson wrote:
> On 2007-10-04, Damjan Lango wrote:
> > Hi!
> > What is the current status of screen reattach?
> > For me it does not work under the default cygwin bash shell, which
> > uses cmd console afaik and it does not work under cygwin sshd. The
> > only way it works is under cygwin rxvt. I would most like to use it
> > under sshd.
> > What's the magic to make it work? :)
> 
> I just tested my setup and it works fine.  I didn't set up anything 
> specially as far as I know.
[...]
> I would not expect screen to work from a console.  What kind of 
> terminal are you using when you try to use it "under cygwin sshd"?

I just tried another experiment.  From a default Cygwin bash shell 
running in a console, I ssh'd to another machine running Cygwin, ran 
screen there, detached, logged out, ssh'd back in, and reattached 
screen.  Again, it worked fine.  I was wrong about screen not 
working from a console.

Regards,
Gary

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

Re: Debugging with cygwin tools

[René Berber]

Alberto Luaces wrote:

> I am just starting to learn how to use the debugging tools available in
> Cygwin. To do so, I have a test program deliberately designed to crash:
[snip]
> I have compiled it with debugging information:
> 
> g++ -g -O0 -o core core.cpp
> 
> Then I try to run it with gdb:
> 
> gdb core.exe
> 
> (gdb) b main
> Breakpoint 1 at 0x401175: file core.cpp, line 4.
> (gdb) r
> Starting program: /home/Demostración/testsC++/core.exe
> Error: dll starting at 0x77d41000 not found.
--^
Isn't this clear?

[snip]
> How can I finally debug my program?

You probably have a problem with your PATH, take a look at it with `echo $PATH`,
it should include /usr/bin and /cygdrive/c/WINDOWS/system32 or similar if you
renamed the root, it should NOT have syntax errors... which is probably the
cause of your problem.
-- 
René Berber


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

RE: Debugging with cygwin tools

[Dave Korn]

On 04 October 2007 16:15, René Berber wrote:

> Alberto Luaces wrote:
> 
>> I am just starting to learn how to use the debugging tools available in
>> Cygwin. To do so, I have a test program deliberately designed to crash:
>> [snip] I have compiled it with debugging information:
>> 
>> g++ -g -O0 -o core core.cpp
>> 
>> Then I try to run it with gdb:
>> 
>> gdb core.exe
>> 
>> (gdb) b main
>> Breakpoint 1 at 0x401175: file core.cpp, line 4.
>> (gdb) r
>> Starting program: /home/Demostración/testsC++/core.exe
>> Error: dll starting at 0x77d41000 not found.
> --^
> Isn't this clear?
> 
> [snip]
>> How can I finally debug my program?
> 
> You probably have a problem with your PATH, take a look at it with `echo
> $PATH`, 

  Hey, I think you don't really mean to use backtick quotes there... :)

> it should include /usr/bin and /cygdrive/c/WINDOWS/system32 or
> similar if you renamed the root, it should NOT have syntax errors... which
> is probably the cause of your problem.

  Also, running "cygcheck core.exe" should show up any missing DLL straight
away.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Debugging with cygwin tools

[Alberto Luaces Fernández]

Dave Korn <[EMAIL PROTECTED]>:


On 04 October 2007 16:15, René Berber wrote:


Alberto Luaces wrote:


I am just starting to learn how to use the debugging tools available in
Cygwin. To do so, I have a test program deliberately designed to crash:
[snip] I have compiled it with debugging information:

g++ -g -O0 -o core core.cpp

Then I try to run it with gdb:

gdb core.exe

(gdb) b main
Breakpoint 1 at 0x401175: file core.cpp, line 4.
(gdb) r
Starting program: /home/Demostración/testsC++/core.exe
Error: dll starting at 0x77d41000 not found.

--^
Isn't this clear?

[snip]

How can I finally debug my program?


You probably have a problem with your PATH, take a look at it with `echo
$PATH`,


  Hey, I think you don't really mean to use backtick quotes there... :)


it should include /usr/bin and /cygdrive/c/WINDOWS/system32 or
similar if you renamed the root, it should NOT have syntax errors... which
is probably the cause of your problem.


  Also, running "cygcheck core.exe" should show up any missing DLL straight
away.


Dave, René,

thanks for the tips, I will check the PATH and look for missing DLLs  
then, although my program is nothing more than a main function  
dereferencing a null pointer, so it should not have any special  
dependencies.


The missing DLL message was a bit misleading because gdb crashes after  
printing it, so I thought it was an error message from gdb.exe and not  
from my program.


Maybe the non 7-bit ASCII character found on my user name  
(Demostración) is causing some issues with PATH, could I try to rename  
my home directory directly or would I need to change something more?


At least I have now several things to try...

Alberto




Correo enviado usando el servicio de Webmail de la UDC.



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

Re: Debugging with cygwin tools

[René Berber]

Alberto Luaces Fernández wrote:

[snip]
> thanks for the tips, I will check the PATH and look for missing DLLs
> then, although my program is nothing more than a main function
> dereferencing a null pointer, so it should not have any special
> dependencies.

It doesn't.

> The missing DLL message was a bit misleading because gdb crashes after
> printing it, so I thought it was an error message from gdb.exe and not
> from my program.

You are probably right, gdb has a lot of dependencies:

gdb.exe -> /usr/bin/gdb.exe
cygwin1.dll -> /usr/bin/cygwin1.dll
cygiconv-2.dll  -> /usr/bin/cygiconv-2.dll
cygintl-3.dll   -> /usr/bin/cygintl-3.dll
cygncurses-8.dll-> /usr/bin/cygncurses-8.dll
comdlg32.dll-> /c/WINDOWS/system32/comdlg32.dll
gdi32.dll   -> /c/WINDOWS/system32/gdi32.dll
kernel32.dll-> /c/WINDOWS/system32/kernel32.dll
shell32.dll -> /c/WINDOWS/system32/shell32.dll
user32.dll  -> /c/WINDOWS/system32/user32.dll
tcl84.dll   -> /usr/bin/tcl84.dll
tk84.dll-> /usr/bin/tk84.dll
comctl32.dll-> /c/WINDOWS/system32/comctl32.dll
imm32.dll   -> /c/WINDOWS/system32/imm32.dll
advapi32.dll-> /c/WINDOWS/system32/advapi32.dll
ntdll.dll   -> /c/WINDOWS/system32/ntdll.dll
msvcrt.dll  -> /c/WINDOWS/system32/msvcrt.dll
rpcrt4.dll  -> /c/WINDOWS/system32/rpcrt4.dll
shlwapi.dll -> /c/WINDOWS/system32/shlwapi.dll

But it was running until you used "r", so it would be interesting to know what
was the dll loaded at the address given by the error.  Your program only uses
cygwin1.dll and Windows' dlls.

> Maybe the non 7-bit ASCII character found on my user name (Demostración)
> is causing some issues with PATH, could I try to rename my home
> directory directly or would I need to change something more?

Don't change anything, gdb debugs your program fine no mater if the directory
you are in has an accent or not (or spaces):

$ gdb core.exe
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) list
1   #include 
2
3   int main()
4   {
5   int *p=0;
6
7   *p=9;
8
9   return 0;
10  }
(gdb) b main
Breakpoint 1 at 0x401175: file core.cc, line 4.
(gdb) r
Starting program: /c/Documents and Settings/René/core.exe
Loaded symbols for /c/WINDOWS/system32/ntdll.dll
Loaded symbols for /c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /c/WINDOWS/system32/advapi32.dll
Loaded symbols for /c/WINDOWS/system32/rpcrt4.dll

Breakpoint 1, main () at core.cc:4
4   {
(gdb) info files
Symbols from "/c/Documents and Settings/René/core.exe".
Win32 child process:
Using the running image of child thread 3492.0x868.
While running this, GDB does not access memory from...
Local exec file:
`/c/Documents and Settings/René/core.exe', file type pei-i386.
Entry point: 0x401000
0x00401000 - 0x00441288 is .text
0x00442000 - 0x00442160 is .data
0x00443000 - 0x00445664 is .rdata
0x00446000 - 0x0044ab60 is .bss
0x0044b000 - 0x0044b6cc is .idata
0x7c901000 - 0x7c97b6fe is .text in /c/WINDOWS/system32/ntdll.dll
0x7c97c000 - 0x7c97f200 is .data in /c/WINDOWS/system32/ntdll.dll
0x7c981000 - 0x7c9ace78 is .rsrc in /c/WINDOWS/system32/ntdll.dll
0x7c9ad000 - 0x7c9afe88 is .reloc in /c/WINDOWS/system32/ntdll.dll
0x7c801000 - 0x7c883111 is .text in /c/WINDOWS/system32/kernel32.dll
0x7c884000 - 0x7c886400 is .data in /c/WINDOWS/system32/kernel32.dll
0x7c889000 - 0x7c88 is .rsrc in /c/WINDOWS/system32/kernel32.dll
0x7c8ef000 - 0x7c8f4bec is .reloc in /c/WINDOWS/system32/kernel32.dll
0x61001000 - 0x610fcaf4 is .text in /usr/bin/cygwin1.dll
0x610fd000 - 0x610ff710 is .autoload_text in /usr/bin/cygwin1.dll
0x6110 - 0x6110af70 is .data in /usr/bin/cygwin1.dll
0x6110b000 - 0x6113e520 is .rdata in /usr/bin/cygwin1.dll
0x6113f000 - 0x611483d0 is .bss in /usr/bin/cygwin1.dll
0x61149000 - 0x61150c9b is .edata in /usr/bin/cygwin1.dll
0x61151000 - 0x61151448 is .rsrc in /usr/bin/cygwin1.dll
0x61152000 - 0x6116210c is .reloc in /usr/bin/cygwin1.dll
---Type  to continue, or q  to quit---
0x61163000 - 0x61163104 is .cygwin_dll_common in /usr/bin/cygwin1.dll
0x61165000 - 0x6117 is .idata in /usr/bin/cygwin1.dll
0x6117 - 0x6120 is .cygheap in /usr/bin/cygwin1.dll
0x77dd1000 - 0x77e452d9 is .text in /c/WINDOWS/system32/advapi32.dll
0x77e46000 - 0x77e48c00 is .data in /c/WINDOWS/system32/advapi32.dll
0x77e4b000 -

Re: screen reattach not working?

[Damjan Lango]

I tried sshing in over putty and also from a linux gnome-term on a
different machine.
Btw, I'm using Vista, is this a problem perhaps?
Also the user I'm ssh-ing into does not have administrator privleges,
might try changing that. I tried to do a cat
/tmp/uscreens/S-name/socket-name and it says permission denied
CYGWIN is set to ntsec tty
/etc/passwd is created using mkpasswd -l
and ssh confugred using ssh-host-config -y or what was that command again
what else could be interesting?
I think that screen does bad at error reporting either it doesn't say
anything or it blurps some strange messages like, "you die in a
dungeon" or something.
btw, after checking processes with ps I can see that screen and bash
are running, i just can't attach to that screen session.

On 2007-10-04, Gary Johnson wrote:
> On 2007-10-04, Gary Johnson wrote:
> > On 2007-10-04, Damjan Lango wrote:
> > > Hi!
> > > What is the current status of screen reattach?
> > > For me it does not work under the default cygwin bash shell, which
> > > uses cmd console afaik and it does not work under cygwin sshd. The
> > > only way it works is under cygwin rxvt. I would most like to use it
> > > under sshd.
> > > What's the magic to make it work? :)
> >
> > I just tested my setup and it works fine.  I didn't set up anything
> > specially as far as I know.
> [...]
> > I would not expect screen to work from a console.  What kind of
> > terminal are you using when you try to use it "under cygwin sshd"?
>
> I just tried another experiment.  From a default Cygwin bash shell
> running in a console, I ssh'd to another machine running Cygwin, ran
> screen there, detached, logged out, ssh'd back in, and reattached
> screen.  Again, it worked fine.  I was wrong about screen not
> working from a console.
>
> Regards,
> Gary
>

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

RE: Problems compiling grep and friends

[Siegfried Heintze]

Siegfried wrote:
OK, I tried that. See below for the results. Looks like we have the same
problem.
Thanks,
Siegfried

Brian wrote:
So as a
workaround, try "make install DESTDIR=/" which would result in
"///foo/bar" which is the POSIX-sanctioned way of dealing with
filesystems that reserve // for network paths.  Or, you could actually
use DESTDIR in the way it's designed (which is probably why this was
never noticed when e.g. creating the grep packages.)

Also, knock this off:

> cd c:/cygwin/usr/src/grep-2.5.1a-4/

cd /usr/src/grep-2.5.1a-4/
make install DESTDIR=/
Making install in intl
make[1]: Entering directory `/usr/src/grep-2.5.1a-4/intl'
if test "grep" = "gettext" \
   && test '' = 'intl-compat.o'; then \
  /bin/sh `case "./mkinstalldirs" in /*) echo "./mkinstalldirs" ;;
*) echo ".././mkinstalldirs" ;; esac` //usr/local/lib //usr/local/include; \
  /usr/bin/install -c -m 644 libintl.h
//usr/local/include/libintl.h; \
  @LIBTOOL@ --mode=install \
/usr/bin/install -c -m 644 libintl.a //usr/local/lib/libintl.a;
\
else \
  : ; \
fi
if test 'no' = yes; then \
  test no != no || /bin/sh `case "./mkinstalldirs" in /*) echo
"./mkinstalldirs" ;; *) echo ".././mkinstalldirs" ;; esac` //usr/local/lib;
\
  temp=//usr/local/lib/t-charset.alias; \
  dest=//usr/local/lib/charset.alias; \
  if test -f //usr/local/lib/charset.alias; then \
orig=//usr/local/lib/charset.alias; \
sed -f ref-add.sed $orig > $temp; \
/usr/bin/install -c -m 644 $temp $dest; \
rm -f $temp; \
  else \
if test no = no; then \
  orig=charset.alias; \
  sed -f ref-add.sed $orig > $temp; \
  /usr/bin/install -c -m 644 $temp $dest; \
  rm -f $temp; \
fi; \
  fi; \
  /bin/sh `case "./mkinstalldirs" in /*) echo "./mkinstalldirs" ;;
*) echo ".././mkinstalldirs" ;; esac` //usr/local/share/locale; \
  test -f //usr/local/share/locale/locale.alias \
&& orig=//usr/local/share/locale/locale.alias \
|| orig=./locale.alias; \
  temp=//usr/local/share/locale/t-locale.alias; \
  dest=//usr/local/share/locale/locale.alias; \
  sed -f ref-add.sed $orig > $temp; \
  /usr/bin/install -c -m 644 $temp $dest; \
  rm -f $temp; \
else \
  : ; \
fi
if test "grep" = "gettext"; then \
  /bin/sh `case "./mkinstalldirs" in /*) echo "./mkinstalldirs" ;;
*) echo ".././mkinstalldirs" ;; esac` //usr/local/share/gettext/intl; \
  /usr/bin/install -c -m 644 VERSION
//usr/local/share/gettext/intl/VERSION; \
  /usr/bin/install -c -m 644 ChangeLog.inst
//usr/local/share/gettext/intl/ChangeLog; \
  dists="COPYING.LIB-2.0 COPYING.LIB-2.1 Makefile.in config.charset
locale.alias ref-add.sin ref-del.sin gmo.h gettextP.h hash-string.h
plural-exp.h eval-plural.h os2compat.h libgnuintl.h loadinfo.h bindtextdom.c
dcgettext.c dgettext.c gettext.c finddomain.c loadmsgcat.c localealias.c
textdomain.c l10nflist.c explodename.c dcigettext.c dcngettext.c dngettext.c
ngettext.c plural.y plural-exp.c localcharset.c localename.c osdep.c
os2compat.c intl-compat.c"; \
  for file in $dists; do \
/usr/bin/install -c -m 644 ./$file \
//usr/local/share/gettext/intl/$file; \
  done; \
  chmod a+x //usr/local/share/gettext/intl/config.charset; \
  dists="plural.c"; \
  for file in $dists; do \
if test -f $file; then dir=.; else dir=.; fi; \
/usr/bin/install -c -m 644 $dir/$file \
//usr/local/share/gettext/intl/$file; \
  done; \
  dists="xopen-msg.sed linux-msg.sed po2tbl.sed.in cat-compat.c
COPYING.LIB-2 gettext.h libgettext.h plural-eval.c"; \
  for file in $dists; do \
rm -f //usr/local/share/gettext/intl/$file; \
  done; \
else \
  : ; \
fi
make[1]: Leaving directory `/usr/src/grep-2.5.1a-4/intl'
Making install in po
make[1]: Entering directory `/usr/src/grep-2.5.1a-4/po'
if test -r ".././mkinstalldirs"; then \
  .././mkinstalldirs ///usr/local/share; \
else \
  /bin/sh ../mkinstalldirs ///usr/local/share; \
fi
mkdir //usr
mkdir: cannot create directory `//usr': No such host or network path
mkdir //usr/local
mkdir: cannot create directory `//usr/local': No such host or network path
mkdir //usr/local/share
mkdir: cannot create directory `//usr/local/share': No such host or network
path
make[1]: *** [install-data-yes] Error 1
make[1]: Leaving directory `/usr/src/grep-2.5.1a-4/po'
make: *** [install-recursive] Error 1

Compilation exited abnormally with code 2 at Thu Oct  4 15:11:53


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Document

Re: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes

[Elliott Hughes]

On Wed, September 19, 2007 02:09, Corinna Vinschen wrote:
> On Sep 18 11:54, Elliott Hughes wrote:
>
>> http://software.jessies.org/terminator/ uses Cygwin to provide
>> Windows support, and it's been most useful. i just thought i'd
>> mention a couple of things that caused crashes in cygwin1.dll 1.5.24-2
>> where that might not have been Cygwin's intent (in both cases the
>> application's skating on thin ice anyway).
>>
>> first, if i do a zero-byte write(2) to a pty, i get a crash. POSIX says
>> the behavior in that situation is undefined. i haven't tested with a
>> regular file (where POSIX explicitly says that "write() will return 0
>> and have no other results").
>>
>> second, if i try to set the window size on fd -1, i get a crash:
>>
>> int fd = -1; struct winsize size; // set size.ws_col, size.ws_row,
>> size.ws_xpixel, and size.ws_ypixel... if (ioctl(fd, TIOCSWINSZ, &size) <
>> 0) {
>>
>>
>> my interpretation of POSIX is that i should get return value -1 and
>> errno set to EBADF in that case. i haven't tested with other invalid
>> file descriptors or other requests.
>>
>> i haven't tested earlier versions of cygwin1.dll.
>>
>> strangely, a quick look at the Cygwin source suggests that these cases
>> should be taken care of. "ioctl.cc"'s ioctl starts with a cygheap_fdget,
>> and check_iovec would appear to take care of the 0- byte write case for
>> write(2).
>
> I've investigated both problems using small testcases and GDB and I
> can't reproduce your observations.  In both cases Cygwin works fine,
> returning 0 from write(2) when writing 0 bytes to anything (including
> ptys), or, returning -1 from ioctl(2) when trying to set the window size
> on an invalid fd.
>
> These spurious crashes might hint to a problem in the application
> itself.  For instance, they could be the result of a stack corruption at
> some earlier point in the code.  Note that just because Cygwin crashes
> but, say, Linux doesn't, that doesn't mean the application is right and
> Cygwin is wrong.  The outcome of the application problem just shows
> different results on different systems.
>
> If, after investigation, you still think there's a Cygwin problem, we
> would need some tiny testcase in plain C, which allows to reproduce the
> problem with as little code as possible.

(sorry it took so long to get back to you, especially after you went to
such trouble, but i haven't had access to a Windows machine for a couple
of weeks.)

okay, i've tried to reproduce the two problems described above, and it
turns out that the problem was me assuming too much from a JVM stack trace
like this:

Stack: [0x1cb0,0x1cd0),  sp=0x1ccfc330,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
C  [cygwin1.dll+0xb48b6]
C  [cygwin1.dll+0x92d88]
C  [cygwin1.dll+0xb5657]
C  [cygwin1.dll+0x92d88]
C  [pty.dll+0x8e27]
C  [pty.dll+0x425f]
C  [pty.dll+0x2140]
j 
terminator.terminal.PtyProcess.sendResizeNotification(Ljava/awt/Dimension;Ljava/awt/Dimension;)V+0

we were/are indeed getting reasonable errors back from Cygwin; the problem
is that we're trying to throw a (C++) exception, and that's causing a
crash.

it looks easily repeatable:

$ cat ex.cpp
#include 
int main() {
 try {
  throw new std::exception();
 } catch (const std::exception& ex) {
  return 1;
 }
 return 0;
}

$ g++ -Wno-long-long -fno-omit-frame-pointer -fno-strict-aliasing 
-gdwarf-2 -W -Wall -Wshadow -Werror  -pedantic ex.cpp -o ex

$ ./ex.exe
Hangup

$ cat ex.exe.stackdump
Stack trace:
Frame Function  Args
0022C8A8  7C802532  (0F50, EA60, 00A4, 0022C8F0)
0022C9C8  6109773C  (, 7C8025F0, 7C802532, 00A4)
0022CAB8  610952BB  (, 003B0023, 0023, )
0022CB18  6109579B  (0022CB30, , 0094, 610A0EAA)
0022CBD8  61095952  (0EEC, 0006, 0022CC08, 61095B52)
0022CBE8  6109597C  (0006, 600301DC, 0022CC58, 00403D73)
0022CC08  61095B52  (0022CC38, 004052F0, 0022CCA4, 0001)
0022CC58  00403D87  (0022CAE0, , 0022CCE8, 004010FB)
0022CC68  004038C6  (00670250, 004072F8, , 00401078)
0022CCE8  004010FB  (0001, 61169200, 00670090, 0022CC70)
0022CD98  61006198  (, 0022CDD0, 61005510, 0022CDD0)
61005510  61004416  (009C, A02404C7, E8611001, FF48)
 17 [sig] ex 3820 c:\src\software.jessies.org\terminator\ex.exe: ***
fatal error - called with threadlist_ix -1

$

strangely, i can't find any mention of this on the web, or in the Cygwin
user guide/FAQ. are C++ exceptions unsupported, or do i need some extra
flags? (removing the flags shown above doesn't seem to make a difference.)
i'll happily RTFM, if someone could point me at the right M...

(apologies again for the earlier wild goose chase.)

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

-- 
Elliott Hughes, http://www.jessies.org/~enh/


cygcheck.out
Description: Bin

Re: interactive process is started on another user's 'desktop'

[J]

No one responded to my message, below (on 10/1/2007).  I've got a 
production system not doing what it is supposed to do until I get this 
worked out... and I don't have a clue where to start looking.  Did I 
provide enough information?  Anyone have any ideas how I can get cron to 
spawn the interactive application on the current desktop (rather than 
one that is not currently being used?)


Thanks =)




[EMAIL PROTECTED] wrote:

I installed cygserver and cron with their included *-config commands.  (
Originally as the user WinAdmin. )  I'm running a call processing
application on user "Call Processing".  I created a cron entry with
crontab -e, from the cygwin prompt as the user "TC".  (logged into Windows
as "TC")  The cron entry fires an application meant to interact with
"TC"'s desktop.  ( I did cygrunsrv -E cron; added the tick to interact
with the desktop under the cron service's properties; applied changes; and
then cygrunsrv -S cron ) ... the cron entry creates a text file every time
it fires.

So... when the text file is created, the application does not appear to
run.  However, when switching users, I find it interacting with "Call
Processing"'s desktop.  This is consistent.  Three users logged in, "TC's"
cron event fires (creating the text file under TC's path), and the
application is running on "Call Processing"'s desktop.

/var/log/cron.log offers no clues.  /usr/bin/cronevents.exe doesn't either.
/var/log/cygserver.log is empty.

Please help.  :)


cygcheck:

Cygwin Configuration Diagnostics
Current System Time: Mon Oct 01 13:41:22 2007

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Python22
c:\Program Files\ATI Technologies\ATI Control Panel

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1009(Triton Connect) GID: 513(None)
0(root)   513(None) 544(Administrators)
545(Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1009(Triton Connect) GID: 513(None)
0(root)   513(None) 544(Administrators)
545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'Triton Connect'
PWD = '/home/Triton Connect'
HOME = '/home/Triton Connect'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\Triton Connect'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\Triton Connect\Application Data'
HOSTNAME = 'Stat'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 9, GenuineIntel'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/usr/bin'
USERDOMAIN = 'STAT'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/TRITON~1/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
USERNAME = 'Triton Connect'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
EDITOR = 'nano'
USERPROFILE = 'C:\Documents and Settings\Triton Connect'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\STAT'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/TRITON~1/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'Auto Samsung ML-1710 Series on ECHO'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0409'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
COMPUTERNAME = 'STAT'
SONICCENTRAL = 'c:\Program Files\Common Files\Sonic Shared\Sonic Central\'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS 28929Mb  37% CP CS UN PA FC HP_PAVILION
d:  hd  FAT32 9215Mb  57% CPUN   HP_RECOVERY
e:  cd N/AN/A

C:\cygwin  /  system  binmode
C:\cygwin/bin  /usr/bin   system  binmode
C:\cygwin/lib  /usr/lib   system  binmode
.  

Re: interactive process is started on another user's 'desktop'

[Larry Hall (Cygwin)]

J wrote:
No one responded to my message, below (on 10/1/2007).  I've got a 
production system not doing what it is supposed to do until I get this 
worked out... and I don't have a clue where to start looking.  Did I 
provide enough information?  Anyone have any ideas how I can get cron to 
spawn the interactive application on the current desktop (rather than 
one that is not currently being used?)


Does changing the order that the users logged in make a difference?

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes

[Lewis Hyatt]

$ cat ex.cpp
#include 
int main() {
 try {
  throw new std::exception();
 } catch (const std::exception& ex) {
  return 1;
 }
 return 0;
}


You are throwing a pointer and trying to catch a reference, so the 
exception never gets caught at all, which causes the program to abort. 
You should should do


throw std::exception();

instead.

-Lewis


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

"Unknown" user after logging into sshd under Vista

[Daniel Noll]

Hi all.

The archives do have a number of Vista-related SSH problems which have solved 
the issue of getting it installed, but I haven't been able to solve the issue 
I found next.

Here's the options I used to configure the service...

> [508] [EMAIL PROTECTED]:~> ssh-host-config
> Overwrite existing /etc/ssh_config file? (yes/no) yes
> Generating /etc/ssh_config file
> Overwrite existing /etc/sshd_config file? (yes/no) yes

> Should privilege separation be used? (yes/no) yes
> Generating /etc/sshd_config file

> Do you want to install sshd as service?
> (Say "no" if it's already installed as service) (yes/no) yes

> Should this script create a new local account 'sshd_server' which has
> the required privileges? (yes/no) yes

> Which value should the environment variable CYGWIN have when
> sshd starts? It's recommended to set at least "ntsec" to be
> able to change user context without password.
> Default is "ntsec".  CYGWIN=


However on logging in...
> [503] [EMAIL PROTECTED]:~> ssh localhost
> Last login: Fri Oct  5 09:20:07 2007 from 127.0.0.1
> Fanfare!!!
> You are successfully logged in to this server!!!
> Could not chdir to home directory /home/daniel: Permission denied
> -bash: cd: /home/daniel: Permission denied

Permissions on my home directory are correct as I can get into it via 
Explorer.  The problem is elsewhere -- if I look in the process list, the 
bash.exe process is running as user "(unknown)", not as my user account.

I'm not sure what to do from here.  What part of Cygwin is responsible for 
changing the user ID when a user logs in via SSH, and what is usually 
responsible for it misbehaving?

Daniel

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

Re: inetutils RSH install

[Alexfed]

Unfortunately outside of running iu-config it has no info on how to create
and run the service.


René Berber-2 wrote:
> 
> Alexfed wrote:
> 
>> How do I install the inetutils RSH and start the service?
> 
> Edit /etc/inetd.conf; I'm assuming you already read
> /usr/share/doc/Cygwin/inetutils-1.3.2.README and installed inetd as a
> service..
> -- 
> René Berber
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/inetutils-RSH-install-tf4564825.html#a13051285
Sent from the Cygwin Users mailing list archive at Nabble.com.


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

RE: Problems compiling grep and friends

[Dave Korn]

On 04 October 2007 22:13, Siegfried Heintze wrote:

> Siegfried wrote:
> OK, I tried that. See below for the results. Looks like we have the same
> problem.


> mkdir //usr
> mkdir: cannot create directory `//usr': No such host or network path
> mkdir //usr/local
> mkdir: cannot create directory `//usr/local': No such host or network path
> mkdir //usr/local/share
> mkdir: cannot create directory `//usr/local/share': No such host or network
> path
> make[1]: *** [install-data-yes] Error 1
> make[1]: Leaving directory `/usr/src/grep-2.5.1a-4/po'
> make: *** [install-recursive] Error 1


  I whipped this up against grep-2.5.1a-3.  It might just apply cleanly to the
version you're working with; make sure it gets all the "$(DESTDIR)/" instances
and changes them to "$DDSLASH".  It WFM:

 '"  '"'---'
/usr/src/grep-2.5.1a-3 $ cd po
@___. .
(   /"\
 ||--||(___)
 '"  '"'---'
/usr/src/grep-2.5.1a-3/po $ make install 2>&1 | tee inst.log
if test -n "" ; then \
  DDSLASH="/" ; \
else \
  DDSLASH="" ; \
fi
if test -r ".././mkinstalldirs"; then \
  .././mkinstalldirs $DDSLASH/usr/local/share; \
else \
  /bin/sh ../mkinstalldirs $DDSLASH/usr/local/share; \
fi
mkdir /usr/local/share/locale/cs
mkdir /usr/local/share/locale/cs/LC_MESSAGES
installing cs.gmo as /usr/local/share/locale/cs/LC_MESSAGES/grep.mo
installing de.gmo as /usr/local/share/locale/de/LC_MESSAGES/grep.mo
installing el.gmo as /usr/local/share/locale/el/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/eo
mkdir /usr/local/share/locale/eo/LC_MESSAGES
installing eo.gmo as /usr/local/share/locale/eo/LC_MESSAGES/grep.mo
installing es.gmo as /usr/local/share/locale/es/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/et
mkdir /usr/local/share/locale/et/LC_MESSAGES
installing et.gmo as /usr/local/share/locale/et/LC_MESSAGES/grep.mo
installing fr.gmo as /usr/local/share/locale/fr/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/gl
mkdir /usr/local/share/locale/gl/LC_MESSAGES
installing gl.gmo as /usr/local/share/locale/gl/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/hr
mkdir /usr/local/share/locale/hr/LC_MESSAGES
installing hr.gmo as /usr/local/share/locale/hr/LC_MESSAGES/grep.mo
installing id.gmo as /usr/local/share/locale/id/LC_MESSAGES/grep.mo
installing it.gmo as /usr/local/share/locale/it/LC_MESSAGES/grep.mo
installing ja.gmo as /usr/local/share/locale/ja/LC_MESSAGES/grep.mo
installing ko.gmo as /usr/local/share/locale/ko/LC_MESSAGES/grep.mo
installing nl.gmo as /usr/local/share/locale/nl/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/no
mkdir /usr/local/share/locale/no/LC_MESSAGES
installing no.gmo as /usr/local/share/locale/no/LC_MESSAGES/grep.mo
installing pl.gmo as /usr/local/share/locale/pl/LC_MESSAGES/grep.mo
installing pt_BR.gmo as /usr/local/share/locale/pt_BR/LC_MESSAGES/grep.mo
installing ru.gmo as /usr/local/share/locale/ru/LC_MESSAGES/grep.mo
mkdir /usr/local/share/locale/sl
mkdir /usr/local/share/locale/sl/LC_MESSAGES
installing sl.gmo as /usr/local/share/locale/sl/LC_MESSAGES/grep.mo
installing sv.gmo as /usr/local/share/locale/sv/LC_MESSAGES/grep.mo
if test "grep" = "gettext"; then \
  if test -r ".././mkinstalldirs"; then \
.././mkinstalldirs $DDSLASH/usr/local/share/gettext/po; \
  else \
/bin/sh ../mkinstalldirs $DDSLASH/usr/local/share/gettext/po; \
  fi; \
  /usr/bin/install -c -m 644 ./Makefile.in.in \
  $DDSLASH/usr/local/share/gettext/po/Makefile.in.in; \
else \
  : ; \
fi


cheers,
  DaveK
-- 
Can't think of a witty .sigline today
diff -pu po.orig/Makefile.in.in po/Makefile.in.in
--- po.orig/Makefile.in.in  2002-03-26 14:38:46.00100 +
+++ po/Makefile.in.in   2007-10-04 22:31:11.260792100 +0100
@@ -110,10 +110,15 @@ install-exec:
 install-data: [EMAIL PROTECTED]@
 install-data-no: all
 install-data-yes: all
+   if test -n "$(DESTDIR)" ; then \
+ DDSLASH="$(DESTDIR)/" ; \
+   else \
+ DDSLASH="" ; \
+   fi
if test -r "$(MKINSTALLDIRS)"; then \
- $(MKINSTALLDIRS) $(DESTDIR)/$(datadir); \
+ $(MKINSTALLDIRS) $$DDSLASH$(datadir); \
else \
- $(SHELL) $(top_srcdir)/mkinstalldirs $(DESTDIR)/$(datadir); \
+ $(SHELL) $(top_srcdir)/mkinstalldirs $$DDSLASH$(datadir); \
fi
@catalogs='$(CATALOGS)'; \
for cat in $$catalogs; do \
@@ -125,27 +130,27 @@ install-data-yes: all
  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
  dir=$$destdir/$$lang/LC_MESSAGES; \
  if test -r "$(MKINSTALLDIRS)"; then \
-   $(MKINSTALLDIRS) $(DESTDIR)/$$dir; \
+   $(MKINSTALLDIRS) $$DDSLASH$$dir; \
  else \
-   $(SHELL) $(top_srcdir)/mkinstalldirs $(DESTDIR)/$$dir; \
+   $(SHELL) $(top_srcdir)/mkinstalldirs $$DDSLASH$$dir; \
  fi; \
  if test -r $$cat; then \
-   $(INSTALL_DATA) $$cat $(DESTDIR)/$$dir/$(PACKAGE)$(INSTOBJEXT); \
-   echo "installing $$cat as 
$(DESTDIR)/$$dir/$(PACKAGE)$(INSTOBJEXT)"; \
+   $(IN

Re: screen reattach not working?

[Andrew Schulman]

> Hi!
> What is the current status of screen reattach?
> For me it does not work under the default cygwin bash shell, which
> uses cmd console afaik and it does not work under cygwin sshd. The
> only way it works is under cygwin rxvt. I would most like to use it
> under sshd.
> What's the magic to make it work? :)

Hi Damjan.  There's information about this in
/usr/share/doc/screen/README.Cygwin.  Read that, but the short version is that
all features of screen are supposed to work correctly in a DOS console with
CYGWIN=tty (set before you open the console), and in rxvt, PuTTYcyg, and
xterm.  I'm not sure about an ssh session.

In fact though, I've had some trouble reattaching to old sessions (I use
PuTTYcyg), but it's nothing I've ever been able to pin down.  The older the
sessions get, the more likely they are to be bad and then I have to -wipe
them, and manually kill any of their child processes.

Please keep posting test reports about screen so I can try to figure out
what's going on.

Thanks,
Andrew.


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

Re: inetutils RSH install

[René Berber]

Alexfed wrote:

> Unfortunately outside of running iu-config it has no info on how to create
> and run the service.

Inetd?  Once installed it starts after every reboot or when you do a "net start
inetd" or ...

If you meant rshd, if configured right on /etc/inet.conf, it starts whenever a
client tries to connect.

> René Berber-2 wrote:
>> Alexfed wrote:
>>
>>> How do I install the inetutils RSH and start the service?
>> Edit /etc/inetd.conf; I'm assuming you already read
>> /usr/share/doc/Cygwin/inetutils-1.3.2.README and installed inetd as a
>> service..
-- 
René Berber


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

Re: inetutils RSH install

[Andrew DeFaria]

René Berber wrote:


Alexfed wrote:
Unfortunately outside of running iu-config it has no info on how to 
create

and run the service.


Inetd? Once installed it starts after every reboot or when you do a 
"net start

inetd" or ...

If you meant rshd, if configured right on /etc/inet.conf, it starts 
whenever a

client tries to connect.


René Berber-2 wrote:

Alexfed wrote:


How do I install the inetutils RSH and start the service?

Edit /etc/inetd.conf; I'm assuming you already read
/usr/share/doc/Cygwin/inetutils-1.3.2.README and installed inetd as a
service..
He obviously did not read /usr/share/doc/Cygwin/inetutils-1.3.2.README 
or at least he did not bother to read down far enough where it says how 
to install it as a service. From what I can see that comes in at ~ line 
314 or 437 lines or 71% in. Essentially you need to do


$ /usr/sbin/inetd --install-as-service

Additionally you need to (IIRC) add C:\Cygwin\bin to your SYSTEM 
environment variable otherwise start up of inetd will fail. Oh and you 
need to reboot too.


Of course you could instead use cygrunsrv to add the service which, I 
believe, does a better job and handles the need to add C:\Cygwin\bin to 
your SYSTEM environment. In fact I believe that this 
--install-as-service option should be removed from inetd and iu-config 
should be enhanced to add the service via cygrunsrv.


Either way a "net start/stop inetd" will start/stop the service and it 
should be set to start automatically at boot up time.

--
Andrew DeFaria 
Everyone hates me because I'm paranoid.


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

Re: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes

[Elliott Hughes]

On Thu, October 4, 2007 16:33, Lewis Hyatt wrote:
>> $ cat ex.cpp
>> #include 
>> int main() { try { throw new std::exception(); } catch (const
>> std::exception& ex) {
>> return 1; }
>> return 0; }
>>
>
> You are throwing a pointer and trying to catch a reference, so the
> exception never gets caught at all, which causes the program to abort. You
> should should do
>
> throw std::exception();
>
> instead.
>
> -Lewis

sorry, that was a Javaism that slipped into my test case. the real code
does throw by value and catch by const reference. as you say, though, if i
change the test case, it doesn't crash.

here are the relevant snippets:

extern "C" JNIEXPORT void JNICALL
Java_terminator_terminal_PtyProcess_sendResizeNotification(JNIEnv* env,
jobject instance, jobject a0, jobject a1) {
try {
terminator_terminal_PtyProcess proxy(env, instance);
proxy.sendResizeNotification(a0, a1);
} catch (const std::exception& ex) {
translateToJavaException(env, "java/io/IOException", ex);
}
}

void terminator_terminal_PtyProcess::sendResizeNotification(jobject
sizeInChars, jobject sizeInPixels) {
throw std::exception();
}

i'm not throwing across shared library boundaries, but i am throwing
within shared library code. (obviously sendResizeNotification usually has
more content, but i've pulled the real content out to try to move closer
to a useful test case.)

i can remove the method call, too. this also crashes:

extern "C" JNIEXPORT void JNICALL
Java_terminator_terminal_PtyProcess_sendResizeNotification(JNIEnv* env,
jobject instance, jobject a0, jobject a1) {
try {
throw std::exception();
} catch (const std::exception& ex) {
}
}

taking the pc from the JVM crash log:

#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x610b48b6, pid=3112,
tid=1244

and the output of "nm cygwin1.dll | sort" suggests we're in
pthread_key_create:

610b47a0 T _pthread_key_create
610b4980 T __ZN11pthread_keyC2EPFvPvE

but i don't know that isn't just an implementation detail. (certainly i
get a lot of seemingly irrelevant matches if i search the web.)

-- 
Elliott Hughes, http://www.jessies.org/~enh/



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

runnable cygwin on a platter (CD)

[Paul McFerrin]

  SURVEY REQUEST ONLY   *
  Replies to only:   [EMAIL PROTECTED] if interested

Hello:

This notice to see how many persons *might* be interested in a "running" 
copy of cygwin on a CD.  The download size would be around 106 MB.  I'm 
trying to address the usefulness of the product and a place to host this 
product.  If you have an interest, please do NOT clutter-up this mailing 
list but EMAIL DIRECTLY TO: [EMAIL PROTECTED] INSTEAD.  Here are 
the product features:


   1- An auto-run version of cygwin 1.5.24, just insert CD
   2- Requires NO installation of cygwin
   3- Minimal set of packages which includes (but not limited)
Cygwin Package Information
Package  Version
ash  20040127-3
base-files   3.7-1
base-passwd  2.2-1
bash 3.2.25-16
binutils 20060817-1
brltty   3.8-3
bzip21.0.3-2
clear1.0-2
coreutils6.9-4
fileutils4.1-3
findutils4.3.8-1
gcc  3.4.4-3
gdb  20060706-2
grep 2.5.1a-4
groff1.18.1-2
gzip 1.3.12-2
man  1.6e-1
mutt 1.4.2.2-2
perl 5.8.8-4
perl_manpages5.8.7-5
tar  1.18-2
termcap  20050421-1
terminfo 5.5_20061104-1
texinfo  4.8a-1
textutils2.0.21-2
unzip5.52-2
vim  7.1-1
zip  2.32-2

The full installation was severely "stripped" of many products.  E.g. no 
X11 stuff.  This was necessary to get a reasonable download size.  I'm 
still working on this stripping process to get it smaller.


After inserting the CD, it will come up with a DOS and "rxvt" windows, 
each with a copy of "ksh" running.  If you want a different shell, 
you're on your own to modify it.


How many times have you been called to someone else's PC only to be 
faced with only MS GUI or DOS shell available?  With CygwinOnAPlatter 
you can have nearly a complete copy of Cygwin running on another PC 
without installing anything!


Cygwin has limited testing on WinXP-sp2 systems.  I have NO other OS's 
to test on.


If you already have a copy of Cygwin installed when you insert the CD; 
the present mounts will be saved before remounting everything for the 
CD.  Upon exit of the DOS window, the original mounts will be restored.


Again, this is only a survey.  The outcome will determine if it will be 
made available, on which server, and what time frame.


I created a B20 version of this CD many years ago.  I found it immensely 
useful over the years.  I was thinking that B20 is quite old.  Are there 
any adequate web space available to host a project of this size?  Yes, 
I'm very cheap and retired (income limited)


- Paul McFerrin


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

Re: "Unknown" user after logging into sshd under Vista

[Larry Hall (Cygwin)]

Daniel Noll wrote:

Hi all.

The archives do have a number of Vista-related SSH problems which have solved 
the issue of getting it installed, but I haven't been able to solve the issue 
I found next.


Here's the options I used to configure the service...


[508] [EMAIL PROTECTED]:~> ssh-host-config
Overwrite existing /etc/ssh_config file? (yes/no) yes
Generating /etc/ssh_config file
Overwrite existing /etc/sshd_config file? (yes/no) yes



Should privilege separation be used? (yes/no) yes
Generating /etc/sshd_config file



Do you want to install sshd as service?
(Say "no" if it's already installed as service) (yes/no) yes



Should this script create a new local account 'sshd_server' which has
the required privileges? (yes/no) yes



Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "ntsec".  CYGWIN=



However on logging in...

[503] [EMAIL PROTECTED]:~> ssh localhost
Last login: Fri Oct  5 09:20:07 2007 from 127.0.0.1
Fanfare!!!
You are successfully logged in to this server!!!
Could not chdir to home directory /home/daniel: Permission denied
-bash: cd: /home/daniel: Permission denied


Permissions on my home directory are correct as I can get into it via 
Explorer.  The problem is elsewhere -- if I look in the process list, the 
bash.exe process is running as user "(unknown)", not as my user account.


I'm not sure what to do from here.  What part of Cygwin is responsible for 
changing the user ID when a user logs in via SSH, and what is usually 
responsible for it misbehaving?



OK, we now know the symptoms and the problem.  But we don't have any basic
configuration information to do some simple triage with.  In short:


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


Please read and follow the above guidelines, paying particular attention to
the part about *attaching* cygcheck output.

In the absence of the above, my WAG is that the user you are logging in as
(domain user perhaps?) is not in your '/etc/passwd' file.  See 'man passwd'
and the Cygwin Users Guide  for more
details.  Ditto for '/etc/group'.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: screen reattach not working?

[Larry Hall (Cygwin)]

Andrew Schulman wrote:

Hi!
What is the current status of screen reattach?
For me it does not work under the default cygwin bash shell, which
uses cmd console afaik and it does not work under cygwin sshd. The
only way it works is under cygwin rxvt. I would most like to use it
under sshd.
What's the magic to make it work? :)


Hi Damjan.  There's information about this in
/usr/share/doc/screen/README.Cygwin.  Read that, but the short version is that
all features of screen are supposed to work correctly in a DOS console with
CYGWIN=tty (set before you open the console), and in rxvt, PuTTYcyg, and
xterm.  I'm not sure about an ssh session.



If it will work from a DOS console with CYGWIN=tty, it should work fine from
ssh.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: "Unknown" user after logging into sshd under Vista

[Daniel Noll]

On Friday 05 October 2007 13:07:41 Larry Hall (Cygwin) wrote:
> OK, we now know the symptoms and the problem.  But we don't have any basic
>
> configuration information to do some simple triage with.  In short:
> > Problem reports:   http://cygwin.com/problems.html
>
> Please read and follow the above guidelines, paying particular attention to
> the part about *attaching* cygcheck output.
>
> In the absence of the above, my WAG is that the user you are logging in as
> (domain user perhaps?) is not in your '/etc/passwd' file.  See 'man passwd'
> and the Cygwin Users Guide  for more
> details.  Ditto for '/etc/group'.

Okay.

Firstly we have this little error that comes straight after running it:

> [501] [EMAIL PROTECTED]:~> cygcheck -s -v -r > cygcheck.out
> 'id' program not found
> 'id' program not found

It does then run, but it recurses forever on one of Windows' (many :-/)
recursive registry nodes.  I've attached the portion of the file before
this takes place, in the hope that the stuff which comes after won't be
needed.

/etc/passwd looks like this:

> SYSTEM:*:18:544:,S-1-5-18::
> Administrators:*:544:544:,S-1-5-32-544::
> Administrator:unused_by_nt/2000/xp:500:513:U-Monolith\Administrator,S-1-5-21-387
>  7142786-2852047967-4020260781-500:/home/Administrator:/bin/bash
> daniel:unused_by_nt/2000/xp:1000:513:U-Monolith\Daniel,S-1-5-21-3877142786-28520
>  47967-4020260781-1000:/home/daniel:/bin/bash
> Guest:unused_by_nt/2000/xp:501:513:U-Monolith\Guest,S-1-5-21-3877142786-28520479
>  67-4020260781-501:/home/Guest:/bin/bash
> sshd:unused_by_nt/2000/xp:1001:513:sshd 
> privsep,U-Monolith\sshd,S-1-5-21-3877142786-2852047967-4020260781-1001:/var/empty:/bin/false
> sshd_server:unused_by_nt/2000/xp:1003:513:sshd server 
> account,U-Monolith\sshd_server,S-1-5-21-2403187937-3420309498-45037-1003:/var/empty:/bin/false

The 'daniel' line exists and does appear to be set to the right user,
except that my username should start with a lowercase d in there but I
tried changing that just now and it didn't make a difference.  Gotta
wonder where it got that capital letter from though, my username all
throughout Windows doesn't have it.

/etc/group has:

> root:S-1-5-32-544:0:
> SYSTEM:S-1-5-18:18:
> None:S-1-5-21-3877142786-2852047967-4020260781-513:513:
> Administrators:S-1-5-32-544:544:
> Backup Operators:S-1-5-32-551:551:
> Cryptographic Operators:S-1-5-32-569:569:
> Distributed COM Users:S-1-5-32-562:562:
> Event Log Readers:S-1-5-32-573:573:
> Guests:S-1-5-32-546:546:
> IIS_IUSRS:S-1-5-32-568:568:
> Network Configuration Operators:S-1-5-32-556:556:
> Performance Log Users:S-1-5-32-559:559:
> Performance Monitor Users:S-1-5-32-558:558:
> Power Users:S-1-5-32-547:547:
> Remote Desktop Users:S-1-5-32-555:555:
> Replicator:S-1-5-32-552:552:
> Users:S-1-5-32-545:545:

Perhaps suspiciously, I'm missing from Users.  But groups doesn't care...

> [516] [EMAIL PROTECTED]:~> groups
> None root Administrators Users

Daniel

Cygwin Configuration Diagnostics
Current System Time: Fri Oct 05 13:51:52 2007

Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 

Running under WOW64 on AMD64

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Windows\system32
c:\Windows
c:\Windows\System32\Wbem
c:\Program Files (x86)\Ant\bin
c:\Program Files (x86)\Java\jdk1.6.0_02\bin

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'daniel'
PWD = '/home/daniel'
HOME = '/home/daniel'
MAKE_MODE = 'unix'

HOMEPATH = '\Users\daniel'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Users\daniel\AppData\Roaming'
PROGRAMW6432 = 'C:\Program Files'
HOSTNAME = 'Monolith'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'AMD64 Family 15 Model 75 Stepping 2, AuthenticAMD'
WINDIR = 'C:\Windows'
VS80COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 
8\Common7\Tools\'
COMMONPROGRAMW6432 = 'C:\Program Files\Common Files'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/usr/bin'
PROGRAMDATA = 'C:\ProgramData'
USERDOMAIN = 'Monolith'
COMMONPROGRAMFILES(X86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
ANT_HOME = 'C:\Program Files (x86)\Ant'
!:: = '::\'
TEMP = '/cygdrive/c/Users/daniel/AppData/Local/Temp'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
USERNAME = 'daniel'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
JAVA_HOME = 'c:\Program Files (x86)\Java\jdk1.6.0_02'
EDITOR = 'vim'
USERPROFILE = 'C:\Users\daniel'
PS1 = '\033[1m[\!] [EMAIL PROTECTED]:\w> \033[0m'
LOGONSERVER = '\\MONOLITH'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\daniel\AppData\Local'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/tmp'
SYSTEMROOT = 'C:\Windows'
PRINT

Re: 1.5.24-2: zero-length write() and ioctl() on fd -1 cause crashes

[Lewis Hyatt]

i can remove the method call, too. this also crashes:

extern "C" JNIEXPORT void JNICALL
Java_terminator_terminal_PtyProcess_sendResizeNotification(JNIEnv* env,
jobject instance, jobject a0, jobject a1) {
try {
throw std::exception();
} catch (const std::exception& ex) {
}
}


OK, well in that case I probably can't be of much help. I can only think 
of two things that don't involve low-level details (of which I know 
nothing):


-If the destructor of jobject can throw... that would immediately 
terminate the program.


-I forget the details, but some compilers will assume that a function 
declared extern "C" won't throw. Maybe that is the explanation?



-Lewis


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