Re: Cygwin making files inaccessible?

[Jay K]

I looked at this a while. I tried various recent cygwin1.dlls as there were two 
ACL changes recently.
I tried building cygwin1.dll with those changes reverted, but failed to build 
it. 
For one thing it took me a while to find shilka..it is in cocom, but that 
wasn't the entire problem.

Eventually.. I noticed the behavior was not the same for every 
file/directory/volume. Sometimes it worked ok.
Though I think the ACLs still get changed quite a bit: "full" expands to "many".
Of course it has worked plenty for me and everyone else.

Eventually I tried chmod -R 777 * and this seems to have worked.

I speculate that some "bad" Cygwin ACLs got created at some point.
 And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on 
directories?
Possibly due to those two recent changes, or maybe user error, I don't know.

 - Jay



From: Jay K
Sent: Saturday, February 5, 2022 12:16 PM
To: cygwin@cygwin.com 
Subject: Cygwin making files inaccessible? 
 
Cygwin making files inaccessible?
i.e. when Cygwin copies or writes to them, not random files.

C:\t>dir /s/b/a

C:\t>dir /q .

02/05/2022  04:11 AM              BUILTIN\Administrators .
02/05/2022  04:11 AM              NT SERVICE\TrustedInsta..

C:\t>cacls .
C:\t Everyone:(OI)(CI)F

C:\t>echo > 1.txt

C:\t>cacls 1.txt
C:\t\1.txt Everyone:F

C:\t>copy 1.txt 2.txt
        1 file(s) copied.

C:\t>cacls 2.txt
C:\t\2.txt Everyone:F

C:\t>del 2.txt

C:\t>uname -a
CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

C:\t>cp 1.txt 2.txt

C:\t>which cp
/usr/bin/cp

C:\t>cacls 2.txt
C:\t\2.txt NULL SID:(DENY)(special access:)
                    READ_CONTROL

           DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
                               FILE_READ_DATA
                               FILE_READ_EA
                               FILE_EXECUTE

           DESKTOP-BCFUMJ4\jay:(special access:)
                               STANDARD_RIGHTS_ALL
                               DELETE
                               READ_CONTROL
                               WRITE_DAC
                               WRITE_OWNER
                               SYNCHRONIZE
                               STANDARD_RIGHTS_REQUIRED
                               FILE_READ_ATTRIBUTES
                               FILE_WRITE_ATTRIBUTES

           DESKTOP-BCFUMJ4\None:R
           Everyone:R


C:\t>more 1.txt
ECHO is on.

C:\t>more 2.txt
Cannot access file C:\t\2.txt

Same behavior from cygwin64.

C:\t>\cygwin64\bin\uname -a
CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

Huh?

I would hope Cygwin could/would just copy the ACLs asis.
I am guessing there is some failed attempt to translate them
to an internal form and then back to NT form.

My real scenario was open/write/read, not cp.exe.

 - Jay

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

Cygwin making files inaccessible?

[Jay K]

Cygwin making files inaccessible?
i.e. when Cygwin copies or writes to them, not random files.

C:\t>dir /s/b/a

C:\t>dir /q .

02/05/2022  04:11 AM  BUILTIN\Administrators .
02/05/2022  04:11 AM  NT SERVICE\TrustedInsta..

C:\t>cacls .
C:\t Everyone:(OI)(CI)F

C:\t>echo > 1.txt

C:\t>cacls 1.txt
C:\t\1.txt Everyone:F

C:\t>copy 1.txt 2.txt
1 file(s) copied.

C:\t>cacls 2.txt
C:\t\2.txt Everyone:F

C:\t>del 2.txt

C:\t>uname -a
CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

C:\t>cp 1.txt 2.txt

C:\t>which cp
/usr/bin/cp

C:\t>cacls 2.txt
C:\t\2.txt NULL SID:(DENY)(special access:)
READ_CONTROL

   DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
   FILE_READ_DATA
   FILE_READ_EA
   FILE_EXECUTE

   DESKTOP-BCFUMJ4\jay:(special access:)
   STANDARD_RIGHTS_ALL
   DELETE
   READ_CONTROL
   WRITE_DAC
   WRITE_OWNER
   SYNCHRONIZE
   STANDARD_RIGHTS_REQUIRED
   FILE_READ_ATTRIBUTES
   FILE_WRITE_ATTRIBUTES

   DESKTOP-BCFUMJ4\None:R
   Everyone:R


C:\t>more 1.txt
ECHO is on.

C:\t>more 2.txt
Cannot access file C:\t\2.txt

Same behavior from cygwin64.

C:\t>\cygwin64\bin\uname -a
CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

Huh?

I would hope Cygwin could/would just copy the ACLs asis.
I am guessing there is some failed attempt to translate them
to an internal form and then back to NT form.

My real scenario was open/write/read, not cp.exe.

 - Jay

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

Re: ExitProcess does not work in Cygwin?

[Jay K]

 > It is best to avoid Cygwin-specific code.

Agreed.
The code is mostly only ifdef win32 vs. Posix but just a few spots are 
Cygwin-specific.
(and Apple specific, Solaris specific, IA64-specific etc.)

 - Jay


From: Andrey Repin 
Sent: Wednesday, January 26, 2022 2:23 PM
To: Jay K ; cygwin@cygwin.com 
Subject: Re: ExitProcess does not work in Cygwin?

Greetings, Jay K!

 >> Just use POSIX exit(3)!


> I did switch my code:

> #ifdef __CYGWIN__
>  exit(x);
> #else
>  ExitProcess(x);
> #endif
> .

It is best to avoid Cygwin-specific code.
Use either Linux(POSIX) or Windows specific tests, and only test for Cygwin if
/absolutely/ necessary.


--
With best regards,
Andrey Repin
Wednesday, January 26, 2022 17:22:01

Sorry for my terrible english...


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

Re: ExitProcess does not work in Cygwin?

[Jay K]

 > Just use POSIX exit(3)!


I did switch my code:

#ifdef __CYGWIN__
 exit(x);
#else
 ExitProcess(x);
#endif
.

I think the problem is actually in how "Cygwin bash"
aka Cygwin, computes the exit code in exec/spawn/system.

I.e. it recognizes it is running a Cygwin exe or a native
exe and does things differently.

I admit I didn't read or debug much.

In one run I was debugging I did seem to see a crash
in some DllMain(process detach), without symbols, and then I seemed to see
ExitProcess(1 or 2) become ExitProcess(0xXX00) and
then I started wondering if Cygwin somewhere is only
taking the lower 8 bits, since I know that is a thing in some code.

But I didn't dig into this further before trying the simple case,
which I don't think crashes and really does NtTerminateProcess(1).

 - Jay


From: Brian Inglis 
Sent: Thursday, January 13, 2022 5:19 PM
To: cygwin@cygwin.com 
Cc: Jay K 
Subject: Re: ExitProcess does not work in Cygwin?

On 2022-01-13 10:07, Kaz Kylheku (Cygwin) wrote:
> On 2022-01-13 05:40, Eliot Moss wrote:
>> On 1/13/2022 1:39 AM, Jay K wrote:
>>> ExitProcess does not work in Cygwin?

Just use POSIX exit(3)!

>> ExitProcess does not appear to be a POSIX function.
>
> This is a real issue worth looking into. Though ExitProcess isn't a POSIX
> function, Cygwin can capture the termination status of non-Cygwin programs.
>
> The concept of termination status cannot be entirely walled off in a
> private Cygwin garden; it belongs to the underlying platform.
>
> In Cygwin, I can do this:
>
>C:\Cygwin\cygwin64\home\kaz>exit 1
>1:BLACKBOX:~$
>1:BLACKBOX:~$ echo $?
>1
>0:BLACKBOX:~$ cmd
>Microsoft Windows [Version 10.0.19042.1052]
>(c) Microsoft Corporation. All rights reserved.
>
>C:\Cygwin\cygwin64\home\kaz>exit 0
>0:BLACKBOX:~$
>
> The number in my Bash prompt is the last exit code. As you can see,
> the non-Cygwin CMD.EXE program produces a termination code which
> is recognized in the Cygwin world.
>
> Most likely it does that via ExitProcess.
>
> It is odd if calling ExitProcess in a Cygwin process causes
> a Cygwin parent not to similarly process the status, as seems
> to be shown by Jay's test cases.
>
> Cygwin supports non-POSIX programming; you can write GUI applications
> using Win32 calls for instance.
>
> (Now I agree that for exiting your process, even if it's a GUI
> application using numerous win32 calls, you should probably do it the
> Cygwin way, and use exit, or return from main. But still ...)

Cygwin installs at-exit handlers and it is likely that when these have
finished, they return a Cygwin exit status if passed by the POSIX
function, perhaps unless some error has occurred during at-exit handling.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

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

Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

[Jay K]

I don't know why I didn't get the reply in email, but this is representative of 
the real world code.

 - Jay


From: Jay K 
Sent: Wednesday, January 12, 2022 6:27 AM
To: cyg...@sourceware.org 
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 
 
Ok, here is a small demonstration of the problem.

#include  
#include 
#include 

unsigned __stdcall thread(void* p)
{
  unsigned i;
  for (i = 0; i < 100; ++i)
   system("./a.exe");
  return 0;
}

int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);

system("g++ a.c");

for (i = 0; i < 100; ++i)
 threads[i] = CreateThread(0, 0, thread, 0,0,0);

for (i = 0; i < 100; ++i)
 WaitForSingleObject(threads[i], -1);

}

$ ./1.exe 
      0 [main] sh 9287 C:\cygwin64\bin\sh.exe: *** fatal error - internal error 
reading the windows environment - too many environment variables?
                                                  3001 [main] sh 9287 
cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
                                                       0 [main] sh 9286 
C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows 
environment - too many environment variables?
                                                                                
                Stack trace:
Frame        Function    Args
000CD30  00180061C6E (001802795F0, 00180269E81, 000, 000BB20)
000CD30  0018004849A (228, 0080160, 000, 000CD30)
000CD30  001800484D2 (000, 000, 000, 000)
000CD30  0018005F12D (00180158C19, 000, 000, 000CD30)
000CD30  00180103AE4 (000, 000, 000, 000)
000CD30  00180048BC2 (000, 000, 000, 000)
000FFF0  00180047746 (000, 000, 000, 000)
000FFF0  001800477F4 (000, 000, 000, 000)
End of stack trace
                        0 [waitproc] 1 9269 proc_waiter: error on read of child 
wait pipe 0x0, Win32 error 6
             1078 [waitproc] 1 9269 proc_waiter: error on read of child wait 
pipe 0x0, Win32 error 6
     4452 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
                                                                                
            sh: ./a.exe: Bad address
  11522 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
                                                                                
          sh: ./a.exe: Bad address
sh: ./a.exe: Bad address
  38623 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
                                                                                
            48009 [waitproc] 1 9269 proc_waiter: error on read of child wait 
pipe 0x0, Win32 error 6
                                                                                
    48660 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
                                                                            
49909 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6


I understand I can workaround this, in that the use of threads is silly.

Is this invalid, to mix Win32 threads with cygwin system()?

 - Jay


From: Jay K 
Sent: Wednesday, January 12, 2022 5:57 AM
To: cyg...@sourceware.org 
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 
 
Um, I know this isn't (yet) diligent/scientific, but must system create this 
thread?

#0  0x7ff811e09e47 in KERNEL32!CreateThread () from 
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL 
#1  0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2  0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3  0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from 
/usr/bin/cygwin1.dll
#4  0x000180134e85 in child_info_spawn::worker(char const*, char const* 
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5  0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6  0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7  0x000180144683 in system () from /usr/bin/cygwin1.dll
#8  0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9  0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0 
"\260\324\005",

'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to 
read stdout/stderr, if they are not equal.

 - Jay


From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org 
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6 
 
I get this a lot:

      0 

ExitProcess does not work in Cygwin?

[Jay K]

ExitProcess does not work in Cygwin?

$ rm *.exe

# u is for Unix
# w is for Windows

$ cat u.c
#include 
int main()
{
 exit(1);
}

$ gcc u.c
$ ./a.exe

$ echo $?
1

 => as expected

$ cat w.c
#include 

int main()
{
 ExitProcess(1);
}

$ gcc w.c
$ ./a.exe

$ echo $?
0

 => not expected

$ uname -a
CYGWIN_NT-10.0 jayk-tp4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

works in debugger:

$ /cygdrive/c/bin/amd64/windbg.exe .\\a.exe

$ echo $?
1

?

 - Jay

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

Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

[Jay K]

Ok, here is a small demonstration of the problem.

#include 
#include 
#include 

unsigned __stdcall thread(void* p)
{
  unsigned i;
  for (i = 0; i < 100; ++i)
   system("./a.exe");
  return 0;
}

int main()
{
unsigned i;
HANDLE threads[100] = {0};
FILE* f = fopen("a.c", "w");
fprintf(f, "int main() { return 0; }\n");
fclose(f);

system("g++ a.c");

for (i = 0; i < 100; ++i)
 threads[i] = CreateThread(0, 0, thread, 0,0,0);

for (i = 0; i < 100; ++i)
 WaitForSingleObject(threads[i], -1);

}

$ ./1.exe
  0 [main] sh 9287 C:\cygwin64\bin\sh.exe: *** fatal error - internal error 
reading the windows environment - too many environment variables?
  3001 [main] sh 9287 
cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
   0 [main] sh 9286 
C:\cygwin64\bin\sh.exe: *** fatal error - internal error reading the windows 
environment - too many environment variables?

Stack trace:
FrameFunctionArgs
000CD30  00180061C6E (001802795F0, 00180269E81, 000, 000BB20)
000CD30  0018004849A (228, 0080160, 000, 000CD30)
000CD30  001800484D2 (000, 000, 000, 000)
000CD30  0018005F12D (00180158C19, 000, 000, 000CD30)
000CD30  00180103AE4 (000, 000, 000, 000)
000CD30  00180048BC2 (000, 000, 000, 000)
000FFF0  00180047746 (000, 000, 000, 000)
000FFF0  001800477F4 (000, 000, 000, 000)
End of stack trace
0 [waitproc] 1 9269 proc_waiter: error on read of child 
wait pipe 0x0, Win32 error 6
 1078 [waitproc] 1 9269 proc_waiter: error on read of child wait 
pipe 0x0, Win32 error 6
 4452 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6

sh: ./a.exe: Bad address
  11522 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6

  sh: ./a.exe: Bad address
sh: ./a.exe: Bad address
  38623 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6

48009 [waitproc] 1 9269 proc_waiter: error on read of child wait 
pipe 0x0, Win32 error 6

48660 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6

49909 [waitproc] 1 9269 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6


I understand I can workaround this, in that the use of threads is silly.

Is this invalid, to mix Win32 threads with cygwin system()?

 - Jay


From: Jay K 
Sent: Wednesday, January 12, 2022 5:57 AM
To: cyg...@sourceware.org 
Subject: Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

Um, I know this isn't (yet) diligent/scientific, but must system create this 
thread?

#0  0x7ff811e09e47 in KERNEL32!CreateThread () from 
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1  0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2  0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3  0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from 
/usr/bin/cygwin1.dll
#4  0x000180134e85 in child_info_spawn::worker(char const*, char const* 
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5  0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6  0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7  0x000180144683 in system () from /usr/bin/cygwin1.dll
#8  0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9  0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0 
"\260\324\005",

'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to 
read stdout/stderr, if they are not equal.

 - Jay


From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org 
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

I get this a lot:

  0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
716 [waitproc] cm3 7641 proc_waiter: e

Re: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

[Jay K]

Um, I know this isn't (yet) diligent/scientific, but must system create this 
thread?

#0  0x7ff811e09e47 in KERNEL32!CreateThread () from 
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1  0x0001800468eb in cygthread::create() () from /usr/bin/cygwin1.dll
#2  0x00018010645f in pinfo::wait() () from /usr/bin/cygwin1.dll
#3  0x00018012e562 in proc_subproc(unsigned int, unsigned long) () from 
/usr/bin/cygwin1.dll
#4  0x000180134e85 in child_info_spawn::worker(char const*, char const* 
const*, char const* const*, int, int, int) () from /usr/bin/cygwin1.dll
#5  0x000180136729 in spawnve () from /usr/bin/cygwin1.dll
#6  0x000180136d05 in spawnvp () from /usr/bin/cygwin1.dll
#7  0x000180144683 in system () from /usr/bin/cygwin1.dll
#8  0x00018018effb in _sigfe () from /usr/bin/cygwin1.dll
#9  0x00010052884b in QMachine__ExecCommand (t_L_563=0x448ef0 
"\260\324\005",

'cause i.e. it complicates any lifetime/management.
I do understand some of the problems here, like needing separate threads to 
read stdout/stderr, if they are not equal.

 - Jay

____
From: Jay K
Sent: Wednesday, January 12, 2022 4:12 AM
To: cyg...@sourceware.org 
Subject: proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

I get this a lot:

  0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
   1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
  0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error 
reading the windows environment - too many environment variables?

Scenario is multi-threaded "launching" a bunch of invocations of gcc.
"launching" was usually spawnve or fork/execve but I changed the code to use 
system and it still happens.
I might try to make a small reproducing, if this is not known.
It seems a bit difficult to believe I could cause this internal looking error.

Thank you,
 - Jay

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

proc_waiter: error on read of child wait pipe 0x0, Win32 error 6

[Jay K]

I get this a lot:

  0 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
452 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
716 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
   1652 [waitproc] cm3 7641 proc_waiter: error on read of child wait pipe 0x0, 
Win32 error 6
  0 [main] sh 7775 C:\cygwin64\bin\sh.exe: *** fatal error - internal error 
reading the windows environment - too many environment variables?

Scenario is multi-threaded "launching" a bunch of invocations of gcc.
"launching" was usually spawnve or fork/execve but I changed the code to use 
system and it still happens.
I might try to make a small reproducing, if this is not known.
It seems a bit difficult to believe I could cause this internal looking error.

Thank you,
 - Jay

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

Re: Just updated cygutils and cygstart no longer works

[Jay Abel via Cygwin]

Sorry, more information.  I'm running Windows 10, 64-bit, AMD.

I've reverted cygutils back to 1.4.16-2 and the problem is resolved.

Jay

On Fri, Aug 13, 2021 at 10:27 AM Jay Abel  wrote:

> Run cygstart with anything and no window opens.  I've tried URLS cygstart
> http://www.cygwin.com, directories cygstart . and cygstart ./  as well as
> pdf files cygstart example.pdf.
>
> None of these seems to do anything anymore.
>

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

Just updated cygutils and cygstart no longer works

[Jay Abel via Cygwin]

Run cygstart with anything and no window opens.  I've tried URLS cygstart
http://www.cygwin.com, directories cygstart . and cygstart ./  as well as
pdf files cygstart example.pdf.

None of these seems to do anything anymore.

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

bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash

[Jay Libove via Cygwin]

Hi Cygwin team,
Here is a consolidated bug report based on the discussion in recent days which 
I'd started under the subject " shell expansion produces e.g. "ls: cannot 
access '*.pdf': No such file or directory" in Windows CMD shell, but works okay 
in bash " (thread starter 
https://cygwin.com/pipermail/cygwin/2020-March/244161.html )
Many thanks to Paul, Andrey, and others for helping me nail down where and how 
it seems to be happening.
My apologies in advance that my coding days are long behind me, so I'm not in a 
position to include a proposed code fix.

cygcheck output attached (lightly modified to redact a couple of personal 
items).

Problem:
Under certain circumstances (see Steps to Reproduce, below) Cygwin programs' 
built-in argv[] globbing will produce unexpected:
"{programName}: cannot access '{glob pattern}: No such file or directory"
e.g.
"ls: cannot access '*.pdf': No such file or directory"
.. despite the fact that e.g. *.pdf definitely exists.

Steps to Reproduce:
* Have some files in the local director with accented characters in the names, 
e.g.:
C:> mkdir c:\temp\test
C:> cd c:\temp\test
C:> touch héllo.pdf
C:> touch gòodbye.pdf
C:> touch normal.pdf
* DON'T have the LANG= environment variable set to anything
* NOT in bash or Cygwin Terminal, but rather within Windows CMD.exe, execute a 
Cygwin command which needs to do file name globbing because the Windows CMD.exe 
shells does not do so for it, e.g.
C:> ls *.pdf
C:> cat *.pdf
These will produce "ls: cannot access '*.pdf': No such file or directory"
Although, curiously,
C:> ls *or*
does correctly produce:
normal.pdf

Also, display output of the áccènted characters is incomplete:
C:> ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf
C:> bash
jay_l@DESKTOP-I9MRIE3 /cygdrive/c/Temp
$ ls
'g'$'\303\262''odbye.pdf'  'h'$'\303\251''llo.pdf'   normal.pdf


Analysis:
I've verified that it's not about case sensitivity. That is, it's not a matter 
of ls *.pdf vs. ls *.PDF.
If these test commands are run either under bash.exe or within a Cygwin 
Terminal window, the problem does not occur.
I've verified that the Windows system locale (per Windows' Region setting) 
actually doesn't matter. (I've reproduced this both on systems in Region Spain 
with language English-International and English-Ireland, and in a VM with a bog 
standard vanilla US English Windows).

Credits to Paul for suggesting deleting files one by one until the problem goes 
away, and to Andrey for pointing out `locale` and the LANG= setting.

Set LANG=en_US.UTF-8, e.g.
C:> set LANG=en_US.UTF-8
.. and the problem goes away.
C:> ls *.pdf
gòodbye.pdf
héllo.pdf
normal.pdf
C:> ls
gòodbye.pdf
héllo.pdf
normal.pdf

Interestingly, Andrey mentioned that he sets LANG=ru_RU.CP866 and he doesn't 
see the problem. When I tried that exact setting, I still had the problem.
So it's maybe not just that LANG must be set to *something*, but that somehow 
LANG must be set to something that matches something in Windows? (Sorry, I know 
that's nearly uselessly vague).


In summary, it appears that the way that the argv[] globbing code which gets 
compiled in to Cygwin programs functions a bit differently than the way the 
shell globbing code works within bash.exe.
And this produces unexpected globbing failures.


Thanks to all the Cygwin maintainers for this amazing software, for so many 
years!
-Jay




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

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

[Jay Libove via Cygwin]

Hi Andrey,
(I have no idea what you mean about "top posting".)

`locale` gives the same in CMD as in bash, on this machine as on another 
machine on my network where I also checked, which also exhibits the same 
globbing problem under Windows CMD:

LANG=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

Aha, wait! No, there is one difference: in Cygwin Terminal (which I've never 
run before today; I've always either just run commands in a CMD window, or run 
bash.exe first; I'd initially mistakenly assumed that Cygwin terminal was the 
same as bash-in-CMD, but clearly it's not):
LANG=en_US.UTF-8

If I set LANG=en_US.UTF-8 in a Windows CMD window, **then the globbing problem 
goes away**.

I'm not sure how that points towards a solution, but it certainly must be a 
clue.

thanks,
Jay


-Original Message-
From: Andrey Repin  
Sent: Monday 23 March 2020 18:44
To: Jay Libove ; cygwin@cygwin.com
Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such 
file or directory" in Windows CMD shell, but works okay in bash

Greetings, Jay Libove!

Please no top posting in this mailing list.

> Good suggestion, deleting files one by one. It's not just one file, 
> but it does seem to have something to do with some file name patterns.
> I think I've got it. It's accented characters.
> I live in Spain. Spanish has accented characters such as "Asociación".
> When I remove all files containing any accented character in their name, the 
> problem goes away.
> So the theory now is that the Cygwin argv-processing code has a problem with 
> áccented charàcters ...

Compare the output of `locale` in Cygwin terminal and your regular console.
Most likely your files have names that do not map cleanly to your console 
codepage, or locale is not set in the native terminal.


--
With best regards,
Andrey Repin
Monday, March 23, 2020 20:40:57

Sorry for my terrible english...
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

[Jay Libove via Cygwin]

Good suggestion, deleting files one by one. It's not just one file, but it does 
seem to have something to do with some file name patterns.
I think I've got it. It's accented characters.
I live in Spain. Spanish has accented characters such as "Asociación".
When I remove all files containing any accented character in their name, the 
problem goes away.
So the theory now is that the Cygwin argv-processing code has a problem with 
áccented charàcters ...
-Jay

-Original Message-
From: Paul Moore  
Sent: Sunday, 22 March 2020 20:42
To: Jay Libove 
Cc: cygwin@cygwin.com
Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such 
file or directory" in Windows CMD shell, but works okay in bash

Have you tried deleting files one by one, to see if the issue is related to a 
single file (sorry if this is an obvious suggestion that you've already tried).

In Cygwin bash, it's the shell that glob-expands wildcards before calling your 
program (e.g. ls), and in find, it's the find code that does the glob matching. 
But when running Cygwin utilities from a Windows shell, it's the Cygwin 
argv-processing code linked into the executable that does the glob-expansion. 
So it's reasonable to me that you should see the issue only with CMD, and not 
with bash or find. But that only confirms what bit of code is involved - not 
what the actual problem is :-(

I don't actually know much about how the cygwin glob code actually works (my 
main involvement with it has been to confirm that it doesn't suit my specific 
needs, and to work out a way to bypass it...) so I can only offer fairly basic 
suggestions, I'm afraid...

Paul

On Sun, 22 Mar 2020 at 19:27, Jay Libove  wrote:
>
> Thanks Paul, both for your initial reply, and your follow-up.
>
> In this case it's not a matter case sensitivity.
> I've verified that, in one of the example cases, there are both *.pdf and 
> *.PDF files in the subject directory.
> Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatever': 
> No such file or directory" error.
>
> (Nor, to the other respondent's question, as I pointed out in my original 
> post, is it ACLs, as I did check CACLS before posting).
>
> I also tried copying (using Windows CMD "COPY") *.pdf (so being under 
> Windows, not Cygwin, it matches all cases) from a subject directory to a new 
> test directory.
> In the resulting copy in the new test directory, the Cygwin shell expansion 
> problem persists.
>
> Here's an interesting twist:
> C:> cd c:\bin\cygwin64\bin
> C:> ln gnufind.exe find.exe # I do this to allow me to differentiate between 
> Windows' built-in very limited FIND command, and GNU/Cygwin's far superior 
> find command.
> C:> cd \my\test\directory
> C:> gnufind . -name *.pdf -print
> [ successfully returns all *.pdf {lower case only} files in the 
> subject directory ] C:> gnufind . -name *.PDF -print [ successfully 
> returns all *.pdf {upper case only} files in the subject directory ]
>
> I'm pretty sure that Cygwin 'find' does NOT try to emulate shell globbing the 
> way 'ls' does, so it makes sense that this works, and it supports the theory 
> that something weird is going on between how Cygwin does shell expansion when 
> under Windows CMD vs. when fully within the Cygwin environment (under bash 
> where of course bash is doing the shell expansion, and ls or other Cygwin 
> commands don't have to).
>
> Does any of this help pinpoint the problem further?
>
> thanks again,
> -Jay
>
> -Original Message-
> From: Paul Moore 
> Sent: Sunday, 22 March 2020 20:09
> To: Jay Libove 
> Cc: cygwin@cygwin.com
> Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': 
> No such file or directory" in Windows CMD shell, but works okay in 
> bash
>
> Is this because cygwin globbing is (by default) case sensitive? You could set 
> the CYGWIN environment variable to "glob:ignorecase" to get case-insensitive 
> behaviour.
>
> Paul
>
> On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin  wrote:
> >
> > I've never seen this before.
> > In a Windows CMD shell, Cygwin shell expansion, for example:
> > ls *.pdf
> >
> > returns:
> > ls: cannot access '*.PDF': No such file or directory (Indeed, any 
> > Cygwin shell expansion, when executed from within Windows CMD, 
> > produces this error. See below)
> >
> > ls *someotherwildcard* (that matches the same .pdf files) DOES return the 
> > expected file list.
> >
> > Example:
> >
> > C:> DIR *.pdf
> > Volume in drive C is C
> > Volume Serial Number is 8674-712A
> >
> > Directory of C:\Temp
> >
> > 22/03/2020  18:30 1.675.954 test.pdf

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

[Jay Libove via Cygwin]

Thanks Paul, both for your initial reply, and your follow-up.

In this case it's not a matter case sensitivity. 
I've verified that, in one of the example cases, there are both *.pdf and *.PDF 
files in the subject directory.
Both 'ls *.pdf' and 'ls *.PDF' produce the "ls: cannot access '*.whatever': No 
such file or directory" error. 

(Nor, to the other respondent's question, as I pointed out in my original post, 
is it ACLs, as I did check CACLS before posting).

I also tried copying (using Windows CMD "COPY") *.pdf (so being under Windows, 
not Cygwin, it matches all cases) from a subject directory to a new test 
directory.
In the resulting copy in the new test directory, the Cygwin shell expansion 
problem persists.

Here's an interesting twist:
C:> cd c:\bin\cygwin64\bin
C:> ln gnufind.exe find.exe # I do this to allow me to differentiate between 
Windows' built-in very limited FIND command, and GNU/Cygwin's far superior find 
command.
C:> cd \my\test\directory
C:> gnufind . -name *.pdf -print
[ successfully returns all *.pdf {lower case only} files in the subject 
directory ]
C:> gnufind . -name *.PDF -print
[ successfully returns all *.pdf {upper case only} files in the subject 
directory ]

I'm pretty sure that Cygwin 'find' does NOT try to emulate shell globbing the 
way 'ls' does, so it makes sense that this works, and it supports the theory 
that something weird is going on between how Cygwin does shell expansion when 
under Windows CMD vs. when fully within the Cygwin environment (under bash 
where of course bash is doing the shell expansion, and ls or other Cygwin 
commands don't have to).

Does any of this help pinpoint the problem further?

thanks again,
-Jay

-Original Message-
From: Paul Moore  
Sent: Sunday, 22 March 2020 20:09
To: Jay Libove 
Cc: cygwin@cygwin.com
Subject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such 
file or directory" in Windows CMD shell, but works okay in bash

Is this because cygwin globbing is (by default) case sensitive? You could set 
the CYGWIN environment variable to "glob:ignorecase" to get case-insensitive 
behaviour.

Paul

On Sun, 22 Mar 2020 at 17:52, Jay Libove via Cygwin  wrote:
>
> I've never seen this before.
> In a Windows CMD shell, Cygwin shell expansion, for example:
> ls *.pdf
>
> returns:
> ls: cannot access '*.PDF': No such file or directory (Indeed, any 
> Cygwin shell expansion, when executed from within Windows CMD, 
> produces this error. See below)
>
> ls *someotherwildcard* (that matches the same .pdf files) DOES return the 
> expected file list.
>
> Example:
>
> C:> DIR *.pdf
> Volume in drive C is C
> Volume Serial Number is 8674-712A
>
> Directory of C:\Temp
>
> 22/03/2020  18:30 1.675.954 test.pdf
> XX/XX/  XX:XX {Any many other .pdf files}
>
> Yet:
>
> C:> ls *.pdf
> ls: cannot access '*.pdf': No such file or directory
>
> And:
> C:> bash
> user@hostname /cygdrive/C/Temp/test
> $ ls *.pdf
> A.pdf
> B.pdf
> {etc}
>
> And, not ALL of the *.pdf files in the particular directory where I've 
> encountered this trigger the problem...
>
> C:> ls N*.pdf
> N.pdf
>
> C:> ls A*.pdf
> ls: cannot access 'A*.pdf': No such file or directory
>
> Nor do all directories containing .pdf files produce this. Of the many 
> thousands of files and directories that I have, only some produce this 
> problem.
> In others, ls *.pdf works perfectly in Windows CMD.
>
> I've looked at the Windows ATTRIB and CACLS of the files in directories where 
> this problem occurs.
> They're all the same. That is, uniform across all files and directories. 
> Nothing interesting.
>
> It's not just 'ls':
>
> C:> cat *.pdf
> cat: '*.pdf': No such file or directory
>
> So, it appears to be Cygwin shell expansion, when executed under Windows CMD, 
> which is provoking this strange behavior.
> Any ideas what could be causing this, and how to solve it?
>
> many thanks,
> Jay
>
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

[Jay Libove via Cygwin]

I've never seen this before.
In a Windows CMD shell, Cygwin shell expansion, for example:
ls *.pdf

returns:
ls: cannot access '*.PDF': No such file or directory
(Indeed, any Cygwin shell expansion, when executed from within Windows CMD, 
produces this error. See below)

ls *someotherwildcard* (that matches the same .pdf files) DOES return the 
expected file list.

Example:

C:> DIR *.pdf
Volume in drive C is C
Volume Serial Number is 8674-712A

Directory of C:\Temp

22/03/2020  18:30 1.675.954 test.pdf
XX/XX/  XX:XX {Any many other .pdf files}

Yet:

C:> ls *.pdf
ls: cannot access '*.pdf': No such file or directory

And:
C:> bash
user@hostname /cygdrive/C/Temp/test
$ ls *.pdf
A.pdf
B.pdf
{etc}

And, not ALL of the *.pdf files in the particular directory where I've 
encountered this trigger the problem...

C:> ls N*.pdf
N.pdf

C:> ls A*.pdf
ls: cannot access 'A*.pdf': No such file or directory

Nor do all directories containing .pdf files produce this. Of the many 
thousands of files and directories that I have, only some produce this problem.
In others, ls *.pdf works perfectly in Windows CMD.

I've looked at the Windows ATTRIB and CACLS of the files in directories where 
this problem occurs.
They're all the same. That is, uniform across all files and directories. 
Nothing interesting.

It's not just 'ls':

C:> cat *.pdf
cat: '*.pdf': No such file or directory

So, it appears to be Cygwin shell expansion, when executed under Windows CMD, 
which is provoking this strange behavior.
Any ideas what could be causing this, and how to solve it?

many thanks,
Jay

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

Re: Problem with installation of Octave

[Jay Abel]

I'm using tcsh and for some reason the default configuration for X11 keeps
leaving zombie dbus processes, none of which seem to be reachable.  For
example, when running Octave I get an error that dbus wasn't replying.  Now,
if within the open xterm window I type dbus-launch and then I run octave,
there is no error.  I noticed that running dbus-launch in the xterm window
creates three environment variables beginning with DBUS_ but the default
startup only creates the first one, DBUS_SESSION or some such.

Any idea what I'm doing wrong?



--
Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html

--
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: mintty window flashes open and immediately closes

[Jay Goldman]

FWIW, this problem has disappeared with the latest setup.exe.
There are no more errors during postinstall and AFAICT everything is working.


On Sat, Dec 21, 2019, at 4:58 PM, Jay Goldman wrote:
> I think my problem applies to this thread. 
> (I'm unclear how to reply to an entry in the mailing list archive)
> 
> 
> all cygwin commands stopped working for me, too.
> (i have been using cygwin for many years, it has been running on my 
> windows 10 system for as long as windows 10 has been available)
> so, i recovered a version of the bin folder from a few days ago, and 
> all is working. (note, i only had to recover the bin folder, i did not 
> have to recover the lib, etc, or var folders)
> 
> not sure if i ran cygcheck correctly - i ran it from a cmd window in a 
> non-cygwin folder (this is newcheck.out)
> so i ran  it again (badcheck.out) while working dir is \bin.bad (my 
> 'bad' version of \bin folder)
> NOTE: i changed the user name changed to )
> 
> Before backing up the bin folder, the situation was:
> When i run cmd window and try anything in cygwin bin folder i get 
> (bash.exe is just an example) (except for cygcheck :-)
> C:\newbin>bash.exe -i
>   0 [main] bash (1588) C:\newbin\bash.exe: *** fatal error - 
> add_item ("\??\C:", "/", ...) failed, errno 22
> 
> This also happens with bat scripts i have been using for many years to 
> start xwindows or just a terminal window.
> 
> It appears, i think, to be a problem with setup (or maybe an 
> interaction with some recent windows 10 update?), 
> since when i run setup-x86_64.exe, i get the following in 
> /var/log/setup.log:
> 
> 2019/12/21 13:48:56 Starting cygwin install, version 2.897
> 2019/12/21 13:48:56 User has backup/restore rights
> 2019/12/21 13:48:56 Current Directory: K:\installation_disks\cygwin64
> 2019/12/21 13:48:56 Could not open service McShield for query, start 
> and stop. McAfee may not be installed, or we don't have access.
> 2019/12/21 13:49:01 source: network install
> 2019/12/21 13:49:02 root: C:\ system
> 2019/12/21 13:49:03 Selected local directory: 
> K:\installation_disks\cygwin64
> 2019/12/21 13:49:04 net: Direct
> 2019/12/21 13:49:06 site: http://mirror.clarkson.edu/cygwin/
> 2019/12/21 13:49:06 HTTP status 404 fetching 
> http://mirror.clarkson.edu/cygwin/x86_64/setup.zst.sig
> 2019/12/21 13:49:06 HTTP status 404 fetching 
> http://mirror.clarkson.edu/cygwin/x86_64/setup.zst
> 2019/12/21 13:49:08 solving: 0 tasks, update: yes, use test packages: no
> 2019/12/21 13:49:11 solving: 0 tasks, update: no, use test packages: no
> 2019/12/21 13:49:11 Augmented Transaction List: is empty
> 2019/12/21 13:49:13 Changing gid back to original
> 2019/12/21 13:49:13 running: C:\\bin\dash.exe 
> "/etc/postinstall/0p_000_autorebase.dash"
> 2019/12/21 13:49:15 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:15 running: C:\\bin\dash.exe 
> "/etc/postinstall/0p_texlive_prep.dash"
> 2019/12/21 13:49:18 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:18 running: C:\\bin\dash.exe 
> "/etc/postinstall/0p_update-info-dir.dash"
> 2019/12/21 13:49:19 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:22 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/bash.sh"
> 2019/12/21 13:49:23 abnormal exit: exit code=256
> 2019/12/21 13:49:23 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/cygwin-doc.sh"
> 2019/12/21 13:49:26 abnormal exit: exit code=256
> 2019/12/21 13:49:26 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/lyx.sh"
> 2019/12/21 13:49:28 abnormal exit: exit code=256
> 2019/12/21 13:49:28 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/TeXmacs.sh"
> 2019/12/21 13:49:29 abnormal exit: exit code=256
> 2019/12/21 13:49:29 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/zp_adwaita-icon-theme.sh"
> 2019/12/21 13:49:31 abnormal exit: exit code=256
> 2019/12/21 13:49:31 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/zp_desktop-file-utils.sh"
> 2019/12/21 13:49:33 abnormal exit: exit code=256
> 2019/12/21 13:49:33 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/zp_fontconfig_cache_1.sh"
> 2019/12/21 13:49:35 abnormal exit: exit code=256
> 2019/12/21 13:49:35 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/zp_glib2.0.sh"
> 2019/12/21 13:49:38 abnormal exit: exit code=256
> 2019/12/21 13:49:38 running: C:\\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/zp_hicolor-icon-theme.sh"
> 2019/12/21 13:49:40 abnormal exit: exit code=256
> 2019/12/21 13:49:40 running: C:\\bin\bash.

RE: How can I determine why gdb throws unknown exceptions when debugging programs with threads on my Cygwin installation?

[Jay P. Elston]

On October 25, 2019 6:48 AM, Michael Soegtrop wrote:

>It has been reported in the past that antivirus software from Trend Micro 
>result in STATUS_GUARD_PAGE_VIOLATION in ntdll!RtlAllocateHeap ().

>See: 
>http://cygwin.1069669.n5.nabble.com/XWin-startup-crash-x86-64-Windows-10-td126544.html#a126561

On the advice of Jon Turney, I ran a "bt f" command after gdb caught the 
exception, and it appears that a Trend Micro dll  (TmUmEvt64.dll) is where the 
error occurs:

Thread 7 received signal ?, Unknown signal.
[Switching to Thread 8736.0x2bf4]
0x77947b97 in ntdll!RtlAllocateHeap ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) bt f
#0  0x77947b97 in ntdll!RtlAllocateHeap ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
No symbol table info available.
#1  0x779f233d in ntdll!EtwEventWriteStartScenario ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
No symbol table info available.
#2  0x779f3014 in ntdll!EtwEventWriteStartScenario ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
No symbol table info available.
#3  0x77947b9c in ntdll!RtlAllocateHeap ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
No symbol table info available.
#4  0x07fefd2e1c68 in TmmonDestoryAddonObject ()
   from /cygdrive/c/Windows/system32/tmumh/20019/AddOn/8.20.0.1028/TmUmEvt64.dll
No symbol table info available.
#5  0x07fefd2267ab in ?? ()
   from /cygdrive/c/Windows/system32/tmumh/20019/AddOn/8.20.0.1028/TmUmEvt64.dll
No symbol table info available.
#6  0x07fefd2a551a in TmmonDestoryAddonObject ()
   from /cygdrive/c/Windows/system32/tmumh/20019/AddOn/8.20.0.1028/TmUmEvt64.dll

This is not a Cygwin problem -- the solution is to be to add the Cygwin bin 
directory to Trend Micro's exception list. I will give this a try
after I get our IT department to do this.

How can I determine why gdb throws unknown exceptions when debugging programs with threads on my Cygwin installation?

[Jay P. Elston]

d *)0);
if ( rc != 0 ) {
fprintf(stderr, "(%s,%d): Error %d creating thread for io 
handler: %s\n"
, __FILE__, __LINE__
, errno, strerror(errno)
    );
return rc;
}
pthread_join(fifteenSecondsThreadId, (void *)0);
return 0;
}


Jay


--
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: Problem with NC.1.107

[Jay Cotton]

Here is the package listing at cygwin

nc: A simple but powerful network tool (installed binaries and support
files)

2013-03-19 15:35   0 usr/
2013-03-19 15:35   0 usr/bin/
2013-03-19 15:35   24576 usr/bin/nc.exe
2013-03-19 15:35   0 usr/share/
2013-03-19 15:35   0 usr/share/man/
2013-03-19 15:35   0 usr/share/man/man1/
2013-03-19 15:305052 usr/share/man/man1/nc.1.gz



On Mon, Apr 9, 2018 at 6:51 PM, L A Walsh <cyg...@tlinx.org> wrote:

> Andrey Repin wrote:
>
>> Greetings, Jay Cotton!
>>
>> Since nc does not reply to --version, I have no way to tell if it's the
>> same
>> you are running with.
>>
> ---
> That's odd.  But has to do with what version of ncat is run.
> I notice my linux machine says:
>
> nc --version
>>
> Ncat: Version 6.47 ( http://nmap.org/ncat )
>
> But the version in cygwin:
>
> cygcheck -f /usr/bin/nc
>>
> nc-1.107-4
>
> is very different.  Not sure which is newer or better, but
> the version at nmap.org supports SCTP, though the BSD version
> supports QOS.  Not sufficiently versed in either to know
> all the differences.  Seems like the nmap.org version has more
> options: 44 vs. BSD's 28 (didn't double count switches from nmap
> that have a short+long form).
> Where do the sources from the BSD version come from?   It
> doesn't seem to list a website.
>
>
>> The file permissions are messed up.
>>>
>> ---
> I didn't notice this.
>
>>
>> $ file /usr/bin/nc
>>> /usr/bin/nc: writable, executable, regular file, no read permission
>>>
>>
>> I don't see the PE32+ executable (console) x86-64, for MS Windows
>>> string.
>>>
>> ---
> weird -- when I tried that, got:
>
> file /usr/bin/nc
>>
> /usr/bin/nc: PE32+ executable (console) x86-64 (stripped to external PDB),
> for MS Windows
>
>
> here is the file in /usr/bin
>>> $ ls -l nc*
>>> -rwxr-xr-x 1 lbmgm lbmgm 24576 Mar 19  2013 nc.exe
>>>
>> 
> Looks like the same file I have:
>
>> ll /usr/bin/nc
>>
> -rwxr-xr-x+ 1 24576 Mar 19  2013 /usr/bin/nc*
>
> I'm not sure your file command is referencing the same file,
> since my ls shows the same size and date as yours, and clearly
> both show read+execute for U,G and other and write only for owner.
>
> I looked at the make file, it seems to be o.k. for generating a
>>> runable program.  (uses gcc) but I don't have enough stuff installed
>>> to allow a build.
>>>
>> ---
>I think something is wrong with your 'file' command.  My nc-binary
> didn't come with a makefile (only binary & manpage):
>
>> cygcheck -l nc
>>
> /usr/bin/nc.exe
> /usr/share/man/man1/nc.1.gz
>
>
> --
> 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

Problem with NC.1.107

[Jay Cotton]

 Just installed nc 1.107-4  expecting to use it to debug some code.

This is what I get when I try to run it.
$ nc 192.168.1.135 23
bash: /usr/bin/nc: Permission denied


The file permissions are messed up.

$ file /usr/bin/nc
/usr/bin/nc: writable, executable, regular file, no read permission

I don't see the PE32+ executable (console) x86-64, for MS Windows
string.


here is the file in /usr/bin
$ ls -l nc*
-rwxr-xr-x 1 lbmgm lbmgm 24576 Mar 19  2013 nc.exe

I looked at the make file, it seems to be o.k. for generating a
runable program.  (uses gcc) but I don't have enough stuff installed
to allow a build.

--
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

fast/native fork?

[Jay K]

I have some desire to discuss fork.
I know it is an old and difficult topic.


I found this:

 "Cygwin fork and RtlCloneUserProcess"
 
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues



NT has had fork since v1.
The Posix subsystem used it.

You didn't need Vista's introduction of RtlCloneUserProcess.

This from 2005 alludes to how to make it work:
  https://www.winvistatips.com/threads/question-about-ntcreateprocess.186504/

but I have difficult questions for you -- anyone, but including Corinna.

What do you expect it to do?


I mean, consider that there is no pthread_atfork or an analog in Win32.
 
Dlls at all levels of the Win32 stack, might have
process-specific state, that needs to be reinitialized.
Maybe they were holding locks in a worker thread.
Maybe they had the pid cached. Dumb, but it works w/o fork.
The usual problems that pthread_atfork is meant to solve.
 
Which memory do you expect to be inherited copy on write, and which
memory do you expect to revert to whatever it is when a process starts (or a
dll is loaded)?

You could hope for something like calling DllMain(process attach) of all the
dlls could help, but it can't, at least because dlls just depend on the
default data in the image, they don't write the defaults to memory
at every load.


ntdll.dll is special. It somehow knows fork occured and can reinitialize itself.
ntdll.dll is special -- it used by the Posix subsystems (SFU/SUA/Interix/etc.) 
and always had to work with fork.
  (Up until Windows 10 and changes for WSL, ntdll.dll was loaded into
  all usermode processes: Win32, Posix, OS/2. This was specifically
  changed for WSL.)


But no other dll expects this.

  
Now, I have some wierd ideas. Let's brainstorm a little?


Can you somehow leave the child process in limbo waiting for exec, know
when you have waited too long (because *anything* else happened) and only
then do the expensive copying?

Or there is the very problem of getting to the exec call and having the exec 
parameters?

I mean, what if you actually knew 100% that exec would come very soon after 
fork?
 What would/could you do then?

 
And when exec does not follow, what do you do?
How much of the child process is inherited from the parent, vs. how much
is reinitialized such as for a new process?

If there a solution that optimizes the guaranteed to exec case,
can you almost just assume it? Breaking the rare (?) program that does not exec?
You could even omit fork.
You'd have fork_slow and fork_before_exec.
People would have to ifdef Cygwin and chose what they want.
Or the default could be fork_before_exec, breaking a small number
of programs, that could be easily ported.


Ok, how about this?
Can you implement exec using only ntdll.dll, avoiding kernel32.dll?
 And the small/zero number of other things valid/used between fork and exec?
And assume exec follows fork?
If so then that is a solution:
 learn how to use native fork
 and have exec only use ntdll.dll
 
 That will give you a fast fork + exec sequence.
 
 Or, can you in the new process, just reinitialize kernel32.dll and 
kernelbase.dll,
 and only use them for exec?
 
 
It doesn't do anything for fork without exec but I still don't understand
how that is supposed to work in Win32.
 
 
 Or how about this:
 Again, if you assume exec is coming, and you just need fork 
 to do the minimum -- basically to get a pid.
 
 fork calls CreateProcess, with a helper .exe, suspended
 fork calls CreateThread, passing it the register context of the creating thread
 the helper thread suspends the creating thread, and takes over its
 register context (including rip and rsp, approximately), shortly thereafter
 the helper thread in the creating process reaches exec.
 
 At this point, somehow, it adjusts everything..hand waving.
 
 How do you implement exec today? Does fork actually get the pid
 of the new child, and exec in the child somehow "replaces" the executable, or
 does exec create a second child, with another pid, and the original
 child just waits for it, and returns its exit code as its own?
 
 Or do you have indirection on pids, and cygwin pids are not win32 pids?
 
Oh, that's right, setjmp/longjmp.
fork calls setjmp in the parent.
The first return continues until exec in the parent and then
returns the new pid the second time?
  Given an arrival at exec, in the parent instead of the child,
  the usual child part of fork need never run at all.


To repeat: To what extent, if any, can we assume exec follows fork?
And what can be done with this idea?
I understand the more general model, where exec does not follow fork.
But how common is it? How would Cygwin fair if by default fork+exec
was fast, fork w/o exec didn't work, and people ported those somehow?


Fyi:  
 https://mikeash.com/pyblog/friday-qa-2012-01-20-fork-safety.html
 
 
 - Jay

--
Problem reports:

'whois' no longer following referrals ?

[Jay Libove]

Once upon a time, the UNIX/cygwin ‘whois’ program would follow referrals. So, 
you could ask, for nearly any domain, ‘whois name.domain’ and whois would first 
find out which whois server could answer the question, and then would query 
that whois server and get the answer.
Lately (months? more?), it doesn’t do this anymore ☹

Example below.

There’s even an option (still) in whois to NOT follow referrals ("-rturn 
off recursive look-ups for contact information").

Now, we need to manually run a second whois, using the -h HOST option, 
supplying it the output of the initial whois command's "Registrar WHOIS Server" 
field.

Is this Just The way It Is now? Or is there an option I'm missing - or a 
replacement whois program - which still does the recursion automatically?

(I'm on Windows 10 64-bit, "Creators" update, with Cygwin installer 2.881 
64-bit, whois package version 5.2.10-1).

thanks,
Jay


C:> WHOIS google.com
   Domain Name: GOOGLE.COM
   Registry Domain ID: 2138514_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2011-07-20T16:55:31Z
   Creation Date: 1997-09-15T04:00:00Z
   Registry Expiry Date: 2020-09-14T04:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: abusecomplai...@markmonitor.com
   Registrar Abuse Contact Phone: +1.2083895740
   Domain Status: clientDeleteProhibited 
https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited 
https://icann.org/epp#clientUpdateProhibited
   Domain Status: serverDeleteProhibited 
https://icann.org/epp#serverDeleteProhibited
   Domain Status: serverTransferProhibited 
https://icann.org/epp#serverTransferProhibited
   Domain Status: serverUpdateProhibited 
https://icann.org/epp#serverUpdateProhibited
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-08-24T10:39:53Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

install of whois reported error - update-desktop-database - update-desktop-database

[Jay Eichelberger]

Greetings!

I had a problem installing whois.  whois was installed but there was 
an error message..


The setup.log.full says:
-snipped--
2013/05/28 02:17:40 running: C:\cygwin\bin\bash.exe --norc --noprofile 
/etc/postinstall/cygutils.sh
/etc/postinstall/cygutils.sh: line 1: /usr/bin/update-desktop-database: 
No such file or directory
/etc/postinstall/cygutils.sh: line 2: /usr/bin/update-mime-database: No 
such file or directory

2013/05/28 02:17:40 abnormal exit: exit code=127
2013/05/28 02:17:40 Changing gid to Administrators
2013/05/28 02:18:13 note: Installation Complete
2013/05/28 02:18:13 Ending cygwin install

limited debug:
1) /etc/postinstall/cygutils.sh   -- file does exist and permissions OK
2) Contents of /etc/postinstall/cygutils.sh:

$ cat cygutils.sh
/usr/bin/update-desktop-database
/usr/bin/update-mime-database /usr/share/mime

3) but
  /usr/bin/update-desktop-database  -- does not exist
  (( there is a 'updatedb', though.)
  and
  /usr/bin/update-mime-database-- does not exist

other:
 setup.exe version 2.774
 http%3a%2f%2fmirrors.xmission.com%2fcygwin%2f

Thank you !!
Jay



--
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

XIO: fatal IO error 108 (Socket operation on non-socket) on X server :0

[Jay F Shachter]

I have little experience with Cygwin, since I normally do not use
Microsoft operating systems; but it is precisely for that reason that
I do install cygwin whenever I have to work on a Microsoft system --
for example, when I remove the viruses (Malwarebytes, as per a
friend's recommendation) from someone else's Windows XP laptop, which
I have been doing for the past couple of days, not because I know
anything about Windows, but because I know more than anyone else
around here.

Anyway, the viruses are all gone now, but it was a fair amount of
work, and in order to make the experience even remotely tolerable, I
installed Cygwin on this laptop, which is my reward, to myself, for
having done this fellow a favor.  But I am encountering a curious
error.  The xinit command creates a root window, but then after a
minute, or maybe less, the root window disappears and the command
exits with the error message, inter alia,

 XIO:  fatal IO error 108 (Socket operation on non-socket) on X server :0
   after 7 requests (7 known processed) with 0 events remaining.
 winClipboardproc - XOpenDisplay() returned and successfully opened the display

 waiting for X server to shut down

There is more, but you get the idea.

Since I almost never use Cygwin, I have little notion of what may be
wrong (when I have used Cygwin in the past, I never saw this error
message), but if you can diagnose this problem from where you are
sitting, or if you can give me a workaround even without diagnosing
the problem, please do me the kindness of telling me what to do.  I do
not normally read this mailing list (an understatement, I never read
this mailing list), but you may contact me using any of the means
indicated below.  Thank you in advance for any and all replies to this
inquiry.


Jay F. Shachter
6424 N Whipple St
Chicago IL  60645-4111
(1-773)7613784  landline
(1-410)9964737  GoogleVoice
j...@m5.chicago.il.us

Quidquid latine dictum sit, altum videtur

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

rcs 5.8-1 corrupt files?

[Jay E.]

rcs 5.8-1
A problem with rcs. - corrupt files..
Here is the sequence:
  Create a 'hello world' file using vi.
  Check in a file.
 ci -u sam
  Check out the file
 co -l sam

get error when doing rlog on the next ci of the file.

example:

rlog sam
   
rlog: RCS/sam,v:31: junk at end of file: 't'

rlog aborted


Here is a hex dump of sam
$ od -cx sam
000   h   e   l   l   o   w   o   r   l   d   .  \r  \n  \r  \n
  65686c6c206f6f776c722e640a0d0a0d
020  \r  \n  \r  \n  \r  \n
  0a0d0a0d0a0d
026


Here is a hex dump of the rcs file:

$ od -cx rcs/sam,v
000   h   e   a   d  \t   1   .   1   ;  \r  \n   a   c   c   e   s
  656864613109312e0d3b610a63637365
020   s   ;  \r  \n   s   y   m   b   o   l   s   ;  \r  \n   l   o
  3b730a0d7973626d6c6f3b730a0d6f6c
040   c   k   s  \r  \n  \t   j   a   y   :   1   .   1   ;   s
  6b630d73090a616a3a792e313b317320
060   t   r   i   c   t   ;  \r  \n   c   o   m   m   e   n   t  \t
  727463693b740a0d6f636d6d6e650974
100   @   #   @   ;  \r  \n  \r  \n  \r  \n   1   .   1  \r  \n
  234040200d3b0d0a0d0a310a312e0a0d
120   d   a   t   e  \t   2   0   1   1   .   1   2   .   1   1   .
  61646574320931302e313231312e2e31
140   0   3   .   4   6   .   3   3   ;  \t   a   u   t   h   o   r
  3330342e2e36093b75616874726f
160   j   a   y   ;  \t   s   t   a   t   e   E   x   p   ;
  6a207961093b74737461206578453b70
200  \r  \n   b   r   a   n   c   h   e   s   ;  \r  \n   n   e   x
  0a0d72626e61686373650d3b6e0a7865
220   t  \t   ;  \r  \n  \r  \n  \r  \n   d   e   s   c  \r  \n   @
  09740d3b0d0a0d0a640a73650d63400a
240   h   e   l   l   o  \r  \n   @  \r  \n  \r  \n  \r  \n   1   .
  65686c6c0d6f400a0a0d0a0d0a0d2e31
260   1  \r  \n   l   o   g  \r  \n   @   I   n   i   t   i   a   l
  0d316c0a676f0a0d4940696e69746c61
300   r   e   v   i   s   i   o   n  \r  \n   @  \r  \n   t   e
  7220766573696f690d6e400a0a0d6574
320   x   t  \r  \n   @   h   e   l   l   o   w   o   r   l   d
  74780a0d68406c656f6c7720726f646c
340   .  \r  \n  \r  \n  \r  \n  \r  \n  \r  \n   @  \r  \n   t  \r
  0d2e0d0a0d0a0d0a0d0a400a0a0d0d74
360  \r  \n   @   h   e   l   l   o   w   o   r   l   d   .  \r
  0a0d68406c656f6c7720726f646c0d2e
400  \r  \n  \r  \r  \n  \r  \r  \n  \r  \r  \n  \r  \r  \n   @  \r
  0a0d0d0d0d0a0a0d0d0d0d0a0a0d0d40
420  \r  \n
  0a0d
422


---

problem also exists if you add a line, then try to check in.

$ vi sam


$ ci -u sam

ci: RCS/sam,v:31: junk at end of file: 't'
ci aborted


---
Suspected line-ender problem.
Started over and used 'flip' to go with unix line-ender.
Same problems.
BUT it looks like the DOS lime ender was added after the flip by ci, or co.



$ vi henry


$ flip -u henry


$ od -cx henry
000   W   h   a   t   s   u   p   ?  \n  \n
  68577461207370750a3f000a
013


$ ci -u henry
RCS/henry,v  --  henry
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!

Did a flip before ci.
.

initial revision: 1.1
done


$ co -l henry
RCS/henry,v  --  henry
revision 1.1 (locked)
done


$ od -cx henry
000   W   h   a   t   s   u   p   ?  \r  \n  \r  \n
  68577461207370750d3f0d0a000a
015


--
Promlem is still there.
$ rlog henry

rlog: RCS/henry,v:28: junk at end of file: '@'
rlog aborted


---
I have saved off my home directory.
Deleted Both the cygwin and the download directories.
Reinstalled from a different mirror.
reloaded my home.
Still problem.
I found that flip -u does better job than dos2unix.
-

reverting back to 5.7-11 of rcs bypasses problem.
T H A N K S,
Jay

PS

The cygcheck.out file will show that I reverted back to an older rcs.




cygcheck.out
Description: Binary data
--
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: Title bar of X apps, no host name?

[Jay Goldman]

You can put what you want in the title by setting PROMPT_COMMAND - e.g., set 
PROMPT_COMMAND=setWindowTitle $(uname -n)

where setWindowTitle is a shell script like:
echo -ne \e]2;$*\a

by putting it in the PROMPT_COMMAND you handle the case where some command sets 
the window title while it is processing (I do this to provide feedback for long 
running scripts without filling up the screen). Once the command finishes the 
window title gets set back to your desired value.

Btw, I use different foreground/background color combinations to distinguish 
between xterms on different machines - 
some of the color combinations are ugly but they are different :-)


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

Re: Solution to using different usernames

[Jay Adams]

I was able to achieve the desired result without modifiying /etc/passwd.
What I did was expand /etc/profile.d/user.sh to:
# use Windows's USERNAME variable
USER=$USERNAME
export USER

HOME=/home/$USER
export HOME

Next I zeroed out /etc/passwd so it was a blank file. Combine these
together and SSH now found the right user. I did some testing, it turns
out that you don't really have to expand /etc/profile.d/user.sh. I think
if Cygwin doesn't get what it wants from /etc/passwd it moves to check
somewhere else. Also, I was told this might cause problems when changing
user; I've never had to change users so I don't know how to test for it.

--
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: Solution to using different usernames

[Jay Adams]

Shouldn't there be a tool in Cygwin that will give you the SID? After
all, it does have to read it too! I do like Sys Internals, but they add
regkeys which I don't like. Also, isn't setting the SID a bit static?
What would happen if I wanted to change usernames again? So I ask, is
there a way to dynamically change the value in /etc/passwd similar to
what I did with /etc/profile.d/user.sh?

--
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

Solution to using different usernames

[Jay Adams]

My friend, Jeremy Bopp, let me know that if I use /etc/profile.d I could
still get updates for /etc/profile unlike when you edit it directly
(comment out USER=`id -un`). I had to think of a way to change $USER
from a different file so I came up with:
/etc/profile.d/user.sh
# use Windows's USERNAME variable
USER=$USERNAME
export USER

/cygwin.bat
...
rem strip trailing slash on directory paths
set dp=%~dp0
if %dp:~-1% equ \ (
 set dp=%dp:~0,-1%
)
...
set USERNAME=[username]
set HOME=%dp%\home\%USERNAME%
...

I made the USER variable use the Windows variable USERNAME (standard
variable). From there I could change the USERNAME variable simply by
setting to what I like. I included the HOME variable in my code snippet.
I don't know if editting /etc/passwd will have the same behaviour as
editting /etc/profile and I don't know if /etc/passwd will change if I
take my Cygwin install to another computer. The main need for this hack
was that I use Cygwin from a USB and the default behaviour of Cygwin is
to use the currently logged in user which would mean I would have tons
of different profiles.

I thought this maybe useful for others to know so I decided to post
here. Also, if anybody has suggestions please let me and everybody know.

P.S. Still doesn't seem to work for SSH (ssh [user_to_use]@[machine]).
Maybe problem with SSH?

--
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: upper limit to df reported available size?

[Jay K]

   I guess what we really need
  is to redefine fsblkcnt_t to become a 64 bit type. Oh well, this
  requires another backward compatibility hack, just like back when we
  switched to 64 bit off_t (Cygwin 1.5). Let's do it at the same time as
  we change sigset_t and time_t to 64-bits(with knock-on effects to
  struct stat, among others). In other words,all good changes, but certainly
  something that will take a lot ofplanning to pull off in one go.
 
 
Can you fix the jmp_buf size then too maybe?
It is blown up by a factor of 4.
http://sourceware.org/ml/cygwin/2009-01/msg00863.html
 
I realize it has less/no value to fixing.
But I'm not sure how changing the others won't require *everything*
(just about) to be recompiled anyway. Maybe you rename functions somehow?
 
 
Thanks,
 - Jay

  

--
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

control key stops working

[Jay Foad]

Hi,

I'm using emacs in console mode in Cygwin 1.7 on Windows 7 Ultimate.
Every so often I do something, or something happens, that stop my
Control key from working the way I expect. Even if I exit emacs, the
Control key is still behaving strangely at my bash prompt. The only
way I've found to fix it is to close the Cygwin window and start a new
one.

Normal behaviour: Ctrl-A goes to start of line, Ctrl-E goes to end of line, etc.

Weird behaviour: Ctrl-A, Ctrl-B, Ctrl-D, Ctrl-E and loads of others
just print a single question-mark. Ctrl-C seems to work normally. Some
other Ctrl-letter combinations print other funny characters.

Any idea what's going on, what causes it, and/or how I can fix it?
(Google didn't help me, but then I wasn't really sure what to Google
for.)

$ uname -a
CYGWIN_NT-6.1-WOW64 Jay-Foad-W7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin

Thanks,
Jay.

--
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

Problems using XWin with remote desktop with latest version

[Jay Goldman]

I have the following batch file to start xwin:
@echo off
SET CYGWIN_ROOT=
SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin
SET PATH=.;%CYGWIN_ROOT%\bin;%PATH%

SET XAPPLRESDIR=
SET XCMSDB=
SET XKEYSYMDB=
SET XNLSPATH=

%RUN% XWin -multiwindow -clipboard -silent-dup-error
IF EXIST %CYGWIN_ROOT%\bin\urxvtd-X.exe  %RUN% 
%CYGWIN_ROOT%\bin\urxvtd-X.exe

This works fine (and has been for a while year).

Occasionally, I have to connect to my machine via windows remote desktop.
I've also been doing this for a while.

With the latest version of x-windows; however, when I do so XWin.exe seg 
faults. 
I then kill the urxvtd-X.exe process, re-run my batch script, and all is well 
within the remote desktop session.

Then I close the remote desktop session, and when I get back to my machine the 
x-windows-based command windows are no longer functional.  I close down 
Xwin.exe (and urxvtd-X.exe), restart them, and I'm ok again.

Any ideas as to what has changed to cause these new issues, 
(a) XWin.exe seg fault due to remote desktop connection (sorry, I don't have 
the seg fault info)
(b) X-windows based command windows, (i.e., windows started with: urxvtc -g 
80x42 -e /bin/bash -l -i) no longer display correctly when I disconnect the 
remote desktop session - I have to 're-start' xwin.exe (and urxvtd-X.exe) 
processes.




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

RE: X Server no longer launches urxvtc-X

[Jay Goldman]

Thanks Bob,
this eliminates the '/bin/find' error when starting rxvt or urxvt.
I just added
cd / 
before the PATH= line.

Still cannot run urxvtc from X server tray app.

 -Original Message-
 From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-
 ow...@cygwin.com] On Behalf Of Rob Gillen
 Sent: Tuesday, August 24, 2010 4:27 PM
 To: cygwin-xfree@cygwin.com
 Subject: RE: X Server no longer launches urxvtc-X
 
  Another data point, when I try:
  black  EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g
 80x40 -e /bin/bash -l -i 
  rxvt successfully starts up but displays:
  /bin/find: failed to restore initial working directory: No such
 file or directory
  Before .bash_profile is invoked
 
 Jay, I resolved the find issue by modifying the /etc/profile file.
 The real issue is the change made in the latest release of the
 cygwin1.dll where the current working directory is set to an invalid
 directory.  Until you set the current working directory to something
 when find is called, you'll continue to see this.  Try moving this
 portion of the /etc/profile script:
 
 # Make sure we start in home unless invoked by CHERE
 if [ ! -z ${CHERE_INVOKING} ]; then
   unset CHERE_INVOKING
 else
   cd ${HOME}
 fi
 
 so that it is located before the execution of all the /etc/profile.d
 scripts.
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Problem reports:   http://cygwin.com/problems.html
 Documentation: http://x.cygwin.com/docs/
 FAQ:   http://x.cygwin.com/docs/faq/


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

RE: X Server no longer launches urxvtc-X

[Jay Goldman]

More data points:
Both 'rxvt' and 'urxvt' work from my .XWinrc, except that I get the '/bin/find: 
failed to restore initial working directory: No such file or directory' message.
But 'urxvtc' does not. 
My .XWinrc entries are:
rxvtexecrxvt   -fg green -bg black-cr dodgerblue -g 80x40
urxvt   execurxvt  -fg white -bg darkblue -cr dodgerblue -g 80x42 -e 
/bin/bash -l -i
urxvtc  execurxvtc -fg white -bg darkblue -cr dodgerblue -g 80x42 -e 
/bin/bash -l -i

however, within windows created using either rxvt or urxvt I can then execute 
urxvtc commands successfully.
Thus the daemon is running, here is ps output:
jgoldman5068   1   ?Aug 20 /usr/bin/XWin
jgoldman8156   1 conAug 20 /usr/bin/urxvtd-X

So, there seems to be some issue with running 'urxvtc' or urxvtc's ability to 
contact the daemon from within the XWindows server. Is there any logging that I 
can enable?

 -Original Message-
 From: Jay Goldman
 Sent: Friday, August 20, 2010 3:59 PM
 To: cygwin-xfree@cygwin.com
 Subject: RE: X Server no longer launches urxvtc-X
 
 When I just replace the cygwin1.dll bash,
   \bin\bash.exe -login -i
 From cmd window results in:
   The procedure entry point CreateProcessAsUserW could not be
 located in the dynamic link library KERNEL32.dll
 
 I have no idea where find is being invoked when I execute rxvt, since
 it is invoked before .bash_profile is invoked.
 
  -Original Message-
  On August 20, 2010 3:06 PM, Corinna Vinschen wrote:
 
 
  Please dont top-post.
 
 
  On Aug 20 14:14, Jay Goldman wrote:
   Another data point, when I try:
 black  EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g
  80x40 -e /bin/bash -l -i 
   rxvt successfully starts up but displays:
 /bin/find: failed to restore initial working directory: No such
  file or directory
   Before .bash_profile is invoked
 
  Works for me without such a message.  Do you know from where find is
  called?
 
   -Original Message-
   From: Corinna Vinschen
   On Aug 20 10:54, Charles Wilson wrote:
On 8/20/2010 10:48 AM, Jay Goldman wrote:
I have the following menu items in my .XWinrc:
Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr
  dodgerblue -g 80x40 -e /bin/bash -l -I
dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr
 blue
  -g 80x42 -e /bin/bash -l -I

Which have been working for months .
 
  Doesn't work for me either, but has apparently nothing to do with
  the CWD issue.  This looks more like a rebase problem.
 
Note, menu items like:
 Xterm exec xterm
Work correctly,
While menu items such as:
 Notepad exec notepad
Do not.
 
  I tried this as well now, and both menu entries work for me.
 
  Maybe the difference is the Cygwin DLL.  Can you please try the
 latest
  Cygwin DLL from the developer snapshots at
 http://cygwin.com/snapshots/
  and report back if this works better for you?
 
 
  Thanks,
  Corinna
 
  --
  Corinna Vinschen  Please, send mails regarding Cygwin
  to
  Cygwin Project Co-Leader  cygwin AT cygwin DOT com
  Red Hat
 
  --
  Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
  Problem reports:   http://cygwin.com/problems.html
  Documentation: http://x.cygwin.com/docs/
  FAQ:   http://x.cygwin.com/docs/faq/

X Server no longer launches urxvtc-X

[Jay Goldman]

I have the following menu items in my .XWinrc:
   Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr dodgerblue -g 80x40 
-e /bin/bash -l -I
   dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr blue -g 80x42 -e 
/bin/bash -l -I

Which have been working for months .

Today I upgraded my cygwin install and all my menu items like the above no 
longer work.
(as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X
If, however, I open up a command window using rxvt and then enter the above 
Line (by copy and paste) it works fine. 

Note, menu items like:
    Xterm exec xterm
Work correctly, 
While menu items such as:
    Notepad exec notepad
Do not.
    

Does anyone know what has changed in cygwin and/or cygwinX that would cause 
this?
Could this be related to the change to the windows working directory?

TIA,
Jay


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

RE: X Server no longer launches urxvtc-X

[Jay Goldman]

Chuck - thanks for the reply. This is what I had concluded but it's nice to get 
some confirmation.
For the next few days I can live with 'manually' starting urxvtc-X via 
individual batch files.

Thanks,
Jay

-Original Message-
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On 
Behalf Of Charles Wilson
Sent: Friday, August 20, 2010 10:54 AM
To: cygwin-xfree@cygwin.com
Subject: Re: X Server no longer launches urxvtc-X

On 8/20/2010 10:48 AM, Jay Goldman wrote:
 I have the following menu items in my .XWinrc:
 Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr dodgerblue -g 
 80x40 -e /bin/bash -l -I
 dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr blue -g 80x42 
 -e /bin/bash -l -I

 Which have been working for months .

 Today I upgraded my cygwin install and all my menu items like the above no 
 longer work.
 (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X
 If, however, I open up a command window using rxvt and then enter the above
 Line (by copy and paste) it works fine.

My first guess was that the urxvt daemon (urxvtd-X) was not running, so 
the client failed. But if you can launch the client using some 
incantation, then that means the daemon is running.


 Note, menu items like:
  Xterm exec xterm
 Work correctly,
 While menu items such as:
  Notepad exec notepad
 Do not.

Ah. Here's the clue: launching a native win32 program fails.  I bet this 
is related to the change in cygwin-1.7.6 where the cygwin current 
working directory and the win32 CWD are no longer automatically kept in 
sync (there are good reasons for this new behavior).

This change has caused a number of problems, and it is not yet clear how 
they will be resolved.  Stay tuned to the main cygwin list -- and 
meanwhile, revert to cygwin-1.7.5.

--
Chuck

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


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

RE: X Server no longer launches urxvtc-X

[Jay Goldman]

Another data point, when I try:
black  EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g 80x40 -e 
/bin/bash -l -i 
rxvt successfully starts up but displays:
/bin/find: failed to restore initial working directory: No such file or 
directory
Before .bash_profile is invoked

-Original Message-
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On 
Behalf Of Corinna Vinschen
Sent: Friday, August 20, 2010 1:57 PM
To: cygwin-xfree@cygwin.com
Subject: Re: X Server no longer launches urxvtc-X

On Aug 20 10:54, Charles Wilson wrote:
 On 8/20/2010 10:48 AM, Jay Goldman wrote:
 I have the following menu items in my .XWinrc:
 Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr dodgerblue -g 
  80x40 -e /bin/bash -l -I
 dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr blue -g 80x42 
  -e /bin/bash -l -I
 
 Which have been working for months .
 
 Today I upgraded my cygwin install and all my menu items like the above no 
 longer work.
 (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X
 If, however, I open up a command window using rxvt and then enter the above
 Line (by copy and paste) it works fine.
 
 My first guess was that the urxvt daemon (urxvtd-X) was not running,
 so the client failed. But if you can launch the client using some
 incantation, then that means the daemon is running.
 
 
 Note, menu items like:
  Xterm exec xterm
 Work correctly,
 While menu items such as:
  Notepad exec notepad
 Do not.
 
 Ah. Here's the clue: launching a native win32 program fails.  I bet
 this is related to the change in cygwin-1.7.6 where the cygwin
 current working directory and the win32 CWD are no longer
 automatically kept in sync (there are good reasons for this new
 behavior).

Maybe that's related, but why?  Does urxvtc-X start applications using
CreateProcess?

I'm asking because if they are started via fork/exec, the cwd for the
child process gets set to the Cygwin cwd if the child is a native Win32
process, like Notepad.  Cygwin executables OTOH shouldn't be affected,
unless, again, they use native Win32 calls.

And that also doesn't answer the question why starting /bin/urxvtc-X in
the menu entries at the start of the mail are not working anymore, at
least unless /bin/urxvtc-X is not a Cygwin application.

 This change has caused a number of problems, and it is not yet clear
 how they will be resolved.

In the first place: http://cygwin.com/ml/cygwin/2010-08/msg00554.html
and http://cygwin.com/ml/cygwin/2010-08/msg00562.html


Corinna

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

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

RE: X Server no longer launches urxvtc-X

[Jay Goldman]

When I just replace the cygwin1.dll bash,
\bin\bash.exe -login -i
From cmd window results in:
The procedure entry point CreateProcessAsUserW could not be located in 
the dynamic link library KERNEL32.dll

I have no idea where find is being invoked when I execute rxvt, since it is 
invoked before .bash_profile is invoked.

 -Original Message-
 On August 20, 2010 3:06 PM, Corinna Vinschen wrote: 

 
 Please dont top-post.
 
 
 On Aug 20 14:14, Jay Goldman wrote:
  Another data point, when I try:
  black  EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g
 80x40 -e /bin/bash -l -i 
  rxvt successfully starts up but displays:
  /bin/find: failed to restore initial working directory: No such
 file or directory
  Before .bash_profile is invoked
 
 Works for me without such a message.  Do you know from where find is
 called?
 
  -Original Message-
  From: Corinna Vinschen
  On Aug 20 10:54, Charles Wilson wrote:
   On 8/20/2010 10:48 AM, Jay Goldman wrote:
   I have the following menu items in my .XWinrc:
   Black EXEC  /bin/urxvtc-X -fg green -bg black   -cr
 dodgerblue -g 80x40 -e /bin/bash -l -I
   dodger EXEC  urxvtc-X -fg white -bg dodgerblue   -cr blue
 -g 80x42 -e /bin/bash -l -I
   
   Which have been working for months .
 
 Doesn't work for me either, but has apparently nothing to do with
 the CWD issue.  This looks more like a rebase problem.
 
   Note, menu items like:
Xterm exec xterm
   Work correctly,
   While menu items such as:
Notepad exec notepad
   Do not.
 
 I tried this as well now, and both menu entries work for me.
 
 Maybe the difference is the Cygwin DLL.  Can you please try the latest
 Cygwin DLL from the developer snapshots at http://cygwin.com/snapshots/
 and report back if this works better for you?
 
 
 Thanks,
 Corinna
 
 --
 Corinna Vinschen  Please, send mails regarding Cygwin
 to
 Cygwin Project Co-Leader  cygwin AT cygwin DOT com
 Red Hat
 
 --
 Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
 Problem reports:   http://cygwin.com/problems.html
 Documentation: http://x.cygwin.com/docs/
 FAQ:   http://x.cygwin.com/docs/faq/

RE: resolving _glgetstr...@4 by linking to _glGetString

[Jay K]

   Not so much of an issue any more (still a bit curious about it, but). I 
soon 
   found that providing a '-lopengl32' link instead of 
   '/cygdrive/c/Windows/System32/opengl32.dll' fixed the problem. 


Linking to /cygdrive/c/windows/system32/whatever is never right.


It is not easy to explain this though.


In the Unix model, the headers and libraries come with the operating system.
  /usr/include, /lib, /usr/lib, etc.


In the Windows model, they come separately with the compiler or a 
development kit.


The Unix model advantages:
   system is self describing 
   smaller: no separate import libraries, just the dynamic libraries 


The Windows model advantages:
  Sort of more amenable to cross builds. Including targeting an older or newer 
OS release.


I say sort of because, like, adding additional headers and libraries doesn't 
change the model.
In the Unix model, any headers/libraries apart from the OS are sort of 
following a different model,
where in the Windows model, they are all following the same model.


This isn't the Unix or Windows model really, it is just how things tend to 
be done on those systems.
If you look at Mac OS X development systems, they are closer to Windows.
If you have ever used sysroot with gcc, well, that is like Windows then.


Personally I prefer the Windows model.
And Cygwin follows it, because, well, again, the main difference is if the 
operating system
contains the headers/libraries needed. Cygwin can be as Gnuy/Linuxy/Posixy as 
it wants, but
the operating system doesn't contain the files it needs, so it includes them.


Now, there is something funny to this term libraries.
You know, modern systems are heavily dynamically linked, and the information 
needed
by the dynamic linker and the static linker is similar/same, in particular 
for the static linker
to build an executable or library that references symbols dynamically.
The main information is just a list of function names.
 Sometimes what library contains what function, depending on the system and 
compiler/linker flags.
 

Thus it becomes reasonable seeming to point at the running code for 
libraries, instead
of some separate libraries, sometimes called stub libraries or import 
libraries, etc.
 (These import libraries basically just contain lists of function names, no 
actual code;
  older forms of them do contain a jmp per function, but that hardly counts.)


Now, then, what is the difference between the file -lopengl32 found, vs. 
/cygdrive/c/windows/system32/opengl32.dll?


Well, Windows on x86 does have something uniquely slightly bad about it: There 
are multiple calling conventions.
And the different calling conventions lead to a form of name mangling, even 
in C code.


There are generally three calling conventions.
Though some compilers let you declare custom ones, e.g. I believe gcc and 
OpenWatcom.
As well the compiler can create custom calling conventions for static 
functions. That is a different more general point and
  true on many systems.


Anyway, the three usual Windows/x86 calling conventions are stdcall, cdecl, 
fastcall.


cdecl is usually the default.
Parameters passed on the stack, right to left, callER pops, function Foo is 
mangled to _Foo.


stdcall is heavily used.
Parameters passed on the stack, right to left, callEE pops, function Foo is 
mangled to _...@n
where N is the decimal number of bytes of parameters, e.g. 0, 4, 8, 16, etc.


fastcall I don't know entirely, but roughly speaking, it passes the first 8 
bytes of parameters in ecx, edx,
right to left, the rest on the stack, callEE pops, Foo becomes _...@foo@N.


cdecl is needed for varargs i.e. printf, because caller pops.
stdcall is smaller/faster because callee pops.


Now, I said stdcall is heavily used.
Almost all public Windows functions (aka APIs) are stdcall.


So instead of generating a reference to  _glGetString, the compiler generates 
a reference to  _glgetstr...@4.


However presumably because it looks nicer or maybe for consistency with the 
other architectures, the exported
names are not mangled (or decorated).
(other architectures: NT on MIPS, Alpha, PowerPC, IA64, AMD64, only one 
calling convention each)


If you run link -dump -exports %windir%\system32\opengl32.dll, you'll see plain 
glGetString.
 There is no clear indication in the .dll that glGetString takes 4 bytes of 
parameters (maybe if you disassemble it...)


The file -lopengl32 found though, contains some stuff in it with both strings 
_glgetstr...@4 and glGetString.
The first is what symbol the linker should resolve against, the second is what 
it should stuck in the special data in the
file it is outputing.


Make sense?


(To repeat, I think distributing headers/libraries separate is good, but having 
multiple calling conventions is clearly mixed/bad.)


 - Jay
  

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http

RE: Cygwin Maximum Memory Documentation

[Jay K]

On 64bit systems, /largeaddressaware gives 32bit processes 4GB of address 
space, and no need to boot with a special option (well, other than using a 
64bit OS!).
 
search for largeaddressaware:
  http://blogs.msdn.com/oldnewthing/archive/2005/06/01/423817.aspx
 
 - Jay



Cygwin Maximum Memory Documentation
162246 by: Rob Donovan 


--Forwarded Message Attachment--
Date: Tue, 27 Apr 2010 12:32:39 -0700
From: hikerman2005...@
To: cygwin@
Subject: Cygwin Maximum Memory Documentation
  

--
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.1: probelms with git

[Jay Heaslip]

Some of the git commands don't seem work.  I able to init a git 
repository and check in changes, but commands like git log  git 
diff are not working.
When I try to run them, they just return to the shell prompt without any 
output.  Has anyone else seen this?


Thanks,
Jay


--
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.1: probelms with git

[Jay Heaslip]

After setting GIT_TRACE to1, I get the following when running git log:

trace: run_command: 'sh' '-c' 'less'
trace: exec 'sh' failed: No such file or directory

I've attached my cygcheck output.

Thanks,
Jay



Cygwin Configuration Diagnostics
Current System Time: Mon Jan 11 11:00:38 2010

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

Path:   C:\Program Files\MySQL\MySQL\MySQL Server 5.1\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\IBM\Infoprint Select
C:\Notes
C:\Program Files\XLView
C:\lotus\compnent
C:\Utilities
C:\Program Files\Common Files\Lenovo
C:\program files\ibm\personal communications\
C:\Program Files\IBM\Trace Facility\
C:\Program Files\Intel\WiFi\bin\
C:\Program Files\ThinkPad\ConnectUtilities
C:\Program Files\QuickTime\QTSystem
C:\Program Files\MySQL\MySQL Server 5.0\bin

Output from C:\cygwin\bin\id.exe
UID: 500(Jay)   GID: 513(None)
0(root) 513(None)   544(Administrators) 545(Users)

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

USER = 'Jay'
PWD = '/cygdrive/c/gittest'
HOME = '/home/Jay'

tvdebugflags = '0x260'
HOMEPATH = '\Documents and Settings\Administrator'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\Administrator\Application Data'
HOSTNAME = 'IBM-44B291789AB'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 10, GenuineIntel'
WINDIR = 'C:\WINDOWS'
TVT = 'C:\Program Files\Lenovo'
OLDPWD = '/home/Jay'
USERDOMAIN = 'IBM-44B291789AB'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
QTJAVA = 'C:\Program Files\IBM\Java50\jre\lib\ext\QTJava.zip'
USERNAME = 'Jay'
PROCESSOR_LEVEL = '6'
com.adobe.versioncue.client.applocale = 'en_US'
PCOMM_Root = 'C:\program files\ibm\personal communications\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
LANG = 'C.UTF-8'
USERPROFILE = 'C:\Documents and Settings\Administrator'
tvlogsessioncount = '5000'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
PD_SOCKET = '6874'
LOGONSERVER = '\\IBM-44B291789AB'
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/ADMINI~1/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PDBASE = 'C:\Program Files\IBM\Infoprint Select'
PRINTER = 'usbtvlfq-H0820/BSC-02-862-Burlington'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '170a'
com.adobe.versioncue.client.appname = 'AdobeDrive'
CLASSPATH = '.;C:\Program Files\IBM\Java50\jre\lib\ext\QTJava.zip'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '2'
com.adobe.versioncue.client.appversion = '1.0.0'
SESSIONNAME = 'Console'
COMPUTERNAME = 'IBM-44B291789AB'
SonicCentral = 'C:\Program Files\Common Files\Sonic Shared\Sonic Central\'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Console\Cygwin
  (default) = 0x000f
  PopupColors = 0x00f5
  ColorTable00 = 0x
  ColorTable01 = 0x0080
  ColorTable02 = 0x8000
  ColorTable03 = 0x00808000
  ColorTable04 = 0x0080
  ColorTable05 = 0x00800080
  ColorTable06 = 0x8080
  ColorTable07 = 0x00c0c0c0
  ColorTable08 = 0x00808080
  ColorTable09 = 0x00ff
  ColorTable10 = 0xff00
  ColorTable11 = 0x0000
  ColorTable12 = 0x00ff
  ColorTable13 = 0x00ff00ff
  ColorTable14 = 0x
  ColorTable15 = 0x00ff
  InsertMode = 0x0001
  QuickEdit = 0x0001
  FullScreen = 0x
  ScreenBufferSize = 0x04b00078
  WindowSize = 0x00280078
  FontSize = 0x000c
  FontFamily = 0x0036
  FontWeight = 0x0190
  FaceName = 'L'
  CursorSize = 0x0019
  HistoryBufferSize = 0x0032
  NumberOfHistoryBuffers = 0x0004
  HistoryNoDup = 0x0001
HKEY_CURRENT_USER\Console\Cygwin Bash Shell
  (default) = 0x0007
  PopupColors = 0x00f5
  ColorTable00 = 0x
  ColorTable01 = 0x0080
  ColorTable02 = 0x8000
  ColorTable03 = 0x00808000
  ColorTable04 = 0x0080
  ColorTable05 = 0x00800080
  ColorTable06 = 0x8080
  ColorTable07 = 0x00c0c0c0
  ColorTable08 = 0x00808080
  ColorTable09 = 0x00ff
  ColorTable10 = 0xff00
  ColorTable11 = 0x0000
  ColorTable12 = 0x00ff
  ColorTable13 = 0x00ff00ff
  ColorTable14 = 0x
  ColorTable15 = 0x00ff
  InsertMode = 0x0001
  QuickEdit = 0x
  FullScreen = 0x
  ScreenBufferSize = 0x012c0050
  WindowSize = 0x00190050
  FontSize = 0x000c0008
  FontFamily = 0x0030
  FontWeight = 0x0190
  FaceName = 'Terminal'
  CursorSize = 0x0019
  HistoryBufferSize = 0x0032
  NumberOfHistoryBuffers

Re: 1.7.1: probelms with git

[Jay Heaslip]

On 01/11/10 11:43 AM, Christopher Faylor wrote:

On Mon, Jan 11, 2010 at 11:39:42AM -0500, Jay Heaslip wrote:
   

After setting GIT_TRACE to1, I get the following when running git log:

trace: run_command: 'sh' '-c' 'less'
trace: exec 'sh' failed: No such file or directory

I've attached my cygcheck output.
 

Wow, an epidemic.

See:  http://cygwin.com/ml/cygwin/2010-01/threads.html#00446
   


Not really, I started the thread. I was getting the list in digest mode 
and wasn't sure how to reply to a specific thread.


I solved my problem by copying bash.exe to sh.exe.  Should this have 
happened during the installation?


Jay


--
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: many spurious equals sign in xterm?

[Jay K]

Billy provided the (pointer to the) solution. Which was working for me to fix 
coincident problems.
Greg and misc had the same problem.
 
 
I'm again seeing quick edit in cmd not work well, took the battery out, still 
not working, maybe I really need to put it back?
 
 
 - Jay


 Date: Fri, 29 May 2009 20:47:39 -0700
 From: cgwalnut
 Subject: many spurious equals sign in xterm?
 To: jay



 Hi,
 I found your posting about cygwin at this link:
 http://www.cygwin.com/ml/cygwin-xfree/2009-01/msg00113.html

 I found a solution that worked for me discussed here:
 http://annoyances.org/exec/forum/winxp/1225339908

 It's silly, but popping the battery out of the laptop removed the issue, and 
 the FilterKeys discussion was dead-on.
 Just a suggestion if you haven't found one yet (I noticed there were no 
 replies in your thread - I first had this issue a few months ago and it took 
 until now to get it resolved).

 Good luck.


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

RE: running MS link.exe under Cygwin sshd?

[Jay K]

Friend also found freesshd works and will use that.
So 3 out of 4 sshd work, Cygwin sshd is the only one that doesn't.
 
 - Jay



[snip]
 

--
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: running MS link.exe under Cygwin sshd?

[Jay K]

 From: reply-to-list-only...@cygwin.com
 On 08/03/2009 12:11 AM, Jay K wrote:
 I found that Interix sshd and WinSSHD work ok here.
 So it is something specific to Cygwin.

 Are you talking about password or public key authentication? If the
 latter, Have you tried the LSA authentication package in Cygwin 1.7?


I don't know. I'll try to deciper that. Sounds complicated. In the meantime, 
friend is using freesshd.
 
 
Thanks Larry.
 
 - Jay

--
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: running MS link.exe under Cygwin sshd?

[Jay K]

I found that Interix sshd and WinSSHD work ok here.
So it is something specific to Cygwin.
 
 - Jay


 From: jay.kr...@cornell.edu
 To: cygwin@cygwin.com
 Subject: running MS link.exe under Cygwin sshd?
 Date: Sat, 1 Aug 2009 04:50:15 +


 http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/eb49be0b-2a8c-4d55-8791-17e3cb1364c1

 
 This issue is caused because cygwin does not implement a full login process. 
 It tries to impersonate, but it looks to me as if it does not make the 
 necessary call to LsaLogonUser. As a result, the wrong SID is in the token as 
 the primary user. According to filemon, the debug server calls into secur32, 
 which suggests that it is doing interpretive access control. It finds the 
 service's SID instead of the users SID in some slot in the token that it gets 
 via RPC, and then everything goes downhill from there.Why VS feels the need 
 to put the PDB access in a separate process under separate access rights is 
 very puzzling, but there it is.
 


 Bug in Cygwin sshd?


 - Jay


--
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

running MS link.exe under Cygwin sshd?

[Jay K]

http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/eb49be0b-2a8c-4d55-8791-17e3cb1364c1
 

This issue is caused because cygwin does not implement a full login process. It 
tries to impersonate, but it looks to me as if it does not make the necessary 
call to LsaLogonUser. As a result, the wrong SID is in the token as the primary 
user. According to filemon, the debug server calls into secur32, which suggests 
that it is doing interpretive access control. It finds the service's SID 
instead of the users SID in some slot in the token that it gets via RPC, and 
then everything goes downhill from there.Why VS feels the need to put the PDB 
access in a separate process under separate access rights is very puzzling, but 
there it is.

 
 
Bug in Cygwin sshd?
 
 
 - Jay
 

--
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

managing autoconf versions?

[Jay]

This is a little off topic.
 
How do people manage autoconf/automake versions?
 
 
In particular, I'm not doing my own work -- I could probably just install one 
recent version of everything and be ok.
 
 
Rather I'm wondering about submitting patches to other projects, some projects 
might use one set of versions, or another. Change configure.ac/Makefile.am or 
such and regenerate configure/Makefile.in or such, using a matching toolset 
version so that churn is only what is desired?
 
 
Is the solution to install to various custom prefix and tailor $PATH based on 
context? Or does one wrapper sniff the input or output and decide among the 
versions installed in a standard place?
You know, like, input/or output could say # use autoconf 1.2.3
and then /usr/bin/autoconf could delegate to /usr/bin/autoconf-1.2.3
or such?
 
Thanks,
- Jay

--
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/

1.5.25-Cygstart not showing visible window

[Jay Cross]

Hello,

It is my first time posting to this mailing list so I'd like to send
greetings to everyone. Hey!

First of all, I have RTFM'ed and googled and searched the mailing
list, etc. etc. all to no avail.

My Issue:

I'm having an problem with cygstart.  When I run a program with it in
a bash shell on my cygwin machine everything is fine. When I'm
accessing cygwin through another machine (using SSH through Putty) the
program window never appears regardless of how I specify command args.
 The program I specify is running in my Task Manager (Process
Explorer) but it has no visible window associated.  I can hear sounds
it makes.. but no window appears.

Is this a feature or a bug - or something in between?

I've tried changing the ownership of cygrunsrv, bash, and sshd.

This behavior also occurs when I run the script below.

I'm trying to run programs/files on my TV computer at the command of
my laptop computer.  It would be useful if they actually displayed on
TV computer.

I know I could use a VNC solution, but it's not really what I'm
looking for.  Cygstart seems like it is designed to do something
similar to what I want, am I asking to much?  Have I missed something?

Thanks in advance to anyone that can help.

Jay



Here's some info about my setup:

Windows XP SP2
CYGWIN 1.5.25
BASH 3.2
CYGSTART 1.4
OpenSSH_5.1p1
OpenSSL 0.9.8j 07 Jan 2009


a script I tried also to no avial:

# begin script 
#!/bin/bash

# Dan Martin converted this to bash and fixed the chmod's.
#
# Thanks Randal R Schulz and Stefan Leppert for basic clues.

fn=$1

# add execute permissions if there are none
isexe=1
[[ -x $fn ]] || { isexe=0 ; `chmod a+x $fn` ;}

win_fn=$(cygpath -w -a $1)

cmd /c $win_fn 

# We want to wait for the windows shell to execute the file before we
# turn off the exe bit.
sleep 1

# if isexe is 0, then we had to set the execute permissions, change back
((isexe)) || chmod a-x $fn
# end script 

--
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: console scroll speed on Win XP

[Jay]

 Andy 
 Yep, the Windows console is slow alright, and I don't know of any way 


Huh?
The windows console is fast, among the fastest
I have ever used, BUT you must have the video
 driver for your specific card.
If you just have the generic VGA driver, it is slow,
and other things are noticably too.

 
I haven't seen a faster graphical console, but text consoles are also fast.
 

Also being in bash seems slower.
I usually set PATH=c:\cygwin\bin;%PATH% but don't use bash interactively.
You might try that.
Being in cmd preserves the nice F8 command line completion against history 
feature
that I haven't found elsewhere.
 


 - Jay

--
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: jmp_buf size?

[Jay]

What is up with the size of jmp_buf?
It appears that setjmp.h confuses bytes and ints, specifically in the Cygwin 
case.
_JBLEN should be 13, not 13*4.
or #define _JBTYPE to char, but that doesn't work as easily.


?
 
 
I applied a local hack workaround, something like:
 
 
  typedef unsigned char JBTYPE __attribute(align(4));  
  #define _JBTYPE _JBTYPE 
  #include  
 
 
Though my larger goal, of implementing (deprecated-in-favor-of-pthreads) Posix 
get/make/set/swapcontext I gave up on anyway, at least via layering over 
setjmp/longjmp. They may be implementable via Win32 fibers, though the overall 
thing still perhaps dodgy and useless (user more threads...).
 
 
I realize that jmp_buf is something deep and system specific, not to be 
messed with lightly, but I'm also pretty darn certain that Cygwin declares its 
own jmp_buf incorrectly.
I also realize that larger than needed is safe, just wasteful, and possibly 
future proof.
It still seems like a mistake.
 

 - Jay

--
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: jmp_buf size?

[Jay]

Thanks, sorry, I didn't see that.
 
 
 - Jay



 Date: Wed, 4 Feb 2009 18:49:50 -0500
 From: reply-to-list-only...@cygwin.com
 To: cygwin@cygwin.com
 CC: jay.kr...@cornell.edu
 Subject: Re: jmp_buf size?

 Jay wrote:
 What is up with the size of jmp_buf?
 It appears that setjmp.h confuses bytes and ints, specifically in the Cygwin 
 case.
 _JBLEN should be 13, not 13*4.
 or #define _JBTYPE to char, but that doesn't work as easily.

 

 Did you see this reply to your first inquiry on this subject?

 

 --
 Larry Hall http://www.rfk.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/

jmp_buf size?

[Jay]

What is up with the size of jmp_buf?
It appears that setjmp.h confuses bytes and ints.
_JBLEN should be 13, not 13*4.
or #define _JBTYPE to char, but that doesn't work as easily.
 
?
 
 - Jay

--
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/

FW: many spurious equals sign in xterm?

[Jay]

?


 From: jay.kr...@cornell.edu
 To: cyg...@cygwin.com
 Subject: many spurious equals sign in xterm?
 Date: Sat, 17 Jan 2009 09:22:27 +



 I'm having strange problem where xterms output a steady trickle of equal 
 signs.

 As if I am pressing equals every second or so.





 No other program displays this behavior, no Windows apps (I'm using cmd and 
 Visual C++ constantly) nor the few other X apps I bring up.

 No other character shows up on its own.

 Just the equals sign, in xterm.

 Typing into the xterm works, but I have to be very quick to get in anything 
 without an eqauls sign in the mix.





 I only use Cygwin/X for minimal testing of X apps running on other machines, 
 displayed locally on NT, so this is ok.





 This is x86 XP SP 3.

 I'm willing to clean install XP and/or Cygwin but...





 Thanks,

 - Jay

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

many spurious equals sign in xterm?

[Jay]

I'm having strange problem where xterms output a steady trickle of equal signs.
As if I am pressing equals every second or so.
 
 
No other program displays this behavior, no Windows apps (I'm using cmd and 
Visual C++ constantly) nor the few other X apps I bring up.
No other character shows up on its own.
Just the equals sign, in xterm.
Typing into the xterm works, but I have to be very quick to get in anything 
without an eqauls sign in the mix.
 
 
I only use Cygwin/X for minimal testing of X apps running on other machines, 
displayed locally on NT, so this is ok.
 
 
This is x86 XP SP 3.
I'm willing to clean install XP and/or Cygwin but...
 
 
Thanks,
 - Jay

--
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/

how to get mmap page size?

[Jay Foad]

I have an application that wants to use mmap() to read a file, but
only if it can guarantee that this will leave one or more zero bytes
after the end of the contents of the file in memory:

  if ((filesize  (pagesize - 1) != 0)
use_mmap();
  else
use_read();

How do I get the appropriate page size on cygwin?

If I call getpagesize() it returns 64k, the allocation granularity.
Internally cygwin has a getsystempagesize() (introduced here:
http://cygwin.com/ml/cygwin-cvs/2005-q4/msg00099.html) that returns
the appropriate page size, 4k, but that doesn't seem to be exposed to
applications.

I know that this has been discussed before, e.g. here:

http://www.cygwin.com/ml/cygwin/2002-01/msg00747.html

but I haven't found an answer to this particular question.

Thanks,
Jay.

--
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: how to get mmap page size?

[Jay Foad]

Corinna Vinschen wrote:

 mmap always allocates in 64K chunks.

That doesn't seem to be true in practice. In the test below I mmap a
1080K file (this is a multiple of 4K but not a multiple of 64K). The
first byte after the end of the file isn't readable.

$ cat mmaptest.c
#include fcntl.h
#include stdio.h
#include sys/mman.h
#include sys/stat.h
int main(int argc, char *argv[])
{
int fd;
struct stat st;
void *p;
if (argc != 2) return 1;
if ((fd = open(argv[1], O_RDONLY, 0))  0) return 1;
if (fstat(fd, st) != 0) return 1;
if ((p = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd,
0)) == MAP_FAILED) return 1;
printf(last byte 0x%02X\n, ((unsigned char *)p)[st.st_size - 1]);
fflush(stdout);
printf(next byte 0x%02X\n, ((unsigned char *)p)[st.st_size]);
return 0;
}

$ gcc -o mmaptest mmaptest.c

$ dd bs=1080K count=1 if=/dev/random of=foo
1+0 records in
1+0 records out
1105920 bytes (1.1 MB) copied, 0.077 s, 14.4 MB/s

$ ./mmaptest foo
last byte 0x5F
  9 [main] mmaptest 3040 _cygtls::handle_exceptions: Error while dumping sta
te (probably corrupted stack)
Segmentation fault (core dumped)

This is a recent cygwin installation on XP Pro SP2.

Thanks,
Jay.

--
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: how to get mmap page size?

[Jay Foad]

Corinna Vinschen wrote:

 Right.  The reason is that mmap started to map memory top down at one
 point to fix a problem with Windows Vista.  The mechanism to align
 the map always to 64K is still in Cygwin, but it currently doesn't
 work for files.  I'll have a look into fixing that for Cygwin 1.7.

OK, thanks. In the mean time I guess I'll just use a hard coded value
of 4K for the page size in my application.

Thanks,
Jay.

--
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: cygserver 1.5.25-15 slows down logoff

[Jay]

Maybe you need to call SetServiceStatus(SERVICE_STOPPED) or exit the process or 
something?
What happens when you use net stop to stop the service? It stops reasonably 
fast, or not?

 - Jay

--
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: Slow fork issue - Win x64

[Jay]

 --Forwarded Message Attachment--
 Date: Wed, 17 Sep 2008 20:41:40 +0200
 From: pkc
 To: cygwin
 Subject: Slow fork issue - Win x64


 I have been noticing extreme slowdowns in vista/2k8 64 with latest cygwin 1.5.

 while (true); do date; done | uniq -c

 On windows 2008 64bit:
  11 Wed Sep 17 20:35:27 RDT 2008

 On windows XP SP3 32bit:
  50 Wed Sep 17 20:35:43 2008

 At first I thought it was a syswow64(windows on windows 64, the windows 32 
 subsystem of windows 64bit)
 that was causing the issue since cygwin is 32 bit.


Me too.
I've been building gcc a lot lately on AMD64/XP and was surprised
that it /seemed/ much faster on x86/XP.
Different machines, but I didn't think that much different.

Your test gets me under 10 always on AMD64, and usually around 30 on x86.
More digging would be required.

I've been experimenting with ways to speed up fork.

   1) implement it like how the text file describes a way to do vfork -- with 
setjmp/longjmp  
   I gave up on that. 
   I realize fork and vfork have different meaning. I figured most forks could 
be vfork, though
   it turns out, maybe not. Bash for example runs a fair amount of code between 
fork and exec.
   Rather than copy the fd table around, I tried changing close to 
close-on-exec that occured
   between the fork and exec, but ultimately, didn't work out, not easily.


   2) Using the fork support in NtCreateProcess. Haven't finished that -- need
   to probably zero and reinit Win32 .dlls' .bss/.data, while leaving Cygwin 
.dlls alone.
   So still slow memcpy-ish work to do. I suppose one could even add it up at 
fork time
   and decide which might be faster..


 but maybe merely bringing up AMD64 up to the speed of x86 would suffice. 


 Wow64 is a fairly thin layer. 
 It has to translate kernel calls, widening/narrowing integers/pointers 
 and translating paths between system32 and syswow64. 
 When your code is running without making kernel calls, it runs at full speed.


 - Jay

--
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: building cygwin1.dll with gcc 4.3.2

[Jay]

: error: extra qualification 
'mount_info::' on member 'create_root_entry'
#
# This is fixed in the 8/27 snapshot.
#
ChangeLineInFile(  void mount_info::create_root_entry (const PWCHAR root);\n,
   void create_root_entry (const PWCHAR root);\n,
 Source + /winsup/cygwin/shared_info.h)


 - Jay

--
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: Difficulty building gcc 4.3.2 under i386-pc-cygwin

[Jay]

You can build gcc 4.3.1 and 4.3.2 just fine from the existing Cygwin gcc 3.x 
package.
 
 
The error also /appeared/ to have the object directory under the source
directory. Don't do that. 
 
 
 I use roughly: 
 
 
  mkdir /obj/gcc.1 
  cd /obj/gcc.1 
  /src/gcc/configure -disable-nls -disable-bootstrap 
  make 
  
  
it generally works.
  
  
There is no need to go through intermediate versions,
  not in going from Cygwin's 3.x to current 4.3.x. (I'll try 4.4/trunk soon). 
  
  
 If you /really/ want to go through intermediate versions, 
 then just remove -disable-bootstrap. 

 Or build twice, should be about the same thing:  
  mkdir /obj/gcc.1 
  cd /obj/gcc.1 
  /src/gcc/configure -disable-nls -disable-bootstrap 
  make 
  make install 
  rm -rf * 
  /src/gcc/configure -disable-nls -disable-bootstrap 
  make 
  make install 
 
  Without -disable-bootstrap, gcc gets built with the existing compiler (gcc 
3.x  
  in a typical Cygwin case, but the larger point is it could be not even gcc),  
  and then uses itself to build itself.  
 
  That it is able to build itself is some large measure of a passing test.   
 
  Look at gcc -v for other suggested switches to configure. 
  Such as the thread model. It seems to default to none instead of posix. 
  But what I show above is an ok start.  
  
 
 - Jay

--
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/

target=i686-pc-mingw32 fails building mingw32/winsup/cygserver.

[Jay]

merged source tree gcc + cygwin-snapshot-20080822-1 (+ binutils 2.18, mpfr, 
gmp..)

configure -build i686-pc-cygwin -host i686-pc-cygwin -target i686-pc-mingw32 ...

 Perhaps that is not a valid combination. Story could end right there. (and
  configure should reject it and tell you to use i686-pc-cygwin.)

 I tried it as a workaround for this bug: 
  
http://sourceforge.net/tracker/index.php?func=detailaid=2090602group_id=2435atid=102435
  

 but I have another workaround to try (listed there). 

 Anyway, this works a lot, but eventually: 

 make[3]: Leaving directory 
`/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mi 
 ngw32/winsup/lsaauth' 
 /bin/sh: line 0: cd: 
/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/w 
 insup/cygwin/..: No such file or directory 
 make[3]: Entering directory 
`/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-m 
 ingw32/winsup/cygserver' 
 make[3]: *** No rule to make target 
`/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i 
 686-pc-mingw32/winsup/cygserver/cygwin/libcygwin.a', needed by 
`cygserver.exe'. 
  Stop. 
 make[3]: Leaving directory 
`/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mi 
 ngw32/winsup/cygserver' 
 make[2]: *** [cygserver] Error 1 
 make[2]: Leaving directory 
`/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mi 
 ngw32/winsup' 
 make[1]: *** [all-target-winsup] Error 2 
 make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32' 
 make: *** [all] Error 2 


 The first two platform directories are my doing -- host and target.  
 The last one is the build system's doing -- target again. 


 So, do lsaauth and cygserver really make sense for mingw32? 
 I don't think so, esp. not cygserver, from the error message. 
 winsup does make sense, to get to winsup/mingw, for the target. 


Or maybe..since the mingw32 compiler is almost the same
as the cygwin compiler, it can build it fine? And one can say i686-pc-mingw32 
-mcygwin? 
I see that cc1.exe etc. are just symlinks in the binary packages.


I've heard it said these are different targets, and best treated that way.
But this is kind of a counterpoint to that.


 As well winsup/cygwin, and probably the others, make sense for the HOST. 


 SO I think the fix is roughly: 


 gcc/Makefile.def only lists winsup as target: 

target_modules = { module= winsup; };
dependencies = { module=all-target-winsup; on=all-target-libiberty; };
dependencies = { module=all-target-winsup; on=all-target-libtermcap; };


 But it is also needed on the host. 
 So I think those three lines need to duplicated, but with target changed to 
host. 


As well, winsup/configure.in I think needs a change, to avoid building this
  stuff for target=mingw32.

The code is currently:

case $target in
  *cygwin*)
if ! test -d $srcdir/cygwin; then
  AC_MSG_ERROR(No cygwin dir.  Can't build Cygwin.  Exiting...)
fi
AC_CONFIG_SUBDIRS(cygwin)
INSTALL_LICENSE=install-license
;;
  *mingw*)
if ! test -d $srcdir/mingw; then
  AC_MSG_ERROR(No mingw dir.  Can't build Mingw.  Exiting...)
fi
;;
esac

if test -d $srcdir/mingw; then
  AC_CONFIG_SUBDIRS(mingw)
fi
AC_CONFIG_SUBDIRS(w32api)

case $with_cross_host in
  |*cygwin*)
# if test -d $srcdir/bz2lib; then
#  AC_CONFIG_SUBDIRS(bz2lib)
# fi
# if test -d $srcdir/zlib; then
#   AC_CONFIG_SUBDIRS(zlib)
# fi
if test -d $srcdir/cygwin; then
  AC_CONFIG_SUBDIRS(cygwin)
fi
if test -d $srcdir/lsaauth; then
  AC_CONFIG_SUBDIRS(lsaauth)
fi
if test -n $use_cygserver -a -d $srcdir/cygserver; then
  AC_CONFIG_SUBDIRS(cygserver)
fi
AC_CONFIG_SUBDIRS(utils doc)
;;
esac


but I think needs to be more like:


case $target in
  *cygwin*)
if ! test -d $srcdir/cygwin; then
  AC_MSG_ERROR(No cygwin dir.  Can't build Cygwin.  Exiting...)
fi
AC_CONFIG_SUBDIRS(cygwin)
if test -d $srcdir/lsaauth; then
  AC_CONFIG_SUBDIRS(lsaauth)
fi
if test -n $use_cygserver -a -d $srcdir/cygserver; then
  AC_CONFIG_SUBDIRS(cygserver)
fi
AC_CONFIG_SUBDIRS(utils doc)
INSTALL_LICENSE=install-license
;;
  *mingw*)
if ! test -d $srcdir/mingw; then
  AC_MSG_ERROR(No mingw dir.  Can't build Mingw.  Exiting...)
fi
;;
esac

if test -d $srcdir/mingw; then
  AC_CONFIG_SUBDIRS(mingw)
fi
AC_CONFIG_SUBDIRS(w32api)


I'll see if I can come up with a working patch, though my workaround of just 
using -B../../../gcc
is much cheaper for me at this point. 


 - Jay

--
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: why the strange stack stuf in cygwin?

[Jay]

 [jay] harder to port to other architectures,
 [cgf] Cygwin works on all of the architectures that Windows NT+ supports.


 I mean really doing a native AMD64 and/or IA64 port, not just relying  
 on the ability to run 32bit x86 code. Imho, that's cheating. 


 [jay] Why does Cygwin do such wierd stuff with the top of the stack? 
 [jay] Is this to have thread locals faster than TlsGetValue offers? 


 [cgf] No, it is a work-around for this: 

 [cgf]   % cat 'EOF' foo.c 
 [cgf]   __thread int abc; 
 [cgf]  
 [cgf]   int 
 [cgf]   main (int argc, char **argv) 
 [cgf]   { 
 [cgf] printf (%d\n, abc); 
 [cgf]   } 
 [cgf]   EOF 
  
 [cgf]   % gcc -o foo foo.c 
 [cgf]   foo.c:2: error: thread-local storage not supported for this target 

 Isn't that what I said? 
 Couldn't the generated code use TlsGetValue? 
 Or that's considered too slow? 
 Or, even, do what Microsoft's __declspec(thread) does? 
 Granted, __declspec(thread) doesn't work pre-Vista if you are loaded with 
LoadLibrary,
   or is __declspec(fiber) provided as you might actually want.
 At least with TlsGetValue, it is easy to switch to FlsGetValue, though that 
requires post-XP.

 Is it worth it?

 [cgf] What kind of answer do you expect here?  A head slap and a What were we
 [cgf] thinking???

Maybe Yes it is gnarly and complicated, but it's all we have so far. ?

 (The cost: harder to LoadLibrary(cygwin1.dll),

 [cgf] Dynamic linking of cygwin1.dll (i.e., making it easier to be a 3PP) has 
never 
 [cgf] been a core goal of Cygwin. 

 3PP? ok, I found it.
 Huh. Pretty much all .dlls work with LoadLibrary.
 Cygwin1.dll is a wierd exception.
 Granted, I can see that in its problem space, it might not be interesting.
 Since LoadLibrary is probably used much more often in Windows code than
  the corresponding dlopen is used in Unix.
 And, I kinda thought that the difficulty of using LoadLibrary on cygwin1.dll
  applied transitively to any .dll using cygwin1.dll, but I haven't verified 
that.
 And still, maybe not interesting for the reason I gave. Still odd though.

the strange path where DllMain respawns, etc.) 

 [cgf] the strange path? 
 [cgf] You're using shorthand which assumes that people understand your 
 thought  

   Searching for 'respawn'...  
  
D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(69):respawn_wow64_process
 ()  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(92):  /* The parent 
is a real 64 bit process?  Respawn! */  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(136):  spawned by a 
genuine 64 bit process.  If so, respawn. */  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140): 
respawn_wow64_process ();  

  The code seems very wierd in places.  
  I don't like it.  
  I know, boo hoo, whine whine whine. It seems to work but it makes me nervous. 
 
 

 - Jay 

--
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: Running 64bit processes from 32bit Cygwin

[Jay]

  [Robert]  Can anyone tell me for sure that it's impossible to run a 64bit 
  [Robert]  windows process from 32bit Cygwin? Or rather.. is it possible to 
spawn 
  [Robert]  a 64bit process from Cygwin and have it not be trapped inside WoW64 
  [Robert]  emulation? It seems as though once you're inside WOW64, you can't 
  [Robert]  readily escape from it? I wonder if it would be possible to ask the 
  [Robert]  explorer process to spawn something for you (possibly via a com 
  [Robert]  message?) rather than using WinExec(). If so a utility to 
facilitate 
  [Robert]  such process spawning would be a very useful addition to Cygwin. 
 
 
 32bit processes can launch 64 bit processes, and vice versa. 
 You are not trapped in emulation. 
 Simply via the normal CreateProcess, or system(), or ShellExecute().
 There's no need to ask Explorer to do it for you. Except...
 There is wierdness though in that 32bit processes cannot usually 
  see the 64bit system directory. They can run 64bit .exes anywhere
  else, but under native %windir%\system32 is wierd.
  Vista adds something like %windir%\sysnative (search the web).

e.g.:
 cd \ 
 copy %windir%\system32\cmd.exe cmd64.exe 
 copy %windir%\syswow64\cmd.exe cmd32.exe 
 They can each run each other: 
 .\cmd32  
 .\cmd64 
 .\cmd32 
 notepad = runs 32bit notepad 
 .\cmd64 
 notepad = runs 64bit notepad 


 IF this is your problem, you merely need to make a 64bit 
 executable in between that you run, that then runs the 64bit 
 PowerShell. It'd be a very small simple program.  
 I have to install PowerShell to check. 

 Or use the APIs that temporarily turn off mucking with paths.  
   Wow64DisableWow64FsRedirection  

 and then system(notepad.exe) from a 32bit app should launch 64bit notepad.  
 And hope that system() doesn't try to LoadLibrary anything in the parent 
process, 
 under same influence of turning off redirection that is meant to only affect 
 finding the .exe. This whole redirection thing..instead of there being 
 \windows\system64, but I guess too much code hardcodes system32 and 
 so it is a great porting convenience.. 

 WinExec is an old function there for compatibility. 
 You shouldn't use it. 

  - Jay 

--
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: why the strange stack stuf in cygwin?

[Jay]

Is it the source code making the function calls that bothers you,
or the code size/perf bloat?

 If it is the source, just hide it with macros, like:

 #define foo /* existing thread local stuff */ 
 #define bar /* existing thread local stuff */ 

  typedef struct cygwin_threadlocals_t {  
int foo;  
int bar;  
  } cygwin_threadlocals_t;  

  /* Returns NULL under rare circumstances:  
 threads created before cygwin1.dll loaded (3pp) plus low memory, 
combined;
 neither scenario alone returns NULL. The data will be allocated in 
 cygwin1!DllMain(thread attach), which isn't called for threads created 
before
cygwin1.dll loads, returning FALSE under low memory. If not then, then on 
demand,
which can fail due to low memory.
  */
  cygwin_threadlocals_t* _cygwin_get_thread_locals(void);  

   #define foo (_cygwin_get_thread_locals()-foo)  
   #define bar (_cygwin_get_thread_locals()-bar)  

  I can go through and make/build/test a complete patch if the approach is ok.  
  This is how msvcrt.dll uses thread locals.
  But again surely you considered that. ?

  If it is the resulting object code, well, yeah, I can see that.  
  It's what I asked -- to be faster than TlsGetValue.  

 Changing a keyword from __thread to __declspec(thread) doesn't really
 solve any problem.

  I understand merely changing __thread to __declspec(thread)  
  accomplishes nothing useful, just another compilation error.  

  I meant implementing __thread in gcc. 
  (actually briefly I was confused) 
  Which would generate code. Which would have to do something.. 
  The Visual C++ implementation is in between TlsGetValue and the existing
   cygwin implementation in size/perf. Around three instructions per
   reference, no function call. 

 What generated code?  You mean have gcc do this?  Feel free to submit 
 a patch to gcc to make this happen. 

 I might. 

 The tls implementation is not the reason why there is no native 64 bit

  I understand that gcc doesn't yet target IA64 or AMD64 Windows and
   that is a /large/ blocking factor. 
  There are patches out there for AMD64, but it isn't clear 
  they are of release quality (last I checked), and they aren't upstream I 
think. 

 FUD to assume that the mechanism used for the 
 32-bit stack manipulation could not be adopted for 64-bit. 

   True that the top of the stack should work on other architectures. 
   But it still seems somehow yucky to me. 

 rather than making silly pedantic and empty arguments I'd rather that you
 contributed to making things better.  That is if you were truely up to it
 capable.

  I am capable of contributing changes. Agreement on what they should be is the 
hard part.

  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140):
 respawn_wow64_process (); 
 This has nothing to do with the strange stack stuff that you are 
 objecting to. 

 I don't yet know what it's there for, but it is vaguly also strange stack 
stuff 
 since it seems to not want the stack in a particular range. 

 If it makes you nervous don't use it.  Delete it from your system.  This 

 It seems the best way by far to use gcc on Windows. 
 Including active maintenance. 
 
- Jay

--
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: why the strange stack stuf in cygwin?

[Jay]

Is it the source code making the function calls that bothers you,
or the code size/perf bloat?

 If it is the source, just hide it with macros, like:

 #define foo /* existing thread local stuff */ 
 #define bar /* existing thread local stuff */ 

  typedef struct cygwin_threadlocals_t {  
int foo;  
int bar;  
  } cygwin_threadlocals_t;  

  /* Returns NULL under rare circumstances:  
 threads created before cygwin1.dll loaded (3pp) plus low memory, 
combined;
 neither scenario alone returns NULL. The data will be allocated in 
 cygwin1!DllMain(thread attach), which isn't called for threads created 
before
cygwin1.dll loads, returning FALSE under low memory. If not then, then on 
demand,
which can fail due to low memory.
  */
  cygwin_threadlocals_t* _cygwin_get_thread_locals(void);  

   #define foo (_cygwin_get_thread_locals()-foo)  
   #define bar (_cygwin_get_thread_locals()-bar)  

  I can go through and make/build/test a complete patch if the approach is ok.  
  This is how msvcrt.dll uses thread locals.
  But again surely you considered that. ?

  If it is the resulting object code, well, yeah, I can see that.  
  It's what I asked -- to be faster than TlsGetValue.  

 Changing a keyword from __thread to __declspec(thread) doesn't really
 solve any problem.

  I understand merely changing __thread to __declspec(thread)  
  accomplishes nothing useful, just another compilation error.  

  I meant implementing __thread in gcc. 
  (actually briefly I was confused) 
  Which would generate code. Which would have to do something.. 
  The Visual C++ implementation is in between TlsGetValue and the existing
   cygwin implementation in size/perf. Around three instructions per
   reference, no function call. 

 What generated code?  You mean have gcc do this?  Feel free to submit 
 a patch to gcc to make this happen. 

 I might. 

 The tls implementation is not the reason why there is no native 64 bit

  I understand that gcc doesn't yet target IA64 or AMD64 Windows and
   that is a /large/ blocking factor. 
  There are patches out there for AMD64, but it isn't clear 
  they are of release quality (last I checked), and they aren't upstream I 
think. 

 FUD to assume that the mechanism used for the 
 32-bit stack manipulation could not be adopted for 64-bit. 

   True that the top of the stack should work on other architectures. 
   But it still seems somehow yucky to me. 

 rather than making silly pedantic and empty arguments I'd rather that you
 contributed to making things better.  That is if you were truely up to it
 capable.

  I am capable of contributing changes. Agreement on what they should be is the 
hard part.

  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140):
 respawn_wow64_process (); 
 This has nothing to do with the strange stack stuff that you are 
 objecting to. 

 I don't yet know what it's there for, but it is vaguly also strange stack 
stuff 
 since it seems to not want the stack in a particular range. 

 If it makes you nervous don't use it.  Delete it from your system.  This 

 It seems the best way by far to use gcc on Windows. 
 Including active maintenance. 
 
- Jay

--
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/

why the strange stack stuf in cygwin?

[Jay]

 Why does Cygwin do such wierd stuff with the top of the stack?
 Is this to have thread locals faster than TlsGetValue offers?
 Is it worth it?
 (The cost: harder to LoadLibrary(cygwin1.dll), harder to port to other 
architectures,
  the strange path where DllMain respawns, etc.)
 

 - Jay

--
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: Probably stupid make question (cmd a=b)

[Jay]

  continuing somewhat off topic:  

   Probably stupid make question
   144097 by: Phil
   144106 by: Stephan
  
  
  But really, just about anything is better than cmd.  
  
  
 Have you tried quotes?

  D:\type 2.cmd
  @echo 1 is %1
  @echo 2 is %2


  D:\.\2.cmd a=b   
  1 is a  
  2 is b  

  D:\.\2.cmd a=b  
  1 is a=b  
  2 is  


  I think tilde is how to strip quotes:  
echo 1 is %~1  
echo 2 is %~2  
  to echo without quotes  

  echo 1 is %~1  
  echo 2 is %~2  

  to echo with one set of quotes, no matter if the input was quoted.  
  Though this might go badly if the last character is a blackslash, it might  
   escape the quote. I find anything involving quoting to be broken.  
   It is difficult/impossible to know how many rounds of unquoting will occur,  
and how/by whom. It seems that a large percentage of cmd and bash  
code is merely fighting to get quoting right. A lot of this stems from the  
bogus construct of representing an array of strings as one string with  
spaces delimiting elements.  


  But really, just about anything is better than cmd.
  I have used cmd a lot and I heartily recommend Perl or Python instead,
   no matter the application.


 I do like cmd for interactive use, it is fast, has decent command line 
editing,  
   history, quickedit (I wish I could triple click for lines), and my favorite 
feature  
   F8 does completion against command line history.   


  But as a programming language, it is terrible. It is too string based.  


  People complain about the need to install Perl/Python on Windows, that they 
aren't built in.  
  Yes, but the alternative, using cmd, is much worse than having to install 
them.  
  Perl can just be copied around, no need to install it.  
  Python I haven't tried that yet.  
  
  
 - Jay  

--
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/

building cygwin1.dll with gcc 4.3.1

[Jay]

gcc 4.3.1

In file included from /src/cygwin-snapshot-20080822-1/winsup/cygwin/dcrt0.cc:29:

/src/cygwin-snapshot-20080822-1/winsup/cygwin/shared_info.h:98: error: extra qua
lification 'mount_info::' on member 'create_root_entry'

class mount_info
{
...
  void mount_info::create_root_entry (const PWCHAR root);
  void create_root_entry (const PWCHAR root);
...
};


and const is almost meaningless here btw, probably
should be PCWSTR.


Haven't looked at these yet but they sound obvious:


/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc: In function 'bool handl
e_to_fn(void*, char*)':
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:973: error: jump to labe
l 'unknown'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:874: error:   from here
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:878: error:   crosses in
itialization of 'size_t w32len'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:877: error:   crosses in
itialization of 'WCHAR* w32'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:973: error: jump to labe
l 'unknown'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:867: error:   from here
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:878: error:   crosses in
itialization of 'size_t w32len'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:877: error:   crosses in
itialization of 'WCHAR* w32'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:973: error: jump to labe
l 'unknown'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:858: error:   from here
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:878: error:   crosses in
itialization of 'size_t w32len'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:877: error:   crosses in
itialization of 'WCHAR* w32'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:862: error:   crosses in
itialization of 'NTSTATUS res'
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc:861: error:   crosses in
itialization of 'OBJECT_NAME_INFORMATION* ntfn'
make[3]: *** [dtable.o] Error 1
make[3]: Leaving directory `/obj/cygwin.1/i686-pc-cygwin/winsup/cygwin'
make[2]: *** [cygwin] Error 1
make[2]: Leaving directory `/obj/cygwin.1/i686-pc-cygwin/winsup'
make[1]: *** [all-target-winsup] Error 2
make[1]: Leaving directory `/obj/cygwin.1'
make: *** [all] Error 2


 - Jay

--
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: building cygwin1.dll with gcc 4.3.1

[Jay]

more of the same, goto and switch skipping initializations.

attached gets as far as:


gcc -c -D__CRTDLL__ -U__MSVCRT__ -g -O2   -I/src/cygwin-snapshot-20080822-1/wins
up/mingw/include -I/src/cygwin-snapshot-20080822-1/winsup/mingw/../include -nost
dinc -iwithprefixbefore include -I /src/cygwin-snapshot-20080822-1/winsup/mingw/
../w32api/include -mno-cygwin /src/cygwin-snapshot-20080822-1/winsup/mingw/crt1.
c -o crt1.o
gcc: error trying to exec 'cc1': execvp: No such file or directory
make[3]: *** [crt1.o] Error 1
make[3]: Leaving directory `/obj/cygwin.1/i686-pc-cygwin/winsup/mingw'
make[2]: *** [mingw] Error 1
make[2]: Leaving directory `/obj/cygwin.1/i686-pc-cygwin/winsup'
make[1]: *** [all-target-winsup] Error 2
make[1]: Leaving directory `/obj/cygwin.1'
make: *** [all] Error 2


[EMAIL PROTECTED] /obj/cygwin.1


which I understand, different problem. I need to go build that compiler.

The .dll seems to basically work.
  I can
  cd /obj/bash.1
  make clean
  make

Haven't waited for it to finish.

using the dll:

Huh?  No /etc/fstab file in \??\D:\cygwin\etc\fstab.d\jay?  Using default root a
nd cygdrive prefix...
bash: /usr/bin/tr: No such file or directory
bash: /usr/bin/sed: No such file or directory

probably for lack of running 1.7 setup?
Maybe the default mount should include /bin = /usr/bin and /lib = /usr/lib?

And this incorrect command line gives an incorrect warning:

$ mount /bin /usr/bin
cygwin warning:
  MS-DOS style path detected: D:\cygwin\usr\bin
  Preferred POSIX equivalent is: /usr/bin
  CYGWIN environment variable option nodosfilewarning turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
mount: /usr/bin: Invalid argument

I couldn't /quickly/ find how to fix the mount stuff I added to /etc/profile

mount d:/cygwin/lib /usr/lib
mount d:/cygwin/bin /usr/bin
mount d:/obj /obj
mount d:/src /src
mount d:/net /net
mount d:/cm3 /cm3
mount d:/dev2 /dev2

I'll go reread the 1.7 stuff.

 - Jay
Common subdirectories: 
/src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/config and 
/src/cygwin-snapshot-20080822-1/winsup/cygwin/config
diff -u /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/dtable.cc 
/src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc
--- /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/dtable.cc
2008-05-21 18:34:09.0 -0700
+++ /src/cygwin-snapshot-20080822-1/winsup/cygwin/dtable.cc 2008-08-26 
09:51:19.296875000 -0700
@@ -851,6 +851,14 @@
   WCHAR *maxmatchdos = NULL;
   int maxmatchlen = 0;
 
+// This is to here avoid goto crossing initialization.
+  if (0)
+{
+unknown:
+  strcpy (posix_fn,  unknown_file);
+  return false;
+}
+
   NtQueryObject (h, ObjectNameInformation, dummy_oni, sizeof (dummy_oni), 
len);
   if (!len)
 {
@@ -969,8 +977,4 @@
 
   debug_printf (derived path '%W', posix '%s', w32, posix_fn);
   return false;
-
-unknown:
-  strcpy (posix_fn,  unknown_file);
-  return false;
 }
diff -u /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/fhandler_fifo.cc 
/src/cygwin-snapshot-20080822-1/winsup/cygwin/fhandler_fifo.cc
--- /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/fhandler_fifo.cc 
2008-08-21 21:06:49.0 -0700
+++ /src/cygwin-snapshot-20080822-1/winsup/cygwin/fhandler_fifo.cc  
2008-08-26 09:41:36.328125000 -0700
@@ -131,11 +131,13 @@
   switch (wait_state)
 {
 case fifo_wait_for_client:
-  bool res = ConnectNamedPipe (get_handle (), get_overlapped ());
-  DWORD dummy_bytes;
-  if (res || GetLastError () == ERROR_PIPE_CONNECTED)
-   return true;
-  return wait_overlapped (res, iswrite, dummy_bytes);
+  {
+   bool res = ConnectNamedPipe (get_handle (), get_overlapped ());
+   DWORD dummy_bytes;
+   if (res || GetLastError () == ERROR_PIPE_CONNECTED)
+ return true;
+   return wait_overlapped (res, iswrite, dummy_bytes);
+  }
 default:
   break;
 }
diff -u /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/hookapi.cc 
/src/cygwin-snapshot-20080822-1/winsup/cygwin/hookapi.cc
--- /src/cygwin-snapshot-20080822-1.orig/winsup/cygwin/hookapi.cc   
2008-05-10 10:08:41.0 -0700
+++ /src/cygwin-snapshot-20080822-1/winsup/cygwin/hookapi.cc2008-08-26 
09:54:30.21875 -0700
@@ -160,7 +160,8 @@
 /* Find first missing dll in a given executable.
FIXME: This is not foolproof since it doesn't look for dlls in the
same directory as the given executable, like Windows.  Instead it
-   searches for dlls in the context of the current executable.  */
+   searches for dlls in the context of the current executable.
+   This is not thread safe, but only used by strace. */
 const char *
 find_first_notloaded_dll (path_conv pc)
 {
@@ -172,6 +173,15 @@
   HANDLE h;
   NTSTATUS status;
 
+// This is here to avoid goto crossing initialization.
+if (0)
+  {
+out:
+   if (hm)
+ UnmapViewOfFile (hm);
+   return res

RE: cygwin 1.7.0 and special filename chars

[Jay]

  Apparently my understanding of FAT is wrong then.  
  Brian 

FAT stores Unicode on disk, if necessary, as part of the long name support.
That is, if a name happens to be 8.3, both in length and character set etc.,
it occupies just one normal directory entry.
If a name is not 8.3, either in length or character set etc., it is stored as 
a long name.

etc. as in, at least, dot location -- multiple dots and leading dots are 
not 8.3.

C:\dir /x
08/24/2008  12:02 PM  F66E2~1  .f
08/24/2008  12:02 PM  112E5D~1.1   1.1.1
08/24/2008  12:02 PM  FO3368~1 .fo
08/24/2008  12:02 PM  FOO~1.foo

(notice how short names can be much longer than long names).

In fact, the Win9x installable file system interfaces traffic in Unicode.

The referenced email describing 1.7 lists some special characters that are
now allowed, but it doesn't mention question mark.
Perhaps a good description would be LIKE: all 8 bit characters except forward 
slash and nul??
(or, whatever, all 8 bit characters except )

 - Jay

--
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: setup v2.573.2.3: Postinstall: abnormal exit: exit code=126

[Jay]

[again as plain text]



 From: [EMAIL PROTECTED]
 To: cygwin@cygwin.com; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: setup v2.573.2.3: Postinstall: abnormal exit: exit code=126
 Date: Sun, 10 Aug 2008 08:35:51 +
 
  [B] From: brian@
 
  [B] ...I think...and we should just have
  [B] bash provide /bin/sh directly without the complicated postinstall
  [B] gymnastics.  There was the objection that the current scheme obstensibly
  [B] allows for the user to use any shell as /bin/sh, but I question how many
  [B] people are aware of this let alone desire to take advantage of it.
 
 [D] From: dave.korn@
  ...
 [D]  The problem is that no matter whether bash or ash install /bin/sh,
 [D] terminfo is going to be installed first, and that means
 [D] /etc/postinstall/terminfo.sh is pretty much doomed to failure.
 
 [J]
 I assume Brian wants bash.tar.bz2 to just have a second copy
 of bash at  bin/sh.exe, or a symlink or hardlink,
 unconditionally overwriting whatever is there.
 Rather than having a postinstall program copy it conditionally.
 
 ?
 
 And that all the extraction happens before any install code runs. ?
 
  - Jay

--
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: ABI unification / non-x86 ports

[Jay]

Clarification:

 .dlls *statically linked the same* CAN communicate in all ways.
 This is the simple world folks generally stay within.

Compiled and statically linked the same.


There are multiple factors.

There is which compiler you use. That actually tends not to matter.
   Unless the headers use language extensions not supported.
   Or if the compilers actually output different formats, that the linkers
did/did not understand. That is the case for the debug info presumably,
but not for the code.
   Actually, there is a reason you can't always mix gcc+link or cl+ld.
That is because __ImageBase has a different name between the two linkers.
So if you use that symbol, your source is stuck with a particular compiler 
and linker.
Unfortunate. This is why, e.g. MS link can't use Cygwin libc.a or such, 
because
it has a use of the GNU/Cygwin symbol analogous to __ImageBase but
differently named.


There is which headers to you use. Ideally they'd be the same.
  But they aren't, and that is the problem (or just how things are).

The static .libs you use. With in any one invocation of the linker, you can
  only use either Cygwin libc.a, or Microsoft msvcrt.lib (or libcmt.lib, 
ignored).

IF the headers were the same, then you could mix .objs within the static
  link that were compiled with either headers.

As well, there is what happens at runtime.
Given the varying headers, there is an analogous lack of interop there too.
Granted, though I kind of said the opposite before.
Folks can still traffic in int and such, but if they pass around FILE*,
trouble is likely. Really, it's about trafficing in types for which you
agree to the definition, for which you used the same headers.
And for opaque types, assuming sizes match (e.g. FILE*), which are
fed down to the same underlying layers.

 - Jay

--
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: ABI unification / non-x86 ports

[Jay]

 non-x86 port 

 Yes, I know what the web page says. 
 And I've seen the code. Stepped through it. Read it. 
 I'm just hoping, ok? 
   Or maybe I can help. I know it's not easy. 
   And ABI unification is a nuisance upon already difficult work. 
 More for AMD64 than IA64. 
 And yes, I know x86 works on them. 

Are you being serious or sarcasting about wanting IA64?

 First, I meant a uniform compile time ABI. 
 Not an ability 
 to mix and match at runtime. This thing ... 
 I simply want to compile two .objs with the different 
 compilers and headers, and then link them together, 
 trafficing in whatever. ... and this thing completely contradict each other. 
 What's the use of being able to link them together if they don't work at 
 runtime? 
 
Sorry, I was not clear.
.objs compiled differently *but statically linked the same*
should be able to communicate.

Like so:
ms.c:
#include 
void ms(const char* a)
 cygwin(fopen(a, r));

cyg:
#include 
  void cygwin(FILE* f)
  {
fread(..., f);
  }

That example WILL (very very likely) work, since it does so little.
Assuming fopen/fread have no inline/macro component.
That they are both always completely function calls.
This is the interoperable world that some folks would like some of.


.dlls *statically linked diffferently* CAN AND DO communicate, but
only in certain ways. Counter example: Like the above.
Example: replace with CreateFile/ReadFile, since I'm talking about
static linking to one C/Posixy runtime or another, and there is only
one underlying CreateFile/ReadFile.
This is the real world with dynamic linking.


.dlls *statically linked the same* CAN communicate in all ways.
This is the simple world folks generally stay within.


It's not really a binary thing, in that there are factors besides Cygwin.
For example, if you define _WIN32_WINNT differently, some structs
in windows.h change size. I think that's gross but oh well.
If one guy passes a pointer of his to another, compiled with a different 
#define,
without specifying the size, and the other copies to or from it, can crash.


It's a combinatorial explosion unfortunately.
You are left trying to match up as much as possible, not being certain
what matters and what doesn't.
Some folks (boost) provide .libs/.dlls built multiple ways, so they can
interop with any kind of client. What an unfortunate cost.


 - Jay

--
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: ABI unification

[Jay]

.. 


 Cygwin didn't necessarily have to add yet another one. 
 But yeah there were already too many. 


 Somewhere somehow these different worlds do come together.
 The question is where and how.
 There are several options.
   One common way for worlds to collide is only via the network -- TCP/IP, SMB. 
   Another way is multiboot, sharing disks that way. 
   Another way is removable media. 
   Another way is via files on the same running system. 
   Another way is via local or remote RPC (which again can include TCP/IP). 

   Another way is via in-process function calls. 
 This last one is where the bindings are tighter, the interfaces 
   change more often, where type checking happens less. 
 You know, IPv4 and IPv6 can identify each other and agree not to talk 
  to each other, for example. But I don't pass a size (or version, or 
layout 
  description of some sort) to stat for it to check. It trusts that we 
agree. 


Anyway, given the errno.h mismatches, it's not possible without a breaking 
change.
Perhaps this can be fixed for any non-x86 Cygwin port? 
I realize, it requires visiting several factors and it ultimately might not fly.
But mismatched errno.h doesn't seem like a good reason.

 - Jay

--
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: compilation - cygwin -mno-cygwin-flag

[Jay]

  [Brian] Using -mno-cygwin switches the compiler
  into MinGW personality mode. You cannot
  mix and match Cygwin and MinGW libraries.
  If you use-mno-cygwin then you must ensure
  that *all* libraries that any component of
  your software links with were built as MinGW
  libraries. You can't let any Cygwin libs enter
  the equation.

Can the ABIs be unifed?
  line up struct stat, or make thin wrappers? 
  line up errno.h? 
  lineup lseek/fseek flags? (probably already the case)
  use the larger of the two jmpbuf sizes?
  keep FILE* opaque?
Maybe line up just its size, if stdin/out/err are defined to be
  elements in an array.
  either line up ctype's data, or use real function calls?
  etc.?
  Under a -slightly-slower-but-more-compatible switch?

ABI multiplicity bugs me..

I realize that it might be too late, at least without a thin translation 
layer,
and even then. Reasonable for like stat, but not really for errno.h, for 
example.

 - Jay

--
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: flex: exec failed?

[Jay]

No longer a Cygwin issue (repros on Linux), but here's why if anyone interested:

#include 
#include 

int main()
{
   signal(SIGPIPE, SIG_IGN);   Python 
   putenv(M4=foo);
   system(flex 1.l);
   return 0;
}

Without ignoring sigpipe, flex dies reading the pipe of a failed-to-exec child,
before it gets around to unlink(lex.yy.c).

If you put instrumentation (printf) in the fgets/fputs loop in 
filter_tee_header in flex,
you find the sh variant stops without exiting the loop, whereas the python 
variant
continues on, and deletes lex.yy.c.

I'll patch my gmp/configure to not set M4 like this.
I've reported this to gcc and gmp (gcc hits this
because it configures gmp with cpu=none; usually building
gmp sets M4=m4, which is ok, though it really it should leave it alone.).

 - Jay


 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: RE: flex: exec failed?
 Date: Thu, 31 Jul 2008 12:45:45 +


 Ok, it works the same on Cygwin and Linux/x86, but Python/NTAMD64 works.
 Somehow Python/Posix related, portably.

 For anyone interested:

 $ echo %% conftest.l
 $ echo %% conftest.l
 $ rm lex.yy.c
 $ export M4=foo
 $ flex conftest.l
 flex: fatal internal error, exec failed
 lex.yy.c exists

 $ rm lex.yy.c
 $ python -c import os; os.system(\flex conftest.l\)
 flex: fatal internal error, exec failed
 flex: 2 error writing output file lex.yy.c (I added the 2 to disambiguate 4 
 identical error messages)
 lex.yy.c does not exists -- make configure-gmp fails

 relevant code in flex:

 filter_tee_header:
 if ((to_cfd = dup (1)) == -1)
 flexfatal (_(dup(1) failed));
 to_c = fdopen (to_cfd, w);
 ...
 fflush (to_c);
 if (ferror (to_c))
 lerrsf (_(2 error writing output file %s),
 outfilename ? outfilename : );

 else if (fclose (to_c))
 lerrsf (_(error closing output file %s),
 outfilename ? outfilename : );

 while (wait (0) 0) ;


 again, I added the 2.

 Digging deeper...

 - Jay


 [snip snip snip]

--
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: flex: exec failed?

[Jay]

Arg.. simple repro is this Python code, with the appropriate gcc source tree:

#! /usr/bin/env python

import os
import sys

def Run(Directory, Command):

sys.stderr.flush()
sys.stdout.flush()

print(cd  + Directory ++ Command)

PreviousDirectory = os.getcwd()
os.chdir(Directory)

if os.name == nt:
Command = sh -c \ + Command + \

sys.stderr.flush()
sys.stdout.flush()

ExitCode = os.system(Command)

os.chdir(PreviousDirectory)

sys.stderr.flush()
sys.stdout.flush()

if ExitCode != 0:
sys.exit(ExitCode)

if not os.path.isdir(./obj):
Run(., mkdir ./obj)

if not os.path.isfile(./obj/Makefile):
Run(./obj, ../gcc/configure)

Run(., rm -rf ./obj/gmp)

Run(./obj, make configure-gmp)

Repros in Python, not outside of Python? Why? That is the question.

Other tidbits:
  flex actually fails to exec m4 either way, just that one way it manages to 
create lex.yy.c first.

It fails to exec m4 because gmp's configure has set M4=m4-not-needed.

This is almost certainly a simple bug in gmp's configure.
A fix would be to probe for external programs (yacc, lex), earlier, before it 
sets M4.
Or unset M4 after it is done with it.

But there is still something amiss, maybe Cygwin specific, maybe not.

Oh, and whether or not gmp sets M4 varies somewhat on build/host/target.

Usually, configuring gmp on its own, probably it is set.

But within gcc, generally not, because gcc configures it with processor=none 
for reasons I don't understand..

I guess it'd be nice if flex printed what it was trying to run -- getenv(M4) 
and not just m4.

I'll follow up separately, at least gcc and gmp..
Still not completely solved.

I do have a quick repro though, you can strip down the configure script a bunch 
and it repros in just a few seconds.
Going through the strace logsbut need to read flex also for when it creates 
the output vs. running m4..

 - Jay


 From: [EMAIL PROTECTED]
 To: cygwin@cygwin.com
 Subject: RE: flex: exec failed?
 Date: Sat, 26 Jul 2008 12:40:01 +


 anecdotes...

 I've seen this quite a few times now, like 10.

 Always this same error -- always configure unable to determine the (f)lex 
 output, I think always configuring gmp.
 (Maybe binutils sometimes, due to the flex source directory, understood, red 
 herring.)

 I've done a lot else successfully, configure/built gcc/binutils/gmp/mpfr, 
 this is the one failure I've seen a few of.
 That is -- lots of stuff works, I'm not messing things up in some large way, 
 but this fails often.

 I'm not using tee any longer, but still running all of this within Python 
 (os.system).
 I don't usually check config.log, but it always the same configure test.

 Peeling one layer, either cd'ing in cmd or bash to gcc toplevel and doing 
 make configure-gmp or two layers, cd'ing to gcc/gmp and whatever/configure 
 whatever, has a much much higher success rate. And then I can run my stuff, 
 which is incremental enough, and so I skip past this.

 I stopped installing Cygwin at the root, though I've seen it both work and 
 not-work that way.
 I am usually on XP/AMD64, and maybe every repro is on that.

 I do notice comments about thread unsafety in Cygwin's fork/exec code.
 My Python is single threaded (I was getting intermittent errors about unable 
 to allocate locks).

 I'll have to put strace in there and focus in on it, instead of continuing to 
 workaround.

 ..Jay


 From: [EMAIL PROTECTED]
 To: cygwin@cygwin.com
 Subject: FW: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:55:06 +


 It failed again without the time/tee. Time to try with -disable-bootstrap, 
 and if it still failed, reboot, and...




 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:53:23 +


 anyone familiar with this:

 flex: fatal internal error, exec failed
 flex: error writing output file lex.yy.c

 It comes while configuring gmp, in a merged (Cygnus) gcc tree.
 I've been able to build this several times, various configurations.
 (various host/target and options, mostly build=cygwin, but
 on some other systems too, unrelated..)

 What I am doing differently this time is two things.

 1) I'm no longer -disable-bootstrap.

 I am running under a wrapper .py file.
 (It goes through multiple configurations.)
 That isn't changed, but:

 2) previously:
 ./build.py
 now:
 time (sh -c ./build.py | tee 1.log)
 or
 time (./build.py | tee 1.log)

 I have tried both.

 config.log nearby:

 configure:32814: checking for flex
 configure:32840: result: flex
 configure:32853: checking for yywrap in -lfl
 configure:32883: gcc -o conftest.exe -g -fkeep-inline-functions -DNO_ASM 
 conftest.c -lfl5
 configure:32889: $? = 0
 configure:32893: test -z
 || test ! -s conftest.err
 configure:32896: $? = 0
 configure:32899: test -s conftest.exe
 configure:32902: $? = 0
 configure:32915: result: yes
 configure:32993: checking lex output file root
 configure:33004: flex conftest.l
 flex

RE: flex: exec failed?

[Jay]

 Ok, it works the same on Cygwin and Linux/x86, but Python/NTAMD64 works. 
 Somehow Python/Posix related, portably.

 For anyone interested: 
 
  $ echo %% conftest.l
  $ echo %% conftest.l
  $ rm lex.yy.c   
  $ export M4=foo
  $ flex conftest.l   
  flex: fatal internal error, exec failed  
  lex.yy.c exists  

  $ rm lex.yy.c 
  $ python -c import os; os.system(\flex conftest.l\)  
   flex: fatal internal error, exec failed
   flex: 2 error writing output file lex.yy.c  (I added the 2 to disambiguate 
4 identical error messages)  
  lex.yy.c does not exists -- make configure-gmp fails   

  relevant code in flex:  

  filter_tee_header:  
if ((to_cfd = dup (1)) == -1) 
flexfatal (_(dup(1) failed));  
to_c = fdopen (to_cfd, w);  
...
fflush (to_c);  
if (ferror (to_c))  
lerrsf (_(2 error writing output file %s),  
outfilename ? outfilename : );  

else if (fclose (to_c))  
lerrsf (_(error closing output file %s),  
outfilename ? outfilename : );  

while (wait (0) 0) ;  


  again, I added the 2.  

  Digging deeper...

 - Jay


 [snip snip snip] 

--
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: flex: exec failed?

[Jay]

anecdotes...

I've seen this quite a few times now, like 10.

Always this same error -- always configure unable to determine the (f)lex 
output, I think always configuring gmp.
 (Maybe binutils sometimes, due to the flex source directory, understood, red 
herring.)

I've done a lot else successfully, configure/built gcc/binutils/gmp/mpfr, 
this is the one failure I've seen a few of.
That is -- lots of stuff works, I'm not messing things up in some large way, 
but this fails often.

I'm not using tee any longer, but still running all of this within Python 
(os.system).
I don't usually check config.log, but it always the same configure test.

Peeling one layer, either cd'ing in cmd or bash to gcc toplevel and doing make 
configure-gmp or two layers, cd'ing to gcc/gmp and whatever/configure 
whatever, has a much much higher success rate. And then I can run my stuff, 
which is incremental enough, and so I skip past this.

I stopped installing Cygwin at the root, though I've seen it both work and 
not-work that way.
I am usually on XP/AMD64, and maybe every repro is on that.

I do notice comments about thread unsafety in Cygwin's fork/exec code.
My Python is single threaded (I was getting intermittent errors about unable to 
allocate locks).

I'll have to put strace in there and focus in on it, instead of continuing to 
workaround.

 ..Jay


 From: [EMAIL PROTECTED]
 To: cygwin@cygwin.com
 Subject: FW: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:55:06 +


 It failed again without the time/tee. Time to try with -disable-bootstrap, 
 and if it still failed, reboot, and...




 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:53:23 +


 anyone familiar with this:

 flex: fatal internal error, exec failed
 flex: error writing output file lex.yy.c

 It comes while configuring gmp, in a merged (Cygnus) gcc tree.
 I've been able to build this several times, various configurations.
 (various host/target and options, mostly build=cygwin, but
 on some other systems too, unrelated..)

 What I am doing differently this time is two things.

 1) I'm no longer -disable-bootstrap.

 I am running under a wrapper .py file.
 (It goes through multiple configurations.)
 That isn't changed, but:

 2) previously:
 ./build.py
 now:
 time (sh -c ./build.py | tee 1.log)
 or
 time (./build.py | tee 1.log)

 I have tried both.

 config.log nearby:

 configure:32814: checking for flex
 configure:32840: result: flex
 configure:32853: checking for yywrap in -lfl
 configure:32883: gcc -o conftest.exe -g -fkeep-inline-functions -DNO_ASM 
 conftest.c -lfl5
 configure:32889: $? = 0
 configure:32893: test -z
 || test ! -s conftest.err
 configure:32896: $? = 0
 configure:32899: test -s conftest.exe
 configure:32902: $? = 0
 configure:32915: result: yes
 configure:32993: checking lex output file root
 configure:33004: flex conftest.l
 flex: fatal internal error, exec failed
 flex: error writing output file lex.yy.c
 configure:33007: $? = 1
 configure:33014: error: cannot find output from flex; giving up


 shell code nearby (configure):


 if test x$LEX != x:; then
 echo $as_me:$LINENO: checking lex output file root5
 echo $ECHO_N checking lex output file root... $ECHO_C6
 if test ${ac_cv_prog_lex_root+set} = set; then
 echo $ECHO_N (cached) $ECHO_C6
 else
 # The minimal lex program is just a single line: %%. But some broken lexes
 # (Solaris, I think it was) want two %% lines, so accommodate them.
 catconftest.l 5
 (eval $LEX conftest.l) 25
 ac_status=$?
 echo $as_me:$LINENO: \$? = $ac_status5
 (exit $ac_status); }
 if test -f lex.yy.c; then
 ac_cv_prog_lex_root=lex.yy
 elif test -f lexyy.c; then
 ac_cv_prog_lex_root=lexyy
 else
 { { echo $as_me:$LINENO: error: cannot find output from $LEX; giving up5
 echo $as_me: error: cannot find output from $LEX; giving up2;}
 { (exit 1); exit 1; }; }
 fi
 fi


 flex code nearby:


 /** Fork and exec entire filter chain.
 * @param chain The head of the chain.
 * @return true on success.
 */
 bool filter_apply_chain (struct filter * chain)
 {
 int pid, pipes[2];

 /* Tricky recursion, since we want to begin the chain
 * at the END. Why? Because we need all the forked processes
 * to be children of the main flex process.
 */
 if (chain)
 filter_apply_chain (chain-next);
 else
 return true;

 /* Now we are the right-most unprocessed link in the chain.
 */

 fflush (stdout);
 fflush (stderr);

 if (pipe (pipes) == -1)
 flexerror (_(pipe failed));

 if ((pid = fork ()) == -1)
 flexerror (_(fork failed));

 if (pid == 0) {
 /* child */

 /* We need stdin (the FILE* stdin) to connect to this new pipe.
 * There is no portable way to set stdin to a new file descriptor,
 * as stdin is not an lvalue on some systems (BSD).
 * So we dup the new pipe onto the stdin descriptor and use a no-op fseek
 * to sync the stream. This is a Hail Mary situation. It seems to work.
 */
 close (pipes[1]);
 if (dup2 (pipes[0], fileno (stdin)) == -1)
 flexfatal (_(dup2(pipes

Re: flex: exec failed? (root install/mount)

[Jay]

  [J] jay
  [C] corinna
  Subject: Re: flex: exec failed? (root install/mount)   


  [J] configure:10596: 
  /obj/gcc.5/i686-pc-cygwin/i686-pc-cygwin/build-i686-pc-cygwin/flex/flex 
  conftest.l   
  [J] strace: error creating process 
  D:\\obj/gcc.5/i686-pc-cygwin/i686-pc-cygwin/build-i686-pc-cygwin/flex/flex, 
  (error 3)  
  [J]   
  [J] which indicates the problem is:  
  [J]  $ mount  
  [J]  d:\bin on /usr/bin type system (binmode)  
  [J]  d:\lib on /usr/lib type system (binmode)  
  [J]  d: on / type system (binmode)  
  [J]  c: on /cygdrive/c type system (binmode,noumount)  
  [J]
  [J]  d: is being interpeted, as it is on Win32, as the current directory on 
  drive d,  
  [J]  and not, as intended here, as the root of d.  

  [C]  This is never the case in Cygwin.  The above error message occurs in   
  [C]  strace, which is not a Cygwin application, but a native Win32   
  [C]  application.
   
  Thanks Corinna. Good catch. I realize what you say, but on the other hand,  
  the mount stuff kind of lives in the transition zone between Win32  
  and the rest of Cygwin. Look, those are Win32 paths on the left, 
  and the theory I gave is reasonable, even if untrue. :)   

 
  However, I did later notice another problem.   
  After believing my theory, and reinstalling to c:\cygwin, 
  the error kept occuring.  
  (Oh, and yes, I stuck strace into the configure file).  


  Finally I remembered, that after the original problem, and noticing   
  that the gcc tree is apparently setup to build a bunch of stuff all together, 
  
  not just gcc, binutils, gmp, mpfr, but a bunch more, including flex,  
  I stuck the flex source in there as well. Figuring I'd maybe build  
  and debug it.Well, it appears the gcc's support for integrating  
  flex is actually not working.   


  Configuring binutils decides to run a flex that doesn't yet exist, if the 
source is there.  
  Looking in . and looking where configure thinks flex will be, while perhaps 
 
  different by a path element or two, to the very lazy/casual/careless/Jay 
observer -- same thing.  


  SO, I've deleted the flex source, and reinstalled to c:\cygwin, and I'll punt 
this for now.  
  I have symlinks /c = /cygdrive/c, /obj = /c/obj, etc.   


  At some point I should go back to c:\ (or d:\, whatever), keep flex source 
out,  
  and see what happens. I still think my theory is close to correct, but I  
  probably polluted the repro case before the later debugging, oops.   
  I'm sure I didn't put the flex code there until after I first had some 
problem.   
 

  Thanks,
   - Jay


--
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/

configuring the backspace key, etc. (un-indenting doesn't work with vim)

[Jay]

While Andrew's tone is a bit strong/rude, I do agree.
The keyboard should just work.
PC keyboards have been for a very long time now.

 
One of the obvious problems though is that there is never
any instant switch over from old days to modern times.
It is a continuum. It is gradual.
Looking backward from our current distant future, many
things look stupid, but they only ever get there gradually.
The teletype surely died off gradually, not instantly.
So how/when do you phase out support for it? How do you
have new code interoperate with the old code that
is sensitive to teletypes? Code lives a very long time of course.


How do you know removing support for something won't break someone?
Do you actively collect telemetry data as to the usage of everthing?
How close to zero is close enough?


When do you go back and remove workarounds for bugs at other layers, that
eventually got fixed? Nobody is still using your code along with the other?
Check versions and exit rudely? For old stuff? For anything you haven't 
tested?
For anything you haven't tested recently?
There are pluses and minuses. Blinding running ignoring the surrounds
is bad. You can't test every combination. You must be willing to run on stuff
you haven't tested.

 
Now, you know, an ironic thing here, is that Windows is the one
with a teletype compatibility that Unix folks/code don't like.

 
As I understand... there was a control code for a typewriter
to move the head (the carriage) to the start of the line,
and another for advancing the paper one line. As well, moving the head
took some time, so advancing the paper elegantly fill the gap.

 
Therefore you get carriage return followed by line feed.

 
Once you have electronic terminals, this separation is less
useful, but not actually useless (I'll come back to this).

 
So Unix folks arbitrarily chose linefeed.
Apple arbitrariliy chose carriage return (Apple II, pre-Mac OS X Mac).
Windows via MS-DOS presumably via CP/M didn't change.
A byte is wasted for every line darn.
 

Now, really, carriage return without line feed can be useful.
It is a way to implement spinners and other fancy ui
involving overwriting text on the same line.

 
I think linefeed might also be useful on its own, to go down one without
moving left or right. Not sure. Like maybe it is an optimization using
free form text ui such as vi, over a slow serial line??

 
I could be wrong here on the cr/lf story. Check Wikipedia...


  That's the price of using stuff without understanding it.  


  Oh man.  
  Let he who has not sinned cast the first stone..  
  Everyone uses stuff they don't understand all the time.
  I use my brain, lungs, cars, airplanes, compilers, linkers, kernels, 
interpreters, Cygwin, etc... 
  I imagine I understand a lot, but... 

 
 - Jay

--
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: cygwin Digest (multiple subjects)

[Jay]

 with that.

 - Jay

--
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/

FW: flex: exec failed?

[Jay]

 restrictions)


 I'll try to narrow it down and investigate more later myself.
 Like, currently I'm running the toplevel gcc configure.
 I'll have to try just gmp. Get it small enough and then strace and maybe gdb.
 For my current run I'll just remove the time/tee.


 - Jay

--
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: flex: exec failed? (root install/mount)

[Jay]

configure:10596: 
/obj/gcc.5/i686-pc-cygwin/i686-pc-cygwin/build-i686-pc-cygwin/flex/flex 
conftest.l
strace: error creating process 
D:\\obj/gcc.5/i686-pc-cygwin/i686-pc-cygwin/build-i686-pc-cygwin/flex/flex, 
(error 3)

which indicates the problem is:

$ mount
d:\bin on /usr/bin type system (binmode)
d:\lib on /usr/lib type system (binmode)
d: on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)


d: is being interpeted, as it is on Win32, as the current directory on drive d, 
and not, as intended here, as the root of d.
I tried unmounting it and explicitly mounting d:\, d:\\, d:/, but they still 
all got treated as d:.
Tried editing the registry, same thing. Used d:\foo also to make sure what I 
was doing was being seen by the code.

Another way to achieve what I want is for d:\cygwin to be an NTFS junction do 
d:\, but then I have circularities in my file system, which I'd rather avoid.

I know installing to the root is discouraged, but..agreed this is a bug? Should 
be fixed? It is easy to fix? I think so, on all counts.
I'm sure I can provide a patch.

The /cygdrive mounts must deal with this specially??

 - Jay

 From: [EMAIL PROTECTED]
 To: cygwin@cygwin.com
 Subject: FW: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:55:06 +

 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: flex: exec failed?
 Date: Wed, 16 Jul 2008 18:53:23 +


 anyone familiar with this:

 flex: fatal internal error, exec failed
 flex: error writing output file lex.yy.c

--
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/

some setup problems

[Jay]

I have found the following bugs all this evening (despite years of not seeing 
them :) )

1)
Attempting to install Cygwin to the root of a drive causes setup to silently 
exit.
I figured a stack overflow, but I tried running under a debugger and it doesn't 
occur there.
Hm. It occurs on a clean install, but not generally otherwise.
I'll try again under a debugger.

I know this isn't recommended.
But I get tired of constantly translating paths between Cygwin and Windows.
Windows accepts forward slashes often.
Therefore, if you install to the root, and you have just one drive letter,
no translation is needed.

I had been using junctions to workaround but wasn't entirely satisfactory.
Due to the crash, well, I'm using junctions again, but differently.

D:\cygwinfor /d %a in (*) do junction %a

D:\cygwin\bin: JUNCTION
   Substitute Name: D:\bin

D:\cygwin\etc: JUNCTION
   Substitute Name: D:\etc

D:\cygwin\lib: JUNCTION
   Substitute Name: D:\lib

D:\cygwin\tmp: JUNCTION
   Substitute Name: D:\tmp

D:\cygwin\usr: JUNCTION
   Substitute Name: D:\usr

D:\cygwin\var: JUNCTION
   Substitute Name: D:\var

I do use /bin, but I will avoid clash.
Nothing else I have seen in many years uses /usr, /etc, /var, to these are safe.
I have long used \dev2 instead of \dev due to that unfortunate use.

2)
Clicking on bash in setup causes setup to crash (unhandled exception).
I know this isn't useful -- I can't not install bash.
But it shouldn't crash setup.

3)
I have a bunch of packages locally.
I select install from local directory.
I click all to change it to install.
Yet still I am told one of the packages I am installing requires gcc-obj, do I 
want to
install it? Given that I selected install on the all node, this shouldn't 
happen.

Running it under a debugger shows a debugprint as to why:

: 1 Removing empty category KDELOG: 1 Removing empty category MailLOG: 1 Removin
g empty category MingwLOG: 1 Removing empty category PublishingLOG: 1 Removing e
mpty category SecurityLOG: 1 Removing empty category X11LOG: 2 Warning, the defa
ult trust level for package  does not meet this specification gcc-objcLOG: 2 War
ning, the default trust level for package  does not meet this specification gcc-
objc

4) Somehow my package directory defaulted to d:\ instead of d:\net\cygwin once.
I clicked next by accident.
There is no way in the gui to cancel the big directory walk -- have to kill 
setup.
Could be due to running under a debugger?


 - Jay

--
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: some setup problems

[Jay]

I have seen both these crashes several times, but now am unable to reproduce 
them. Oh well.

 - Jay




 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: some setup problems
 Date: Sun, 13 Jul 2008 08:34:25 +


 I have found the following bugs all this evening (despite years of not seeing 
 them :) )

 1)
 Attempting to install Cygwin to the root of a drive causes setup to silently 
 exit.
 I figured a stack overflow, but I tried running under a debugger and it 
 doesn't occur there.
 Hm. It occurs on a clean install, but not generally otherwise.
 I'll try again under a debugger.

 I know this isn't recommended.
 But I get tired of constantly translating paths between Cygwin and Windows.
 Windows accepts forward slashes often.
 Therefore, if you install to the root, and you have just one drive letter,
 no translation is needed.

 I had been using junctions to workaround but wasn't entirely satisfactory.
 Due to the crash, well, I'm using junctions again, but differently.

 D:\cygwinfor /d %a in (*) do junction %a

 D:\cygwin\bin: JUNCTION
 Substitute Name: D:\bin

 D:\cygwin\etc: JUNCTION
 Substitute Name: D:\etc

 D:\cygwin\lib: JUNCTION
 Substitute Name: D:\lib

 D:\cygwin\tmp: JUNCTION
 Substitute Name: D:\tmp

 D:\cygwin\usr: JUNCTION
 Substitute Name: D:\usr

 D:\cygwin\var: JUNCTION
 Substitute Name: D:\var

 I do use /bin, but I will avoid clash.
 Nothing else I have seen in many years uses /usr, /etc, /var, to these are 
 safe.
 I have long used \dev2 instead of \dev due to that unfortunate use.

 2)
 Clicking on bash in setup causes setup to crash (unhandled exception).
 I know this isn't useful -- I can't not install bash.
 But it shouldn't crash setup.

 3)
 I have a bunch of packages locally.
 I select install from local directory.
 I click all to change it to install.
 Yet still I am told one of the packages I am installing requires gcc-obj, do 
 I want to
 install it? Given that I selected install on the all node, this shouldn't 
 happen.

 Running it under a debugger shows a debugprint as to why:

 : 1 Removing empty category KDELOG: 1 Removing empty category MailLOG: 1 
 Removin
 g empty category MingwLOG: 1 Removing empty category PublishingLOG: 1 
 Removing e
 mpty category SecurityLOG: 1 Removing empty category X11LOG: 2 Warning, the 
 defa
 ult trust level for package does not meet this specification gcc-objcLOG: 2 
 War
 ning, the default trust level for package does not meet this specification 
 gcc-
 objc

 4) Somehow my package directory defaulted to d:\ instead of d:\net\cygwin 
 once.
 I clicked next by accident.
 There is no way in the gui to cancel the big directory walk -- have to kill 
 setup.
 Could be due to running under a debugger?


 - Jay

--
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: Re: need help with bash -c command with cygpath

[Jay]

 H:\C:\cygwin\bin\bash -v -c 'UNC_PATH\\Dir'
 
 (actually only the first really needs to be doubled, because \ has
 no special meaning if it's followed by a letter)
 
 Phil
 
 

I'm getting the path from the registry via a right click menu and passing it
into the bash -c command.  
But the leading slash is getting removed on UNC paths.  
I think i'm going to have to sed it.








--
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: need help with bash -c command with cygpath

[Jay]

 That's still somewhat wasteful, starting bash just to get a vim alias -
 why not use the full name gvim, and bypass the bash process to begin with?

you right, i'm going to remove it, thanks.

My main problem now is that for some reason the leading backslash on UNC names
is getting dropped when calling bash -c from the windows command prompt, even
when using just single quotes.  So if you run this from a windows command 
prompt:

H:\C:\cygwin\bin\bash -v -c '\\UNC_PATH\Dir'
\UNC_PATH\Dir   --Leading backslash dropped
/usr/bin/bash: UNC_PATHDir: command not found

It drops off the leading backslash.

When you run it from Cygwin bash:
bash -v -c '\\UNC_PATH\Dir'
\\UNC_PATH\Dir   --The leading backslash is preserved.
bash: \UNC_PATHDir: command not found

I know i can make it work by piping the path into sed, but I'm just wondering
why i'm losing the leading backslash when running from windows.

Maybe dos is passing in the single quotes as double quotes.

Thanks again for the help.


--
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: need help with bash -c command with cygpath

[Jay]

Eric Blake ebb9 at byu.net writes:

 
 
 According to Dave Korn on 1/11/2008 9:38 AM:
 |   I believe what is needed is 1) outer double-quotes, for cmd's benefit, 2)
 | inner single-quotes, for bash's benefit, 3) double up the slashes /as well/,
 | because there's one more level of quoting being stripped than I can account
 | for, but anyway it works for me:
 |
 | C:\Documents and Settings\dkC:\cygwin\bin\bash -v -x -c
 'UNC_PATH\\Dir'
 | '\\UNC_PATH\Dir'
 | + '\\UNC_PATH\Dir'
 | /usr/bin/bash: \\UNC_PATH\Dir: command not found
 
 '\\' - the  quotes are stripped and \\ collapsed by cmd.exe = '\'
 '\' - the ' quotes are stripped by bash on execution = \
 
 |   If I wasn't trying to execute a directory but list it instead, I'd say
 |
 | C:\cygwin\bin\bash -v -x -c ls -la 'UNC_PATH\\Dir'
 
 Which means:
 
 bash -vxc ls -la UNC_PATHDir
 
 will also work (8 leading \ converted to 4 by cmd, then 4 converted to 2
 by bash, so that ls sees an argument with 2 leading \).

Thanks everyone for the help.  Since i'm getting the path from the registry i
can't add in the extra backslashes without using sed.  I ended up with this
registy key which seems to work for local drives as well as network drives
(UNCs) (haven't tested files with special characters).

(manually typed into the registry)
C:\cygwin\bin\bash -v -c /usr/bin/head \$(/usr/bin/echo '%1' | /usr/bin/sed
's#^\(\w\)#\1#;s#\\\#\/#g')\ | /cygdrive/c/John/Tools/vim/gvim.exe
-R - 

Here is the regfile if anyone wants to try it out.  You will prob need to change
your path to gvim, or just use the path to cygwin vim.

--START REGFILE---
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\Head2Vim]

[HKEY_CLASSES_ROOT\*\shell\Head2Vim\Command]
@=C:\\cygwin\\bin\\bash -v -c \/usr/bin/head \\\$(/usr/bin/echo '%1' |
/usr/bin/sed 's#^\\(\\w\\)#\\1#;s#\\#\\/#g')\\\ |
/cygdrive/c/John/Tools/vim/gvim.exe -R -\ 

--END REGFILE--
 




--
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: need help with bash -c command with cygpath

[Jay]

 Whoa - it seldom makes sense to use -i and -c simultaneously - what good

What i'm actually trying to do is have a right-click menu in windows so that
when i right click on a file i can choose head from the context menu, and it
will send the top 10 lines of the file to vim.  I have gvim (windows version)
aliased in my .bashrc so that's why i'm using the -i switch.

What i have done is created the following registry key:
[HKEY_CLASSES_ROOT\*\shell\Head\Command]
with the (default) value set to: 
C:\CYGWIN\bin\bash -i -c head $(cygpath -a '%1') | vim -R -

This works perfectly for local files, but does not work at all for network
shares via UNCs due to the problem stated earlier.

 bash -c cygpath -a ''\\uncpath\mydrive$'\'

This works! but i can't figure out how to make it work for this scenario

bash -i -c head $(cygpath -a 
'\\gandy1\rjapps$\Subsidiarypayroll\Web.config'')

Maybe i have the quotes messed up, or maybe i'm going about doing this all 
wrong.

 By the way, none of this tutorial on shell quoting is cygwin specific.

Thanks again for the help.  






--
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/

need help with bash -c command with cygpath

[Jay]

When i run
cygpath -a '\\uncpath\mydrive$'
//uncpath/mydrive$

Which is the expected behaivor.

When i run
bash -i -c cygpath -a '\\uncpath\mydrive$'
/C/uncpath/mydrive$

Which is not what i want.  I'm trying to pass in the unc path from windows, so
it needs converted.

Why do i get different results depending on how it is called? 

Thanks in advance.

Jay.


--
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: need help with bash -c command with cygpath

[Jay]

 It's because of the way the backslash is handled within double quotes.
 
 info bash may be of some help.
 
 cgf
 
 

Thanks for the help.  I read the info.  Looks like i will have to pass the UNC
path into a script and do the work there.

Thanks again.



--
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: xterm not accepting Window Title name changes

[Jay Abel]

Found this somewhere along the way, I forgot where.  Works on my
machine.  I did notice that the cd command on my machine does meddle
with the prompt string and send it to xterm.  Sorry I can't be more
helpful.

#!/usr/bin/perl
#
# This is a simple program to change the text in an X-windows title bar.
# This used to be a shell script, but that got hosed in an ``update''
# on Linux.  It's probably a Good Idea(tm) to do this in perl anyway since
# the my program could be vulnerable to somebody putting something really
# wierd in as arguments.
#
print qq(\033]2;@ARGV\007);
exit(0)


On 10/22/07, Paul McFerrin [EMAIL PROTECTED] wrote:

 Hum...  The PS1 setting. Nope, that's not the problem.

 The root of the settitle() function is NOT the setting of PS1.  It's
 setting in /etc/profile is commented out.  In my local .profile, PS1 is
 set to just '$PWD'.  I have verified that there are no other hidden
 settings of PS1.

 I tried your settitle() function, and the title remains unchanged:
 basename of the shell.

 My posting in the archives envolves the use of 'rxvt' only and has
 nothing to do with xterm.  I always startup 'startxwin.sh' from a
 non-rxvt window (e.g. the console window).

 Regardless what shell I'm using, it always seems to get it's basename
 into the window.  Hum

 Does anyone else want to try a stab at this problem?

 Brian Dessent wrote:
  Paul McFerrin wrote:
 
 
  I can't seem to get xterm to recognize Window Title name changes via the
  following:
 
  echo \0332;new_title\07\c
 
 
  You were just recently posting in the thread where this came up before:
  http://cygwin.com/ml/cygwin/2007-10/threads.html#00188 and
  http://cygwin.com/ml/cygwin/2007-10/msg00202.html.  Specifically, the
  default Cygwin prompt (PS1) contains characters that set the title so
  anything you do that doesn't involve changing PS1 will have no effect --
  or more precisely, your echo command above does set the title for a few
  milliseconds, until the next prompt overwrites it.   (In your rxvt
  example, you aren't starting a login shell and thus /etc/profile isn't
  sourced and PS1 isn't set, which is presumably why it works there.)
 
  Brian
 
  --
  Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
  Problem reports:   http://cygwin.com/problems.html
  Documentation: http://x.cygwin.com/docs/
  FAQ:   http://x.cygwin.com/docs/faq/
 
 

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



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

Re: XWin starts but hangs as soon as I start an X-application

[Jay Abel]

I'm having similar trouble, starting yesterday.  xterm and xclock both
hang as described, but xeyes, xfig and rxvt all work.

On 8/17/07, Larry Hall (Cygwin X) [EMAIL PROTECTED] wrote:
 Olumide wrote:
  Hi -
 
  Yesterday, I started my X server as usual and followed by an
  X-application (gnuplot), which refused to start up. At the same time the
  XWin process stopped working, in fact it had stopped page faulting. On
  terminating the XWin process I got the following message
 
  XIO:  fatal IO error 104 (Connection reset by peer) on X server
  127.0.0.1:0.0 (IP address changed)
after 0 requests (0 known processed) with 0 events remaining.
 

 snip

 
  All of this is really strange. The only change/installation I made to my
  system yesterday was to install a logitech webcam.

 Remove it again.  I think you'll find that solves the problems you were
 seeing.  Logitech drivers are known to cause problems.  Cygwin is one of
 its lucky affected applications.  Search the email list archives for dodgy
 apps to find a list of software with buggy versions which can cause
 problems like this.


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

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



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

Re: XWin starts but hangs as soon as I start an X-application

[Jay Abel]

I can no longer reproduce the problem.  Whatever it was, it seems to
have sorted itself out in that queasy just try rebooting 50 times
way that windows 'fixes' iteself.

Gah.

On 8/18/07, Jay Abel [EMAIL PROTECTED] wrote:
 Yikes.  I turned off VirusScan on-access and buffer overflow checking,
 then xterm ran.  So happy it was running, I forgot what I was doing
 and fixed some missing fields in my .xdefaults file (changed Xterm to
 xterm) and opened another window.  No problem.  xclock now runs, no
 problem.  Re-enable buffer overflow and access scan, and guess what?
 they both still work.  Put back configuration file.  Still works.
 wtf?

 I'll try rebooting and see if the problem reappears.

 On 8/18/07, Jay Abel [EMAIL PROTECTED] wrote:
  On 8/18/07, Larry Hall (Cygwin X) [EMAIL PROTECTED] wrote:
   Jay Abel wrote:
I'm having similar trouble, starting yesterday.  xterm and xclock both
hang as described, but xeyes, xfig and rxvt all work.
  
   And have you installed any dodgy app recently?
  
   --
   Larry Hall  http://www.rfk.com
   RFK Partners, Inc.  (508) 893-9779 - RFK Office
   216 Dalton Rd.  (508) 429-6305 - FAX
   Holliston, MA 01746
 
  Not recently, but I'm checking now.  I do have an evil logitech mouse,
  but I thought I forced it to use the stock ms drivers.  It's possible
  that I already have the unwanted/conflicting software, but that it
  wasn't a problem until I upgraded to the most recent cygwin1.dll.
  I'll see if I can find the list of evil applications then check if I
  have any of them installed, and also try using an older cygwin.dll to
  see if the problem disappears.
 
  I noticed that in the case of xterm, its associated shell also starts
  and the xterm process cannot be killed until the corresponding shell
  has also been killed, not from taskmanager, cygwin, etc.  On the other
  hand, even typing 'xterm -version' hangs before any output is
  produced.  It's almost as if the output pipe isn't being created
  properly, but ps doesn't show xterm in the I state.  What I'm trying
  to say is that the problem seems to happen when output is produced.
  Note that even if the $DISPLAY variable isn't set, xterm still hangs
  (you'd expect it to spit out an error message and die).  So I'd wager
  the problem is related to writing to stdout, not to X.
 
  I'll take another look to see if I have any of the non-recommended
  applications, such as logitech stuff, that might be interfering.
 


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