less 378 still not anchoring to \

[f]

Hello,

I just reinstalled "less" from the cygwin site.
It still doesn't seem to anchor to word boundaries
using regex(3) rules i.e. \ doesn't
match anything, as does .   I read
a posting suggesing a solution by using perl
syntax (apparently):

   /\bSomeWord\b

That works, but is there a known reason why
the regex notation doesn't work?  I'd like to
avoid surprises.

Thanks.

Fred


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: less 378 still not anchoring to \

[Max Bowsher]

f wrote:
> I just reinstalled "less" from the cygwin site.
> It still doesn't seem to anchor to word boundaries
> using regex(3) rules i.e. \ doesn't
> match anything, as does .   I read
> a posting suggesing a solution by using perl
> syntax (apparently):
> 
> /\bSomeWord\b
> 
> That works, but is there a known reason why
> the regex notation doesn't work?

Because less is linked with pcre(3), not regex(3).


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: less 378 still not anchoring to \

[Shing-Fat Fred Ma]

Max Bowsher wrote:

> f wrote:
> > I just reinstalled "less" from the cygwin site.
> > It still doesn't seem to anchor to word boundaries
> > using regex(3) rules i.e. \ doesn't
> > match anything, as does .   I read
> > a posting suggesing a solution by using perl
> > syntax (apparently):
> >
> > /\bSomeWord\b
> >
> > That works, but is there a known reason why
> > the regex notation doesn't work?
>
> Because less is linked with pcre(3), not regex(3).
>
> Max.

Thanks, Max.  The posting I saw did indeed mention
linking Perl, but I thought that meant added
features rather than different syntax.  It looks
like I better accelerate my picking up of Perl.

Fred

--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache corrupt big file

[Stipe Tolj]

Tetsu KOUNO wrote:
> 
> (6) ServerType
>ServerType inetd  ... successful!!
>Maybe, same reason to ftp download was successful.
> 
> Any idea?

the inetd variant, means that on every incoming TCP connect on port 80
(or whatever you have confiured), inetd will spawn an httpd prozess
for that specific connection.

This is less TCP connection fault tolerant, yes.

The problem within the current Apache+Cygwin (normal setup) is within
the accept() serialization, which means the mechanism that the core
parent httpd prozess deals with incoming TCP connect and spreads the
load across the idle child httpd within the scoreboard file.

Unfortunatly it's unclear to me why the beast serves for a couple of
requests and then suddenly stops doing this.

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache corrupt big file

[Elfyn McBratney]

> The problem within the current Apache+Cygwin (normal setup) is within
> the accept() serialization, which means the mechanism that the core
> parent httpd prozess deals with incoming TCP connect and spreads the
> load across the idle child httpd within the scoreboard file.


Stipe, have you tested with the latest or semi-latest snapshot? Corinna made
a change to the socket code that fixed the socket state to being set to
CONNECTED...just a thought ;-) Would try myself but am behind bars infront
of a vax brr.


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache corrupt big file

[Stipe Tolj]

Elfyn McBratney wrote:
> 
> > The problem within the current Apache+Cygwin (normal setup) is within
> > the accept() serialization, which means the mechanism that the core
> > parent httpd prozess deals with incoming TCP connect and spreads the
> > load across the idle child httpd within the scoreboard file.
> 
> Stipe, have you tested with the latest or semi-latest snapshot? Corinna made
> a change to the socket code that fixed the socket state to being set to
> CONNECTED...just a thought ;-) Would try myself but am behind bars infront
> of a vax brr.

Hi Elfyn,

ok, I may hit a try. Can you tell me if she posted some explanation
about the fixes/changes in the mailing list? I'd like to know what she
did in front.

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache corrupt big file

[Elfyn McBratney]

> ok, I may hit a try. Can you tell me if she posted some explanation
> about the fixes/changes in the mailing list? I'd like to know what she
> did in front.


Absolutely...

http://www.cygwin.com/ml/cygwin-cvs/2003-q1/msg00153.html (the cvs-commit
info)
http://www.cygwin.com/ml/cygwin/2003-01/msg01640.html (the answering thread)

HTH,
Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup hangs repetedly

[Max Bowsher]

Martin Magnusson wrote:
> Max Bowsher wrote:
>  > Does it hang in the middle of installing a package, or between
>  > packages?
> It varies. Now I have actually managed to install the basic Cygwin
> packages (everything set to default, no compilers or anything). It
> worked on the second attempt. But I'm still struggling, trying to add
> gcc and such (from my local directory). After I installed the basics I
> ran setup-2.303 again, and  only checked the Devel category. The first
> time it hung when starting to install doxygen, and the second time it
> hung in the middle of /usr/.../texinfo.tex.
>
>  > Does the MD5sum check go OK?
> Yes, all of the MD5sum checks go OK.
>
> I also just scanned my hard drives again (including the free space)
> with NDD, and it didn't report any problems.

I'm out of ideas. I'm sorry, I can't think of any problem that could cause
this. If you can install gdb, and use it on debug build of setup, you might
turn up something. I don't know.


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache corrupt big file

[Elfyn McBratney]

> thanks!
> 
> Stipe

No probs! ;-) Just hope that was what was holding apache back -)


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: installing pinfo

[Max Bowsher]

Robert Mark Bram wrote:
> I downloaded pinfo recently because I have heard it is a better help
> program than man. I ran the cygwin setup program, selected pinfo and
> thought it ran through ok. However, when I type "pinfo", the command
> is not known:
>
>  $ pinfo
>  bash: pinfo: command not found

Run:

$ ls -l /bin/pinfo
$ cygcheck -c pinfo

Post the output of those 2 commands here, and we'll try to help.

> I went and had a look at the files inside the pinfo download:
> pinfo-0.6.6p1-1.tar.bz2. I found a readme file with the following
> information in it:
>
> To rebuild the package for cygwin:

Rebuild = rebuild from source. You probably don't want to do that.

> This is a bit confusing for me at the moment. I assumed:
>   pinfo-x.x.x-x-src = pinfo-0.6.6p1-1.tar.bz2

Not true. -src means the source package, not the binary package.

>   > copy sample pinforc to /usr/share/pinfo/pinforc
>   > copy CAPITALIZEDFILES to /usr/doc/pinfo-x.x.x-x/

Uhh... those are instructions for a human, not commands to be fed verbatim
to a shell.


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

bug: fork, LoadLibrary, Windows ME

[Paul Kienzle]

Hi,

I'm trying to debug a problem with Octave running under
Cygwin for Windows ME.

Every time I fork, I get a message box for each dynamically
loaded dll saying:
  Octave has caused an error in SUB.DLL
  Octave will now close.
This does not happen in Windows 2000.

The following code demonstrates the error:

--- dynmain.cc:
#include 
#include 
int main(int argc, char *argv[])
{
HINSTANCE handle = LoadLibrary("dynsub.dll");
std::cout << "# Calling fork\n";
std::cout << (fork()?"parent\n":"child\n");
return 0;
}

--- dynsub.c:
#include 
void dynsub(void) { printf("in dynsub\n"); }

--- Makefile:
all: dynsub.dll dynmain.exe
dynmain.exe: dynmain.cc  ; g++ -o $@ $<
dynsub.dll : dynsub.c   ; gcc -shared -o $@ $<

I updated my cygwin distribution as of this morning (Feb 2, 2003) and
the problem persists.

Paul Kienzle
[EMAIL PROTECTED]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: manuals for newbies?

[Chris January]

> Since I'm totally new to cygwin, (I just installed it
> a couple of days ago) it turns out that I had a lot of
> questions while getting familiar with it. I hate
> asking them here cause I believe they are very simple
> questions and probably lots of people had the same
> questions before. But the cygwin and cygwin-xfree docs
> and faqs are kind of too short and don't provide
> enough information to answer my questions and strangly
> enough, I couldn't find the answer here by doing
> keyword search. So is there any manuals for newbies
> somewhere on the net that I don't know? Or I have to
> keep bothering you guys? :)

http://www.doc.ic.ac.uk/~ccj00/twiki/bin/view/Cygwin/WebHome

has some useful bits and pieces.

Chris


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Compile of NetBSD 1.6

[Christos Dritsas]

Christos wrote:



I am attempting to compile NetBSD 1.6 via Cygwin 1.3.19-1 (on Win2k) 
by issuing the following command:

./build.sh -m shark -u -t

I get the following error:

$ ./build.sh -m shark -u -t
===> Bootstrapping nbmake
checking for sh... /usr/bin/sh
checking for gcc... cc
checking for C compiler default output... configure: error: C 
compiler cannot create executables

ERROR: configure of nbmake failed
*** BUILD ABORTED ***

So, what appears to be happening is that the build.sh script is 
recoginizing "cc" when checking for "gcc". Cygwin does not appear to 
recognize "cc" as a compiler on it - attempted test compiles with the 
"cc" comand. Without changing anything in the build scripts, is there an 
easy way to tell the Cygwin bash enviornment to recognize "cc" as "gcc"? 
I did attempt to use a name-value pair in the bash enviornment (as per 
the bash man page - "CC=C:\cygwin\bin\gcc.exe"), but it did not work for 
me.

Any pointers would be apprecitated - thank you,
Christos



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Compile of NetBSD 1.6

[Elfyn McBratney]

> So, what appears to be happening is that the build.sh script is 
> recoginizing "cc" when checking for "gcc". Cygwin does not appear to 
> recognize "cc" as a compiler on it - attempted test compiles with the 
> "cc" comand. Without changing anything in the build scripts, is there an 
> easy way to tell the Cygwin bash enviornment to recognize "cc" as "gcc"? 
> I did attempt to use a name-value pair in the bash enviornment (as per 
> the bash man page - "CC=C:\cygwin\bin\gcc.exe"), but it did not work for 
> me.

You can create a symbolic link from gcc to cc:

$ cd /bin && ln -s gcc cc


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Compile of NetBSD 1.6

[Max Bowsher]

Elfyn McBratney wrote:
>> So, what appears to be happening is that the build.sh script is
>> recoginizing "cc" when checking for "gcc". Cygwin does not appear to
>> recognize "cc" as a compiler on it - attempted test compiles with the
>> "cc" comand. Without changing anything in the build scripts, is
>> there an easy way to tell the Cygwin bash enviornment to recognize
>> "cc" as "gcc"? I did attempt to use a name-value pair in the bash
>> enviornment (as per the bash man page - "CC=C:\cygwin\bin\gcc.exe"),
>> but it did not work for me.
>
> You can create a symbolic link from gcc to cc:
>
> $ cd /bin && ln -s gcc cc

Or find out why it is finding a cc at all, and stop it.
Run "which cc" to find out where the cc is, if it is in your PATH.
If that doesn't find anything, then hack build.sh to preserve config.log,
and check that.

Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin Compile of NetBSD 1.6

[Christopher Faylor]

On Sun, Feb 02, 2003 at 07:03:20PM -, Max Bowsher wrote:
>Elfyn McBratney wrote:
>>>So, what appears to be happening is that the build.sh script is
>>>recoginizing "cc" when checking for "gcc".  Cygwin does not appear to
>>>recognize "cc" as a compiler on it - attempted test compiles with the
>>>"cc" comand.  Without changing anything in the build scripts, is there
>>>an easy way to tell the Cygwin bash enviornment to recognize "cc" as
>>>"gcc"?  I did attempt to use a name-value pair in the bash enviornment
>>>(as per the bash man page - "CC=C:\cygwin\bin\gcc.exe"), but it did not
>>>work for me.
>>
>>You can create a symbolic link from gcc to cc:
>>
>>$ cd /bin && ln -s gcc cc
>
>Or find out why it is finding a cc at all, and stop it.  Run "which cc"
>to find out where the cc is, if it is in your PATH.  If that doesn't
>find anything, then hack build.sh to preserve config.log, and check
>that.

Or, even, just give up since the likelihood of actually being able to
build NetBSD under Cygwin with little or no knowledge of cross compilers
or symlinks or log files is remote at best.

This is not going to be a "fix a few problems and it works" type of
exercise.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

bison-1.875-1 generates code incompatible with g++

[Max Bowsher]

(Ran into this when building setup)

bison 1.875 produces this code fragment:

| yyerrlab1:
|
|   /* Suppress GCC warning that yyerrlab1 is unused when no action
|  invokes YYERROR.  */
| #if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
|   __attribute__ ((__unused__))
| #endif

which compiles with gcc, but g++ doesn't accept attributes on labels.

This seems to be a g++ bug.

Comments?


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: installing pinfo

[Robert Mark Bram]

Howdy Max!

> Run:
> 
> $ ls -l /bin/pinfo
> $ cygcheck -c pinfo
> 
> Post the output of those 2 commands here, and we'll try to help.


$ ls -l /bin/pinfo
ls: /bin/pinfo: No such file or directory

$ cygcheck -c pinfo
Cygwin Package Information
Package Version
pinfo   0.6.6p1-1

Use -h to see help about each section

$

Rob
:)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bison-1.875-1 generates code incompatible with g++

[Christopher Faylor]

On Sun, Feb 02, 2003 at 07:33:22PM -, Max Bowsher wrote:
>(Ran into this when building setup)
>
>bison 1.875 produces this code fragment:
>
>| yyerrlab1:
>|
>|   /* Suppress GCC warning that yyerrlab1 is unused when no action
>|  invokes YYERROR.  */
>| #if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
>|   __attribute__ ((__unused__))
>| #endif
>
>which compiles with gcc, but g++ doesn't accept attributes on labels.
>
>This seems to be a g++ bug.
>
>Comments?

Probably one of the mailing lists designed for bison would have observations
about this:

http://mail.gnu.org/mailman/listinfo

Search for "bison".

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[G. Ken Holman]

Hi folks,

I used to use one of the Cygwin B packages where the egrep.exe utility was 
included.

I'm on an XP system and I downloaded replacement packages yesterday and 
ensured that I included the "grep" package.

I went to use "egrep.exe" and found it wasn't installed.  I did find an 
egrep.1 but it just points to grep.

I reviewed my installation and found "Keep" for grep package 2.5-1 
(indicating to me the package has been installed), and see egrep listed in 
the package description.  I also see fgrep listed, though I'm not 
interested in using it.

Neither egrep.exe nor fgrep.exe exist in my bin/ directory, as I would have 
expected.  Did this fall through the cracks?

In the short term I can copy grep.exe to egrep.exe because my existing 
batch files rely on it by name, so I just thought I'd report this in case 
either:

 (1) the files get added or

 (2) the package description removes references to the files not included.

I hope this helps.

... Ken

p.s. http://cygwin.com/bugs.html points to http://cygwin.com/lists.html and 
says where *not* to send bugs, but not where bugs should be sent for 
problems like this ... I would have thought that would be a FAQ: "which 
bugs (by example) go to which mail lists?"

--
Upcoming hands-on in-depth   Europe: February 17-21, 2003
XSLT/XPath and/or XSL-FO North America:  June 16-20, 2003

G. Ken Holmanmailto:[EMAIL PROTECTED]
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/z/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6  Definitive XSLT and XPath
ISBN 0-13-140374-5  Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1  Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/z/bc



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: installing pinfo

[Elfyn McBratney]

> $ cygcheck -c pinfo
> Cygwin Package Information
> Package Version
> pinfo   0.6.6p1-1

As far as setup (cygcheck) is concerned you have pinfo installed but it's
not working (corrupt, unknown?).Double check your path (PATH env. variable)
is set-up correctly, just a thought before you re-install. If cygwin (your
PATH env. variable) is set-up correctly return to setup and re-install
pinfo.


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Christopher Faylor]

On Sun, Feb 02, 2003 at 03:05:07PM -0500, G. Ken Holman wrote:
>I used to use one of the Cygwin B packages where the egrep.exe utility was 
>included.

Sigh.

>I'm on an XP system and I downloaded replacement packages yesterday and 
>ensured that I included the "grep" package.
>
>I went to use "egrep.exe" and found it wasn't installed.  I did find an 
>egrep.1 but it just points to grep.

egrep and fgrep are symbolic links to grep.exe.  Both work properly when
invoked from bash.  I just checked.

>p.s. http://cygwin.com/bugs.html points to http://cygwin.com/lists.html and 
>says where *not* to send bugs, but not where bugs should be sent for 
>problems like this ... I would have thought that would be a FAQ: "which 
>bugs (by example) go to which mail lists?"

The cygwin mailing list says that it is for "just about all things
cygwin" with "two exceptions".

Is grep, egrep, or fgrep listed as one of the two exceptions?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[G. Ken Holman]

Hi folks,

I used to use one of the Cygwin B packages where the egrep.exe utility was 
included.

I'm on an XP system and I downloaded replacement packages yesterday and 
ensured that I included the "grep" package.

I went to use "egrep.exe" and found it wasn't installed.  I did find an 
egrep.1 but it just points to grep.

I reviewed my installation and found "Keep" for grep package 2.5-1 
(indicating to me the package has been installed), and see egrep listed in 
the package description.  I also see fgrep listed, though I'm not 
interested in using it.

Neither egrep.exe nor fgrep.exe exist in my bin/ directory, as I would have 
expected.  Did this fall through the cracks?

In the short term I can copy grep.exe to egrep.exe because my existing 
batch files rely on it by name, so I just thought I'd report this in case 
either:

 (1) the files get added or

 (2) the package description removes references to the files not included.

I hope this helps.

... Ken

p.s. http://cygwin.com/bugs.html points to http://cygwin.com/lists.html and 
says where *not* to send bugs, but not where bugs should be sent for 
problems like this ... I would have thought that would be a FAQ: "which 
bugs (by example) go to which mail lists?"

--
Upcoming hands-on in-depth   Europe: February 17-21, 2003
XSLT/XPath and/or XSL-FO North America:  June 16-20, 2003

G. Ken Holmanmailto:[EMAIL PROTECTED]
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/z/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6  Definitive XSLT and XPath
ISBN 0-13-140374-5  Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1  Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/z/bc


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Randall R Schulz]

Ken,

At 12:05 2003-02-02, G. Ken Holman wrote:

Hi folks,

I used to use one of the Cygwin B packages where the egrep.exe utility 
was included.

"B" as in beta? b17, b18... One of those? Ancient history and truly the 
good old days of Cygnus / Cygwin.


I'm on an XP system and I downloaded replacement packages yesterday 
and ensured that I included the "grep" package.

I went to use "egrep.exe" and found it wasn't installed.  I did find 
an egrep.1 but it just points to grep.

That's a common technique in Unix programming. Because by universal 
convention the name of the program _as it was invoked_ is passed as 
argument 0, a single binary can have "multiple personalities." This can 
be accomplished by either symbolic or hard links. Grep is one such 
multifaceted program. When invoked as "egrep" it behaves like egrep.


I reviewed my installation and found "Keep" for grep package 2.5-1 
(indicating to me the package has been installed), and see egrep 
listed in the package description.  I also see fgrep listed, though 
I'm not interested in using it.

Neither egrep.exe nor fgrep.exe exist in my bin/ directory, as I would 
have expected.  Did this fall through the cracks?

Look for the symlinks "fgrep -> grep" and "egrep -> grep". Symlinks 
don't include the ".exe" suffix even if they're pointing to a ".exe" 
file. The same goes for the symlink target name, too.


In the short term I can copy grep.exe to egrep.exe because my existing 
batch files rely on it by name, so I just thought I'd report this in 
case either:

 (1) the files get added or

 (2) the package description removes references to the files not included.

I don't believe anything needs to be fixed in the package. Perhaps for 
some reason your system lost the symlinks that supply fgrep and egrep?


I hope this helps.

... Ken

p.s. http://cygwin.com/bugs.html points to 
http://cygwin.com/lists.html and says where *not* to send bugs, but 
not where bugs should be sent for problems like this ... I would have 
thought that would be a FAQ: "which bugs (by example) go to which mail lists?"


Randall Schulz 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Elfyn McBratney]

> I'm on an XP system and I downloaded replacement packages yesterday and
> ensured that I included the "grep" package.
>
> I went to use "egrep.exe" and found it wasn't installed.  I did find an
> egrep.1 but it just points to grep.

The file you are loking for, egrep.exe is no longer in the packge. Instead
there is a symbolic link from egrep to grep, which AFAIK uses the same "if
your name is sh, behave like sh" semantics, but don't quote me on this as
I'm not too sure ;-)

> I reviewed my installation and found "Keep" for grep package 2.5-1
> (indicating to me the package has been installed), and see egrep listed in
> the package description.  I also see fgrep listed, though I'm not
> interested in using it.
>
> Neither egrep.exe nor fgrep.exe exist in my bin/ directory, as I would
have
> expected.  Did this fall through the cracks?

Again these are jyst syms to the main binary:

lrwxrwxrwx1 root root   15 Nov 27 20:04 /bin/egrep -> grep
lrwxrwxrwx1 root root   15 Nov 27 20:04 /bin/fgrep -> grep

> In the short term I can copy grep.exe to egrep.exe because my existing
> batch files rely on it by name, so I just thought I'd report this in case
> either:
>
>   (1) the files get added or
>
>   (2) the package description removes references to the files not
included.

You might consider instead editing your scripts to make hem more
cross-compatible...Just a thought.


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: missing make

[mibrah]

> Hi, I need to install CygWin on my pc (running windows 98) but I know
> almost nothing of itI've just tried to install all the packages I
don't
> know why but the file make.exe is missing in my bin directorywhy? what
> happened?

Not too sure :| For starters, just incase, run these two lines:

$ /bin/ls -al /bin/make /bin/make.exe
$ cygcheck -c make

If neither, first showing the file information, and the second saying
nothing about make's version, give you any informative info then you don't
have make installed. If so, return to setup and install it :-)

If you have it installed re-install it, and if nake still doesn't show then
reply with the output of `cygcheck -svr' at a *non-compressed* plain text
attachment.


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk




what you suggest doesn't work and I've also tried to reinstall ALL the packages. 
the file "make.exe" still misses in my bin directory.. :-(

does anybody know why?

I'm posting the output of the "cygcheck -svr" command... be patient ;-)
---


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sun Feb 02 17:26:28 2003

Windows 98 SE Ver 4.10 Build  

Path:   C:\MOUSE
C:\WINDOWS
C:\WINDOWS\COMMAND
C:\PROGRAMMI\JAVASOFT\JRE\1.3.1_04\BIN
C:\CYGWIN\BIN
C:\PROGRAMMI\MTS

SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS


TMP = `C:\WINDOWS\TEMP'
TEMP = `C:\WINDOWS\TEMP'
PROMPT = `$p$g'
winbootdir = `C:\WINDOWS'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
CLASSPATH = `C:\Program Files\PhotoDeluxe 2.0\AdobeConnectables'
SOUND = `C:\PROGRA~1\CREATIVE\CTSND'
MIDI = `SYNTH:1 MAP:E'
windir = `C:\WINDOWS'
BLASTER = `A220 I5 D1 H1 P330 T6'
CMDLINE = `cygcheck -svr '

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 = 0x0020
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x0008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options

a:  fd  FAT1Mb  20% CPUN   PKBACK#001
c:  hd  FAT32   2043Mb  78% CPUN   
d:  hd  FAT32900Mb  88% CPUN   
e:  cd  CDFS   8Mb 100%030202_0011

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

Found: .\bash.exe
Found: C:\CYGWIN\BIN\bash.exe
Warning: .\bash.exe hides C:\CYGWIN\BIN\bash.exe
Found: .\cat.exe
Found: C:\CYGWIN\BIN\cat.exe
Warning: .\cat.exe hides C:\CYGWIN\BIN\cat.exe
Not Found: cpp (good!)
Found: .\find.exe
Found: C:\WINDOWS\COMMAND\find.exe
Warning: .\find.exe hides C:\WINDOWS\COMMAND\find.exe
Found: C:\CYGWIN\BIN\find.exe
Warning: .\find.exe hides C:\CYGWIN\BIN\find.exe
Not Found: gcc
Not Found: gdb
Not Found: ld
Found: .\ls.exe
Found: C:\CYGWIN\BIN\ls.exe
Warning: .\ls.exe hides C:\CYGWIN\BIN\ls.exe
Not Found: make
Found: .\sh.exe
Found: C:\CYGWIN\BIN\sh.exe
Warning: .\sh.exe hides C:\CYGWIN\BIN\sh.exe

   19k 2002/02/20 .\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
  "cyggdbm.dll" v0.0 ts=2002/2/20 4:05
   22k 2001/12/13 .\cygintl-1.dll - os=4.0 img=1.0 sys=4.0
  "cygintl-1.dll" v0.0 ts=2001/12/13 10:28
   45k 2001/04/25 .\cygform5.dll - os=4.0 img=1.0 sys=4.0
  "cygform5.dll" v0.0 ts=2001/4/25 7:28
   26k 2001/04/25 .\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
  "cygmenu5.dll" v0.0 ts=2001/4/25 7:27
  156k 2001/04/25 .\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
  "cygncurses++5.dll" v0.0 ts=2001/4/25 7:29
  226k 2001/04/25 .\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
  "cygncurses5.dll" v0.0 ts=2001/4/25 7:17
   15k 2001/04/25 .\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
  "cygpanel5.dll" v0.0 ts=2001/4/25 7:27
   35k 2002/01/09 .\cygform6.dll - os=4.0 img=1.0 sys=4.0
  "cygform6.dll" v0.0 ts=2002/1/9 7:03
   20k 2002/01/09 .\cygmenu6.dll - os=4.0 img=1.0 sys=4.0
  "cygmenu6.dll" v0.0 ts=2002/1/9 7:03
  175k 2002/01/09 .\cy

Re: missing make

[Elfyn McBratney]

> what you suggest doesn't work and I've also tried to reinstall ALL
> the packages. the file "make.exe" still misses in my bin
> directory.. :-(
>
> does anybody know why?
>
> I'm posting the output of the "cygcheck -svr" command... be patient
;-)
> -
> Package Version
> ash 20020731-1
> bash2.05b-2
> cygwin  1.3.12-2
> [...]
> login   1.4-3
> ncurses 5.2-8
> readline4.3-1
> [...]

No make there.

Ok, follow these steps and report back with your progress:

1. Run these commands from a cygwin shell

$ which make
$ ls -al /bin/make

2. If the above doesn't find make return to setup and click through to the
package selection chooser. Click on the Devel tree and click on make's
version info bit (that either says keep,install,re-install,source) untill it
says re-install or install whichever it may be.

3. Run these again...after setup finishes

$ which make
$ ls -al /bin/make


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[G. Ken Holman]

At 2003-02-02 15:25 -0500, Christopher Faylor <[EMAIL PROTECTED]> wrote:

On Sun, Feb 02, 2003 at 03:05:07PM -0500, G. Ken Holman wrote:
>I used to use one of the Cygwin B packages where the egrep.exe utility was
>included.

Sigh.


I apologize for having taken your time with this to warrant such an 
exclamation.  I was citing my previous experience with Cygwin where I had 
utilized an "exe" and created ".bat" files that pointed to it.  After 
installing the new version my batch files stopped working.

>I'm on an XP system and I downloaded replacement packages yesterday and
>ensured that I included the "grep" package.
>
>I went to use "egrep.exe" and found it wasn't installed.  I did find an
>egrep.1 but it just points to grep.

egrep and fgrep are symbolic links to grep.exe.  Both work properly when
invoked from bash.  I just checked.


Perhaps ... but I'm not running under bash and never have.  Did I miss a 
documented restriction that the programs *only* run under bash?

Could there be a FAQ that says "where is the .exe I'm expecting?" ... when 
not running in bash?  I did a search on the FAQ TOC for .exe and didn't 
find anything.

I honestly tried to solve this without burdening the list with another 
question, and was basing my question on my prior experience with the Cygwin 
collection.

>p.s. http://cygwin.com/bugs.html points to http://cygwin.com/lists.html and
>says where *not* to send bugs, but not where bugs should be sent for
>problems like this ... I would have thought that would be a FAQ: "which
>bugs (by example) go to which mail lists?"

The cygwin mailing list says that it is for "just about all things
cygwin" with "two exceptions".

Is grep, egrep, or fgrep listed as one of the two exceptions?


I now see the word "bugs" in the description that I had missed 
earlier.  Sorry for my oversight.

Again, I apologize that I have taken your time; I was quite sincere in my 
attempts to help the project.

 Ken


--
Upcoming hands-on in-depth   Europe: February 17-21, 2003
XSLT/XPath and/or XSL-FO North America:  June 16-20, 2003

G. Ken Holmanmailto:[EMAIL PROTECTED]
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/z/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6  Definitive XSLT and XPath
ISBN 0-13-140374-5  Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1  Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/z/bc


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: missing make

[Elfyn McBratney]

Also in any follow-up messages where you need to send along your cygcheck
output please send it to the mailing list at a plain text *non-compressed*
attachment, instead of including the output in the message because it can
cause false-positives on the search engine for the archives. :-)


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Elfyn McBratney]

> Perhaps ... but I'm not running under bash and never have.  Did I miss a
> documented restriction that the programs *only* run under bash?

It depends on the package. With something like grep you cannot (?) call a
egrep from cmd.exe/command.com per se as it is a symbolic link to grep.exe
(a windows shortcut) but you could call it from bash

> bash -c /bin/egrep

within your batch scripts.


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Max Bowsher]

G. Ken Holman wrote:
> At 2003-02-02 15:25 -0500, Christopher Faylor <[EMAIL PROTECTED]>
> wrote:
>> On Sun, Feb 02, 2003 at 03:05:07PM -0500, G. Ken Holman wrote:
>>> I used to use one of the Cygwin B packages where the egrep.exe
>>> utility was included.
>>
>> Sigh.
>
> I apologize for having taken your time with this to warrant such an
> exclamation.

I think the "Sigh" was referring to the fact that people are *still* using
Bxx versions, even though they are about 5 years old.

> I was citing my previous experience with Cygwin where I
> had utilized an "exe" and created ".bat" files that pointed to it.
> After installing the new version my batch files stopped working.

Well, Bxx -> 1.3.x is a major version number increase. A little breakage
here and there is to be expected.

>>> I'm on an XP system and I downloaded replacement packages yesterday
>>> and ensured that I included the "grep" package.
>>>
>>> I went to use "egrep.exe" and found it wasn't installed.  I did
>>> find an egrep.1 but it just points to grep.
>>
>> egrep and fgrep are symbolic links to grep.exe.  Both work properly
>> when invoked from bash.  I just checked.
>
> Perhaps ... but I'm not running under bash and never have.  Did I
> miss a documented restriction that the programs *only* run under bash?

No, but running symlinks from a non-Cygwin program is not possible.

> Could there be a FAQ that says "where is the .exe I'm expecting?" ...
> when not running in bash?  I did a search on the FAQ TOC for .exe and
> didn't find anything.

Its not frequently-asked - possibly because most people use Cygwin shells.

> I honestly tried to solve this without burdening the list with another
> question, and was basing my question on my prior experience with the
> Cygwin collection.

Good. But the list is here to help, so don't worry. Also, if you have just
upgraded from a Bxx version, then your prior experience will be a little
out-of-date.


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Max Bowsher]

Elfyn McBratney wrote:
>> Perhaps ... but I'm not running under bash and never have.  Did I
>> miss a documented restriction that the programs *only* run under
>> bash?
>
> It depends on the package. With something like grep you cannot (?)
> call a egrep from cmd.exe/command.com per se as it is a symbolic link
> to grep.exe (a windows shortcut) but you could call it from bash

Ah, but since it is created by setup, it is a system-cookie type symlink,
not a windows-shortcut type symlink.

>> bash -c /bin/egrep
>
> within your batch scripts.

What about grep -E ? (Which is preferred anyway for maximum portability.)

Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[avail for test] libtool-devel-20030121-1

[Charles Wilson]

I've updated libtool-devel to the 20030121 CVS, plus added a major 
change of my own (inspired by Earnie Boyd and others on the libtool 
mailing list) that "fixes" the 'relink exe's over and over and over' 
problem on both mingw and cygwin.

[Skip to the last two paragraphs for the real important part]

A (not-so-short) description of the problem and the solution approach 
taken: if you have a package that builds a shared library (.dll) AND an 
exe which relies on that library, then libtool puts the actual 
executable into a .lib/ subdirectory under your current build directory, 
and NOT in the build directory itself.

This is also done on "real" unix platforms.  The reason is that 
uninstalled shared libraries cannot easily be found by the runtime 
loader on most platforms, unix and cygwin/windows included.

So, in order to run the uninstalled executable, you must first set the 
environment appropriately so that the shared library (.dll) will be 
found.  This means setting LD_LIBRARY_PATH on some unices, or setting 
PATH on cygwin so that the Windows Runtime Loader will find the .dll.

libtool does this by creating a shell script in the actual build 
directory.  The shell script sets the variables and then exec's 
./lib/my-real-executable.

If your application is "foo", this works fine on unix.  The makefile 
wants to see 'foo' -- and it does; only the 'foo' that make sees is 
actually a shell script:

  /foo   : a shell script
  /.lib/foo  : the real executable

And it only gets built once.  However, on cygwin/windows, you have
  /foo   : a shell script
  /.lib/foo.exe  : the real executable
and the makefile *wants* 'foo.exe' -- but only sees 'foo'.  Therefore, 
make assumes that the executable hasn't been created, and builds it 
again.  EVERY time you run 'make '.  Sometimes *multiple* 
times if there are cross-dependencies.

There were several solutions:
  1) Teach 'make' to only want 'foo' instead of 'foo.exe'.  There are 
problems here -- this requires mucking with automake, which has the 
potential to break non-libtool builds if not done carefully.
  2) Name the script 'foo.exe' -- bad idea.  cygwin and mingw take one 
look at the extension, and simply exec it directly *without* parsing the 
first line for an interpreter.  Doing this would actually require mods 
to the cygwin and MSYS kernel -- and would slow cygwin down on *every* 
executable invokation.



  3) What I did:  create a binary wrapper -- an actual executable -- 
named 'foo.exe' in the main build directory.  It is NOT the real 
foo.exe.  It simply exec's the shell script, which in turn sets up the 
environment and exec's the real .lib/foo.exe.  Eventually, the 'set up 
the environment' part could be moved into the binary wrapper itself, at 
least on cygwin/mingw -- but there are problems with that; libtool 
itself *sources* and parses the shell wrapper -- it can't do that with a 
binary wrapper.  So that's for later.  This works now, even if it is a 
bit kludgey.

Unfortunately, it might lead to a FAQ: the shell wrapper contains a 
banner at the top that says "This is not the real foo.exe.  It is a 
wrapper" blah blah blah.  Plus, it's named 'foo' instead of 'foo.exe' -- 
a tipoff for us windows denizens.  Now, you have:

/foo   : shell wrapper
/foo.exe   : binary wrapper
/.lib/foo.exe  : the real executable

There's no easy way to 'label' /foo.exe as a wrapper -- so 
some folks may be tempted to install it, with disappointing results. 
Perhaps if the binary wrapper doesn't find .libs/foo.exe, it can report 
an error of the form:
  "You must have installed foo.exe by hand, because I am not the
real foo.exe.  I am simply a wrapper used during the build process.  Go 
back to your build directory, and look in the .lib subdirectory for the 
real foo.exe.  And next time, use 'make install' -- don't try to install 
libtoolized packages by hand."

In any case, my patch has made it into libtool CVS as of 2003-01-30 
(without the friendly error message), but I haven't updated this test 
distribution to that level; I'm simply releasing my patched version of 
2002-01-21.

So, test and enjoy; I will probably make this the official cygwin 
libtool-devel very soon.  It has been up on my off-site cygutils testing 
area for almost two weeks, and now that Robert Boehne has put this 
iteration of my patch into CVS I wanted to release it to a wider testing 
audience.

Unless there are significant bugs reported, I do not expect to update 
our libtool-devel again until libtool-1.5 is released, which may be in a 
month -- or it may be in June.  For now, I am happy with the status of 
libtool-devel (the friendly error message is just a simple cosmetic fix; 
I'm too swamped right now to worry about cosmetics; functionality only.)

[IMPORTANT]
Translation: this will be the basic behavior of official libtool-1.5 on 
cygwin.  If you don't like it, now is the time to yell.  So TEST, you 
huskies, TEST!

Anyway, you know the drill: setup.ex

Re: missing make

[mibrah]

Also in any follow-up messages where you need to send along your cygcheck
output please send it to the mailing list at a plain text *non-compressed*
attachment, instead of including the output in the message because it can
cause false-positives on the search engine for the archives. :-)


Regards,

Elfyn McBratney
[EMAIL PROTECTED]
www.exposure.org.uk





I'm sorry :-)

but in my mind it didn't make much sense to send an attachment to a forum I think 
I've never seen a such thing...

however I've done :-))

I won't disturb you any more with my silliness ;-)

thanx a lot

Best regards




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Randall R Schulz]

Max,

At 13:12 2003-02-02, Max Bowsher wrote:

Elfyn McBratney wrote:
>> Perhaps ... but I'm not running under bash and never have.  Did I
>> miss a documented restriction that the programs *only* run under
>> bash?
>
> It depends on the package. With something like grep you cannot (?)
> call a egrep from cmd.exe/command.com per se as it is a symbolic link
> to grep.exe (a windows shortcut) but you could call it from bash

Ah, but since it is created by setup, it is a system-cookie type symlink,
not a windows-shortcut type symlink.


On my system both egrep and fgrep are old-style Cygwin-only symlinks. 
But some of the symlinks in my Cygwin bin directory are the new Windows 
shortcut-based symlinks.

Perhaps this mixture occurs for me because my Cygwin installation 
predates the debut of the Windows-shortcut-based symlinks. Or could it 
be because some of the symlinks are created by post-install scripts and 
are new-style and others are created by the tar code embedded in the 
Cygwin Setup.exe installer and are the old kind?


>> bash -c /bin/egrep
>
> within your batch scripts.

What about grep -E ? (Which is preferred anyway for maximum portability.)


(Oh?)



Max.



Randall Schulz 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Setup 2.249.2.5, Package 'grep' 2.5-1, missing 'egrep.exe' and 'fgrep.exe'

[Max Bowsher]

Randall R Schulz wrote:
> Max,
>
> At 13:12 2003-02-02, Max Bowsher wrote:
>> Elfyn McBratney wrote:
 Perhaps ... but I'm not running under bash and never have.  Did I
 miss a documented restriction that the programs *only* run under
 bash?
>>>
>>> It depends on the package. With something like grep you cannot (?)
>>> call a egrep from cmd.exe/command.com per se as it is a symbolic
>>> link to grep.exe (a windows shortcut) but you could call it from
>>> bash
>>
>> Ah, but since it is created by setup, it is a system-cookie type
>> symlink, not a windows-shortcut type symlink.
>
> On my system both egrep and fgrep are old-style Cygwin-only symlinks.
> But some of the symlinks in my Cygwin bin directory are the new
> Windows shortcut-based symlinks.
>
> Perhaps this mixture occurs for me because my Cygwin installation
> predates the debut of the Windows-shortcut-based symlinks. Or could it
> be because some of the symlinks are created by post-install scripts
> and are new-style and others are created by the tar code embedded in
> the Cygwin Setup.exe installer and are the old kind?

The 2nd.

 bash -c /bin/egrep
>>>
>>> within your batch scripts.
>>
>> What about grep -E ? (Which is preferred anyway for maximum
>> portability.)
>
> (Oh?)

IIRC, POSIX dropped the requirement for egrep and fgrep. Libtool has been
converting egrep -> "grep -E" and fgrep -> "grep -F".


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: installing pinfo

[Igor Pechtchanski]

On Sun, 2 Feb 2003, Elfyn McBratney wrote:

> > $ cygcheck -c pinfo
> > Cygwin Package Information
> > Package Version
> > pinfo   0.6.6p1-1
>
> As far as setup (cygcheck) is concerned you have pinfo installed but it's
> not working (corrupt, unknown?).Double check your path (PATH env. variable)
> is set-up correctly, just a thought before you re-install. If cygwin (your
> PATH env. variable) is set-up correctly return to setup and re-install
> pinfo.
>
> Regards,
>
> Elfyn McBratney

I think you meant the mount table, not the PATH variable, since specifying
an explicit path to /bin/pinfo didn't work.

To the OP: one more guess, though: try posting the result of "ls -l
/bin/pinfo.exe" (notice the extension).  If that file exists, but is not
executable, there's something wrong with either your CYGWIN variable or
your mount table (or your umask, but I doubt that).
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't see full list in setup.exe

[Colin Harrison]

Hi,

I'm trying to find the snapshot setup-2.303 sources, to make a debug
build...
The released sources (2.249.2.5-1) configure on my system but don't make.

I'm following instructions:-

>> Try downloading the source for setup and building it from that.
>> Since you
>> can't see the packages for some reason, a direct link to the source
>> tarball is
>>
>>ftp://archive.progeny.com/cygwin/release/setup/setup-2.249.2.5-1-src.tar.b
z
>>
>> Instructions for compiling are at
>> . Enjoy.

>That won't work, I'm afraid. The current instructions on that webpage are
>for building with gcc 3. But setup didn't support building with gcc 3 until
>recently. You could try the setup-2.303 source from the snapshots area. But
>you cannot easily (at all?) build setup without Cygwin installed.

Note that I can see all the packages on my development system (but am
building to trace
the no-show on my production machine)

I've looked in CVS (:pserver:[EMAIL PROTECTED]) and
http://cgwin.com/snapshots
Am I looking in the correct areas?

Thanks

Colin


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't see full list in setup.exe

[Max Bowsher]

Colin Harrison wrote:
> I'm trying to find the snapshot setup-2.303 sources, to make a debug
> build...
> The released sources (2.249.2.5-1) configure on my system but don't
> make.
>
> I'm following instructions:-
>
>>> Try downloading the source for setup and building it from that.
>>> Since you
>>> can't see the packages for some reason, a direct link to the source
>>> tarball is
>>>
>>>
ftp://archive.progeny.com/cygwin/release/setup/setup-2.249.2.5-1-src.tar.b
>>> z
>>>
>>> Instructions for compiling are at
>>> . Enjoy.
>
>> That won't work, I'm afraid. The current instructions on that
>> webpage are for building with gcc 3. But setup didn't support
>> building with gcc 3 until recently. You could try the setup-2.303
>> source from the snapshots area. But you cannot easily (at all?)
>> build setup without Cygwin installed.
>
> Note that I can see all the packages on my development system (but am
> building to trace
> the no-show on my production machine)
>
> I've looked in CVS (:pserver:[EMAIL PROTECTED]) and
> http://cgwin.com/snapshots
> Am I looking in the correct areas?

You should look more closely at the instructions webpage. It contains the
correct cvs location:
"cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvs/cygwin-apps co setup"

Alternatively, snapshot source tarball is at
http://cygwin.com/setup-snapshots/.


Max.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't see full list in setup.exe

[Igor Pechtchanski]

On Sun, 2 Feb 2003, Colin Harrison wrote:

> Hi,
>
> I'm trying to find the snapshot setup-2.303 sources, to make a debug
> build...
> The released sources (2.249.2.5-1) configure on my system but don't make.
>
> I'm following instructions:-
>
> >> Try downloading the source for setup and building it from that. Since
> >> you can't see the packages for some reason, a direct link to the
> >> source tarball is
> >> 
> >>
> >> Instructions for compiling are at
> >> . Enjoy.
>
> >That won't work, I'm afraid. The current instructions on that webpage are
> >for building with gcc 3. But setup didn't support building with gcc 3 until
> >recently. You could try the setup-2.303 source from the snapshots area. But
> >you cannot easily (at all?) build setup without Cygwin installed.
>
> Note that I can see all the packages on my development system (but am
> building to trace the no-show on my production machine)
>
> I've looked in CVS (:pserver:[EMAIL PROTECTED]) and
> http://cygwin.com/snapshots
> Am I looking in the correct areas?
>
> Thanks
> Colin

Colin,

The page with the build instructions mentioned above also contains the cvs
checkout command to get the latest setup source.

FYI, I have also built setup-2.249.2.5 from the source package before,
using the following configure line:

/usr/src/setup-2.249.2.5/configure -C --enable-dependencies --disable-shared 
--host=i686-pc-mingw32 --build=i686-pc-cygwin 'CC=gcc-2 -mno-cygwin' 'CXX=g++-2 
-mno-cygwin' 'CPPFLAGS=-I/usr/include/g++-3' --enable-maintainer-mode
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Can't see full list in setup.exe

[Colin Harrison]

Hi,

Thanks.
I got a build to make for 2.303 using the instructions on
http://sources.redhat.com/cygwin-apps/setup.html

And it runs and exhibits the fault on the original prod. machine (of cause
it naturally works on my
development machine..what doesn't!). I've got the software (XP Pro) and as
many settings as possible to match,
but the development machine is a shinny/fast new one with different hardware
(and drivers!!)

So the fun can now begin..

Colin


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: User Guide page out of date

[Joshua Daniel Franklin]

> A note to the maintainer of the User Guide: the "regtool" information on
>  is out of date (so, for
> that matter, is the regtool manpage).  For more info, see "regtool
> --help".  

I've fixed this in CVS. For future reference, it would be best to submit 
a patch for utils.sgml whenever you add a option to one of the utils.
Also, you can't use things like "" in SGML files, you have to use
"" (unless it really is an SGML tag, of course). 

> I could provide a patch for the manpage if I only knew what to
> diff against.  

>From /usr/doc/Cygwin/cygwin-doc-1.3-2.README :
-
The two intro pages (intro.1 and intro.3) were written by hand by me.
The rest of the cygwin man pages are autogenerated from the SGML files
found in CVS. 
-

Expect a refresh of cygwin-doc (relatively) soon.

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bash & $PS1 (display error)

[Carlo Florendo]

> Sorry to but-in :-)
>
> Now, I havent't been following this thread *bad me* but is the problem
that
> once you've typed say over 60 characters on the prompt it then starts
> overwritting the prompt instead of carrying onto the next line?
>
> If not, Sorry for buttin-in...I'll but-out now ;-)
>
>
> Regards,
>
> Elfyn McBratney
> [EMAIL PROTECTED]
> www.exposure.org.uk

I've had the problem of prompt overwriting but it really didn't bother me
since I know the commands are there but they just don't appear.

When I execute the same command some another time by using the arrow keys to
scroll through previous commands I've typed, the prompt gets overwritten
too.

What may be the cause of the problem?

Thanks!

Regards,

Carlo





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

1.3.19-1:poll bug. Patch included.

[Peter Rehley]

Hello,

While working on another program (syslogd in inetutils) I found that 
the poll function was returning POLLERR when something arrived on a UDP 
socket; it should be return POLLIN.  Inside the poll function, recvfrom 
was returning -1 with errno = EMSGSIZE, but the only error value being 
check for in WSAENOTCONN.  However EMSGSIZE is a reasonable return 
value since the buffer to recvfrom was only 1 byte while the actual 
message size was larger than this.  Basically saying your buffer is too 
small for the message, but since we are only peeking, this shouldn't be 
returned as a POLLERR.

The fix should be to add EMSGSIZE as part of the condition so this 
error returns POLLIN.  I'm including the patch below and a changelog 
following that.  Please review these changes and make sure that they 
seem reasonable.  I've done tests on my system (windows XP) and have 
verified that the change works.

Patch
---
Index: winsup/cygwin/poll.cc
===
RCS file: /cvs/src/src/winsup/cygwin/poll.cc,v
retrieving revision 1.34
diff -u -p -r1.34 poll.cc
--- winsup/cygwin/poll.cc	20 Nov 2002 11:00:15 -	1.34
+++ winsup/cygwin/poll.cc	3 Feb 2003 01:52:10 -
@@ -112,7 +112,8 @@ poll (struct pollfd *fds, unsigned int n
  sense then.  It returns WSAENOTCONN in that
  case.  Since that's not actually an error,
  we must not set POLLERR but POLLIN. */
-			  if (WSAGetLastError () != WSAENOTCONN)
+			  if (WSAGetLastError () != WSAENOTCONN &&
+  errno!=EMSGSIZE)
 fds[i].revents |= POLLERR;
 			  else
 fds[i].revents |= POLLIN;
--
Changelog
2003-02-02  Peter Rehley<[EMAIL PROTECTED]>

* poll.cc: EMSGSIZE being ignore returning incorrect POLLERR on UDP 
socket receive
 if recvfrom returns error, return POLLIN if errno = EMSGSIZE
---

Peter
=
Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.3.19-1:poll bug. Patch included.

[Christopher Faylor]

On Sun, Feb 02, 2003 at 06:37:34PM -0800, Peter Rehley wrote:
>Hello,
>
>While working on another program (syslogd in inetutils) I found that 
>the poll function was returning POLLERR when something arrived on a UDP 
>socket; it should be return POLLIN.  Inside the poll function, recvfrom 
>was returning -1 with errno = EMSGSIZE, but the only error value being 
>check for in WSAENOTCONN.  However EMSGSIZE is a reasonable return 
>value since the buffer to recvfrom was only 1 byte while the actual 
>message size was larger than this.  Basically saying your buffer is too 
>small for the message, but since we are only peeking, this shouldn't be 
>returned as a POLLERR.
>
>The fix should be to add EMSGSIZE as part of the condition so this 
>error returns POLLIN.  I'm including the patch below and a changelog 
>following that.  Please review these changes and make sure that they 
>seem reasonable.  I've done tests on my system (windows XP) and have 
>verified that the change works.

Thanks for the patch.  Would you mind reworking it so that it doesn't set
errno at all in the case that you describe and then check against the correct
WSAGetLastError value?

cgf

>Patch
>---
>Index: winsup/cygwin/poll.cc
>===
>RCS file: /cvs/src/src/winsup/cygwin/poll.cc,v
>retrieving revision 1.34
>diff -u -p -r1.34 poll.cc
>--- winsup/cygwin/poll.cc  20 Nov 2002 11:00:15 -  1.34
>+++ winsup/cygwin/poll.cc  3 Feb 2003 01:52:10 -
>@@ -112,7 +112,8 @@ poll (struct pollfd *fds, unsigned int n
>sense then.  It returns WSAENOTCONN in that
>case.  Since that's not actually an error,
>we must not set POLLERR but POLLIN. */
>-if (WSAGetLastError () != WSAENOTCONN)
>+if (WSAGetLastError () != WSAENOTCONN &&
>+errno!=EMSGSIZE)
>   fds[i].revents |= POLLERR;
> else
>   fds[i].revents |= POLLIN;
>--
>Changelog
>2003-02-02  Peter Rehley<[EMAIL PROTECTED]>
>
>* poll.cc: EMSGSIZE being ignore returning incorrect POLLERR on UDP 
>socket receive
> if recvfrom returns error, return POLLIN if errno = EMSGSIZE
>---
>
>Peter
>=
>Infinity Softworks.  Making scientific, financial and realtor 
>calculators for Palm Pilots and other PDAs since 1997
>
>Visit them today at http://www.infinitysw.com
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Segmentation fault running JvCreateJavaVM possile bug ?

[school]

On Wed, 29 Jan 2003 12:05:12 -0500
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Sorry, I don't have time to try this (I don't use gcj) but have you 
> looked here:
> 
> http://cygwin.com/cygwin-ug-net/dll.html
> 
> It's hard for me to tell by the information you've given but I do 
> see some differences between what you're doing (in process) and 
> that which is described in this guide.  Perhaps that will help?
> 
> Larry
Thanks for your hint. I've got one step further.

I can link programs  against "gcc -shared " created dll but only with gcc.
I made an export file (def) and a library (lib) with implib and compiled the same 
sample with
bcc32 and it links ok.But at runtime an error pops up saying :

  DLLtest.exe raised an EAccessViolation class error.Illegal acces to 000 from 
address 6100F47B in cygwin1.dll.Procces stopped.

  This is not exactly what it shows because ,since I'm using a japanese version of 
win2k,
the error messages are in japanese,but it's a "close enough" translation I think.

 Do you know if this is a cygwin problem or windows or borland.I looked on the borland 
pages (that`s how I found the import method which works if it doesn`t call cygwin1.dll)
but couldn`t find anything relevant. 

Thanks for your time .
  


-- 
Lucian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.3.19-1:poll bug. Patch included.

[Peter Rehley]

Hello,

Just to make sure that we are both clear.  Change recvfrom so that if 
the buffer is too small it returns the number of bytes that can be 
written into the buffer instead of setting errno.  Also clear errno 
since there is no error.

Now in poll since we will now be returning the number of bytes instead 
of -1, do we will need to check for WSAEMSGSIZE?  I don't think so 
because that will now be handled in recvfrom.

Is this correct?

Peter

On Sunday, February 2, 2003, at 07:03  PM, Christopher Faylor wrote:

On Sun, Feb 02, 2003 at 06:37:34PM -0800, Peter Rehley wrote:

Hello,

While working on another program (syslogd in inetutils) I found that
the poll function was returning POLLERR when something arrived on a 
UDP
socket; it should be return POLLIN.  Inside the poll function, 
recvfrom
was returning -1 with errno = EMSGSIZE, but the only error value being
check for in WSAENOTCONN.  However EMSGSIZE is a reasonable return
value since the buffer to recvfrom was only 1 byte while the actual
message size was larger than this.  Basically saying your buffer is 
too
small for the message, but since we are only peeking, this shouldn't 
be
returned as a POLLERR.

The fix should be to add EMSGSIZE as part of the condition so this
error returns POLLIN.  I'm including the patch below and a changelog
following that.  Please review these changes and make sure that they
seem reasonable.  I've done tests on my system (windows XP) and have
verified that the change works.

Thanks for the patch.  Would you mind reworking it so that it doesn't 
set
errno at all in the case that you describe and then check against the 
correct
WSAGetLastError value?

cgf

Patch
---
Index: winsup/cygwin/poll.cc
===
RCS file: /cvs/src/src/winsup/cygwin/poll.cc,v
retrieving revision 1.34
diff -u -p -r1.34 poll.cc
--- winsup/cygwin/poll.cc	20 Nov 2002 11:00:15 -	1.34
+++ winsup/cygwin/poll.cc	3 Feb 2003 01:52:10 -
@@ -112,7 +112,8 @@ poll (struct pollfd *fds, unsigned int n
 sense then.  It returns WSAENOTCONN in that
 case.  Since that's not actually an error,
 we must not set POLLERR but POLLIN. */
-			  if (WSAGetLastError () != WSAENOTCONN)
+			  if (WSAGetLastError () != WSAENOTCONN &&
+  errno!=EMSGSIZE)
fds[i].revents |= POLLERR;
			  else
fds[i].revents |= POLLIN;
--
Changelog
2003-02-02  Peter Rehley<[EMAIL PROTECTED]>

* poll.cc: EMSGSIZE being ignore returning incorrect POLLERR on UDP
socket receive
if recvfrom returns error, return POLLIN if errno = EMSGSIZE
---

Peter
=
Infinity Softworks.  Making scientific, financial and realtor
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




=

Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: installing pinfo

[Robert Mark Bram]

Howdy Elfyn and Igor,

> > As far as setup (cygcheck) is concerned you have pinfo
> installed but it's
> > not working (corrupt, unknown?).Double check your path (PATH
> env. variable)
> > is set-up correctly, just a thought before you re-install. If
> cygwin (your
> > PATH env. variable) is set-up correctly return to setup and re-install
> > pinfo.

...

> To the OP: one more guess, though: try posting the result of "ls -l
> /bin/pinfo.exe" (notice the extension).  If that file exists, but is not
> executable, there's something wrong with either your CYGWIN variable or
> your mount table (or your umask, but I doubt that).

Here is the result of the testing I did:

  $ cd /bin

  $ pwd
  /bin

  $ ls | grep pinfo
  zipinfo

Well... I reinstalled (through Cygwin's setup.exe) and now it works - I see
something exciting when I type the command "pinfo".. next step: figuring out
how to use pinfo!

Thanks for the help!

Rob
:)



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/