RE: New windows from cygwin in ssh

[Pavel Ivanoff]

As I understand "Allow service to interact with desktop" is exactly what
I want. But this checkbox is active only when service los on as SYSTEM
but my sshd logs on as me. And installing the service with '-i' option
said to me the same: "cygrunsrv: --interactive not allowed with --user".
Is there any solution to this problem? Or I must run service as SYSTEM
to have this functions usable?

Pavel Ivanov

> -Original Message-
> From: Igor Peshansky
> Sent: Tuesday, September 26, 2006 4:27 PM
> To: Pavel Ivanoff
> Subject: RE: New windows from cygwin in ssh
> 
> You weren't clear on exactly what you want to happen.  If you 
> wish to see
> the window pop up on the remote machine's desktop, you need to add the
> "Allow service to interact with desktop" checkmark in the sshd service
> description (or, alternatively, install it with the '-i' 
> cygrunsrv flag).
> 
> If you want the window to be forwarded over to the local 
> machine (i.e.,
> the one you're ssh'ing from), that is not currently possible 
> with Windows.
> One thing you can try is use a tool like VNC (which you can 
> forward over
> ssh, too).
> HTH,
>   Igor

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

gdb with X-win problem

[Wynfield Henman]

I am not able to get the new gdb to handle any x-window applications
or even on the non-x window invocation of emacs.

Does anyone else have this problem.


From zsh


Attaching to program `/usr/local/bin/xv.exe', process 2772
zsh: suspended (tty output)  gdb xv 2940


From bash


(gdb) attach 2340
Attaching to process 2772

[1]+  Stopped gdb
bash-3.1$


then when used from a terminal window I get
gdb emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /bin/emacs.exe
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw-8.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXp-6.dll
Loaded symbols for /usr/X11R6/bin/cygXau-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll

emacs: standard input is not a tty

Program exited with code 01.
(gdb) C

---

Any comments are welcome.

Thanks,
 Henman

--
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: Potential bug in sshd

[Dave Korn]

  I was sent the following mail off-list, and am forwarding it (with
permission), because it contains a useful workaround for people having
problems with McAffee: disable the "buffer overrun protection".


On 27 September 2006 11:40, Michael Teske wrote:

> Hi!
> 
> I'm not subscribed to the cygwin mailing list but found your message in
> http://www.mail-archive.com/cygwin@cygwin.com/msg72341.html
> while searching "linked dll data write copy failed" on google. I just
> wanted to report a similar problem, that happens if sshd runs together
> with McAffee virus checker. Somehow then sshd has the same problems -
> only after reboot, not if restarted later. The problems vanish if one
> disables the "buffer overrun protection".
> My suspicion is that this happens because sshd is started before the
> McAffee service and thus McAffee gets confused. Unfortunately there's no
> way to determine the starting order of services...
> 
> Greetings,
>   Michael


  Not being a McAffee user[*], (and not often running a sshd on my own box), I
haven't been able to test this, but it seems worth trying for anyone who's
having sshd problems that might be related.

cheers,
  DaveK

[*] - to put it mildly!
-- 
Can't think of a witty .sigline today


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

RE: New windows from cygwin in ssh

[Igor Peshansky]

Ugh, top-posting...  Reformatted.

On Wed, 27 Sep 2006, Pavel Ivanoff wrote:

> > -Original Message-
> > From: Igor Peshansky
> > Sent: Tuesday, September 26, 2006 4:27 PM
> > To: Pavel Ivanoff
> > Subject: RE: New windows from cygwin in ssh
> >
> > You weren't clear on exactly what you want to happen.  If you wish to
> > see the window pop up on the remote machine's desktop, you need to add
> > the "Allow service to interact with desktop" checkmark in the sshd
> > service description (or, alternatively, install it with the '-i'
> > cygrunsrv flag).
> >
> > If you want the window to be forwarded over to the local machine
> > (i.e., the one you're ssh'ing from), that is not currently possible
> > with Windows.  One thing you can try is use a tool like VNC (which you
> > can forward over ssh, too).
>
> As I understand "Allow service to interact with desktop" is exactly what
> I want. But this checkbox is active only when service los on as SYSTEM
> but my sshd logs on as me. And installing the service with '-i' option
> said to me the same: "cygrunsrv: --interactive not allowed with --user".
> Is there any solution to this problem? Or I must run service as SYSTEM
> to have this functions usable?

I'm afraid so.  It's unclear why Windows imposes this restriction, but if
your sshd is running as a non-SYSTEM user, it can't interact with the
desktop.  I was going to suggest using "cygstart", but even that
apparently doesn't work as-is.  It probably can be patched up to obtain
the current window station and ask the shell to execute the program there,
but .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: New windows from cygwin in ssh

[Pavel Ivanoff]

> I'm afraid so.  It's unclear why Windows imposes this 
> restriction, but if
> your sshd is running as a non-SYSTEM user, it can't interact with the
> desktop.  I was going to suggest using "cygstart", but even that
> apparently doesn't work as-is.  It probably can be patched up 
> to obtain
> the current window station and ask the shell to execute the 
> program there,
> but .

But in combination cygwin of 01.03.2005 + Windows 2000 this feature
works as intended. What is it: new security prohibition of Windows XP or
new feature of last version of cygwin?
I know that there are many security features added in new sshd (that I
had to recognize when reinstalled cygwin). This is another one that
can't be solved to work as it was?
 
Pavel Ivanov


> -Original Message-
> From: Igor Peshansky
> Sent: Wednesday, September 27, 2006 4:59 PM
> To: Pavel Ivanoff
> Subject: RE: New windows from cygwin in ssh
> 
> Ugh, top-posting...  Reformatted.
> 
> On Wed, 27 Sep 2006, Pavel Ivanoff wrote:
> 
> > > -Original Message-
> > > From: Igor Peshansky
> > > Sent: Tuesday, September 26, 2006 4:27 PM
> > > To: Pavel Ivanoff
> > > Subject: RE: New windows from cygwin in ssh
> > >
> > > You weren't clear on exactly what you want to happen.  If 
> you wish to
> > > see the window pop up on the remote machine's desktop, 
> you need to add
> > > the "Allow service to interact with desktop" checkmark in the sshd
> > > service description (or, alternatively, install it with the '-i'
> > > cygrunsrv flag).
> > >
> > > If you want the window to be forwarded over to the local machine
> > > (i.e., the one you're ssh'ing from), that is not 
> currently possible
> > > with Windows.  One thing you can try is use a tool like 
> VNC (which you
> > > can forward over ssh, too).
> >
> > As I understand "Allow service to interact with desktop" is 
> exactly what
> > I want. But this checkbox is active only when service los 
> on as SYSTEM
> > but my sshd logs on as me. And installing the service with 
> '-i' option
> > said to me the same: "cygrunsrv: --interactive not allowed 
> with --user".
> > Is there any solution to this problem? Or I must run 
> service as SYSTEM
> > to have this functions usable?
> 
> I'm afraid so.  It's unclear why Windows imposes this 
> restriction, but if
> your sshd is running as a non-SYSTEM user, it can't interact with the
> desktop.  I was going to suggest using "cygstart", but even that
> apparently doesn't work as-is.  It probably can be patched up 
> to obtain
> the current window station and ask the shell to execute the 
> program there,
> but .
>   Igor
> -- 

--
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: FW: Potential bug in sshd

[Igor Peshansky]

On Wed, 27 Sep 2006, Dave Korn wrote:

>
>   I was sent the following mail off-list, and am forwarding it (with
> permission), because it contains a useful workaround for people having
> problems with McAffee: disable the "buffer overrun protection".
>
> On 27 September 2006 11:40, Michael Teske wrote:
>
> > Hi!
> >
> > I'm not subscribed to the cygwin mailing list but found your message in
> > http://www.mail-archive.com/cygwin@cygwin.com/msg72341.html
> > while searching "linked dll data write copy failed" on google. I just
> > wanted to report a similar problem, that happens if sshd runs together
> > with McAffee virus checker. Somehow then sshd has the same problems -
> > only after reboot, not if restarted later. The problems vanish if one
> > disables the "buffer overrun protection".
> > My suspicion is that this happens because sshd is started before the
> > McAffee service and thus McAffee gets confused. Unfortunately there's no
> > way to determine the starting order of services...
> >
> > Greetings,
> > Michael
>
>
>   Not being a McAffee user[*], (and not often running a sshd on my own
> box), I haven't been able to test this, but it seems worth trying for
> anyone who's having sshd problems that might be related.
>
> cheers,
>   DaveK
>
> [*] - to put it mildly!

FWIW, there *is* a way to determine the starting order of services -- make
one depend on the other.  So, in this case, add McAfee to the dependencies
of the sshd service (using the -y cygrunsrv option).

Dave, I can't Cc: Michael, and he's not on-list -- can you forward this to
him or point him at the archived message?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Install hangs

[Larry Hall (Cygwin)]

Artie Ziff wrote:

Is there an example of log file (posted somewhere) that illustrates
what a successful cygwin installation looks like?



Not that I recall, at least in terms of "here's a good log for your
reference".  I'd suggest just posting your log and letting people
here point out errors or lack thereof.


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

--
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: gdb with X-win problem

[Larry Hall (Cygwin)]

Wynfield Henman wrote:

I am not able to get the new gdb to handle any x-window applications
or even on the non-x window invocation of emacs.

Does anyone else have this problem.


From zsh


Attaching to program `/usr/local/bin/xv.exe', process 2772
zsh: suspended (tty output)  gdb xv 2940


From bash


(gdb) attach 2340
Attaching to process 2772

[1]+  Stopped gdb
bash-3.1$


then when used from a terminal window I get
gdb emacs
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /bin/emacs.exe
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygjpeg-62.dll
Loaded symbols for /usr/bin/cygpng12.dll
Loaded symbols for /usr/bin/cygz.dll
Loaded symbols for /usr/bin/cygtiff-5.dll
Loaded symbols for /usr/bin/cygungif-4.dll
Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
Loaded symbols for /usr/X11R6/bin/cygXaw-8.dll
Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
Loaded symbols for /usr/X11R6/bin/cygXp-6.dll
Loaded symbols for /usr/X11R6/bin/cygXau-6.dll
Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll

emacs: standard input is not a tty

Program exited with code 01.
(gdb) C

---

Any comments are welcome.



What does you CYGWIN environment variable look like?  For that matter,
.


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

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

Problems with bind and UDP server

[Anonymous]

Hello,

I saw these series of posts on UDP - was there a conclusion to them?

http://cygwin.com/ml/cygwin/2006-06/msg00701.html
http://cygwin.com/ml/cygwin/2006-06/msg00703.html
http://cygwin.com/ml/cygwin/2006-06/msg00705.html
http://cygwin.com/ml/cygwin/2006-06/msg00706.html

I compile and run net-snmp under cygwin (I have net-snmp 5.3.0.1).
The server snmpd by default uses UDP port 161. I now have the most
recent cygwin DLL and the server snmpd seems no longer to work.

I think I tracked down the problem to the bind command. For a 
"very simple test" I used Beej's socket programming examples.
I give the listings at the end of the message.

http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html#listen

The listener program works fine on regular Linux and with older
cygwin DLLs . but under the latest it returns an error.
Has something changed?

Many Thanks,

Mark.

-
reply-to:[EMAIL PROTECTED]
replace the I_HATE_SPAM.nowhere with
schmid-telecom.com to get my real email address
-

listener.c

/*
** listener.c -- a datagram sockets "server" demo
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define MYPORT 4950 // the port users will be connecting to

#define MAXBUFLEN 100

int main(void)
{
int sockfd;
struct sockaddr_in my_addr; // my address information
struct sockaddr_in their_addr; // connector's address information
socklen_t addr_len;
int numbytes;
char buf[MAXBUFLEN];

if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
perror("socket");
exit(1);
}

my_addr.sin_family = AF_INET;// host byte order
my_addr.sin_port = htons(MYPORT);// short, network byte order
my_addr.sin_addr.s_addr = INADDR_ANY; // automatically fill with my IP
memset(&(my_addr.sin_zero), '\0', 8); // zero the rest of the struct

if (bind(sockfd, (struct sockaddr *)&my_addr,
sizeof(struct sockaddr)) == -1) {
perror("bind");
exit(1);
}

addr_len = sizeof(struct sockaddr);
if ((numbytes = recvfrom(sockfd, buf, MAXBUFLEN-1 , 0,
(struct sockaddr *)&their_addr, &addr_len)) == -1) {
perror("recvfrom");
exit(1);
}

printf("got packet from %s\n",inet_ntoa(their_addr.sin_addr));
printf("packet is %d bytes long\n",numbytes);
buf[numbytes] = '\0';
printf("packet contains \"%s\"\n",buf);

close(sockfd);

return 0;
}


talker.c


/*
** talker.c -- a datagram "client" demo
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define SERVERPORT 4950 // the port users will be connecting to

int main(int argc, char *argv[])
{
int sockfd;
struct sockaddr_in their_addr; // connector's address information
struct hostent *he;
int numbytes;

if (argc != 3) {
fprintf(stderr,"usage: talker hostname message\n");
exit(1);
}

if ((he=gethostbyname(argv[1])) == NULL) {  // get the host info
perror("gethostbyname");
exit(1);
}

if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
perror("socket");
exit(1);
}

their_addr.sin_family = AF_INET; // host byte order
their_addr.sin_port = htons(SERVERPORT); // short, network byte order
their_addr.sin_addr = *((struct in_addr *)he->h_addr);
memset(&(their_addr.sin_zero), '\0', 8);  // zero the rest of the struct

if ((numbytes = sendto(sockfd, argv[2], strlen(argv[2]), 0,
 (struct sockaddr *)&their_addr, sizeof(struct 
sockaddr))) == -1) {
perror("sendto");
exit(1);
}

printf("sent %d bytes to %s\n", numbytes, 
inet_ntoa(their_addr.sin_addr));

close(sockfd);

return 0;
}



--
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 configure cron's mail?

[Harig, Mark]

> -Original Message-
> Sent: Tuesday, September 26, 2006 11:50 PM
> To: Cygwin Users
> Subject: How to configure cron's mail?
> 
> Hi,
> 
> Can I configure where cron sends the mail to? It seems to be
> "[EMAIL PROTECTED]", where user is the account cron is running 
> under, but I
> would like it to go to "[EMAIL PROTECTED]".
> 
> 

cygcheck -l cron
cygcheck -l ssmtp

See then the Cygwin-specific README files in /usr/share/doc/Cygwin/.

---

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

make 3.81-1 problems with DOS-paths

[Knut Schwichtenberg]

Hi,

I've udated on 14.Sep.06 my Cygwin make to 3.81-1. The C-project I was compiling 
 generated dependency files including system files. For system files the full 
path in DOS notation is entered into the dependency file. Make stops the 
execution of the makefile with the "very" expressive message: "multiple target 
patterns.  Stop." Digging around with gdb and the source code I found out a 
missing define at compile time of make. The define "HAS_DOS_PATHS" was not set 
in the makefie for make. Version 3.80 of make ran without problems and setting 
this switch makes 3.81 run without a problem.


How is it possible that ./configure does not recognize the Cygwin environment 
properly for a Windows-PC? Is the missing define only a derived problem that is 
based on an error in the toolchain before?


While finding the problem and the solution - and of course better gcc switches 
to avoid absolute pathes for system include - I have no problem at the moment, 
but that took me quiet a while.


Cheers

Knut

--
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: Problems with archiver "ar"

[Frank Illenseer]

Sorry - for not providing all infos...

I did some additional tests: When mounting my drives in "binmode" the error 
is gone and when mounting them in "textmode" the error is there.


But due to the newest bash update, I rather need "textmode" to re-use my 
existing scripts without conversion, as the come from a revision control 
system which always generates the EOLs according to the underlying system.


What I am doing is basically to compile "f2c" into a library...

Additional information for my cygwin installation is attached.

Do you have any further questions or do you require any further information?



Cygwin Configuration Diagnostics
Current System Time: Wed Sep 27 19:24:15 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\Programme\cygwin\bin
C:\Programme\cygwin\usr\local\bin
C:\Programme\cygwin\bin
C:\Programme\cygwin\bin
C:\Programme\cygwin\usr\X11R6\bin
c:\Programme\MiKTeX 2.5\miktex\bin
c:\Programme\Windows Resource Kits\Tools\
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
C:\Programme\cygwin
C:\Programme\cygwin\bin
c:\Programme\emacs-21.3
c:\Programme\emacs-21.3\bin
c:\Programme\AccuRev\bin
c:\Programme\Gemeinsame Dateien\GTK\2.0\bin
c:\Programme\WinXP Support Tools
c:\Programme\FEKO\bin
c:\Programme\FEKO\InterOp\code\bin
c:\DATA-FI\bin
C:\Programme\cygwin\lib\lapack

Output from C:\Programme\cygwin\bin\id.exe (nontsec)
UID: 1003(illenseer) GID: 513(Kein)
513(Kein)544(Administratoren) 545(Benutzer)

Output from C:\Programme\cygwin\bin\id.exe (ntsec)
UID: 1003(illenseer) GID: 513(Kein)
513(Kein)544(Administratoren) 545(Benutzer)

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

USER = 'illenseer'
PWD = '/cygdrive/c/Data-FI'
HOME = '/cygdrive/c/Data-FI'
MAKE_MODE = 'unix'

HOMEPATH = '\Dokumente und Einstellungen\illenseer'
MANPATH = 
'/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man:/usr/X11R6/man'

APPDATA = 'C:\Dokumente und Einstellungen\illenseer\Anwendungsdaten'
HOSTNAME = 'fi-win'
VS71COMNTOOLS = 'C:\Programme\Microsoft Visual Studio .NET 
2003\Common7\Tools\'

INTEL_LICENSE_FILE = 'C:\Programme\Gemeinsame Dateien\Intel\Licenses'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 31 Stepping 0, AuthenticAMD'
WINDIR = 'C:\WINDOWS'
VS80COMNTOOLS = 'C:\Programme\Microsoft Visual Studio 8\Common7\Tools\'
DIRCMD = '/a /o'
TEXDOCVIEW_txt = 'cygstart %s'
TEXDOCVIEW_dvi = 'cygstart %s'
OLDPWD = '/usr/bin'
USERDOMAIN = 'FI-WIN'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Dokumente und Einstellungen\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOKUME~1/ILLENS~1/LOKALE~1/Temp'
COMMONPROGRAMFILES = 'C:\Programme\Gemeinsame Dateien'
USERNAME = 'illenseer'
COLUMNS = '80'
TEXDOCVIEW_pdf = 'cygstart %s'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
__COMPAT_LAYER = 'EnableNXShowUI '
TEXDOCVIEW_html = 'cygstart %s'
USERPROFILE = 'C:\Dokumente und Einstellungen\illenseer'
LANG = 'en'
CLIENTNAME = 'Console'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\FI-WIN'
LINES = '82'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\Programme\cygwin\bin'
PS2 = '> '
SHLVL = '1'
PS4 = '+ '
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
FEKO_USER_HOME = 'C:\Programme\FEKO'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOKUME~1/ILLENS~1/LOKALE~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'Samsung CLP-510N'
PROCESSOR_REVISION = '1f00'
CVS_RSH = '/bin/ssh'
FEKOLANG = 'e'
FEKO = 'C:\Programme\FEKO\bin'
PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig'
TEXDOCVIEW_ps = 'cygstart %s'
INFOPATH = 
'/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'

PROGRAMFILES = 'C:\Programme'
NUMBER_OF_PROCESSORS = '1'
SESSIONNAME = 'Console'
COMPUTERNAME = 'FI-WIN'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.inc_Win32_Cygnus_mpich
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.inc_Win32_Cygnus_mpich\OpenWithList
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.inc_Win32_Cygnus_mpich2
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.inc_Win32_Cygnus_mpich2\OpenWithList
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
 (default) = '/cygdrive'
 cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
 (default) = 'C:\Programme\c

Re: make 3.81-1 problems with DOS-paths

[mwoehlke]

Knut Schwichtenberg wrote:
I've udated on 14.Sep.06 my Cygwin make to 3.81-1. The C-project I was 
compiling  generated dependency files including system files. For system 
files the full path in DOS notation is entered into the dependency file. 
Make stops the execution of the makefile with the "very" expressive 
message: "multiple target patterns.  Stop." Digging around with gdb and 
the source code I found out a missing define at compile time of make. 
The define "HAS_DOS_PATHS" was not set in the makefie for make. Version 
3.80 of make ran without problems and setting this switch makes 3.81 run 
without a problem.


How is it possible that ./configure does not recognize the Cygwin 
environment properly for a Windows-PC? Is the missing define only a 
derived problem that is based on an error in the toolchain before?


If you'd STFLA'd (LA = List Archives), you'd know that this was the 
subject of Cygwin's most recent Holy War. IIRC "HAS_DOS_PATHS" is a 
broken solution, which is why it was not (and as I understand, never 
was) defined for Cygwin. Instead there was a kludgy patch in place that 
CGF decided to stop maintaining (which generated a lot of irate users... 
and a new upstream patch, which I thought was in the latest available 
package?).


So if someone that knows what the status of said package would kindly 
step in now? (Or you can STFLA...)


In short: make 3.81 intentionally removed support for DOS paths; use 
make 3.80 or the newer version (make-3.81-2?).


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: make 3.81-1 problems with DOS-paths

[Christopher Faylor]

On Wed, Sep 27, 2006 at 12:59:03PM -0500, mwoehlke wrote:
>In short: make 3.81 intentionally removed support for DOS paths; use 
>make 3.80 or the newer version (make-3.81-2?).

http://cygwin.com/ml/cygwin/2006-09/msg00315.html

--
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 configure cron's mail?

[René Berber]

René Berber wrote:

> Joost Kraaijeveld wrote:
> 
>> Can I configure where cron sends the mail to? It seems to be 
>> "[EMAIL PROTECTED]", where user is the account cron is running under,
>> but I would like it to go to "[EMAIL PROTECTED]".
> 
> Yes, in /etc/ssmtp/ssmtp.conf, but when you install the ssmtp package
> you are supposed to run ssmtp-config.  Anyway you can edit the file,
> just define root and rewriteDomain so that cron uses those.

I forgot to add that there is a second option: specify MAILTO inside crontab.

In fact that is a more flexible option, you could make cron send emails to 
several addresses, also to different ones for each job.
-- 
René Berber


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

tcgetattr problem

[ahnkle]

hi

I wrote a small program to test some serial stuff. I was puzzled because I 
recall
that I was able to set baud rate on a serial port before, but now I cannot.

I call tcgetattr() after I open the serial port, but it fails (the tcsetattr() 
also
fails which first got my attention).

I enclose a short example, and cygwin details, too. Any ideas?

regards,
ahnkle


Cygwin Configuration Diagnostics
Current System Time: Wed Sep 27 20:23:55 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\ATI Technologies\ATI Control Panel
c:\WINDOWS\system32\nls
c:\WINDOWS\system32\nls\ENGLISH
c:\Program Files\Microsoft SQL Server\80\Tools\Binn\
c:\Program Files\doxygen\bin
c:\Program Files\Common Files\GTK\2.0\bin
c:\Nokia\Update_Manager\bin
c:\Program Files\Subversion\bin
c:\Nokia\Tools\Nokia_Developers_Suite_for_J2ME_3_0\bin
C:\cygwin\bin
C:\cygwin\home\jekers\scripts

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1007(jekers)GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1008(Debugger Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1007(jekers)GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1008(Debugger Users)

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

USER = 'jekers'
PWD = '/home/jekers/tmp'
HOME = '/home/jekers'
MAKE_MODE = 'unix'

HOMEPATH = '\'
MANPATH = 
'/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\jekers\Application Data'
HOSTNAME = 'W156DL'
VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 1, GenuineIntel'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/home/jekers'
USERDOMAIN = 'W156DL'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APR_ICONV_PATH = 'C:\Program Files\Subversion\iconv'
LS_COLORS = 
'no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jpg=01;35:*.png=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.png=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:'
TEMP = '/c/DOCUME~1/jekers/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
USERNAME = 'jekers'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
USERPROFILE = 'C:\Documents and Settings\jekers'
LANG = 'en_GB'
PS1 = '[EMAIL PROTECTED]:\w $ '
LOGONSERVER = '\\W156DL'
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 = '/c/DOCUME~1/jekers/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'EPSON Stylus C66 Series'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0401'
PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig'
INFOPATH = 
'/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = '127.0.0.1:0.0'
NUMBER_OF_PROCESSORS = '2'
INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\'
SESSIONNAME = 'Console'
COMPUTERNAME = 'W156DL'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = 'c:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
  (default) = 'd:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/e
  (default) = 'e:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/g
  (default) = 'g:'
  flags = 0x010a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/h
  (default) = 'h:'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v

Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

I recently updated to Bash 3.1.17(8) and found my local build system
failing due to the removal of CR/LF support:
"A script on a binary mount that uses \r\n line endings will probably
encounter syntax errors or odd variable assignments, because the \r is
treated literally.  If this happens to you, use d2u to fix the line
endings, or change your script to live in a text mount point.  A
script  that resides on a text mount can have either line ending (even
inconsistently mixed), but be aware that text mount points are
slower,  due to \r\n filtering."

Unfortunately simply running "d2u" isn't a solution because:
   * Some revision control systems make the files read-only.
   * Some detect the change to  as changes require manual merging.
   * Some translate files to a "Local" format (CR/LF on Windows).

I think the bigger issue here is that this arbitrary change will break
a "significant" number of existing scripts. I contract for a few
companies that use Cygwin/Bakefile to achieve support for multiple
compilers/tool-chains, and for hourly auto-build servers. This change
will break all of them - some of which have been functional for over 4
years.

In my opinion a better solution would have been to err on the side of
compatibility and only use the new fast readline code if manually
enabled.

Discussions around the local office this morning have resulted in the
project manager being forced to consider branching a Cygwin mirror,
rolling back Bash to 3.1.17(6) and mandating all developers use the
intranet mirror and not grab any further web updates.

--
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: Install hangs

[Larry Hall (Cygwin)]

Eric Mader wrote:

Eric Mader wrote:

Eric Mader wrote:
I was able to get setup.exe unstuck by cd'ing to /etc/preremove, 
running automake-devel.sh and then deleting it. I had to do this with 
about three other scripts in this directory before setup.exe would 
move on to the next phase. It's now happily installing all the 
selected packages.


I'm not sure what was going on with the offending scripts...

Regards,
Eric


It seems I spoke too soon, now it setup.exe hangs on the 
/etc/postinstall/00ash.sh script. The installation seems incomplete. 
For example, the "ls" command doesn't work.


So it seems that whatever was going on with the preinstall scripts is 
also happening w/ th postinstall scripts, but now I don't have a 
functioning environment in which to run them by hand :-(


I found a bunch of stalled processes running "ash", "bash" and "sh". I 
killed them all and rebooted for good measure. :-) When I ran setup.exe 
again, it gets as far as running /etc/postinstall/gnugo.sh and then 
stalls. The environment seems to be more-or-less working. I've enclosed 
the output of cygcheck -c , cygcheck -s and /var/log/setup.log.full.


Am I good to go at this point, or is there still something that's a 
little off?





'hicolor-icon-theme' reports itself as incomplete but otherwise the
packages themselves are there.  Postinstall scripts have a purpose
so to the extent that you haven't run them, you may see some issues
with your environment.  I'd recommend trying two things that might
help:

  1. Remove '/', '/usr/lib', and '/usr/bin' as binary and rerun
 'setup.exe'.  See 'man mount' and the '-f' and '-b' flags
 for more details.

  2. With or without the above, go to the '/etc/postinstall' directory
 and run any scripts there that don't have the 'done' suffix.
 Once they have all run successfully, move them to the script
 name plus the 'done' suffix.

Hopefully one of these two procedures will get all your postinstall
scripts to run.  If that's true, you're good to go.

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

--
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: Bash 3.1.17(8) CR/LF problem

[Larry Hall (Cygwin)]

Malcolm Nixon wrote:

I recently updated to Bash 3.1.17(8) and found my local build system
failing due to the removal of CR/LF support:
"A script on a binary mount that uses \r\n line endings will probably
encounter syntax errors or odd variable assignments, because the \r is
treated literally.  If this happens to you, use d2u to fix the line
endings, or change your script to live in a text mount point.  A
script  that resides on a text mount can have either line ending (even
inconsistently mixed), but be aware that text mount points are
slower,  due to \r\n filtering."

Unfortunately simply running "d2u" isn't a solution because:
   * Some revision control systems make the files read-only.
   * Some detect the change to  as changes require manual merging.
   * Some translate files to a "Local" format (CR/LF on Windows).

I think the bigger issue here is that this arbitrary change will break
a "significant" number of existing scripts. I contract for a few
companies that use Cygwin/Bakefile to achieve support for multiple
compilers/tool-chains, and for hourly auto-build servers. This change
will break all of them - some of which have been functional for over 4
years.

In my opinion a better solution would have been to err on the side of
compatibility and only use the new fast readline code if manually
enabled.

Discussions around the local office this morning have resulted in the
project manager being forced to consider branching a Cygwin mirror,
rolling back Bash to 3.1.17(6) and mandating all developers use the
intranet mirror and not grab any further web updates.



You forgot to make the argument of why using text mounts for the source 
directories isn't a reasonable solution?



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

--
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: Bash 3.1.17(8) CR/LF problem

[Dave Korn]

On 27 September 2006 20:42, Malcolm Nixon wrote:

> I recently updated to Bash 3.1.17(8) and found my local build system
> failing due to the removal of CR/LF support:
> "A script on a binary mount that uses \r\n line endings will probably
> encounter syntax errors or odd variable assignments, because the \r is
>  treated literally.  If this happens to you, use d2u to fix the line
> endings, or change your script to live in a text mount point.  A
> script  that resides on a text mount can have either line ending (even
>  inconsistently mixed), but be aware that text mount points are
> slower,  due to \r\n filtering."
> 
> Unfortunately simply running "d2u" isn't a solution because:

  So why isn't using a textmode mount a solution?

> * Some revision control systems make the files read-only.

  Huh?  You mean, permanently?  How are you supposed to edit them?  You don't
need an RCS for a read-only file that can't ever be changed, you can just burn
a copy to CD.

> * Some detect the change to  as changes require manual merging.

  What, on lines that you /haven't/ edited locally?  That's just a bug.

> * Some translate files to a "Local" format (CR/LF on Windows).

  FCOL, what on earth does an rcs think it's playing at, tampering with your
data?  Any rcs that doesn't give you back exactly what you put into it is just
plain buggy.  Nobody asked for a "automatically mangle my data whether I want
you to or not" feature.

> I think the bigger issue here is that this arbitrary change will break
> a "significant" number of existing scripts. 

  YM a "significant" number of /broken/ scripts.  Try running any of them on a
linux box and see what you get.

> I contract for a few
> companies that use Cygwin/Bakefile to achieve support for multiple
> compilers/tool-chains, and for hourly auto-build servers. This change
> will break all of them - some of which have been functional for over 4
> years.
> 
> In my opinion a better solution would have been to err on the side of
> compatibility and only use the new fast readline code if manually
> enabled.

  Then according to your opinion, everyone else in the world has to suffer
from crippled bash performance because you can't be bothered to fix your
systems.  Better for /you/ maybe, but it's not always all about you.  In MY
opinion, a better solution would be to err on the side of efficency, and only
use the old slow readline code if manually enabled.

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


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

Re: Bash 3.1.17(8) CR/LF problem

[Jonathan Arnold]

Malcolm Nixon wrote:

Unfortunately simply running "d2u" isn't a solution because:
   * Some revision control systems make the files read-only.


I would venture to guess that *all* sccs make a file read-only.


   * Some detect the change to  as changes require manual merging.


It ought to, if you made the change.  Check it out, make the change to
fix the broken code and check it back in.


   * Some translate files to a "Local" format (CR/LF on Windows).


Perforce will do this if you let it.  Or you can set the LineEnd option
for the client to be Unix or Share.

--
Jonathan Arnold   http://www.buddydog.org

When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.


--
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: Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

So why isn't using a textmode mount a solution?

Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
the bash scripts in a textmode mount would be virtually impossible.

In my case we're talking about a number of non-unix developers
with existing Cygwin installations (with no textmode mounts) that they
update periodically. They're going to take their functioning Cygwin
installations, run an update at the end of the month to get the latest
stable security patches, and have their build environment turn to goo.



* Some revision control systems make the files read-only.

 Huh?  You mean, permanently?  How are you supposed to edit them?  You don't
need an RCS for a read-only file that can't ever be changed, you can just burn
a copy to CD.

The revision control system I'm using as an example here is Perforce. Perforce
will build you a local repository with all files read-only. If the
files are modified
to read-write and/or are modified in any way, then Perforce will
refuse to manage
the file until it is deleted and re-fetched.


* Some detect the change to  as changes require manual merging.

What, on lines that you /haven't/ edited locally?  That's just a bug.

Perforce translates to CR/LF when it gets the file on a Windows system. Any
modification at all (read-only / line-ends) is a local edit.


* Some translate files to a "Local" format (CR/LF on Windows).

FCOL, what on earth does an rcs think it's playing at, tampering with your
data?  Any rcs that doesn't give you back exactly what you put into it is just
plain buggy.  Nobody asked for a "automatically mangle my data whether I want
you to or not" feature.

This is a Perforce 'feature' if you wish to call it that. Perforce
will translate
files you have specified as 'Text' to whatever 'Text' means on the local system
- LF on Unixes and CR/LF on Windows. One potential workaround would be to
declare the script files as binary files so they aren't touched, but
then you loose
the ability to diff.


  I think the bigger issue here is that this arbitrary change will break
  a "significant" number of existing scripts.

YM a "significant" number of /broken/ scripts.  Try running any of them on a
linux box and see what you get.

Agreed, on a linux box the Perforce command-line utility would get me a LF
terminated bash script which would run fine. The point I was trying to make was
for backwards compatibility. If Cygwin Bash had never supported CR/LF on
a virgin installation then we wouldn't be having this discussion. The problem
sems from introducing CR/LF as a feature, and then removing it once the
feature is depended upon by members of the community.


 Then according to your opinion, everyone else in the world has to suffer
from crippled bash performance because you can't be bothered to fix your
systems.  Better for /you/ maybe, but it's not always all about you.  In MY
opinion, a better solution would be to err on the side of efficency, and only
use the old slow readline code if manually enabled.

It would be better for Windows(tm) if they completely removed support for
16-bit applications, but the community they are supporting would be up in
arms over it. If people want pure Linux behavior, then they just install
Linux. I know that CR/LF sucks, but at the same time I am forced to
recognize that's the Windows standard, and a significant number of Windows
tools require it.

My issue comes from breaking compatibility and forcing people to expend
time and money to fix systems that used to work. I think part of my
frustration comes from the fact that I can't even fix this by adding a few
checks/commands to the root build script because I can't get the root build
script to run any more.

Instead I'll have to create a document and get it out PDQ before the next
security patch that describes how to modify Cygwin from the default virgin
configuration to one with textmode mounts or an equivalent modification.

--
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: Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

Jonathan Arnold wrote:

 * Some translate files to a "Local" format (CR/LF on Windows).

Perforce will do this if you let it.  Or you can set the LineEnd option
for the client to be Unix or Share.


This was in fact my original patch attempt, however it had the following
problems:
  * You can only set this option for an entire ClientSpec, not
individual files.
  * Some editors (Notepad & Crimson Editor) don't support just LF.
  * Perforce messes up files on check-in. We haven't tracked down the exact
cause yet, but some files modified on systems with LineEnd=unix are
being fetched with only LF on systems with LineEnd=local.

Basically we can't 'infect' a mostly Windows source-tree with LF
terminated files, whether the LFs are only resident on peoples local
Windows boxes, or checked in to the Perforce repository.

--
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: Bash 3.1.17(8) CR/LF problem

[mwoehlke]

Malcolm Nixon wrote:

I recently updated to Bash 3.1.17(8) and found my local build system
failing due to the removal of CR/LF support:
"A script on a binary mount that uses \r\n line endings will probably
encounter syntax errors or odd variable assignments, because the \r is
treated literally.  If this happens to you, use d2u to fix the line
endings, or change your script to live in a text mount point.  A
script  that resides on a text mount can have either line ending (even
inconsistently mixed), but be aware that text mount points are
slower,  due to \r\n filtering."

Unfortunately simply running "d2u" isn't a solution because:
   * Some revision control systems make the files read-only.
   * Some detect the change to  as changes require manual merging.
   * Some translate files to a "Local" format (CR/LF on Windows).


At least in some cases, there is a solution to this: use a Cygwin 
version of the RCS that knows that "native" means UNIX-style. :-) This 
works great for me (although I also go so far as specifying UNIX-style 
rather than "native").



I think the bigger issue here is that this arbitrary change will break
a "significant" number of existing scripts. I contract for a few
companies that use Cygwin/Bakefile to achieve support for multiple
compilers/tool-chains, and for hourly auto-build servers. This change
will break all of them - some of which have been functional for over 4
years.


It won't break ours. Nor did make-3.81. We DIRTFT (Did It Right The 
First Time). :-)



In my opinion a better solution would have been to err on the side of
compatibility and only use the new fast readline code if manually
enabled.


I think a better solution would be to push for upstream to patch bash 
(probably as an option via shopt or an environment var or something) to 
just ignore '\r' at the end of a line. Interix has this problem also, 
and I think Rodney's version of bash does this (I know they went through 
this same issue, and the result was a bash that could always handle 
mixed line endings - I don't think Interix has any concept of a 'text 
mode' mount so it sees scripts like a UNIX would).


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: Bash 3.1.17(8) CR/LF problem

[mwoehlke]

Jonathan Arnold wrote:

Malcolm Nixon wrote:

Unfortunately simply running "d2u" isn't a solution because:
   * Some revision control systems make the files read-only.


I would venture to guess that *all* sccs make a file read-only.


I know svn doesn't... rcs's that have a concept of "edit" usually will, 
but not all rcs's (again, e.g. svn) do.


Not that 'chmod' won't fix this for you in a snap.

--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


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

bash 3.1.18 seems seriously broken

[Larry Breyer]

What changed from bash 3.1.17 to 3.1.18 ?

I blindly performed a cygwin update, rebooted, and attempted startx.
X came up OK but the terminals would not respond to keyboard input.
Looking at the output of startx it became apparent something was
seriously wrong with /bin/sh (/bin/bash).

I got syntax errors on blank lines.

I also found, by adding little debugging stuff, like 'ls $XAPPLRESDIR',
that the shell was quoting env variables.  I was getting "no such file
or directory" on valid paths because the shell was including single
quotes around the path.  At least that's what it looked like.

Really odd.  I solved the problem by reverting to bash 3.1.17.
-- 
Larry Breyer
UCSD Computer Science
(858) 822-4990

--
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: Bash 3.1.17(8) CR/LF problem

[mwoehlke]

Dave Korn wrote:

On 27 September 2006 20:42, Malcolm Nixon wrote:

In my opinion a better solution would have been to err on the side of
compatibility and only use the new fast readline code if manually
enabled.


  Then according to your opinion, everyone else in the world has to suffer
from crippled bash performance because you can't be bothered to fix your
systems.  Better for /you/ maybe, but it's not always all about you.  In MY
opinion, a better solution would be to err on the side of efficency, and only
use the old slow readline code if manually enabled.


Right; non-standard behavior (and any non-binary treatment of '\r' 
certainly counts!) should - and I might dare even to say "must" - be 
disabled by default. Although in this case I can't think of any reason 
why you would ever have a '\r' in a shell script (other than as part of 
a line ending). Although if we make any of this optional, then IMO it 
needs to be done the right way, which is to just ignore '\r', at least 
at the end of lines. That way we can ALWAYS read in binary mode, and it 
isn't a major performance penalty.


I suppose this would mean if it is turned on, scripts on textmode mounts 
will actually be faster because we can ignore the textmode.


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


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

compling and running c program

[niceporch]

i'm new to this cygwin and programming thing, so sorry if this is a dumb
question. i want to do some c programming so i downloaded the distcc
compliler and vim. when i try to compile i get a message like... #include
expects "filename"  or . just wondering what i might be doing
wrong. 
-- 
View this message in context: 
http://www.nabble.com/compling-and-running-c-program-tf2347445.html#a6535774
Sent from the Cygwin Users mailing list archive at Nabble.com.


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

Re: bash 3.1.18 seems seriously broken

[mwoehlke]

Larry Breyer wrote:

What changed from bash 3.1.17 to 3.1.18 ?


Did you bother reading the ANNOUNCEMENT?


I blindly performed a cygwin update, rebooted, and attempted startx.
X came up OK but the terminals would not respond to keyboard input.
Looking at the output of startx it became apparent something was
seriously wrong with /bin/sh (/bin/bash).

I got syntax errors on blank lines.

I also found, by adding little debugging stuff, like 'ls $XAPPLRESDIR',
that the shell was quoting env variables.  I was getting "no such file
or directory" on valid paths because the shell was including single
quotes around the path.  At least that's what it looked like.

Really odd.  I solved the problem by reverting to bash 3.1.17.


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: Bash 3.1.17(8) CR/LF problem

[mwoehlke]

Malcolm Nixon wrote:

So why isn't using a textmode mount a solution?

Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
the bash scripts in a textmode mount would be virtually impossible.


I trust someone else will chime in, but I thought this was not an issue? 
If a textmode mount can't have non-text, then it would be useless (and 
there would not be an option to make *all of cygwin* textmode in 
setup.exe, because nothing would work). Are you sure textmode isn't just 
applied to things opened (using the Cygwin libs) with "rt", and has no 
effect if you open "rb" (which is how I would assume it works)?


--
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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: Bash 3.1.17(8) CR/LF problem

[Larry Hall (Cygwin)]

On 09/27/2006, Malcolm Nixon wrote:

> So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
the bash scripts in a textmode mount would be virtually impossible.




You lost me here.  *Exactly* what is the problem with placing your source
tree in a text mount?  Unless you're telling me that Perforce somehow is
able to turn your binaries into text files, I just don't see any issue.




>> * Some detect the change to  as changes require manual merging.
> What, on lines that you /haven't/ edited locally?  That's just a bug.
Perforce translates to CR/LF when it gets the file on a Windows system. Any
modification at all (read-only / line-ends) is a local edit.

>> * Some translate files to a "Local" format (CR/LF on Windows).
> FCOL, what on earth does an rcs think it's playing at, tampering with your
> data?  Any rcs that doesn't give you back exactly what you put into it is 
just
> plain buggy.  Nobody asked for a "automatically mangle my data whether I 
want

> you to or not" feature.
This is a Perforce 'feature' if you wish to call it that. Perforce
will translate
files you have specified as 'Text' to whatever 'Text' means on the local 
system

- LF on Unixes and CR/LF on Windows. One potential workaround would be to
declare the script files as binary files so they aren't touched, but
then you loose
the ability to diff. 



So why don't you just tell Perforce not to do this translation and pull to
a text mount?  As long as Perforce is at least reasonably bright, it should
create binary files as binary and text files without any designation, which
the Cygwin mount will then create as \r\n.

If that doesn't work for some weird reason, why not use the version of
their tools that are built for Cygwin -
?  I'll set
aside the issue that these tools still seem to be violating the GPL

I can't believe that the Perforce folks haven't taken your case into account.
You should really check with them if you can't figure out a way to make this
work.  I expect they could help you, especially since they seem to be well
aware of Cygwin.


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

--
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: bash 3.1.18 seems seriously broken

[Larry Hall (Cygwin)]

mwoehlke wrote:

Larry Breyer wrote:

What changed from bash 3.1.17 to 3.1.18 ?


Did you bother reading the ANNOUNCEMENT?



Right.  This is *not* a bug.  It's a feature.  If you read the ANNOUNCEMENT
on the ANOUNCEMENT list (copied to the Cygwin list as well), it would be
obvious to you why you're having this problem and what the solution is.



I blindly performed a cygwin update, rebooted, and attempted startx.



Ah.  Blindly doing *anything* and then blaming others for the results is
not a recipe for sympathy.

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

--
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: compling and running c program

[Larry Hall (Cygwin)]

niceporch wrote:

i'm new to this cygwin and programming thing, so sorry if this is a dumb
question. i want to do some c programming so i downloaded the distcc
compliler and vim. when i try to compile i get a message like... #include
expects "filename"  or . just wondering what i might be doing
wrong. 


I'll start by saying that your problem report isn't too useful.  Please
read and follow the problem reporting guidelines if you need to post a
problem report to this list.  You can find it as a link @ cygwin.com -



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

--
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: Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

mwoehlke wrote:

Right; non-standard behavior (and any non-binary treatment
of '\r' certainly counts!) should - and I might dare even to say
"must" - be disabled by default. Although in this case I can't
think of any reason why you would ever have a '\r' in a shell
script (other than as part of a line ending). Although if we
make any of this optional, then IMO it needs to be done the
right way, which is to just ignore '\r', at least at the end of
lines. That way we can ALWAYS read in binary mode, and
it isn't a major performance penalty.


I guess I'm 50/50 here. On one hand  is most certainly
not a standard line terminator character on Unix systems, but
at the same time Cygwin advertises a "collection of tools which
provide Linux look and feel" for Windows.

If pure Linux compatibility/restrictions was the only goal, then
it could be achieved far easier by running Debian in a VM.

Instead Cygwin tries to add the power of the Linux-like tools
into the cruftiness of Windows. Unfortunately I believe that implies
supporting Windows/DOS crufty CR/LF files.

--
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: tcgetattr problem

[Igor Peshansky]

On Wed, 27 Sep 2006, ahnkle wrote:

> hi
>
> I wrote a small program to test some serial stuff. I was puzzled because
> I recall that I was able to set baud rate on a serial port before, but
> now I cannot.
>
> I call tcgetattr() after I open the serial port, but it fails (the
> tcsetattr() also fails which first got my attention).
>
> I enclose a short example, and cygwin details, too. Any ideas?

Hmm...  Either you've asked this before, or I saw an almost exactly the
same program posted within the past month or two.  Quoting the first few
lines of your program:

#define PORT "com1"
...
  fd = open(PORT, O_RDWR | O_NOCTTY );

There's your problem.  When you open a port as "com1", it looks like a
file to Cygwin, since it doesn't recognize it as a valid device name.
Thus any attempt to manipulate that fd as a device will fail.

Use the Cygwin device (e.g., "/dev/ttyS0").
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Bash 3.1.17(8) CR/LF problem

[Igor Peshansky]

On Wed, 27 Sep 2006, Malcolm Nixon wrote:

> > So why isn't using a textmode mount a solution?
>
> Packages generally contain the sources, build scripts, tools binaries,
> etc in a single directory tree. For example a ./configure script located
> in the package root directory along side other project files. As such
> placing just the bash scripts in a textmode mount would be virtually
> impossible.
>
> In my case we're talking about a number of non-unix developers
> with existing Cygwin installations (with no textmode mounts) that they
> update periodically. They're going to take their functioning Cygwin
> installations, run an update at the end of the month to get the latest
> stable security patches, and have their build environment turn to goo.

I think you may be confused about what text mode mounts really do.  They
do not force every CRLF combination to be interpreted as LF (in all
files).  All they do is allow Cygwin programs (like bash) that open files
in default (non-binary) mode to understand CRLF line endings as if they
were pure LFs.

Just to reinforce what others were saying, try remounting the directory
with your source checkout in textmode (see "man mount").  It won't
actually change the contents of the files -- only how Cygwin programs
interpret them.

> The problem stems from introducing CR/LF as a feature, and then removing
> it once the feature is depended upon by members of the community.

FWIW, bash still supports CR/LF (and with the same crippled performance),
but on textmode mounts.

> My issue comes from breaking compatibility and forcing people to expend
> time and money to fix systems that used to work. I think part of my
> frustration comes from the fact that I can't even fix this by adding a
> few checks/commands to the root build script because I can't get the
> root build script to run any more.

Running one command is hardly an exorbitant expenditure of time...

> Instead I'll have to create a document and get it out PDQ before the
> next security patch that describes how to modify Cygwin from the default
> virgin configuration to one with textmode mounts or an equivalent
> modification.

It's easy enough to come up with a bash (or batch) script that your users
can run to get their mounts converted automatically.  Mind you, not all
mounts need to be converted -- only the directory tree where you keep your
Perforce checkout.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Bash 3.1.17(8) CR/LF problem

[Jonathan Arnold]

Malcolm Nixon wrote:

Jonathan Arnold wrote:

 * Some translate files to a "Local" format (CR/LF on Windows).

Perforce will do this if you let it.  Or you can set the LineEnd option
for the client to be Unix or Share.


This was in fact my original patch attempt, however it had the following
problems:
  * You can only set this option for an entire ClientSpec, not
individual files.
  * Some editors (Notepad & Crimson Editor) don't support just LF.
  * Perforce messes up files on check-in. We haven't tracked down the exact
cause yet, but some files modified on systems with LineEnd=unix are
being fetched with only LF on systems with LineEnd=local.

Basically we can't 'infect' a mostly Windows source-tree with LF
terminated files, whether the LFs are only resident on peoples local
Windows boxes, or checked in to the Perforce repository.


You can change the Perforce filetype to be binary, and that way Perforce
will leave the cr/lf alone. Then check out the scripts, do a d2u on them,
and check them back in.

$ p4 edit -t binary myscript.sh

--
Jonathan Arnold   http://www.buddydog.org

When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.


--
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: Bash 3.1.17(8) CR/LF problem

[Larry Hall (Cygwin)]

Malcolm Nixon wrote:

mwoehlke wrote:

Right; non-standard behavior (and any non-binary treatment
of '\r' certainly counts!) should - and I might dare even to say
"must" - be disabled by default. Although in this case I can't
think of any reason why you would ever have a '\r' in a shell
script (other than as part of a line ending). Although if we
make any of this optional, then IMO it needs to be done the
right way, which is to just ignore '\r', at least at the end of
lines. That way we can ALWAYS read in binary mode, and
it isn't a major performance penalty.


I guess I'm 50/50 here. On one hand  is most certainly
not a standard line terminator character on Unix systems, but
at the same time Cygwin advertises a "collection of tools which
provide Linux look and feel" for Windows.

If pure Linux compatibility/restrictions was the only goal, then
it could be achieved far easier by running Debian in a VM.



Not true.  Running a different O/S on the same or other machine
does not give the same interoperability that Cygwin does, regardless
of issues that come up where UNIX/Linux conventions clash with
Windows.  This argument is a red-herring.



Instead Cygwin tries to add the power of the Linux-like tools
into the cruftiness of Windows. Unfortunately I believe that implies
supporting Windows/DOS crufty CR/LF files.


No one said that Cygwin tools don't support CR/LFs.  If they didn't,
there would be no text mounts.  Every text file generated by Windows apps
would need to be filtered before processed by Cygwin apps.  And bash and
all the other shells wouldn't work with text files in any way.  But they
do.  The fact that you haven't been able to bash to work transparently
in your environment is merely an indication that you don't completely
understand the problem yet (or haven't been able to communicate it well
to the list).  Obviously, whether bash changes in any way based on your
feedback is a decision completely in the hands of the maintainer.  But
what you've described so far isn't adding up and my guess is you're going
to have to offer a more convincing argument based on detailed facts relevant
to the problem you're having to sway the hearts and minds of those who do
the work.


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

--
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: tcgetattr problem

[ahnkle]

On 18:36 Wed 27 Sep , Igor Peshansky wrote:
> 
> #define PORT "com1"
> ...
>   fd = open(PORT, O_RDWR | O_NOCTTY );
> 
> There's your problem.  When you open a port as "com1", it looks like a
> file to Cygwin, since it doesn't recognize it as a valid device name.
> Thus any attempt to manipulate that fd as a device will fail.
> 
> Use the Cygwin device (e.g., "/dev/ttyS0").

Strangely, com1 *does* work in the call to open. Having tried "/dev/ttyS0",
tcgetattr() works ok.

I also note that read() and write() work ok too using "com1", but
tcsetattr() also fails.

BTW, I obtained the CVS source, but couldn't find the _ioctl() call 
anywhere in my (brief) grepping. Is there any documentation about internal
structure, and whats going on under the hood?

regards,
ahnkle


--
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: tcgetattr problem

[Larry Hall (Cygwin)]

On 09/27/2006, ahnkle wrote:

On 18:36 Wed 27 Sep , Igor Peshansky wrote:
> > 
> > #define PORT "com1"

> > ...
> >   fd = open(PORT, O_RDWR | O_NOCTTY );
> > 
> > There's your problem.  When you open a port as "com1", it looks like a

> > file to Cygwin, since it doesn't recognize it as a valid device name.
> > Thus any attempt to manipulate that fd as a device will fail.
> > 
> > Use the Cygwin device (e.g., "/dev/ttyS0").


Strangely, com1 *does* work in the call to open. Having tried "/dev/ttyS0",
tcgetattr() works ok.

I also note that read() and write() work ok too using "com1", but
tcsetattr() also fails.


"/dev/ttyS0" is an emulated device in Cygwin.  "com1" is a DOS/Windows device.
If you want POSIX behavior from a device, use the Cygwin emulated device.
Otherwise, you're stuck with DOS/Windows devices and their semantics.  That's
why "/dev/ttyS0" exists.  There's no magic here.  And there certainly isn't
any bug.

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

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

Re: 1.5.20: Running background scripts, that use backtick assighments, from other sh scripts

[Steve Slany]

Steven Slany  gmail.com> writes:



Hello All,

I've posted this problem but I haven't recieved a response yet. This seems like
a pretty sever problem with forking processes in the background in cygwin. I was
wandering if anyone else has ran into this?

Thanks,
->Steve



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

emach hang problem: sbrk weirdness in cygwin 1.5.20?

[Sean M. Paus]

I recently upgraded to cygwin 1.5.21-1.  Once doing so I noticed that I
could no longer run emacs.  emacs would hang and take up around 90-99%
of the cpu.  Attaching a debugger, I noticed that one of the threads
appeared to be in an infinite loop.

I downloaded the emacs source, rebuilt it (debug) and noticed that the
same problem would occur during the build process when
bootstrap-emacs.exe was run.

At this point I attached gdb, finding that one of the threads was in an
infinite loop in morecore.  Apparently, the call to align returned a
result that was smaller than the base of the heap.

I further tracked this down to the result of __sbrk in __default_morecore.

Prior to running bootstrap_emacs.exe, another emacs executable
(temacs.exe) ran without error.  This confused me until I determined
that __default_morecore was invoking bss_sbrk instead of __sbrk.

Now, it's still confusing that bss_sbrk is working while __sbrk is not,
but at least it narrows down the result of the problem.

For example, __sbrk would return a result of 0x642000 while _heapbase
had a value of 0x203f4000.

Here's essentiall what the loop in morecore does to compute newsize:

  newsize = heapsize;
  do
newsize *= 2;
  while ( BLOCK( result + size ) > newsize);

where result is returned by (ultimately) __sbrk, size is the extra space
requested, newsize is the actual amount to grow, and BLOCK calculates
the block number relative to _heapbase.  heapsize usually starts around
1024.

The problem is, if result < _heapbase, BLOCK returns a huge number
(~4gig in my case).  If new size starts at 1024, it will continue to
double until it's greater than BLOCK(result+size).  If at some point
newsize is slightly less than BLOCK(result+size) doubling new size
causes an overflow and set's newsize to zero.  Infinite loop.

Anybody got a clue as to why __sbrk might be returning a value that is
so clearly wrong?

I've attached my sysinfo if that will help.

Sean

Cygwin Configuration Diagnostics
Current System Time: Wed Sep 27 19:13:28 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   ~\bin
C:\cygwin\usr\local\tena-tools\i686-pc-cygwin\bin
C:\cygwin\usr\local\tena-tools\bin
C:\cygwin\lib\qt3
C:\cygwin\lib
C:\cygwin\lib\kde3
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Common Files\Adaptec Shared\System
c:\Program Files\QuickTime\QTSystem\
c:\Program Files\Rational\common
c:\Program Files\Rational\PurifyPlus
c:\Program Files\Rational\Common
c:\Program Files\Microsoft Visual Studio 8\Common7\IDE
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\lib\lapack

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1003(spaus)  GID: 513(None)
0(root)   513(None) 544(Administrators)
547(Power Users)  555(Remote Desktop Users) 545(Users)
1005(Debugger Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1003(spaus)  GID: 513(None)
0(root)   513(None) 544(Administrators)
547(Power Users)  555(Remote Desktop Users) 545(Users)
1005(Debugger Users)

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

USER = 'spaus'
PWD = '/usr/src/emacs-21.3.50-2/emacs-21.3.50-build'
CYGWIN = 'server'
HOME = '/home/spaus'
MAKE_MODE = 'unix'

Use '-r' to scan registry

c:  hd  NTFS 57231Mb  96% CP CS UN PA FC 
s:  net NTFS234730Mb  93% CP CSPApublic
z:  net NTFS234730Mb  93% CP CSPAspaus

C:\cygwin/  system  binmode
C:\Program Files\PalmSource\Palm OS Developer Suite  /PalmDev   system  textmode
C:\cygwin/bin/usr/bin   system  binmode
C:\cygwin/lib/usr/lib   system  binmode
./cygdrive  system  
binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\crontab.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Found: C:\cygwin\bin\vim.exe

 1529k 2006/08/14 C:\cygwin\lib\kde3\cygkatepart.dll
  107k 2006/08/14 C:\cygwin\lib\kde3\cygkcertpart.dll
   25k 2006/08/14 C:\cygwin\lib\kde3\cygkdeprint_management_module.dll
   

RE: Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

Jonathan Arnold wrote:

You can change the Perforce filetype to be binary, and that way Perforce
will leave the cr/lf alone. Then check out the scripts, do a d2u on them,
and check them back in.


$ p4 edit -t binary myscript.sh


I believe this is what I will end up being forced to do. Many of the other
fixes could be used if this were just my system, however I have to
assist over 30 developers scattered around the country, most of whom
are Cygwin illiterate (other than running a simple build script).

The mount point idea would work, except that every developer gets their
local sandbox in different areas of their drives, and most have multiple
sandboxes active for work on different branches.

The only truly annoying thing with binary files in Perforce is that it
makes diffing and merging much harder.

--
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: Bash 3.1.17(8) CR/LF problem

[Igor Peshansky]

On Wed, 27 Sep 2006, Malcolm Nixon wrote:

> Jonathan Arnold wrote:
> > You can change the Perforce filetype to be binary, and that way Perforce
> > will leave the cr/lf alone. Then check out the scripts, do a d2u on them,
> > and check them back in.
> >
> > $ p4 edit -t binary myscript.sh
>
> I believe this is what I will end up being forced to do.  Many of the
> other fixes could be used if this were just my system, however I have to
> assist over 30 developers scattered around the country, most of whom are
> Cygwin illiterate (other than running a simple build script).
>
> The mount point idea would work, except that every developer gets their
> local sandbox in different areas of their drives, and most have multiple
> sandboxes active for work on different branches.

Right.  So do the above "binary" fix on just the main build script (since
your Cygwin-illiterate developers are unlikely to touch that), and also
have that script adjust the mount where *it* lives (or some path relative
to it) if the OS is Cygwin and the mount is binary...

> The only truly annoying thing with binary files in Perforce is that it
> makes diffing and merging much harder.

Indeed.  So don't go the full Monty until you've exhausted other options.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Bash 3.1.17(8) CR/LF problem

[Malcolm Nixon]

Larry Hall (Cygwin) wrote:

But what you've described so far isn't adding up and my guess is
you're going to have to offer a more convincing argument based
on detailed facts relevant to the problem you're having to sway
the hearts and minds of those who do the work.


I guess I have been somewhat vague, so here's about as specific
as I can get without bumping into NDA issues.

The customer in question has a project they compile using multiple
tool chains. Some just for linting, some for debugging/unit testing,
some for actual end-product release. The targets in question are:
Visual C++ 6.0, Visual C++ 8.0, SPLint, GCC, ARM Developer
Suite, RealView Developer Suite, GreenHill.


From the vantage point of a developer, they:

 1) Construct a sandbox in an arbitrary directory on their hard drive.
 2) Start a Cygwin bash prompt.
 3) Run a build.sh script at the root of the sandbox.

Then 'voila' everything works. The 'voila' masks using Bakefile
(bakefile.sourceforge.net) to generate project files and makefiles
for all of the targets; using Doxygen to generate source level
documentation; building the makefiles with make; and the project
files with the appropriate tools.

The power of this approach is:
  * The user can get their sandbox anywhere, not just to a specific
text-mode mount point.
  * The user is free to edit the source files in whatever Windows
editor they choose.
  * The user may open the Project files in the appropriate IDE.
Note: We're probably going to be adding Eclipse soon ;-)
  * The development sources are also the build sources used by
cygwin, so builds against all targets can be performed without
checking back in to perforce.

Unfortunately most of the developers only know how to run that root
build.sh script (with a few different command line arguments).
They're not converse enough with Cygwin to construct a text-mode
mount point before doing the fetch from source-control.

The fix I will probably end up falling back on is to mark those Bash
scripts as Binary for Perforce so they don't undergo translation in
the act of fetching. This unfortunately means that merging script
changes is going to be extremely problematic.

So to run through the current list of proposed fixes:
- Change just the Bash scripts to use :
 Perforce translates them back.
- Create text mount points for the sand boxes:
 The developers grab sandboxes all over the disk.
- Force  mode for all files in Perforce:
 The Windows IDEs and editors the developers use then fail.
- Run d2u on the scripts:
 There are enough scripts to change that I'd need to write a
 Bash script to fix the Bash scripts. Chicken != Egg.
 Additionally those changes would screw with Perforce.

The fix must be something that having an untrained developer
merely getting a new sandbox is enough. At this time setting
the scripts to Binary in Perforce is the only one that meets
this requirement.

--
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: bash 3.1.18 seems seriously broken

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Larry Breyer on 9/27/2006 3:22 PM:
> What changed from bash 3.1.17 to 3.1.18 ?

I don't know, but let me know when you find out :)
(There is no 3.1.18 - the latest official bash is 3.1.17, at cygwin
release 8, but upstream is very unlikely to release 3.1.18 since 3.2 is in
beta now.)

> 
> I blindly performed a cygwin update, rebooted, and attempted startx.
> X came up OK but the terminals would not respond to keyboard input.
> Looking at the output of startx it became apparent something was
> seriously wrong with /bin/sh (/bin/bash).
> 
> I got syntax errors on blank lines.

That means your script has CRLF line endings, but resides on a binary
mount point.  Fix it in one of three ways:
change the script to use plain LF line endings (with d2u)
change to a text mount point (with mount)
change the script to ignore whitespace (make the first non-comment line
set IFS appropriately, as in this snippet:
IFS=' ''''
'
that would be space, tab, then either CRLF or LF depending on whether your
script is on a binary or text mount)

- --
Life is short - so eat dessert first!

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

iD8DBQFFGx9C84KuGfSFAYARAt46AJ9YMH2+/0ZI1RwCJ43Hagg56tNOfwCfbLl+
r9r5HdMEXMT7irrCNgw5rXg=
=ggzD
-END PGP SIGNATURE-

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

Re: gdb with X-win problem

[Wynfield Henman]

echo $CYGWIN

==>   ntsec

If this is wrong, let me know.

Regards,
Henman
---
On 9/28/06, Larry Hall (Cygwin) <[EMAIL PROTECTED]> wrote:

Wynfield Henman wrote:
> I am not able to get the new gdb to handle any x-window applications
> or even on the non-x window invocation of emacs.
>
> Does anyone else have this problem.
>
>> From zsh
> 
> Attaching to program `/usr/local/bin/xv.exe', process 2772
> zsh: suspended (tty output)  gdb xv 2940
>
>> From bash
> 
> (gdb) attach 2340
> Attaching to process 2772
>
> [1]+  Stopped gdb
> bash-3.1$
>
> 
> then when used from a terminal window I get
> gdb emacs
> GNU gdb 6.5.50.20060706-cvs (cygwin-special)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin"...
> (gdb) run
> Starting program: /bin/emacs.exe
> Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
> Loaded symbols for /usr/bin/cygncurses-8.dll
> Loaded symbols for /usr/bin/cygwin1.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
> Loaded symbols for /usr/bin/cygjpeg-62.dll
> Loaded symbols for /usr/bin/cygpng12.dll
> Loaded symbols for /usr/bin/cygz.dll
> Loaded symbols for /usr/bin/cygtiff-5.dll
> Loaded symbols for /usr/bin/cygungif-4.dll
> Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
> Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
> Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXaw-8.dll
> Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXp-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXau-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
>
> emacs: standard input is not a tty
>
> Program exited with code 01.
> (gdb) C
>
> ---
>
> Any comments are welcome.


What does you CYGWIN environment variable look like?  For that matter,
.


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

Re: Bash 3.1.17(8) CR/LF problem

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Malcolm Nixon on 9/27/2006 4:09 PM:
> mwoehlke wrote:
>> Right; non-standard behavior (and any non-binary treatment
>> of '\r' certainly counts!) should - and I might dare even to say
>> "must" - be disabled by default. Although in this case I can't
>> think of any reason why you would ever have a '\r' in a shell
>> script (other than as part of a line ending). Although if we
>> make any of this optional, then IMO it needs to be done the
>> right way, which is to just ignore '\r', at least at the end of
>> lines. That way we can ALWAYS read in binary mode, and
>> it isn't a major performance penalty.
> 
> I guess I'm 50/50 here. On one hand  is most certainly
> not a standard line terminator character on Unix systems, but
> at the same time Cygwin advertises a "collection of tools which
> provide Linux look and feel" for Windows.

Here's my take on it.  If you want POSIX behavior and Linux compatibility,
use binary mounts and LF line endings, and don't edit files with notepad.
 If you want Windows behavior, where text and binary are not synonymous,
but where \r is generally ignored when treating a file as text, and where
you can develop in notepad (ugh, the thought makes me cringe in horror :),
then use text mounts.  Binary vs. text mounts only affects how _cygwin_
programs will react to your data; the underlying data is untouched when
viewed by non-cygwin programs.

By the way, there is another option that has not been mentioned in this
thread yet:

Make the first lines of your script read as follows:

#!/bin/sh
IFS=' ''''
' # Yes, that was a space, tab, and line ending
# On Linux and cygwin text mounts, the last component is just \n.
# On cygwin binary mounts, when the file has \r\n line endings,
# whether by accident or by perforce (pardon the pun),
# the last component is \r\n; now bash will silently ignore literal
# carriage returns, and your \r\n script will still work on a binary
# cygwin mount.  Case solved.

By setting IFS properly, you can solve your chicken-and-egg problem of
using a \r\n script on a binary mount to determine how to change the
environment for all subsequent scripts invoked in your build process.

> 
> If pure Linux compatibility/restrictions was the only goal, then
> it could be achieved far easier by running Debian in a VM.
> 
> Instead Cygwin tries to add the power of the Linux-like tools
> into the cruftiness of Windows. Unfortunately I believe that implies
> supporting Windows/DOS crufty CR/LF files.

I am only willing supporting the crufty CRLF transparently _when it does
not penalize people who could care less about using notepad_.  In other
words, I try hard to make sure that my packages work sanely with CRLF
files on text mounts, but I have no sympathy for breakages that occur due
to improper CRLF endings on binary mounts.

- --
Life is short - so eat dessert first!

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

iD8DBQFFGyHt84KuGfSFAYARAkkKAJ9V+zAjyAuzUIxJN33LCxIehoXeygCfTGor
3yPOy7kSjHQ3RTDTdMsuvSg=
=lHA0
-END PGP SIGNATURE-

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

Re: Bash 3.1.17(8) CR/LF problem

[Larry Hall (Cygwin)]

Malcolm Nixon wrote:

Larry Hall (Cygwin) wrote:

But what you've described so far isn't adding up and my guess is
you're going to have to offer a more convincing argument based
on detailed facts relevant to the problem you're having to sway
the hearts and minds of those who do the work.


I guess I have been somewhat vague, so here's about as specific
as I can get without bumping into NDA issues.

The customer in question has a project they compile using multiple
tool chains. Some just for linting, some for debugging/unit testing,
some for actual end-product release. The targets in question are:
Visual C++ 6.0, Visual C++ 8.0, SPLint, GCC, ARM Developer
Suite, RealView Developer Suite, GreenHill.


From the vantage point of a developer, they:

 1) Construct a sandbox in an arbitrary directory on their hard drive.
 2) Start a Cygwin bash prompt.
 3) Run a build.sh script at the root of the sandbox.

Then 'voila' everything works. The 'voila' masks using Bakefile
(bakefile.sourceforge.net) to generate project files and makefiles
for all of the targets; using Doxygen to generate source level
documentation; building the makefiles with make; and the project
files with the appropriate tools.

The power of this approach is:
  * The user can get their sandbox anywhere, not just to a specific
text-mode mount point.
  * The user is free to edit the source files in whatever Windows
editor they choose.
  * The user may open the Project files in the appropriate IDE.
Note: We're probably going to be adding Eclipse soon ;-)
  * The development sources are also the build sources used by
cygwin, so builds against all targets can be performed without
checking back in to perforce.

Unfortunately most of the developers only know how to run that root
build.sh script (with a few different command line arguments).
They're not converse enough with Cygwin to construct a text-mode
mount point before doing the fetch from source-control.

The fix I will probably end up falling back on is to mark those Bash
scripts as Binary for Perforce so they don't undergo translation in
the act of fetching. This unfortunately means that merging script
changes is going to be extremely problematic.

So to run through the current list of proposed fixes:
- Change just the Bash scripts to use :
 Perforce translates them back.
- Create text mount points for the sand boxes:
 The developers grab sandboxes all over the disk.
- Force  mode for all files in Perforce:
 The Windows IDEs and editors the developers use then fail.
- Run d2u on the scripts:
 There are enough scripts to change that I'd need to write a
 Bash script to fix the Bash scripts. Chicken != Egg.
 Additionally those changes would screw with Perforce.

The fix must be something that having an untrained developer
merely getting a new sandbox is enough. At this time setting
the scripts to Binary in Perforce is the only one that meets
this requirement.



Some other ideas:

- Put the top-level build script (or create a new one) into a set
  location in a binary mount.  It would take the directory name
  for the new tree, mount it properly and kick off the Perforce
  pull/update.  You could even hook this up as a shell command
  so that users could invoke it on the directory they want. ;-)
  This should be a simple build script that wouldn't change much.
  Also, since it's always possible to pull a previous version to
  disk, you can use Cygwin or other tools to do diffs when needed,
  if you can't get Perforce to do them for you in binary mode.

- "mount -ct /cygdrive".  Now everything other than the default
  Cygwin installation directory and '/usr/lib' and '/usr/bin'
  are text mounts to Cygwin tools.  Users can make their installation
  anywhere outside of these three locations (which don't make much
  sense for Perforce source trees anyway).  No mess.  No fuss.

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

--
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: gdb with X-win problem

[Larry Hall (Cygwin)]

.  Reformatted.

Wynfield Henman wrote:

On 9/28/06, Larry Hall (Cygwin)  cygwin  com> 
wrote:

   ^^^
.  Thanks.


Wynfield Henman wrote:
> I am not able to get the new gdb to handle any x-window applications
> or even on the non-x window invocation of emacs.
>
> Does anyone else have this problem.
>
>> From zsh
> 
> Attaching to program `/usr/local/bin/xv.exe', process 2772
> zsh: suspended (tty output)  gdb xv 2940
>
>> From bash
> 
> (gdb) attach 2340
> Attaching to process 2772
>
> [1]+  Stopped gdb
> bash-3.1$
>
> 
> then when used from a terminal window I get
> gdb emacs
> GNU gdb 6.5.50.20060706-cvs (cygwin-special)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
you

> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
details.

> This GDB was configured as "i686-pc-cygwin"...
> (gdb) run
> Starting program: /bin/emacs.exe
> Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
> Loaded symbols for /usr/bin/cygncurses-8.dll
> Loaded symbols for /usr/bin/cygwin1.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
> Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
> Loaded symbols for /usr/bin/cygjpeg-62.dll
> Loaded symbols for /usr/bin/cygpng12.dll
> Loaded symbols for /usr/bin/cygz.dll
> Loaded symbols for /usr/bin/cygtiff-5.dll
> Loaded symbols for /usr/bin/cygungif-4.dll
> Loaded symbols for /usr/X11R6/bin/cygX11-6.dll
> Loaded symbols for /usr/X11R6/bin/cygICE-6.dll
> Loaded symbols for /usr/X11R6/bin/cygSM-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXaw-8.dll
> Loaded symbols for /usr/X11R6/bin/cygXext-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXmu-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXt-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXp-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXau-6.dll
> Loaded symbols for /usr/X11R6/bin/cygXpm-4.dll
>
> emacs: standard input is not a tty
>
> Program exited with code 01.
> (gdb) C
>
> ---
>
> Any comments are welcome.


What does you CYGWIN environment variable look like?  For that matter,
.



> echo $CYGWIN
>
> ==>   ntsec
>
> If this is wrong, let me know.
>
> Regards,
> Henman


So far, so good!


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

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

Re: Problems with archiver "ar"

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Frank Illenseer on 9/27/2006 11:34 AM:
> Sorry - for not providing all infos...
> 
> I did some additional tests: When mounting my drives in "binmode" the
> error is gone and when mounting them in "textmode" the error is there.

Sounds like ar needs to be taught about open(O_BINARY)/fopen("rb") (or be
linked with binmode.o).

> 
> But due to the newest bash update, I rather need "textmode" to re-use my
> existing scripts without conversion, as the come from a revision control
> system which always generates the EOLs according to the underlying system.

See the other thread on this today.  First, why can't you teach your
revision control system that on a cygwin binary mount, the underlying
system uses \n line endings, not \r\n?  Second, you can add this to the
beginning of your script to make bash ignore \r when the file has \r\n
endings even on a cygwin binary mount:

IFS=' ''''
' # Yes, that is space, tab, and either a 1 or 2-character EOL as needed

> Cygwin Configuration Diagnostics
> Current System Time: Wed Sep 27 19:24:15 2006

We ask that you ATTACH this, not include it inline, to avoid spurious hits
in the mail archive search engine.

> 
> a:  fd N/AN/A
> c:  hd  NTFS 8Mb  99% CP CS UN PA FC OS-WinXP & Apps

Wow - that's one packed drive.

> 
> C:\Programme\cygwin  /  system  binmode
> C:\Programme\cygwin/bin  /usr/bin   system  binmode
> C:\Programme\cygwin/lib  /usr/lib   system  binmode
> ./cygdrive  system  binmode,cygdrive

I thought you said you had to use textmode?

> Not Found: sh

Not good.  Are you sure evereything is installed correctly?

- --
Life is short - so eat dessert first!

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

iD8DBQFFGyh084KuGfSFAYARApOGAJ0WqlXTnLfjPVy1DSffKw0CRUvA7wCdEU/c
C8VgGZS+DK5ICM0WXh4M7mw=
=i6l8
-END PGP SIGNATURE-

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

[ANNOUNCEMENT] Updated: whois-4.7.17-1

[Lapo Luchini]

Version 4.7.17-1 of whois has been uploaded.

Whois is a client for the whois directory service.
It allows you to retrieve information on domains name,
IP addresses, and more.


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

http://sources.redhat.com/lists.html#unsubscribe-simple

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



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

[ANNOUNCEMENT] Updated: monotone-0.30-1

[Lapo Luchini]

Version 0.30-1 of monotone has been uploaded.

monotone is a free distributed version control system. it provides a
simple, single-file transactional version store, with fully disconnected
operation and an efficient peer-to-peer synchronization protocol. it
understands history-sensitive merging, lightweight branches, integrated
code review and 3rd party testing. it uses cryptographic version naming
and client-side RSA certificates. it has good internationalization
support, has no external dependencies, runs on linux, solaris, OSX,
windows, and other unixes, and is licensed under the GNU GPL.

Several internal data formats have changed with this release;
migration is straight-forward, but slightly more complicated
than usual:
  -- The formats used to store some cached data in the
 database have changed.  To upgrade your databases, you
 must run:
   $ mtn -d mydb.mtn db migrate
   $ mtn -d mydb.mtn db regenerate_rosters
  -- The metadata stored in _MTN in each workspace has been
 rearranged slightly.  To upgrade your workspaces, you
 must run
   $ mtn migrate_workspace
 in each workspace.
All of these operations are completely lossless, and 0.30
remains compatible with earlier versions with regards to
netsync.

You can find information about new features here:
http://venge.net/monotone/NEWS


If you have questions or comments, please send them to the Cygwin
mailing list at: cygwin@cygwin.com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

http://sources.redhat.com/lists.html#unsubscribe-simple

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



--
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: Install hangs

[Eric Mader]

Larry Hall (Cygwin) wrote:

Eric Mader wrote:
I found a bunch of stalled processes running "ash", "bash" and "sh". I 
killed them all and rebooted for good measure. :-) When I ran 
setup.exe again, it gets as far as running /etc/postinstall/gnugo.sh 
and then stalls. The environment seems to be more-or-less working. 
I've enclosed the output of cygcheck -c , cygcheck -s and 
/var/log/setup.log.full.


Am I good to go at this point, or is there still something that's a 
little off?





'hicolor-icon-theme' reports itself as incomplete but otherwise the
packages themselves are there.  Postinstall scripts have a purpose
so to the extent that you haven't run them, you may see some issues
with your environment.  I'd recommend trying two things that might
help:

  1. Remove '/', '/usr/lib', and '/usr/bin' as binary and rerun
 'setup.exe'.  See 'man mount' and the '-f' and '-b' flags
 for more details.

  2. With or without the above, go to the '/etc/postinstall' directory
 and run any scripts there that don't have the 'done' suffix.
 Once they have all run successfully, move them to the script
 name plus the 'done' suffix.

Hopefully one of these two procedures will get all your postinstall
scripts to run.  If that's true, you're good to go.



I remounted '/', '/usr/lib' and '/usr/bin' as binary (I assume you meant 
"remount" rather than "remove"?) and reran setup.exe. It ran all the way 
to completion w/o any complaints, so I think I'm in pretty good shape.


I'm enclosing the output of 'cygcheck -svr > cygcheck.out'.

In the process of messing around w/ the scripts in /etc/postinstall I 
ran into a problem w/ find. In an attempt to find scripts where both the 
'.sh' and the '.sh.done' versions existed I typed the command:


find . -name "*.sh" -exec ls \{\}.done \;

This caused some strange error messages, and left some stalled processes 
running 'find' behind. (I can't run this command now because the 
successful run of setup.exe cleaned them all up, but here's the output 
of a similar use of '-exec' in find:


$ find . -name "*.sh.done" -exec ls \{\} \;
197 [main] find 16764 fhandler_dev_zero::fixup_mmap_after_fork: 
requested 0x
43 != 0x0 mem alloc base 0x43, state 0x2000, size 1040384, Win32 
error 4

87
543 [main] find 16764 c:\cygwin\bin\find.exe: *** fatal error - 
c:\cygwin\bi

n\find.exe: *** recreate_mmaps_after_fork_failed

It takes quite a long time to get a command prompt back after these 
error messages, and it leaves behing a stalled process.


Is this releated somehow to my many failed attempts to run setup.exe, or 
is it a know problem w/ find?


Regards,
Eric



Cygwin Configuration Diagnostics
Current System Time: Wed Sep 27 15:37:59 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   c:\cygwin\usr\local\bin
c:\cygwin\bin
c:\cygwin\bin
c:\cygwin\usr\X11R6\bin
c:\PROGRAM FILES\THINKPAD\UTILITIES
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\IBM\Infoprint Select
c:\Program Files\ATI Technologies\ATI Control Panel
c:\Program Files\ATI Technologies\Fire GL 3D Studio Max
c:\Program Files\PC-Doctor for Windows\services
c:\PROGRA~1\GNU\WINCVS~1.3\CVSNT
c:\Program Files\doxygen\bin
c:\Program Files\Rational\common
c:\Program Files\ThinkPad\ConnectUtilities
c:\Program Files\QuickTime\QTSystem\
c:\dev\icu\bin

Output from c:\cygwin\bin\id.exe (nontsec)
UID: 1005(emader)GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1006(Debugger Users)

Output from c:\cygwin\bin\id.exe (ntsec)
UID: 1005(emader)GID: 513(None)
0(root)  513(None)544(Administrators)
545(Users)   1006(Debugger Users)

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

USER = 'emader'
PWD = '/cygdrive/c'
HOME = '/home/emader'
MAKE_MODE = 'unix'

TVDEBUGFLAGS = '0x260'
HOMEPATH = '\Documents and Settings\emader'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/X11R6/man'
APPDATA = 'C:\Documents and Settings\emader\Application Data'
HOSTNAME = 'StarBug2'
VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
TVLOGSESSIONCOUNT = '5000'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 9 Stepping 5, GenuineIntel'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/etc/postinstall'
USERDOMAIN = 'STARBUG2'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/emader/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
QTJAVA = 'C:\Program Files\Java\jre1.5.0_08\lib\ext\QTJava.zip'
USERNAME = 'emader'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
JAVA_HOME = 'C:\Program Files\Java\jdk1.5.0_08'
USERPROFILE = 'C:\Documents and Settings\emad

RE: Bash 3.1.17(8) CR/LF problem

[Gary R. Van Sickle]

> From: Eric Blake
> Sent: Wednesday, September 27, 2006 8:14 PM
> Subject: Re: Bash 3.1.17(8) CR/LF problem
> 
[snip]
> > I guess I'm 50/50 here. On one hand  is most certainly not a 
> > standard line terminator character on Unix systems, but at the same 
> > time Cygwin advertises a "collection of tools which provide 
> Linux look 
> > and feel" for Windows.
> 
> Here's my take on it.  If you want POSIX behavior and Linux 
> compatibility, use binary mounts and LF line endings, and 
> don't edit files with notepad.

Actually, it would be: "don't use notepad at all, don't create any text
files you want bash to understand with any native Windows text editor, and
if you are going to use a native Windows text editor to edit files you want
bash to understand, make sure it maintains the original line endings.  Also,
make sure any other tools you might wish to use to process text, cygwin or
non-cygwin, do the same."

The "/r/n vs /n vs /r" Crisis Which Shall Plague Computer Science Forever is
most assuredly not merely a matter of "don't use notepad".

-- 
Gary R. Van Sickle


--
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: tcgetattr problem

[Christopher Faylor]

On Thu, Sep 28, 2006 at 12:10:18AM +0100, ahnkle wrote:
>On 18:36 Wed 27 Sep , Igor Peshansky wrote:
>> 
>> #define PORT "com1"
>> ...
>>   fd = open(PORT, O_RDWR | O_NOCTTY );
>> 
>> There's your problem.  When you open a port as "com1", it looks like a
>> file to Cygwin, since it doesn't recognize it as a valid device name.
>> Thus any attempt to manipulate that fd as a device will fail.
>> 
>> Use the Cygwin device (e.g., "/dev/ttyS0").
>
>Strangely, com1 *does* work in the call to open. Having tried "/dev/ttyS0",
>tcgetattr() works ok.

"It looks like a file to Cygwin"

>I also note that read() and write() work ok too using "com1", but
>tcsetattr() also fails.

"It looks like a file to Cygwin"

>BTW, I obtained the CVS source, but couldn't find the _ioctl() call 
>anywhere in my (brief) grepping. Is there any documentation about internal
>structure, and whats going on under the hood?

The name of the function is "ioctl", not "ioctl".

--
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: bash 3.1.18 seems seriously broken

[Christopher Faylor]

On Wed, Sep 27, 2006 at 05:58:15PM -0400, Larry Hall (Cygwin) wrote:
>Ah.  Blindly doing *anything* and then blaming others for the results is
>not a recipe for sympathy.

I think that one is going in my "quotes" file.

cgf

--
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: tcgetattr problem

[Christopher Faylor]

On Wed, Sep 27, 2006 at 10:13:36PM -0400, Christopher Faylor wrote:
>The name of the function is "ioctl", not "ioctl".
   "_ioctl".

cgf

--
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: Install hangs

[Larry Hall (Cygwin)]

Eric Mader wrote:

Larry Hall (Cygwin) wrote:

Eric Mader wrote:
I found a bunch of stalled processes running "ash", "bash" and "sh". 
I killed them all and rebooted for good measure. :-) When I ran 
setup.exe again, it gets as far as running /etc/postinstall/gnugo.sh 
and then stalls. The environment seems to be more-or-less working. 
I've enclosed the output of cygcheck -c , cygcheck -s and 
/var/log/setup.log.full.


Am I good to go at this point, or is there still something that's a 
little off?





'hicolor-icon-theme' reports itself as incomplete but otherwise the
packages themselves are there.  Postinstall scripts have a purpose
so to the extent that you haven't run them, you may see some issues
with your environment.  I'd recommend trying two things that might
help:

  1. Remove '/', '/usr/lib', and '/usr/bin' as binary and rerun
 'setup.exe'.  See 'man mount' and the '-f' and '-b' flags
 for more details.

  2. With or without the above, go to the '/etc/postinstall' directory
 and run any scripts there that don't have the 'done' suffix.
 Once they have all run successfully, move them to the script
 name plus the 'done' suffix.

Hopefully one of these two procedures will get all your postinstall
scripts to run.  If that's true, you're good to go.



I remounted '/', '/usr/lib' and '/usr/bin' as binary (I assume you meant 
"remount" rather than "remove"?) and reran setup.exe. It ran all the way 
to completion w/o any complaints, so I think I'm in pretty good shape.



Yes, remount.  Sorry about that.  My proofreading wasn't too good this
afternoon.

Cygcheck looks OK to me.  It's not immediately obvious to me why the
text mounts got in the way here but I'm glad it fixed it.  And I fear
other similar reports!



I'm enclosing the output of 'cygcheck -svr > cygcheck.out'.

In the process of messing around w/ the scripts in /etc/postinstall I 
ran into a problem w/ find. In an attempt to find scripts where both the 
'.sh' and the '.sh.done' versions existed I typed the command:


find . -name "*.sh" -exec ls \{\}.done \;

This caused some strange error messages, and left some stalled processes 
running 'find' behind. (I can't run this command now because the 
successful run of setup.exe cleaned them all up, but here's the output 
of a similar use of '-exec' in find:


$ find . -name "*.sh.done" -exec ls \{\} \;
197 [main] find 16764 fhandler_dev_zero::fixup_mmap_after_fork: 
requested 0x
43 != 0x0 mem alloc base 0x43, state 0x2000, size 1040384, Win32 
error 4

87
543 [main] find 16764 c:\cygwin\bin\find.exe: *** fatal error - 
c:\cygwin\bi

n\find.exe: *** recreate_mmaps_after_fork_failed

It takes quite a long time to get a command prompt back after these 
error messages, and it leaves behing a stalled process.


Is this releated somehow to my many failed attempts to run setup.exe, or 
is it a know problem w/ find?




Could be a rebase issue.  Try installing the package, read the README, and
follow the instructions for rebasing your system.

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

--
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: bash 3.1.18 seems seriously broken

[Larry Hall (Cygwin)]

Christopher Faylor wrote:

On Wed, Sep 27, 2006 at 05:58:15PM -0400, Larry Hall (Cygwin) wrote:

Ah.  Blindly doing *anything* and then blaming others for the results is
not a recipe for sympathy.


I think that one is going in my "quotes" file.


I am honored. :-)

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

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

RE: Problems with archiver "ar"

[Gary R. Van Sickle]

> From: Eric Blake
> Sent: Wednesday, September 27, 2006 8:42 PM
> Subject: Re: Problems with archiver "ar"
> 
[snip]
> > 
> > But due to the newest bash update, I rather need "textmode" 
> to re-use 
> > my existing scripts without conversion, as the come from a revision 
> > control system which always generates the EOLs according to 
> the underlying system.
> 
> See the other thread on this today.  First, why can't you 
> teach your revision control system that on a cygwin binary 
> mount, the underlying system uses \n line endings, not \r\n?

I hate to sound like a broken record, but not-quite-correct statements such
as the above give aid and comfort to our common enemy, The "/r/n vs /n vs
/r" Debacle Which None Of Us Shall Live Long Enough To See Resolved, and I
therefore must wax pedantic:

The "underlying system" (i.e. Windows, Linux, Cygwin binary mounts,
whatever) has no notion of what a "line ending" even is, much less what
values might represent it.  Bytes is bytes; have been since CP/M died.
Programs which manipulate text in some way, and the libraries they link
with, are who and what define the notion of a text file, and hence text file
formats, and hence "line endings".

Most of these programs and/or libraries are broken in either implementation
or design, in that they are only capable of reading one text file format.
When faced with the simple task of reading a plain text file with a format
other than the One True Format which they can handle, they fail, with
varying degrees of spectacularity.  Researchers have been unable to
determine why, in the 21st century, this problem is still as bad as its ever
been, but such is the sorry state of affairs of the Computer Science world
we live in.

At any rate, in an effort to mitigate the inevitable problems caused by
these broken programs, workarounds such as Cygwin's "text mode mount" were
invented.  Of course, Life never closes a door without also closing a
window, and these workarounds are not without their own problems.  There can
be speed issues, especially if the broken program wants random access to the
file (lseek()/fseek()).  Programs that are broken in the opposite direction,
i.e. programs which treat all files - executables, binaries, graphics,
whatever - as if they were text files in their One True Format, can be
broken (and yes, as impossible as it is to believe, such programs are not at
all uncommon!).

The good news, Gentle Reader, is that there is a teeny-tiny glimmer of hope
on the horizon: Unicode.  The Unicode standard actually had the courage to
define not one, but no less than *seven* valid line terminator sequences
(q.v.: http://en.wikipedia.org/wiki/Newline).  So, as Unixoid, Windowsoid,
and Macoid tools slowly become Unicode-capable, and assuming they make even
a token attempt at meeting the standard, perhaps, some day, our great,
great, great, greatgreatgreat grandchildren will be able to creat a plain
text file on one computer and have it be understood on another.

But I wouldn't put money on it.

-- 
Gary R. Van Sickle
 


--
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 minimize the shell to system tray?

[Lei Tang]

Hi, I want to minimize the Cygwin bash shell to windows system tray. Is 
there any way to do that?


Thanks!
-Lei


--
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 minimize the shell to system tray?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lei Tang on 9/27/2006 8:02 PM:
> Hi, I want to minimize the Cygwin bash shell to windows system tray. Is
> there any way to do that?

I don't know of anything in cygwin that can do it, but I'm pretty sure you
can google for programs written for Windows that can minimize arbitrary
windows to the systray.

- --
Life is short - so eat dessert first!

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

iD8DBQFFGz/I84KuGfSFAYARAhUwAJ41HZsoXc4kw2kuRUaIc+B65wpPcQCfRoPg
zC8+rMtpmaPtCKkZqwBlD8o=
=hbjL
-END PGP SIGNATURE-

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

Re: How to minimize the shell to system tray?

[Hans Horn]

I'd give DeskMate (http://sourceforge.net/projects/dm2/) a try. It's free & 
works!
H.

"Eric Blake" wrote in message
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Lei Tang on 9/27/2006 8:02 PM:
>> Hi, I want to minimize the Cygwin bash shell to windows system tray. Is
>> there any way to do that?
>
> I don't know of anything in cygwin that can do it, but I'm pretty sure you
> can google for programs written for Windows that can minimize arbitrary
> windows to the systray.
>
> - --
> Life is short - so eat dessert first!
>
> Eric Blake > -BEGIN PGP SIGNATURE-




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

Re: How to minimize the shell to system tray?

[Lei Tang]

Hans Horn wrote:
I'd give DeskMate (http://sourceforge.net/projects/dm2/) a try. It's free & 
works!

H.

"Eric Blake" wrote in message

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lei Tang on 9/27/2006 8:02 PM:

Hi, I want to minimize the Cygwin bash shell to windows system tray. Is
there any way to do that?

I don't know of anything in cygwin that can do it, but I'm pretty sure you
can google for programs written for Windows that can minimize arbitrary
windows to the systray.

- --
Life is short - so eat dessert first!

Eric Blake > -BEGIN PGP SIGNATURE-






thanks!


--
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.21-1 - Crash on anything using cygwin1.dll

[[EMAIL PROTECTED]]

1.5.21-1 - Crash on anything using cygwin1.dll


Havent used Cygwin in a while, and then today I was trying to rm' a dir
when I get this handy message:

===
5 [main] rm 5852 dll_crt0_1: internal error: couldn't determine location
of thread function on stack.  Expect signal problems.
===

Never saw that one before, so I try to open up the cygwin shell (which
is bash).  Upon (attempting) to launch the shell with cygwin.bat, I get
a crash.

===
AppName: bash.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===

So I start reading the page on reporting bugs, and I see about cygcheck,
so I decide to run that.  I notice it says: "If you can't run cygcheck
for some reason (and why shouldn't you be able to? cygcheck is just a
standard windows program which does not use the cygwin dll)"

Well, I guess I'm not so lucky, it runs for a bit, then I get this
handy-dandy crasher:

===
AppName: cygcheck.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===

-and-

===
AppName: id.exe  AppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===

Hurm, detecting a reoccuring pattern here.


So I completely uninstalled cygwin and tried reinstalling it.  It was
fine till it got to the post-install scripts which gave me yet another:

===
AppName: bash.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===

This is running on a Win XP Pro SP2 machine.

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

Re: 1.5.21-1 - Crash on anything using cygwin1.dll

[Larry Hall (Cygwin)]

[EMAIL PROTECTED] wrote:

1.5.21-1 - Crash on anything using cygwin1.dll


Havent used Cygwin in a while, and then today I was trying to rm' a dir
when I get this handy message:

===
5 [main] rm 5852 dll_crt0_1: internal error: couldn't determine location
of thread function on stack.  Expect signal problems.
===

Never saw that one before, so I try to open up the cygwin shell (which
is bash).  Upon (attempting) to launch the shell with cygwin.bat, I get
a crash.

===
AppName: bash.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===

So I start reading the page on reporting bugs, and I see about cygcheck,
so I decide to run that.  I notice it says: "If you can't run cygcheck
for some reason (and why shouldn't you be able to? cygcheck is just a
standard windows program which does not use the cygwin dll)"

Well, I guess I'm not so lucky, it runs for a bit, then I get this
handy-dandy crasher:

===
AppName: cygcheck.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===



'cygcheck' doesn't use 'cygwin1.dll' so I'm not sure that you have the
right info here.



-and-

===
AppName: id.exe  AppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===



'id' on the other hand does.



Hurm, detecting a reoccuring pattern here.



Me too.




So I completely uninstalled cygwin and tried reinstalling it.  It was
fine till it got to the post-install scripts which gave me yet another:

===
AppName: bash.exeAppVer: 0.0.0.0 ModName: cygwin1.dll
ModVer: 1005.21.0.0  Offset: 365f
===



Sounds to me a little like you have another copy of 'cygwin1.dll' on your
system that something is running.  Try searching for 'cygwin1.dll's


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

--
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: end key in less

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ilguiz Latypov on 9/27/2006 10:07 PM:
> Hello,
> 
> Since the Cygwin's less package still ships a version dependent on
> termcap, here is an addition to rxvt termcap entry so that 
> pressing the End key moves the window to the end of file.

Wrong list.  Redirecting to the main list.  (Not to mention that less
already understands 'G' to move to the file end.)

- --
Life is short - so eat dessert first!

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

iD8DBQFFG07e84KuGfSFAYARAha5AKDKmCzxVXrs9VQ+o4751dg/MOG+xQCffQr+
kRngcTujPJdYYzPBCGycacg=
=vqb7
-END PGP SIGNATURE-

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

Re: 1.5.21-1 - Crash on anything using cygwin1.dll

[OQ]

Larry Hall (Cygwin) wrote:
> [EMAIL PROTECTED] wrote:
>> 1.5.21-1 - Crash on anything using cygwin1.dll
>>
>>
>> Havent used Cygwin in a while, and then today I was trying to rm' a dir
>> when I get this handy message:
>>
>> ===
>> 5 [main] rm 5852 dll_crt0_1: internal error: couldn't determine location
>> of thread function on stack.  Expect signal problems.
>> ===
>>
>> Never saw that one before, so I try to open up the cygwin shell (which
>> is bash).  Upon (attempting) to launch the shell with cygwin.bat, I get
>> a crash.
>>
>> ===
>> AppName: bash.exe AppVer: 0.0.0.0 ModName: cygwin1.dll
>> ModVer: 1005.21.0.0 Offset: 365f
>> ===
>>
>> So I start reading the page on reporting bugs, and I see about cygcheck,
>> so I decide to run that.  I notice it says: "If you can't run cygcheck
>> for some reason (and why shouldn't you be able to? cygcheck is just a
>> standard windows program which does not use the cygwin dll)"
>>
>> Well, I guess I'm not so lucky, it runs for a bit, then I get this
>> handy-dandy crasher:
>>
>> ===
>> AppName: cygcheck.exe AppVer: 0.0.0.0 ModName: cygwin1.dll
>> ModVer: 1005.21.0.0 Offset: 365f
>> ===
> 
> 
> 'cygcheck' doesn't use 'cygwin1.dll' so I'm not sure that you have the
> right info here.
> 
> 
>> -and-
>>
>> ===
>> AppName: id.exe AppVer: 0.0.0.0 ModName: cygwin1.dll
>> ModVer: 1005.21.0.0 Offset: 365f
>> ===
> 
> 
> 'id' on the other hand does.
> 
> 
>> Hurm, detecting a reoccuring pattern here.
> 
> 
> Me too.
> 
> 
>>
>> So I completely uninstalled cygwin and tried reinstalling it.  It was
>> fine till it got to the post-install scripts which gave me yet another:
>>
>> ===
>> AppName: bash.exe AppVer: 0.0.0.0 ModName: cygwin1.dll
>> ModVer: 1005.21.0.0 Offset: 365f
>> ===
> 
> 
> Sounds to me a little like you have another copy of 'cygwin1.dll' on your
> system that something is running.  Try searching for 'cygwin1.dll's
> 

according to process explorer no other cygwin1.dll is loaded and also
that bash.exe is using C:\cygwin\bin\cygwin1.dll

But for the sake of it, I've removed all other cygwin1.dlls and the
problem persists.


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

Re: 1.5.21-1 - Crash on anything using cygwin1.dll

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to OQ on 9/27/2006 10:39 PM:
>>
>> Sounds to me a little like you have another copy of 'cygwin1.dll' on your
>> system that something is running.  Try searching for 'cygwin1.dll's
>>
> 
> according to process explorer no other cygwin1.dll is loaded and also
> that bash.exe is using C:\cygwin\bin\cygwin1.dll
> 
> But for the sake of it, I've removed all other cygwin1.dlls and the
> problem persists.

All others?  That sounds fishy right there; you should never have had more
than one in the first place if you wanted sane operational behavior.
Complete output from cygcheck would really be useful (just click past any
failure boxes that come up from trying to invoke id or other cygwin
subprocesses).

- --
Life is short - so eat dessert first!

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

iD8DBQFFG1My84KuGfSFAYARAuz/AKCGHBROpKRbHq+dkY20jvetLEV7hACg07Dr
m7Ky7AFOOfwsi3+mWfwaknE=
=ycak
-END PGP SIGNATURE-

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

Re: 1.5.21-1 - Crash on anything using cygwin1.dll

[[EMAIL PROTECTED]]

Eric Blake wrote:
> According to OQ on 9/27/2006 10:39 PM:
 Sounds to me a little like you have another copy of 'cygwin1.dll' on your
 system that something is running.  Try searching for 'cygwin1.dll's

>>> according to process explorer no other cygwin1.dll is loaded and also
>>> that bash.exe is using C:\cygwin\bin\cygwin1.dll
>>>
>>> But for the sake of it, I've removed all other cygwin1.dlls and the
>>> problem persists.
> 
> All others?  That sounds fishy right there; you should never have had more
> than one in the first place if you wanted sane operational behavior.
> Complete output from cygcheck would really be useful (just click past any
> failure boxes that come up from trying to invoke id or other cygwin
> subprocesses).
> 
> --
> Life is short - so eat dessert first!
> 
> Eric Blake [EMAIL PROTECTED]


  6 [main] id 4196 dll_crt0_1: internal error: couldn't determine
location of thread function on stack.  Expect signal problems.
  6 [main] id 3640 dll_crt0_1: internal error: couldn't determine
location of thread function on stack.  Expect signal problems.

Gets printed to stderr.  cygcheck:

===

Cygwin Configuration Diagnostics
Current System Time: Thu Sep 28 00:02:57 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\Program Files\Microsoft Visual Studio 8\Common7\IDE
C:\Program Files\Microsoft Visual Studio 8\VC\BIN
C:\Program Files\Microsoft Visual Studio 8\Common7\Tools
C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\bin
C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\bin
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
C:\Program Files\Microsoft Visual Studio 8\VC\VCPackages
C:\Perl\bin\
C:\cygwin\bin
c:\program files\imagemagick-6.2.6-q16
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Common Files\GTK\2.0\bin
C:\progra~1\putty\
C:\Program Files\Microsoft SQL Server\90\Tools\binn\
D:\Program Files\MySQL\MySQL Server 5.0\bin
D:\Program Files\Subversion\bin
c:\php
C:\Program Files\QuickTime\QTSystem\
C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
C:\Program Files\OpenVPN\bin
C:\Program Files\Bitsum Technologies\PECompact2

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 400(Harl) GID: 401(mkpasswd)
401(mkpasswd)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 400(Harl) GID: 401(mkpasswd)
401(mkpasswd)

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

Path = 'C:\Program Files\Microsoft Visual Studio
8\Common7\IDE;C:\Program Files\Microsoft Visual Studio
8\VC\BIN;C:\Program Files\Microsoft Visual Studio
8\Common7\Tools;C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\bin;C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\Microsoft Visual Studio
8\VC\VCPackages;C:\Perl\bin\;C:\cygwin\bin;c:\program
files\imagemagick-6.2.6-q16;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
Files\Common Files\GTK\2.0\bin;C:\progra~1\putty\;C:\Program
Files\Microsoft SQL Server\90\Tools\binn\;D:\Program Files\MySQL\MySQL
Server 5.0\bin;D:\Program Files\Subversion\bin;c:\php;C:\Program
Files\QuickTime\QTSystem\;C:\Program Files\Microsoft SQL
Server\80\Tools\Binn\;C:\Program Files\OpenVPN\bin;C:\Program
Files\Bitsum Technologies\PECompact2'

ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\Harl\Application Data'
APR_ICONV_PATH = 'D:\Program Files\Subversion\iconv'
CLASSPATH = '.;C:\Program Files\Java\jre1.6.0\lib\ext\QTJava.zip'
CLIENTNAME = 'Console'
CommonProgramFiles = 'C:\Program Files\Common Files'
COMPUTERNAME = 'VDF'
ComSpec = 'C:\WINDOWS\system32\cmd.exe'
DevEnvDir = 'C:\Program Files\Microsoft Visual Studio 8\Common7\IDE'
FP_NO_HOST_CHECK = 'NO'
FrameworkDir = 'C:\WINDOWS\Microsoft.NET\Framework'
FrameworkSDKDir = 'C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0'
FrameworkVersion = 'v2.0.50727'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\Harl'
INCLUDE = 'C:\Program Files\Microsoft Visual Studio
8\VC\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio
8\VC\INCLUDE;C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\include;C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\include;'
JAVA_HOME = 'C:\progra~1\java\jdk1.6.0'
LIB = 'C:\Program Files\Microsoft Visual Studio
8\VC\ATLMFC\LIB;C:\Program Files\Microsoft Visual Studio
8\VC\LIB;C:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\lib;C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\lib;'
LIBPATH = 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\Microsoft Visual Studio 8\VC\ATLMFC\LIB'
LOGONSERVER = '\\VDF'
NUMBER_OF_PROCESSORS = '1'
OPENSSL_CONF = 'C:\OpenSSL\b

Re: 1.5.21-1 - Crash on anything using cygwin1.dll

[[EMAIL PROTECTED]]

Eric Blake wrote:
> According to OQ on 9/27/2006 10:39 PM:
 Sounds to me a little like you have another copy of 'cygwin1.dll' on your
 system that something is running.  Try searching for 'cygwin1.dll's

>>> according to process explorer no other cygwin1.dll is loaded and also
>>> that bash.exe is using C:\cygwin\bin\cygwin1.dll
>>>
>>> But for the sake of it, I've removed all other cygwin1.dlls and the
>>> problem persists.
> 
> All others?  That sounds fishy right there; you should never have had more
> than one in the first place if you wanted sane operational behavior.
> Complete output from cygcheck would really be useful (just click past any
> failure boxes that come up from trying to invoke id or other cygwin
> subprocesses).
> 
> --
> Life is short - so eat dessert first!
> 
> Eric Blake [EMAIL PROTECTED]

oops I lied dwwin killed it prematurely, here's the rest of the output:

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

a:  fd N/AN/A
c:  hd  NTFS10Mb  82% CP CS UN PA FC
d:  hd  NTFS286166Mb  79% CP CS UN PA FC Seagate
e:  hd  NTFS  7789Mb  80% CP CS UN PA FC L2J
f:  cd N/AN/A
g:  cd  UDF   4429Mb 100%CS UN   DISK1
h:  cd  CDFS   197Mb 100%CS UN   XWildSp2006

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

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Not Found: gcc
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Not Found: ld
Found: C:\cygwin\bin\ls.exe
Not Found: make
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\Perl\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Not Found: ssh
Not Found: sh
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Not Found: vim

   25k 2005/08/15 C:\cygwin\bin\cygao-2.dll - os=4.0 img=1.0 sys=4.0
  "cygao-2.dll" v0.0 ts=2005/8/15 4:22
  145k 2004/09/02 C:\cygwin\bin\cygaudiofile-0.dll - os=4.0 img=1.0 sys=4.0
  "cygaudiofile-0.dll" v0.0 ts=2004/9/1 22:38
   56k 2005/07/09 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
  "cygbz2-1.dll" v0.0 ts=2005/7/9 0:09
7k 2005/11/20 C:\cygwin\bin\cygcharset-1.dll - os=4.0 img=1.0 sys=4.0
  "cygcharset-1.dll" v0.0 ts=2005/11/19 20:24
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0
  "cygcrypt-0.dll" v0.0 ts=2003/10/19 2:57
 1108k 2006/06/01 C:\cygwin\bin\cygcrypto-0.9.7.dll - os=4.0 img=1.0 sys=4.0
  "cygcrypto-0.9.7.dll" v0.0 ts=2006/6/1 10:50
 1050k 2006/06/01 C:\cygwin\bin\cygcrypto-0.9.8.dll - os=4.0 img=1.0 sys=4.0
  "cygcrypto-0.9.8.dll" v0.0 ts=2006/6/1 11:08
  194k 2006/06/12 C:\cygwin\bin\cygcurl-3.dll - os=4.0 img=1.0 sys=4.0
  "cygcurl-3.dll" v0.0 ts=2006/6/12 4:00
   27k 2005/08/21 C:\cygwin\bin\cygesd-0.dll - os=4.0 img=1.0 sys=4.0
  "cygesd-0.dll" v0.0 ts=2005/8/21 18:04
  214k 2005/08/13 C:\cygwin\bin\cygFLAC++-5.dll - os=4.0 img=1.0 sys=4.0
  "cygFLAC++-5.dll" v0.0 ts=2005/8/13 3:09
  274k 2005/08/13 C:\cygwin\bin\cygFLAC-7.dll - os=4.0 img=1.0 sys=4.0
  "cygFLAC-7.dll" v0.0 ts=2005/8/13 3:04
   40k 2006/03/24 C:\cygwin\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0
  "cygform-8.dll" v0.0 ts=2006/3/24 1:16
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
  "cygform5.dll" v0.0 ts=2001/4/25 0:28
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll - os=4.0 img=1.0 sys=4.0
  "cygform6.dll" v0.0 ts=2002/1/9 0:03
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll - os=4.0 img=1.0 sys=4.0
  "cygform7.dll" v0.0 ts=2003/8/9 4:25
   28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll - os=4.0 img=1.0 sys=4.0
  "cyggdbm-3.dll" v0.0 ts=2003/7/20 2:58
   30k 2003/08/11 C:\cygwin\bin\cyggdbm-4.dll - os=4.0 img=1.0 sys=4.0
  "cyggdbm-4.dll" v0.0 ts=2003/8/10 21:12
   19k 2003/03/22 C:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
  "cyggdbm.dll"