Re: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Brian Dessent  dessent.net> writes:

> 
> Your test case does not compile...

...good point...I was just trying to cut down on the length of the post...but 
it really didn't save that much anyway...I'll attach the full code on the end 
of this post in case anyone wants to try it.

> 
> Is there anything that differs between your two machines in regard to
> what's connected to the com port, or the com port settings?  Have to
> tried compiling with -Wall to see if there are any warnings that might
> indicate you forgot a prototype or used an incorrect parameter? 
> (Standard troubleshooting stuff..)

...hmm...yeah maybe I should try -Wall.  Thnx for the suggestion.  The output 
device really isn't relevant for my problem.  The code takes arguments that 
allow it to run in a mode where it doesn't even try to write to the output 
device (which is a COM port BTW)when run with the options "-x -d" the code 
just reads from the socket and prints to STDOUT so I can debug this problem.  
The only problem I seem to have on the one machine is actually reading data 
from the socket.

> 
> If you're doing serial IO then you probably need calls to tcgetattr()
> and tcsetattr().

..well...the com port I am writing to is actually a "virtual" com port that 
doesn't really exist...so those settings don't matter (I think)...regardless, 
it's not really the output that is giving me trouble.

> 
> > len = recv(infd,buf,1,0);
> 
> You might as well use read() here if you aren't using the flags.

I had that...and put in recv to see if it would make a difference...it 
didn't  :)

Thanks for your input.  Here is the full source code in case anyone wants to 
compile it and try it (of course...you need a open port to connect it 
to...maybe a telnet server somewhere...??)  The options 

program_name -x -d -h= -p=

...would be the ones to use.

I compiled with -Wall and found I was missing the  include.  I added 
this and -Wall is now cleanbut I can't try the code until tomorrow (not 
near the problem machine right now).  If anyone wants to try the original 
code, just comment out the include of 

//#define __USE_W32_SOCKETS
//#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#define OUTPUT_DEVICE   "COM4"
#define DEFAULT_PORT8080
#define DEFAULT_IP  "localhost"

int main(int argc,char *argv[])
{
int infd,outfd;
struct sockaddr_in ipaddr;
struct hostent *hp;
char *srcip = DEFAULT_IP;
unsigned short server_port = DEFAULT_PORT;
int argnum;
int debug_mode = 0;
int block_output = 0;
char *outdev = OUTPUT_DEVICE;

for (argnum = 1;argnum < argc;argnum++)
{
char *arg = argv[argnum];

if (arg[0] != '-')
{
printf("Ignoring invalid arg |%s|\n",arg);
continue;
}

switch (arg[1])
{
case 'd':
debug_mode = 1;
break;
case 'x':
block_output = 1;
break;
case 'h':
srcip = &arg[3];
break;
case 'p':
sscanf(&arg[3],"%hd",&server_port);
break;
case 's':
outdev = &arg[3];
break;

}
}

printf("Connecting to %s:%d\n",srcip,server_port);
printf("Redirecting output to %s\n",outdev);

infd = socket(AF_INET,SOCK_STREAM,0);
if (infd < 0)
{
printf("Unable to create socket\n");
printf("errno = %d,infd = %d\n", errno,infd);
printf("This means %s\n", strerror(errno));
exit(1);
}

if ((hp = gethostbyname(srcip)) == NULL) {
printf("Error: cannot get the host information about ip %s!\n",srcip);
exit(1);
}

memset(&ipaddr, 0, sizeof(ipaddr));
ipaddr.sin_family = hp->h_addrtype;
bcopy((char*)hp->h_addr, (char*)&ipaddr.sin_addr, hp->h_length);

ipaddr.sin_port = htons(server_port);

if (connect(infd, (struct sockaddr*)&ipaddr, sizeof(ipaddr)) != 0)
{
printf("Error: cannot connect!\n");
printf("errno = %d\n", errno);
printf("This means %s\n", strerror(errno));
exit(1);
}

if (block_output == 0)
{
outfd = open(outdev,O_RDWR | O_BINARY,S_IREAD | S_IWRITE);

if (outfd < 0)
{
printf("Error opening %s\n",outdev);
exit(-1);
}
}

while(1)
{
char buf[80];
int len;

len = recv(infd,buf,1,0);

if (len < 1)
{
printf("len = %d\n",len);
printf("errno = %d\n",errno);
printf("This means %s\n", strerror(errno));
sleep(1);
}
else
{
if (debug_mode)
{
printf("%c",(buf[0] & 0x7f));
if (((buf[0] & 0x7f) == 0x0d) || ((buf[0] & 0x7f) == 0x05))
{
printf("\n");
   

Re: Socket read problem on Windows XP Pro & Cygwin

[Brian Dessent]

Todd Rearick wrote:

> #define OUTPUT_DEVICE   "COM4"

*cough*

--
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: Socket read problem on Windows XP Pro & Cygwin

[Corinna Vinschen]

On Oct 22 07:06, Todd Rearick wrote:
> while(1)
>   {
>   char buf[80];
>   int len;
> 
>   len = recv(infd,buf,1,0);
> 
>   if (len < 1)
>   {
>   printf("len = %d\n",len);
> printf("errno = %d\n",errno);
> printf("This means %s\n", strerror(errno));
> sleep(1);

What you're entirely missing at this point is the fact that a return
value of 0 (zero) indicates EOF.  You don't test for this.  Instead
you're also testing errno in case of EOF, which has no meaning in this
case.


Corinna

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

--
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: struct msghdr in socket.h is wrong

[Corinna Vinschen]

On Oct 21 16:18, Sam Steingold wrote:
> > * Corinna Vinschen <[EMAIL PROTECTED]> [2005-10-17 23:34:52 +0200]:
> >
> > Never mind, I've changed it in CVS.  Note that msg_control,
> > msg_controllen and msg_flags members are still without function.
> 
> that's OK, as long as they are there.
> 
> while you are at it, two more networking functions appear AWOL:
> http://www.opengroup.org/onlinepubs/007904975/functions/getaddrinfo.html
> http://www.opengroup.org/onlinepubs/007904975/functions/getnameinfo.html

No, not yet.


Corinna

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

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

Re: Cygwin on Windows x64

[Corinna Vinschen]

On Oct 21 20:05, Sebastian Tillmann wrote:
> Hi,
> 
> I'm trying to compile ClanLib with Cygwin on my Windows XP Professional 
> x64 Edition. [...]
> 
> $ ./configure --enable-static --disable-shared
> checking build system type... ./config.guess: unable to guess system type

What happens is that Cygwin reports the *real* CPU type, which is a 64
bit type, instead of the emulated 32 bit type it's running on (i686
inside of WOW64).

This is fixed in recent developer snapshots of Cygwin.  Try the latest
from http://cygwin.com/snapshots/


Corinna

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

--
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: Please help on GCC

[estech users]

Dear all,

Please can you enlighten me on why it is more
advantageous to use gcc rather that Microsoft
studio.net visual c ?

Thank you.

Best wishes,

Olorunfemi, Temitope

--- Igor Pechtchanski <[EMAIL PROTECTED]> wrote:

> Ugh, top-posting...  Reformatted.
> 
> On Fri, 30 Sep 2005, estech users wrote:
> 
> > --- Igor Pechtchanski <[EMAIL PROTECTED]> wrote:
> 
> . 
> Thanks.
> 
> > > On Fri, 30 Sep 2005, estech users wrote:
> > >
> > > > Dear all,
> > > >
> > > > Somebody helping me on my research work has
> just
> > > > introduced me to your wonderful work.
> > > >
> > > > I am currently using Win XP, I loaded the
> cygwin just
> > > > 2 days ago and the version of the cygcheck is
> 1.74 and
> > > > it was compiled on July 2 2005.
> 
> BTW, I forgot to mention that this is not how you
> find out the version of
> Cygwin you have.  See
>  for instructions
> on providing information about your Cygwin
> installation.
> 
> > > > My problem now is that the gcc command in not
> found
> > > > and also startx, how do I get this gcc
> installed
> > > > because I purposely  want to use it to compile
> a c
> > > > programs.
> > > >
> > > > Please help and thank you for your good work.
> > >
> > >
>
.
> >
> > Dear Sir,
> >
> > Thanks so much for your quick response. I saw the
> > packages but how to download the gcc files and
> install
> > is the problem, please help me.
> 
> I believe
>

> is what
> you're looking for.  It may be worth changing the
> first FAQ entry to
> mention that installing extra packages happens using
> the same setup.exe...
> 
> If you are using setup, but having problems with
> installation, please
> provide the exact steps you use to reproduce the
> problems, any error
> messages you get, and other information requested in
> the Cygwin problem
> reporting guidelines at
> .
>   Igor
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski,
> Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a
> JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> If there's any real truth it's that the entire
> multidimensional infinity
> of the Universe is almost certainly being run by a
> bunch of maniacs. /DA
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.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: python problems with dos lineendings in python-scripts

[Jason Tishler]

Marco,

On Fri, Oct 21, 2005 at 08:27:12PM +0200, marco wrote:
> i can not run any python scripts with dos lineendings.
> if i run such scripts i get stupid syntax error messages from python.

Sorry, but I can't reproduce your problem.

> what can i do to run these scripts without changing the lineending of
> these scripts.

AFAICT, nothing.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Corinna Vinschen  cygwin.com> writes:

> 
> On Oct 22 07:06, Todd Rearick wrote:
> > while(1)
> > {
> > char buf[80];
> > int len;
> > 
> > len = recv(infd,buf,1,0);
> > 
> > if (len < 1)
> > {
> > printf("len = %d\n",len);
> > printf("errno = %d\n",errno);
> > printf("This means %s\n", strerror(errno));
> > sleep(1);
> 
> What you're entirely missing at this point is the fact that a return
> value of 0 (zero) indicates EOF.  You don't test for this.  Instead
> you're also testing errno in case of EOF, which has no meaning in this
> case.
> 
> Corinna
> 

hmm...good point (and you are correct)Here is the full program output 
(well...up until I hit Ctrl-C)

Connecting to localhost:8080
Redirecting output to COM4
len = 0
errno = 119
This means Operation now in progress
len = 0
errno = 119
This means Operation now in progress
len = 0
errno = 119
This means Operation now in progress
etc

The only reason I ever checked errno was because I was trying to get more 
information as to why it wasn't receiving the dataYou're right 
though...the errno=119 must be from something earlier in the program...and 
maybe that is a cluebut (as you can see from the code) I check the returns 
of all previous calls and none fail when I run the code.

After further testing...it looks like the "connect" call sets errno...even 
though it's return value indicated no error occuredThe other end of the 
socket also "thinks" it is connected.

My *NEW* question is this then:  Why do I get len = 0 over and over.  I never 
receive a character (even when I know one was transmitted).  The read first 
blocks (as it should)...until the first character is sent...and then it starts 
bailing out immediately with len=0 over and over...and I never do receive the 
character I sent in the other end of the pipe.

Thanks again for all your help,
Todd







--
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: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Brian Dessent  dessent.net> writes:

> 
> > #define OUTPUT_DEVICE   "COM4"
> 
> *cough*
> 
> 


Like I said.  I'm not having a problem with output.  The program fails even 
when I run it with the options "-x -d"in this case, COM4 is never even 
opened..and no attempts are made to write to it.  All the program does in this 
case is read from the socket and print the data out to STDOUTand THAT 
doesn't even work.  The read never returns any data to me

Todd





--
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: python problems with dos lineendings in python-scripts

[Thorsten Kampe]

* marco (2005-10-21 19:27 +0100)
> i can not run any python scripts with dos lineendings.

Works for me. Probably a classical "Problem exists between chair and
computer" issue?

> if i run such scripts i get stupid syntax error messages from python.

But you forgot to tell us this "stupid syntax error message" - because
it was so terribly misleading and unimportant, right?!
 
> what can i do to run these scripts without changing the lineending of these 
> scripts.

You could try to remember the first programming rule:
you don't give (us) any input - you won't get any output (from us).


--
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: Socket read problem on Windows XP Pro & Cygwin

[Corinna Vinschen]

On Oct 22 13:31, Todd Rearick wrote:
> Corinna Vinschen  cygwin.com> writes:
> > What you're entirely missing at this point is the fact that a return
> > value of 0 (zero) indicates EOF.  You don't test for this.  Instead
> > you're also testing errno in case of EOF, which has no meaning in this
> > case.
> 
> The only reason I ever checked errno was because I was trying to get more 
> information as to why it wasn't receiving the dataYou're right 
> though...the errno=119 must be from something earlier in the program...and 
> maybe that is a cluebut (as you can see from the code) I check the 
> returns 

No, the errno is set on some internal operation and has nothing to do
with something going wrong in your application.  Your job is to react
appropriately to a return value of 0 which just means EOF.  The error
value you receive at that point is just meaningless.

> of all previous calls and none fail when I run the code.
> 
> After further testing...it looks like the "connect" call sets errno...even 
> though it's return value indicated no error occuredThe other end of the 
> socket also "thinks" it is connected.
> 
> My *NEW* question is this then:  Why do I get len = 0 over and over.  I never 
> receive a character (even when I know one was transmitted).  The read first 
> blocks (as it should)...until the first character is sent...and then it 
> starts 
> bailing out immediately with len=0 over and over...and I never do receive the 
> character I sent in the other end of the pipe.

This I can't tell you since I don't know the server side of the
connection.  It's normal to get EOF (== 0) over and over again if EOF
has been detected.  This behaviour can be observed on, for instance,
Linux, too.

FYI, I tried your application against a simple time server, port 37,
which is known to accept a connection, sends 4 bytes and then closes the
connection.


Corinna

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

--
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: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Corinna Vinschen  cygwin.com> writes:

> 
> This I can't tell you since I don't know the server side of the
> connection.  It's normal to get EOF (== 0) over and over again if EOF
> has been detected.  This behaviour can be observed on, for instance,
> Linux, too.

Well..I thought it shouldn't if it's set for blocking mode (which is the 
default I think).but *now* I see why... SEE #3 BELOW:

> 
> FYI, I tried your application against a simple time server, port 37,
> which is known to accept a connection, sends 4 bytes and then closes the
> connection.
> 

Good idea.  FYI, the server program I am trying to run is a virtual serial 
port program at this url:

http://www.hw-group.com/products/hw_vsp/index_en.html

Thanks for the input...and I think I am making headway with this help.  After 
some more testing...I now think the problem has nothing directly to do with 
cygwin or my program.  Here's why:

1.) Using a time server as the server always works...no matter where I run the 
client program.

2.) I now have 2 PC's that fail, and one that doesn't.  If I run the client on 
the PC's that fail, and I run the "hw-group" server program ANYWHERE, the 
client fails to receive data.

3.) If I run some *other* client software on the PC's that fail 
(telnet...hypertermetc...) and try to connect to the "hw-group" server (no 
matter where that server is running), that also fails.  Those programs report 
that the server ended the connection.  THAT's why read returns 0...because it 
*thinks* the server closed the connection.

4.) Lastly, all client programs (telnet, my program, hyperterm..etc...) all 
work properly with the "hw-group" server when those programs are run on 
the "working" PC (my laptop).

So...it looks to me like there is some kind of basic incompatibility between 
the "hw-group" server program (no matter where it is run) and the winsock code 
on the client PCs that failsince the problem seems to affect both windows 
and cygwin clients alike.  Doesn't look like this really has anything to do 
with cygwin.  One of the client PC's that fails is still only SP1 of XP.  The 
other is SP2maybe I'll try and update the SP1 machine to the latest and 
see what happens.

Thanks for all of your help.  Unfortunately...now the problem isn't really 
directly under my control...hope I can find a solution.

Todd







--
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: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Todd Rearick  cox.net> writes:

> Thanks for all of your help.  Unfortunately...now the problem isn't really 
> directly under my control...hope I can find a solution.
> 


HAHA!!!  I'm such an idiot.  I have firewall software running on the 2 PC's 
that don't work (Norton Internet Security).  When I disabled the 
NIS...everything starts working.

Whew...thanks everyone...I don't know why I didn't think of that sooner.

Todd





--
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: Socket read problem on Windows XP Pro & Cygwin

[Corinna Vinschen]

On Oct 22 14:58, Todd Rearick wrote:
> Todd Rearick  cox.net> writes:
> > Thanks for all of your help.  Unfortunately...now the problem isn't really 
> > directly under my control...hope I can find a solution.
> 
> HAHA!!!  I'm such an idiot.  [...]

No worries, me too.  Thanks to your report I was curious where the
EINPROGRESS was coming from.  I found that it already happens in connect
and after some thought I finally implemented a much simpler technique for
an interuptible blocking connect than before.  Actually the former
implementation looks embarrasingly complex in contrast to the new one.
The positive side effect of the new technique is now that your application
never gets errno set accidentally.


Corinna

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

--
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: Please help on GCC

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to estech users on 10/22/2005 3:19 AM:
> Dear all,
> 
> Please can you enlighten me on why it is more
> advantageous to use gcc rather that Microsoft
> studio.net visual c ?

1) gcc is free, Microsoft is not (even if you can obtain a copy without
paying money, it is still not free - you are not free to see its source code)

2) gcc understands cygwin, Microsoft does not

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

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

iD8DBQFDWlg784KuGfSFAYARAolKAKDFzdtj36otMFbizdKXzEXE48twHQCgmdCT
Pzlma6ILmeUig5BIjwH8Tlw=
=0iTR
-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: Cygwin on Windows x64

[Sebastian Tillmann]

Hi,

I've downloaded the latest snapshot, it works now, everything fine.

Thanks for the help.

Sebastian


What happens is that Cygwin reports the *real* CPU type, which is a 64
bit type, instead of the emulated 32 bit type it's running on (i686
inside of WOW64).

This is fixed in recent developer snapshots of Cygwin.  Try the latest
from http://cygwin.com/snapshots/


Corinna

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


--
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: info bash - Bash Features: No such file or directory

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Arend-Jan Westhoff on 10/22/2005 7:02 AM:
>>It works for me.  You'll have to help by giving me a better formula for
>>reproducing the problem.  What does "info -w bash" print?  Also, could you
>>please follow the problem-reporting directions below, and attach
>> cygcheck.out?
> 
> 
> I can reproduce the problem.

I don't know if you are reproducing the same problem as the OP, since the
OP didn't exactly print what error message he was getting, but you
certainly reproduced a problem.

>   info -w bash
> produces:
>   gunzip: stdin: invalid compressed data--crc error
> 
>   gunzip: stdin: invalid compressed data--length error
>   /usr/share/info/bash.info.gz

> E:\cygwin  / system
textmode
> E:\cygwin/bin  /usr/bin  system
textmode
> E:\cygwin/lib  /usr/lib  system
textmode
> E:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
> .  /cygdrive system
textmode,cygdrive
>


This is probably because you've mounted / as textmode.  I don't know if it
is a bug in info or in gunzip for not opening files in binary even when
they live in a textmode directory, but if you would use a binary mount,
your problem should go away.

> When run from cmd or bash.
> 
> Whereas:
>   7z t bash.info.gz

7z is not a cygwin program (although I have built it for cygwin, and may
consider packaging it since I already package tar).

>   gzip -tv bash.info.gz
> Produces:
>   bash.info.gz:OK
> When run from cmd or bash.
> 
> But running:
>   gunzip
> Or:
>   gunzip -tv bash.info.gz
> from a cmd shell. Brings up a message box titled:
>   16 bit MS-DOS Subsystem
> with contents:
>   ... - gunzip
>   The NTVDM CPU has encountered an illegal instruction.

That would be because gunzip is a symlink, and cmd.com does not know how
to run symlinks.  You need a cygwin shell to exec a cygwin symlink.  (Hmm,
maybe that is related to why cmd.com is reporting an error for info -w
bash, since info is apparently trying to use gunzip rather than gzip -d).

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

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

iD8DBQFDWlw384KuGfSFAYARAl5AAKCbIfWo/gFgtg2FGtKOYh5JXNIChwCfZ1Ts
ODp6AzN0llzijuS6UueRWL4=
=hc1C
-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: Please help on GCC

[estech users]

Dear Sir,

Thanks for yours.

But is there any advantage of using GCC over MS
products when it comes to the issue of security?

Best wishes,

Olorunfemi, Temitope

--- Eric Blake <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to estech users on 10/22/2005 3:19 AM:
> > Dear all,
> > 
> > Please can you enlighten me on why it is more
> > advantageous to use gcc rather that Microsoft
> > studio.net visual c ?
> 
> 1) gcc is free, Microsoft is not (even if you can
> obtain a copy without
> paying money, it is still not free - you are not
> free to see its source code)
> 
> 2) gcc understands cygwin, Microsoft does not
> 
> - --
> Life is short - so eat dessert first!
> 
> Eric Blake [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (Cygwin)
> Comment: Public key at
> home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFDWlg784KuGfSFAYARAolKAKDFzdtj36otMFbizdKXzEXE48twHQCgmdCT
> Pzlma6ILmeUig5BIjwH8Tlw=
> =0iTR
> -END PGP SIGNATURE-
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.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: info bash - Bash Features: No such file or directory

[Lennart Borgman]

Eric Blake wrote:


I don't know if you are reproducing the same problem as the OP, since the
OP didn't exactly print what error message he was getting, but you
certainly reproduced a problem.
 


...


This is probably because you've mounted / as textmode.  I don't know if it
is a bug in info or in gunzip for not opening files in binary even when
they live in a textmode directory, but if you would use a binary mount,
your problem should go away.
 

Probably it is the same problem though I did not see that message as far 
as I remember now. But I use text mode as default and I do not do any 
extra mounts.


--
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: Please help on GCC

[Gerrit P. Haase]

estech users wrote:


But is there any advantage of using GCC over MS
products when it comes to the issue of security?


If you find a security problem in GCC you may fix it yourself.


Gerrit
--
=^..^=

--
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: Please help on GCC

[Christopher Faylor]

On Sat, Oct 22, 2005 at 08:37:46AM -0700, estech users wrote:
>But is there any advantage of using GCC over MS products when it comes
>to the issue of security?

No.

--
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: struct msghdr in socket.h is wrong

[Corinna Vinschen]

On Oct 22 11:07, Corinna Vinschen wrote:
> On Oct 21 16:18, Sam Steingold wrote:
> > > * Corinna Vinschen <[EMAIL PROTECTED]> [2005-10-17 23:34:52 +0200]:
> > >
> > > Never mind, I've changed it in CVS.  Note that msg_control,
> > > msg_controllen and msg_flags members are still without function.
> > 
> > that's OK, as long as they are there.
> > 
> > while you are at it, two more networking functions appear AWOL:
> > http://www.opengroup.org/onlinepubs/007904975/functions/getaddrinfo.html
> > http://www.opengroup.org/onlinepubs/007904975/functions/getnameinfo.html
> 
> No, not yet.

Btw., you have a Cygwin assignment in place, AFAIR.

http://cygwin.com/acronyms/#SHTDI
http://cygwin.com/acronyms/#PTC


Corinna

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

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

When are Windows Short Path Names required

[zzapper]

Hi

$ cygpath -d c:/Program\ Files/Internet\ Explorer
c:\PROGRA~1\INTERN~1

I've just had another case where the I had to use the short form, is the short 
form the "real name"?


-- 
zzapper
Success for Techies and Vim,Zsh tips
http://SuccessTheory.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: Socket read problem on Windows XP Pro & Cygwin

[Brian Dessent]

Todd Rearick wrote:

> > > #define OUTPUT_DEVICE   "COM4"
> >
> > *cough*
> 
> Like I said.  I'm not having a problem with output.  The program fails even
> when I run it with the options "-x -d"in this case, COM4 is never even
> opened..and no attempts are made to write to it.  All the program does in this
> case is read from the socket and print the data out to STDOUTand THAT
> doesn't even work.  The read never returns any data to me

What I was trying to emphasize is that passing "COM4" to open() in a
Cygwin program sets you up for a world of hurt, unless you understand
precisely what you're doing.  It may not matter now, but if you do
anything non-trivial with the port, it will.

Brian

--
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: When are Windows Short Path Names required

[Brian Dessent]

zzapper wrote:

> $ cygpath -d c:/Program\ Files/Internet\ Explorer
> c:\PROGRA~1\INTERN~1
> 
> I've just had another case where the I had to use the short form, is the 
> short form the "real name"?

Huh?  What do you mean?  Does the short form uniquely identify the
file?  Yes, of course.  But only in that particular instance. 
"progra~1" does not necessarily always map to "Program Files".  For
example if you created "Program Data" and then later created "Program
Files", you would have "progra~1" and "progra~2".  So you can not and
should not blindly assume that a certain short name will always map to a
given long name.  It's a one-way thing.  Even storing a short name (such
as in the registry or a config file) and then later referring to that
file is not safe, since the ~1 mapping might have changed.  (Many, many
programs make this mistake still.)

Generation of the short name from the long name is not even not
guaranteed to exist or work.  You can turn off 8.3 filename generation
on NTFS volumes, which means that the short form no longer works.

In other words, 8.3 filenames are a hideous hack that no one should be
using in this day and age.  Fix the quoting problem instead.

Brian

--
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: When are Windows Short Path Names required

[Brian Dessent]

Brian Dessent wrote:

> Generation of the short name from the long name is not even not
> guaranteed to exist or work.

s/not even not guaranteed/not even guaranteed/

--
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: Socket read problem on Windows XP Pro & Cygwin

[Todd Rearick]

Brian Dessent  dessent.net> writes:

> What I was trying to emphasize is that passing "COM4" to open() in a
> Cygwin program sets you up for a world of hurt...
> 
> Brian

It's even worse than you think.  In this case...COM4 is not even a real serial
port...but a "virtual" serial port constructed by a USB driver.  Fortunately for
me...because it's not a real port...I don't actually need to configure it at
all

I'm actually quite impressed that I can even open COM ports and write to them
and it all seems to work OK via cygwin.  Thanks for the warning and the help.

Todd





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

Where is documentation on keyring?

[Siegfried Heintze]

I'm poking around in c:/cygwin/usr/share/doc/gnome-keyring-0.4.3 trying to
understand how to use this program called keyring.

Can I expect all Cygwin utilities to be already compiled and have a file
that contains a URL to the documentation? 

I could google for it, but I wanted to be assured that the copy I have from
Cygwin is the same program I find with google. (For example, active state
perl is quite different from Cygwin perl and Cygwin cvs is quite different
from cvsnt even though the name of the cvsnt client is still cvs.exe).

There is an INSTALL file, but do I need to install it after running the
Cygwin setup.exe? I could not find the source code directory anyway
(probably because I did not request to get the source).

Should I not be able to find a file in
c:/cygwin/usr/share/doc/gnome-keyring-0.4.3 that points me to some
directions on how to run the program that I presume is already compiled and
installed on my system?

Oh - I also tried info keyring and man keyring -- no luck there either.

OK, I give up: I'm googling for it: I'm getting something about palm
keyring. Hmmm... that is probably not it. What about
http://cvs.gnome.org/viewcvs/gnome-keyring-manager/ ? This does not tell me
much more than I already know.

I'm stuck. Can someone please point me to the documentation?

Thanks,
Siegfried


--
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: Where is documentation on keyring?

[René Berber]

Siegfried Heintze wrote:
[snip]
> I'm stuck. Can someone please point me to the documentation?

/usr/share/doc/Cygwin/gnome-keyring-0.4.5.README

-- 
René Berber


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

Re: Where is documentation on keyring?

[Gerrit P. Haase]

Siegfried Heintze wrote:


I'm stuck. Can someone please point me to the documentation?


There is not much more included as you can find in
/usr/share/doc/gnome-keyring-0.4.5/

Other Gnome applications hold their docs under /usr/share/gtk-doc where
it may be accessed by the Gnome help browser, however there is no
documentation included with this package.  I'll look if there is a
packaging problem.


Gerrit

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

setting baud for USB serial adaptors

[tns1]

WinXP SP2, cygwin 5.19 snapshot

Once I grabbed the latest cygwin snapshot and made sure I had the 
coreutils 5.9xxx, I could finally use stty to set the baud of my 
built-in COM port, but it does not work for my USB serial adaptors. Any 
ideas?



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