RE: Extracting Debug (meta data) from executable images?

[Siegfried Heintze]

How does ELFDump.exe work? I did a 

chmod 777 hello.*

and still 

ELFDump hello.o

And

ELFDump hello.exe


Still produce the 

Can't openinput file "Hello.exe"

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: Extracting Debug (meta data) from executable images?

[Siegfried Heintze]

>The gcc / binutils / gdb distributed with Cygwin use stabs.  I believe
>that patches to get dwarf2 working have been submitted, and in theory if
>you build your own toolchain you should be able to do this.


I looked in c:\cygwin\usr\doc\ELFIO and there is a nice PDF file that refers
to the examples directory. Where is this examples directory? 

What is the relationship between stabs and ELF?

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: Extracting Debug (meta data) from executable images?

[Siegfried Heintze]

>But "extracting debug info" is way too vague of a term to offer any
>meaningful help.  You'd have to state exactly what you're trying to do.
>Try "man objdump" or "objdump -g file", or read the binutils/bfd
>internals manuals.

I basically want to implement reflection for C++ by extracting all the
metadata in the debug portion of the executable image to an xml file. Then I
can easily write programs that can enumerate all the data members of any
given struct or class. GDB can do this: too bad it produces C syntax instead
of XML. I don't want to parse C, it is too difficult.

I found a utility called gccxml which uses the gcc front end and dumps XML
for all the class and struct information. It is strange, however, because it
does not implement the -I switch that gcc does.

Neither nm, readelf or objdump enumerate the fields of a struct. It looks
like dwarfdump would, but libdwarf does not compile with cygwin/gcc 3.4 or
RedHat8/gcc 3.2.

So if I download the source code for GDB, do I compile it on cygwin using
g++? I'd just need to modify the "info variables" and "ptype" commands to
emit XML instead of C.

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: Cygwin logo

[Matthew Persico]

On 12/7/05, Larry Hall (Cygwin) <[EMAIL PROTECTED]> wrote:
> Igor Pechtchanski wrote:
> > On Wed, 7 Dec 2005, Larry Hall (Cygwin) wrote:
> >
> >
> >>Can anyone work an otter or a hippo into the logo? ;-) ;-) ;-)
> >
> >
> > You mean, like this? :-)
> >   Igor
>
> LOL!
>
> That's perfect!  Does anyone want to set up a web site that we can all
> vote at so I can go vote for this one a couple of thousand times. ;-)
>

Looks like the logo for YetAnotherStarTrekSeries, this time in an
alternative universe 90 degrees out of phase with ours...

:-)
--
Matthew O. Persico

--
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: octave-forge dependency?

[Charles Wilson]

Chris Taylor wrote:

James R. Phillips wrote:
OK, it seems an elaboration of the idea could though.  The 
autoconf/automake

environment needs to be like octave, while the rest of the time, you want
miktex in the front of the path.  Wouldn't executing

export PATH=$PATH_FOR_OCTAVE

before starting ./configure work for that purpose?

jrp



No.

Two things: Firstly, the OP _doesn't_ want his configure scripts picking 
up tetex, ergo tetex must not be in the path.


As jrp pointed out in a separate message, I don't mind having tetex 
installed *as long as* it doesn't interfere with my command-line usage 
of miktex.


It's okay if my packages get configured using (now) available tetex 
tools; they are mostly "re-build the documentation" and don't actually 
add new runtime dependencies to MY packages.


So resetting the PATH to remove miktex, just before configuring, is okay 
-- but feels like a kludgy, ad-hoc solution to me.  If I wanted to do it 
"Right" (e.g. the Corporate, controlled-release) I'd have a rigorously 
consistent runtime environment that I used to build packages for release 
(e.g. with only minimal "other" packages installed).  A partway solution 
would be a separate user, sharing my kitchen-sink cygwin installation, 
but with controlled .profile stuff specifically for this purpose (and 
THAT user wouldn't need "miktex" in the front of HIS $path).


Or, I suppose, a "launch maintainance shell" script that culls out all 
the "goodies" of my normal shell environment.


But, fellas, I'm touched that my original post raised such a ruckus -- 
it's really not that big a deal (to me).  I'm okay, you're okay.


I guess it's good that the actual source of the dependency was tracked 
down, and will hopefully lead to a correction in gnuplot's code, but 
gollee...


Secondly, tetex installs (at least last time I checked) in such a way 
that it's located automatically by configure scripts (given that it's in 
the default path).

The only way to stop this behaviour is to
a) completely trash the cygwin path, and thus lose 99% of the functionality
b) install tetex elsewhere (/usr/local/octave-tetex/*hierarchy_here* for 
example).


Neither of these are brilliant solutions, and the latter would actually 
require hacking the cygwin package in order for it to install there, and 
still work (it would probably require tetex to be recompiled).


Yep, all the above would be true -- IF I really really didn't want my 
configure scripts to find tetex, or be used by packages when I build 
them (since, by default, tetex goes smack in the middle of all the OTHER 
cygwin tools, right there under /usr).  But *that* doesn't matter to me.


[snip]

I think the rest of this post is OBE, given the discovery of the gnuplot 
issue.


Thanks for everybody chiming in on this thread. (I gotta start checking 
the list more than once a day...)


--
Chuck

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

[Larry Hall (Cygwin)]

Igor Pechtchanski wrote:

On Wed, 7 Dec 2005, Larry Hall (Cygwin) wrote:



Can anyone work an otter or a hippo into the logo? ;-) ;-) ;-)



You mean, like this? :-)
Igor


LOL!

That's perfect!  Does anyone want to set up a web site that we can all
vote at so I can go vote for this one a couple of thousand times. ;-)

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

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

Re: Cygwin logo

[Igor Pechtchanski]

On Wed, 7 Dec 2005, Larry Hall (Cygwin) wrote:

> Can anyone work an otter or a hippo into the logo? ;-) ;-) ;-)

You mean, like this? :-)
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

cygwin-logo-hippo.png
Description: Binary data
--
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 logo

[Larry Hall (Cygwin)]

On 12/07/2005, Thorsten Kampe wrote:

>There has been one (1) reply to this message from someone who said that
>> they liked it.  I don't think that it yet has a ringing endorsement from
>> the community so I think it is premature for Corinna or me to get
>> involved.


Well, actually there are two now (fergus and my humble entity). That
makes a overwhelming majority of 100 % (= one hundred percent) who
like the "new logo".

 ;-) 


Well, not to ruin that statistic or to be a spoil-sport but I prefer the
the current logo.  But I guess I'm just a traditionalist. ;-)

I should say that I don't make this remark to denigrate Denis's efforts.

And assuming this thread takes off (ugh, my mailbox... my poor mailbox! ;-) ),
I'm guessing my view would be in the minority.  Personally, I wouldn't mind
seeing this open up into a run-off of a few (or more) different designs.  I
mean, if we're going to consider a new logo, let's have some options! :-)
Can anyone work an otter or a hippo into the logo? ;-) ;-) ;-)

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

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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, Tony Richardson wrote:

> I often use octave and do no plotting at all.  Octave starts and runs
> fine if gnuplot isn't installed.  (It complains about not being able
> to find gnuplot when the plot command is used.)  Should there really
> be a dependency if only a subset of features requires a package?
>
> I'd prefer to see gnuplot removed from the octave dependency list.
> Of course then you'd have to deal with all the posts saying that
> the plot command in octave is broken.  So I don't know what the best
> approach would be.  How do others feel?

Actually, a viable solution for this was already proposed by John W Eaton
in .  Since octave adds
other directories to the path before it runs, it's possible to create a
gnuplot wrapper that uses the real gnuplot if present and exits with a
reasonable error message otherwise.

Just to clarify, the reason I thought it was a hack was that it was an
*octave-forge* script dealing with a *gnuplot* bug.  I don't think the
mechanism itself is in any way hacky.
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

--
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: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, James R. Phillips wrote:

> --- Igor Pechtchanski wrote:
>
> > Ok, so first off, octave-forge *shouldn't* depend on tetex-bin. If
> > anything needs to depend on tetex-bin, it should be gnuplot.  The
> > presence of tetex-bin in octave-forge's requires: line is a packaging
> > bug (even if it's intended to work around gnuplot's missing
> > dependency).
>
> Igor, if you read the whole thread, you will see that the dependency
> could not possibly have been intended to work around a problem with
> gnuplot, because we didn't know there was a problem with gnuplot.  All
> we knew was that there was a problem with octave-forge.

I realize that.  I never claimed that you should have not inserted the
dependency -- just that in the light of this thread, the dependency should
be in gnuplot.  Maybe adding the "anymore" after the sentence with the
starred "shouldn't" would help...

> Now that we know more specifically where the problem is, I can agree
> that the tetex-bin dependency for octave-forge causes more problems than
> it solves, and should be dropped.
>
> It seems the best solution to this problem lies in updating the gnuplot
> package.  In the meantime, users can try the workarounds suggested.
>
> BTW, the gnuplot version in Debian sarge behaves exactly the same way as
> the cygwin version in response saving a file if kpsexpand is not
> present.

What is the behavior?  Does it fail, or does it simply produce the error
messages?  I don't think this was ever specified...  If it's the error
messages, then I'd even say a note in the README that those are harmless
would be enough...

> And Debian does not list tetex-bin as a dependency for gnuplot.

Well, Debian doesn't quite target the OOTB experience that Cygwin does...
:-)

> Probably this needs to be researched further with the gnuplot mailing
> lists.  Possibly some bugs need to be filed upstream.

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

--
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: octave-forge dependency?

[Tony Richardson]

James R. Phillips  yahoo.com> writes:

> 
> The octave-forge legend command requires tetex-bin.  This came up in:
> 
> http://www.octave.org/mailing-lists/help-octave/2005/4239
> 
> I promised to fix it, and I did.
> 
> Everyone who complains about long downloads should get broadband ;)
> 
> Everyone who complains about many files should get a bigger hard drive ;)

I have a similar gripe regarding an octave dependency.  I have an old
laptop in which I keep a rather lean cygwin installation.  I do use octave
quite a bit, but I prefer to use it with the native-Windows version of
gnuplot instead of the cygwin-X11 version.  (Just set gnuplot_binary equal
to "/cygdrive/c/Program Files/gnuplot4.00/bin/pgnuplot" or similar
in the .octaverc file.)

Because of the dependency on gnuplot and the gnuplot dependency on X11
upgrading octave is painful.  (I don't have any of the X11 packages
installed and I don't want to install them.  Note also that X11 is
required only through the gnuplot dependency, it isn't required for
viewing images, octave-forge sets up IE as the default image viewer.)

I often use octave and do no plotting at all.  Octave starts and runs
fine if gnuplot isn't installed.  (It complains about not being able
to find gnuplot when the plot command is used.)  Should there really
be a dependency if only a subset of features requires a package?

I'd prefer to see gnuplot removed from the octave dependency list.
Of course then you'd have to deal with all the posts saying that
the plot command in octave is broken.  So I don't know what the best
approach would be.  How do others feel?

Tony Richardson



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

[Christopher Faylor]

On Wed, Dec 07, 2005 at 10:24:35PM +, Thorsten Kampe wrote:
>* Christopher Faylor (2005-12-07 19:59 +0100)
>> On Wed, Dec 07, 2005 at 07:42:27PM +, Thorsten Kampe wrote:
>>>* Denis Washington (2005-12-07 19:10 +0100)
 My big question now is: who will i have to talk about the logo? I'd like
 to propose it as new Cygwin logo.
>>>
>>>Probably to Cristopher 'the man' Faylor or Corinna 'the woman'
>>>Vinschen (see http://cygwin.com/faq/faq.html#faq.what.who)
>> 
>> ...Both of whom read the mailing list and don't require any personal
>> pinging about this.
>
>My reply was targeted to the one who posed the question.

You implied that the OP had to talk to us personally, resulting in
personal email to me.  I was setting the record straight.  No personal
email is required, especially at this point.

>>There has been one (1) reply to this message from someone who said that
>>they liked it.  I don't think that it yet has a ringing endorsement
>>from the community so I think it is premature for Corinna or me to get
>>involved.
>
>Well, actually there are two now (fergus and my humble entity).

Yes, the second vote was a reply to my message.

cgf

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

[ANNOUNCEMENT] New Package: bsflite 0.80

[Jon Allen]

PACKAGE DESCRIPTION
===

BSFlite - A minimalist console AIM client

Homepage: http://bsflite.sourceforge.net/
Version : 0.80
License : BSD

BSFlite is a rather small and "minimalistic" client for AOL's Instant 
Messenger service.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "Net" and "Web" categories.  After installation, 
read the documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

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

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

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

[EMAIL PROTECTED]

More information on unsubscribing can be found:

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

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


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

RE: Size difference reported by /proc/partitions and lseek(SEEK_END) on block device

[Loh, Joe]

>> On Dec  7 11:17, Loh, Joe wrote:
>> We just installed the cygwin-inst-20051207.tar.bz2 snapshot.  The 
>> output in //proc/partitions is the same as the Cygwin Kernel 1.5.18.

>> However, the lseek(SEEK_END) no longer works.  When I rerun the "C" 
>> program it gave the following error. I even recompiled with the new 
>> snapshot just to make sure, still the same error.  I have also 
>> attached the strace output for the lseekend.
>> 
>> $ ./lseekend.exe /dev/sda
>> lseek: Invalid argument
>
> Ouch.  Thanks for the report.  I have fixed a buggy condition which
only allowed to seek to 1 byte below EOM in CVS.  You should see the
change in the next developers snapshot.
>
>> Here's the output from the snapshot:
>> 
>> major minor  #blocks  name
>> 
>> 8 0  78124095 sda
>> 8 1  15358108 sda1
>> 8 2104422 sda2
>> 8 3  16386300 sda3
>
> The reason that /proc/partition contains wrong information is that the
/proc/partition information uses an > old, deprecated IOCTL call to
evaluate the disk size by # of cylinders, # of tracks per sektor, etc.
I didn't fix that so far but it's not overly complicated, so stay tuned.

Thank you.  We will give the next snapshot a try.

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

[ANNOUNCEMENT] Updated: boost-1.33.1-1

[Václav Haisman]

The following packages have been updated:

boost-1.33.1-1
boost-devel-1.33.1-1

Changes:

New upstream release.

Details:

*  Any Library: Cast to reference types introduced in 1.33.0 is now
documented on any_cast documentation page.
* Config Library: Don't undef BOOST_LIB_TOOLSET after use.
* Boost.Python:
  o The build now assumes Python 2.4 by default, rather than 2.2
  o Support Python that's built without Unicode support
  o Support for wrapping classes with overloaded address-of (&)
operators
* Smart Pointer Library: Fixed problems under Metrowerks CodeWarrior
on PowerPC (Mac OS X) with inlining on, GNU GCC on PowerPC 64.
* Regex Library: Fixed the supplied makefiles, and other small
compiler specific changes. Refer to the regex history page for more
information on these and other small changes.
* Iostreams Library: Improved the interface for accessing a chain's
components, added is_open members to the file and file descriptor
devices, fixed memory-mapped files on Windows, and made minor changes to
the documentation.
* Functional/Hash Library: Fixed the points example.
* Multi-index Containers Library: Fixed a problem with multithreaded
code, and other minor changes. Refer to the library release notes for
further details.
* Graph Library:
  o Fixed a problem with the relaxed heap on x86 Linux (fixes
bug in dijkstra_shortest_paths).
  o Fixed problems with cuthill_mckee_ordering and king_ordering
producing no results.
  o Added color_map parameter to dijkstra_shortest_paths.
* Signals Library: Fixed problems with the use of Signals across
shared library boundaries.
* Thread library: read_write_mutex has been removed due to problems
with deadlocks.
* Wave library (V1.2.1) Fixed a couple of problems, refer to the
change log for further details.

--
Vaclav Haisman


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

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

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


signature.asc
Description: OpenPGP digital signature

RE: Error reported dd'ing close of end of block device with skip

[Loh, Joe]

>> On Dec  7 11:55, Loh, Joe wrote:
>> QUESTION:  
>> 
>> Is there a way in Cygwin to do a read of a block device using "C"
that 
>> does not do a read-ahead?  We needed to develop an application that 
>> will issue the exact transfer size to the target device as requested.
>> Looking at the strace, it appears that read() less than 61440-bytes 
>> gets translated to reading 61440 bytes into buffer and then a subset 
>> of that read is returned to the caller.
>
> There's a non-portable (only Cygwin) way to set the buffer size after
opening a device:
>
>   #include 
>
>   struct rdop rd;
>
>   fd = open ("dev/sda", ...);
>
>   rd.rd_op = RDSETBLK;
>   rd.rd_parm = 0; /* Unbuffered reading */
>   rd.rd_parm = 1; /* Unbuffered reading */
>   rd.rd_parm = n; /* Buffered reading with buffer size n */
>
>   ioctl (fd, RDIOCDOP, &rd);
>
> Note that the ioctl fails if the buffer already contains data, so
ioctl should be called before the first > read.  Also note that in
unbuffered mode the usual Windows blocking rule applies, the length
given to read > must be a multiple of 512.
>
> Sigh, it seems that I introduced a bug into this ioctl also not long
ago.
> I fixed this in CVS.  Recent code will probably not work very well
when setting it to unbuffered mode.  Please wait for the next developers
snapshot.
>
>
> Corinna

Thank you ... This will work. Any plans on supporting O_DIRECT flag in
open()?  We believe this effectively gives unbuffered I/O.  Please
correct if we are making the wrong assumption.

Again.  Thank you for the recommendation and we will wait for the next
Cygwin Kernel before porting our codes over.

--
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: sshd crahes; ssh instal fails

[kumarchi]

I cleaned and reinstalled and everything works fine now. thanx
my original problem might have been due to windows firewall.
thanx


> I installed sshd using sshd-host-config. I did no give any options to the 
> script.
> when it ran it asked about a creating an unprivileged sshd. I tried both the 
> options creating unprivileged sshd and without creating one.

Nothing in your cygcheck output seems out of the oridinary.

Normally the reason for the malfunction is listed in the Event Log,
which you need to check.  There is a chance there is also information in
/var/log/sshd.log but this will only be the case if cygrunsrv itself
encounters an error (rather than sshd.)

In my experience almost all cases of sshd not starting are due to wrong
or incorrect permissions on some files.  ssh-host-config ought to take
care of this for you.  It could also be a software firewall that isn't
allowing the process to bind to port 22.

If you cannot figure out from the above what the problem is, I suggest
you remove all traces of the sshd service and re-run ssh-host-config. 
To do this:

$ cygrunsrv --remove sshd
$ rm -rf /etc/{ssh_host_*,sshd_config} /var/{empty,run/sshd*,log/sshd*}
$ ssh-host-config

If you get any permission denied errors at the rm step you'll need to
chown the files before deleting them.


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

[Thorsten Kampe]

* Christopher Faylor (2005-12-07 19:59 +0100)
> On Wed, Dec 07, 2005 at 07:42:27PM +, Thorsten Kampe wrote:
>>* Denis Washington (2005-12-07 19:10 +0100)
>>> My big question now is: who will i have to talk about the logo? I'd like
>>> to propose it as new Cygwin logo.
>>
>>Probably to Cristopher 'the man' Faylor or Corinna 'the woman'
>>Vinschen (see http://cygwin.com/faq/faq.html#faq.what.who)
> 
> ...Both of whom read the mailing list and don't require any personal
> pinging about this.

My reply was targeted to the one who posed the question.
 
> There has been one (1) reply to this message from someone who said that
> they liked it.  I don't think that it yet has a ringing endorsement from
> the community so I think it is premature for Corinna or me to get
> involved.

Well, actually there are two now (fergus and my humble entity). That
makes a overwhelming majority of 100 % (= one hundred percent) who
like the "new logo".

;-)


--
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: Extracting Debug (meta data) from executable images?

[Christopher Faylor]

On Wed, Dec 07, 2005 at 01:18:17PM -0800, Brian Dessent wrote:
>Siegfried Heintze wrote:
>>What is the relationship between cygwin, windows and these formats and
>>libraries?  Can I use these linux libraries to read debug information
>>in images created with g++ on cygwin?
>>
>>If not, how do I read the debug information in images created with g++
>>on cygwin?
>
>The gcc / binutils / gdb distributed with Cygwin use stabs.  I believe
>that patches to get dwarf2 working have been submitted, and in theory
>if you build your own toolchain you should be able to do this.
>
>But "extracting debug info" is way too vague of a term to offer any
>meaningful help.  You'd have to state exactly what you're trying to do.
>Try "man objdump" or "objdump -g file", or read the binutils/bfd
>internals manuals.

But despite all of this, I'm sure Igor is still pleased...

cgf

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

Re: bug: unsetenv should return int, not void

[Christopher Faylor]

On Wed, Dec 07, 2005 at 04:12:52PM -0500, Sam Steingold wrote:
> * Christopher Faylor <[EMAIL PROTECTED]> [2005-12-07 15:01:32 -0500]:
>> The linux man page (i.e., the ones that Corinna and I can access)
>> seems to contradict its header files, though, so I've modified cygwin
>> to use what linux actually does rather than what linux documents.
>
>could you please also report the bug (header - man page discrepancy) to
>the linux people?

It's already fixed in later versions of man-pages.  As it turns out, I
just happened to be checking on the wrong systems.  The documentation is
correct on Fedora Core 4.

cgf

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

Re: dll v so?

[Brian Dessent]

Siegfried Heintze wrote:

> I'm confused about dll v. so and cygwin. I've used the documentation to
> create and load dlls with g++.
> 
> However, I notice that Apache Httpd uses ".so" files. Is the choice to
> produce ".dll" or ".so" files purely a matter of who is going to load them?

It's just the name of the file.  Regardless of the filename, they are
always going to be PE format, and as long as you are using LoadLibrary()
or dlopen() you can call your shared modules anything you want.  They
must be named .dll though if you use standard dynamic linking (as
opposed to runtime object loading, as apache does with modules) because
that is what the windows loader expects to see.

The real reason that apache uses .so (at least in the case of 1.3) is
that the build environment is too stupid to understand that they should
really be named .dll.  But again since these are modules loaded at
runtime and not standard libraries, the extension used doesn't matter.

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: encoding scripts (so that user can't see passwords easily)?

[Williams, Gerald S \(Jerry\)]

Ehud Karni wrote:
> [I think this discussion is off topic for cygwin]

Agreed, which is why I didn't elucidate earlier. If I
were inclined to do something like your second script
and override normal passphrase security, I'd probably
use another mechanism (maybe an environment variable?)
to avoid the passphrase appearing in the process list.
But as we both said, this discussion is really OT for
this list.

gsw


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

[fergus]

> .. premature ..
I think it's beautiful.
Fergus


--
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: Extracting Debug (meta data) from executable images?

[Brian Dessent]

Siegfried Heintze wrote:

> What is the relationship between cygwin, windows and these formats and
> libraries? Can I use these linux libraries to read debug information in
> images created with g++ on cygwin?
> 
> If not, how do I read the debug information in images created with g++ on
> cygwin?

The gcc / binutils / gdb distributed with Cygwin use stabs.  I believe
that patches to get dwarf2 working have been submitted, and in theory if
you build your own toolchain you should be able to do this.

But "extracting debug info" is way too vague of a term to offer any
meaningful help.  You'd have to state exactly what you're trying to do. 
Try "man objdump" or "objdump -g file", or read the binutils/bfd
internals manuals.

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: bug: unsetenv should return int, not void

[Sam Steingold]

> * Christopher Faylor <[EMAIL PROTECTED]> [2005-12-07 15:01:32 -0500]:
>
> On Mon, Dec 05, 2005 at 04:32:57PM -0500, Sam Steingold wrote:
>>http://www.opengroup.org/onlinepubs/009695399/functions/unsetenv.html
>>#include 
>>int unsetenv(const char *name);
>
> Actually we emulate linux not SUSv3.

interesting.  since linux tries to emulate SUS, maybe it is a good idea
to aim towards SUS directly?

> The linux man page (i.e., the ones that Corinna and I can access)
> seems to contradict its header files, though, so I've modified cygwin
> to use what linux actually does rather than what linux documents.

could you please also report the bug (header - man page discrepancy) to
the linux people?

thanks a lot!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
http://www.dhimmi.com/ http://www.savegushkatif.org http://www.iris.org.il
http://truepeace.org http://www.camera.org http://www.openvotingconsortium.org/
I'm out of my mind, but feel free to leave a message...

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

dll v so?

[Siegfried Heintze]

I'm confused about dll v. so and cygwin. I've used the documentation to
create and load dlls with g++.

However, I notice that Apache Httpd uses ".so" files. Is the choice to
produce ".dll" or ".so" files purely a matter of who is going to load them?

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/

Extracting Debug (meta data) from executable images?

[Siegfried Heintze]

I hope Igor will be pleased that I first posted in a g++ forum about reading
executable images.

I was referred to STABS, DWARF, DWARFv2 and v3 and
http://www.eagercon.com/dwarf/dwarf3std.htm and
http://reality.sgi.com/davea/dwarf.html.

What is the relationship between cygwin, windows and these formats and
libraries? Can I use these linux libraries to read debug information in
images created with g++ on cygwin?

If not, how do I read the debug information in images created with g++ on
cygwin?

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: Size difference reported by /proc/partitions and lseek(SEEK_END) on block device

[Corinna Vinschen]

On Dec  7 19:12, Corinna Vinschen wrote:
> On Dec  7 11:17, Loh, Joe wrote:
> > major minor  #blocks  name
> > 
> > 8 0  78124095 sda
> > 8 1  15358108 sda1
> > 8 2104422 sda2
> > 8 3  16386300 sda3
> 
> The reason that /proc/partition contains wrong information is that
> the /proc/partition information uses an old, deprecated IOCTL call
> to evaluate the disk size by # of cylinders, # of tracks per sektor,
> etc.  I didn't fix that so far but it's not overly complicated, so
> stay tuned.

This should be fixed now, too, in CVS.  Please try the next developers
snapshot.


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: bash vs sh in scripts

[Eric Blake]

> 
> /bin/sh should exist and be a hard-link to /bin/bash.  If this is not
> the case you have an installation problem.  The bash postinstall script
> should ensure this.

Actually, it should be a copy rather than a hard link, since hard links
can't be broken to be upgraded while the postinstall script is
running.  But the postinstall takes care of that.

> 
> /bin vs. /usr/bin is meaningless since they're the same under cygwin.

Unless you've messed with your mount points.

> 
> If you have no /bin/sh you will run into countless problems all over the
> place, such as anything that calls system().

By the way, attaching the output of 'cygcheck -svr' would have
pointed out all of these issues.

--
Eric Blake
volunteer cygwin bash maintainer

--
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: octave-forge dependency?

[James R. Phillips]

--- Igor Pechtchanski wrote:

> Ok, so first off, octave-forge *shouldn't* depend on tetex-bin. If
> anything needs to depend on tetex-bin, it should be gnuplot.  The presence
> of tetex-bin in octave-forge's requires: line is a packaging bug (even if
> it's intended to work around gnuplot's missing dependency).
> 

Igor, if you read the whole thread, you will see that the dependency could not
possibly have been intended to work around a problem with gnuplot, because we
didn't know there was a problem with gnuplot.  All we knew was that there was a
problem with octave-forge.

Now that we know more specifically where the problem is, I can agree that the
tetex-bin dependency for octave-forge causes more problems than it solves, and
should be dropped.

It seems the best solution to this problem lies in updating the gnuplot
package.  In the meantime, users can try the workarounds suggested.

BTW, the gnuplot version in Debian sarge behaves exactly the same way as the
cygwin version in response saving a file if kpsexpand is not present.  And
Debian does not list tetex-bin as a dependency for gnuplot.  Probably this
needs to be researched further with the gnuplot mailing lists.  Possibly some
bugs need to be filed upstream.

--
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: smartmontools install issue

[Christian Franke]

David Arnstein wrote:


I updated my installation of smartmontools by using the usual cygwin
setup.exe. This caused my smartd.conf file to be overwritten.
 



Could not reproduce.

/etc/smartd.conf is not updated if it differs from the default 
(/etc/defaults/etc/smartd.conf).


Try the following commands to test:

sh -x /etc/preremove/smartmontools.sh
sh -x /etc/postinstall/smartmontools.sh.done

Christian


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

Re: bash vs sh in scripts

[Brian Dessent]

David Arnstein wrote:

> Some cygwin packages install shell scripts that begin with the line
> #!/bin/sh
> The latest example is the smartd script that smartmontools installs in
> /etc/rc.d/init.d. But there are many others. This seems to be standard
> Linux usage.
> 
> On some of my PCs, this causes the shell script to fail. In most
> cases, I can fix this by replacing the above line with
> #!/usr/bin/bash

/bin/sh should exist and be a hard-link to /bin/bash.  If this is not
the case you have an installation problem.  The bash postinstall script
should ensure this.

/bin vs. /usr/bin is meaningless since they're the same under cygwin.

If you have no /bin/sh you will run into countless problems all over the
place, such as anything that calls system().

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: bug: unsetenv should return int, not void

[Christopher Faylor]

On Mon, Dec 05, 2005 at 04:32:57PM -0500, Sam Steingold wrote:
>http://www.opengroup.org/onlinepubs/009695399/functions/unsetenv.html
>#include 
>int unsetenv(const char *name);

Actually we emulate linux not SUSv3.  The linux man page (i.e., the ones
that Corinna and I can access) seems to contradict its header files,
though, so I've modified cygwin to use what linux actually does rather
than what linux documents.

cgf

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

Re: Cygwin logo

[Christopher Faylor]

On Wed, Dec 07, 2005 at 07:42:27PM +, Thorsten Kampe wrote:
>* Denis Washington (2005-12-07 19:10 +0100)
>> My big question now is: who will i have to talk about the logo? I'd like
>> to propose it as new Cygwin logo.
>
>Probably to Cristopher 'the man' Faylor or Corinna 'the woman'
>Vinschen (see http://cygwin.com/faq/faq.html#faq.what.who)

...Both of whom read the mailing list and don't require any personal
pinging about this.

There has been one (1) reply to this message from someone who said that
they liked it.  I don't think that it yet has a ringing endorsement from
the community so I think it is premature for Corinna or me to get
involved.

cgf

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

bash vs sh in scripts

[David Arnstein]

Some cygwin packages install shell scripts that begin with the line
#!/bin/sh
The latest example is the smartd script that smartmontools installs in
/etc/rc.d/init.d. But there are many others. This seems to be standard
Linux usage.

On some of my PCs, this causes the shell script to fail. In most
cases, I can fix this by replacing the above line with
#!/usr/bin/bash

I would like a canonical solution to this issue. Should I simply copy
/usr/bin/bash.exe to /bin/bash.exe? This has fixed the problem on one
of my PCs.

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

smartmontools install issue

[David Arnstein]

I updated my installation of smartmontools by using the usual cygwin
setup.exe. This caused my smartd.conf file to be overwritten.

This is not a good thing. The comments in the distributed smartd.conf
file urge the user to customize the file.

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

[Thorsten Kampe]

* Denis Washington (2005-12-07 19:10 +0100)
> My big question now is: who will i have to talk about the logo? I'd like
> to propose it as new Cygwin logo.

Probably to Cristopher 'the man' Faylor or Corinna 'the woman'
Vinschen (see http://cygwin.com/faq/faq.html#faq.what.who)


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

[Denis Washington]

I'm glad you like it :)

My big question now is: who will i have to talk about the logo? I'd like
to propose it as new Cygwin logo.


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

Ezmlm configuration.

[Bas van Gompel]

Hi,

Recently my mailbox was flooded by a virus (Sober CF), causing me
to miss several mails from cygwin-MLs and a report being sent by
ezmlm. When I later got the messages from the archive (using
ezmlm-get), I noticed the messages in the returned digest do not
have a ``In-Reply-To''- nor a ``References''-header. Would it be
possible to configure ezmlm to return those headers, when available?

I would love to be able to restore threading for my local archives.
(I use Hamster to read the MLs as if they were NGs.)


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| mail for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."| me. 4^re

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

[Denis Washington]

I'm glad you like it :)

My big question now is: who will i have to talk about the logo? I'd like 
to propose it as new Cygwin logo.


--
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: Error reported dd'ing close of end of block device with skip

[Corinna Vinschen]

On Dec  7 11:55, Loh, Joe wrote:
> QUESTION:  
> 
> Is there a way in Cygwin to do a read of a block device using "C" that
> does not do a read-ahead?  We needed to develop an application that will
> issue the exact transfer size to the target device as requested.
> Looking at the strace, it appears that read() less than 61440-bytes gets
> translated to reading 61440 bytes into buffer and then a subset of that
> read is returned to the caller.

There's a non-portable (only Cygwin) way to set the buffer size after
opening a device:

  #include 

  struct rdop rd;

  fd = open ("dev/sda", ...);

  rd.rd_op = RDSETBLK;
  rd.rd_parm = 0;   /* Unbuffered reading */
  rd.rd_parm = 1;   /* Unbuffered reading */
  rd.rd_parm = n;   /* Buffered reading with buffer size n */

  ioctl (fd, RDIOCDOP, &rd);

Note that the ioctl fails if the buffer already contains data, so ioctl
should be called before the first read.  Also note that in unbuffered
mode the usual Windows blocking rule applies, the length given to read
must be a multiple of 512.

Sigh, it seems that I introduced a bug into this ioctl also not long ago.
I fixed this in CVS.  Recent code will probably not work very well when
setting it to unbuffered mode.  Please wait for the next developers
snapshot.


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: Hang with 20051205 snapshot while building OOo

[Christopher Faylor]

On Wed, Dec 07, 2005 at 05:16:17PM +0100, Volker Quetschke wrote:
>We got some new features in the hangs with the 20051205 snapshot
>when building OOo.
>
>This trace looks a little bit different from the old versions,
>see thread around ,
>but it still hangs.

It looks different because I took out all of the debugging strace
output that I added to try to track this down.

I'm convinced that the hang is coming from timeGetTime.  That's a
Windows routine and there's not much I can do if a windows routine
decides to take a long time to return.

So, in other words, I'm admitting defeat in this case, especially since
this isn't a regression from 1.5.18.

cgf

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

Re: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, John W. Eaton wrote:

> OK, let's back up a bit, and see why kpsexpand is needed in the first
> place.

Yes, let's.

> Graphics in Octave use gnuplot.  The legend function from Octave Forge
> sends a "save FILE" command to gnuplot so that it can extract some
> information about gnuplot's current state.  If you do the following
>
>   mv /usr/bin/kpsexpand. /usr/bin/kpsexpand-save
>   gnuplot
>   ...
>   gnuplot> save "foo"
>
> you should see the errors
>
>   sh: kpsexpand: command not found

Ok, so first off, octave-forge *shouldn't* depend on tetex-bin.  If
anything needs to depend on tetex-bin, it should be gnuplot.  The presence
of tetex-bin in octave-forge's requires: line is a packaging bug (even if
it's intended to work around gnuplot's missing dependency).

> So, why does gnuplot need kpsexpand to save state?

Yes, why does it *need* kpsexpand/kpsewhich to save state?  Looks like the
kpsexpand command can easily fail with no adverse effects.  The only
problem is the error message -- so this looks to me to be a bug in gnuplot
(either a minor one if all it does is display the message, or a major one
if it stops processing the curr_fontpath array on such errors).

> So gnuplot is using kpsexpand to locate some font files.
> It looks like there are a couple of options.
>
> One is to set GNUPLOT_FONTPATH in the environment before calling
> gnuplot.

That would avoid the use of kpsexpand altogether, but will hard-code the
paths.  A better solution would be to use kpsexpand if it's available, and
ignore it if it isn't (but this has to be done in gnuplot).

> Another is to make a wrapper kpsexpand that looks for the real version
> and does nothing if the real version is not present:
>
>   #! /bin/sh
>   if [ -x /usr/bin/kpsexpand ]; then
> exec /usr/bin/kspexpand "$@"
>   fi
>
> (though you might want to add some comments about why this is needed).

Ugh.  Why not just modify gnuplot to test whether an executable is present
before blindly calling it?

> If the real kpsexpand is not present, then chances are the font files
> are not -either, so it should not matter that the corresponding
> directories named in the fontpath are bogus.

Bingo.

> You could install the wrapper script in one of the directories in
> Octave's DEFAULT_EXEC_PATH (for example,
> /usr/lib/octave/2.1.72/exec/i686-pc-cygwin, where a couple of other
> scripts are already installed), then it would only be found by Octave
> and should not introduce any other conflicts.

Either one is a reasonable hack pending the appropriate gnuplot change,
but both are still hacks, IMO.
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

--
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: Size difference reported by /proc/partitions and lseek(SEEK_END) on block device

[Corinna Vinschen]

On Dec  7 11:17, Loh, Joe wrote:
> We just installed the cygwin-inst-20051207.tar.bz2 snapshot.  The output
> in //proc/partitions is the same as the Cygwin Kernel 1.5.18.  However,
> the lseek(SEEK_END) no longer works.  When I rerun the "C" program it
> gave the following error. I even recompiled with the new snapshot just
> to make sure, still the same error.  I have also attached the strace
> output for the lseekend.
> 
> $ ./lseekend.exe /dev/sda
> lseek: Invalid argument

Ouch.  Thanks for the report.  I have fixed a buggy condition which
only allowed to seek to 1 byte below EOM in CVS.  You should see the
change in the next developers snapshot.

> Here's the output from the snapshot:
> 
> major minor  #blocks  name
> 
> 8 0  78124095 sda
> 8 1  15358108 sda1
> 8 2104422 sda2
> 8 3  16386300 sda3

The reason that /proc/partition contains wrong information is that
the /proc/partition information uses an old, deprecated IOCTL call
to evaluate the disk size by # of cylinders, # of tracks per sektor,
etc.  I didn't fix that so far but it's not overly complicated, so
stay tuned.


Thanks again,
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: Error reported dd'ing close of end of block device with skip

[Loh, Joe]

> Searching the archive 
>
>  http://cygwin.com/cgi-bin/htsearch?config=htdig&words=dd+eom
>
> reveals a thread "Bug in dd ?? at EOM" which starts here:
>
>  http://sourceware.org/ml/cygwin/2005-09/msg00878.html
>
> Btw, have you tried the latest snapshot from
http://cygwin.com/snapshots/ ?
>
>
> Corinna

We tried with the cygwin-inst-20051207.tar.bz2 snapshot.  Using the same
"dd" commands we no longer observed the problem.  

QUESTION:  

Is there a way in Cygwin to do a read of a block device using "C" that
does not do a read-ahead?  We needed to develop an application that will
issue the exact transfer size to the target device as requested.
Looking at the strace, it appears that read() less than 61440-bytes gets
translated to reading 61440 bytes into buffer and then a subset of that
read is returned to the caller.

Here're the outputs:

dd if=/dev/sda count=1 bs=1024 skip=`expr 78125000 - 60` > /dev/null
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0 seconds, Infinity B/s

dd if=/dev/sda count=1 bs=1024 skip=`expr 78125000 - 59` > /dev/null
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0 seconds, Infinity B/s

Looking at the strace for the command that used to failed, we noticed
that the read ahead transfer size is adjusted to not overshoot the end
of device:

 3260   25940 [main] dd 3660 lseek64: 7939584 = lseek (0,
7939584, 1)
   61   26001 [main] dd 3660 readv: readv (0, 0x22ED80, 1) blocking,
sigcatchers 4
   45   26046 [main] dd 3660 readv: no need to call ready_for_read
   49   26095 [main] dd 3660 fhandler_dev_floppy::raw_read: read 60416
bytes into buffer
  567   26662 [main] dd 3660 fhandler_dev_floppy::read_file: 1 (err 0) =
ReadFile (1640, 268507896, to_read 60416, read 60416, 0)
   47   26709 [main] dd 3660 fhandler_dev_floppy::raw_read: read 1024
bytes from buffer (rest 59392)



--
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: octave-forge dependency?

[John W. Eaton]

OK, let's back up a bit, and see why kpsexpand is needed in the first
place.

Graphics in Octave use gnuplot.  The legend function from Octave Forge
sends a "save FILE" command to gnuplot so that it can extract some
information about gnuplot's current state.  If you do the following

  mv /usr/bin/kpsexpand. /usr/bin/kpsexpand-save
  gnuplot
  ...
  gnuplot> save "foo"

you should see the errors

  sh: kpsexpand: command not found

So, why does gnuplot need kpsexpand to save state?  Looking at the
gnuplot sources, one finds

  /* Yet, no special font paths for these operating systems:
   * MSDOS, ATARI, AMIGA, MTOS, NeXT, ultrix, VMS, _IBMR2, alliant
   *
   * Environmental variables are written as $(name).
   * Commands are written as $`command`.
   */

  [...]

  #if defined(_Windows) && !defined(FONTPATHSET)
  #  define FONTPATHSET
  static const struct path_table fontpath_tbl[] =
  {
  { "$(windir)\\fonts" },
  /* Ghostscript */
  { "c:\\gs\\fonts" },
  /* X11 */
  { "$(CYGWIN_ROOT)\\usr\\X11R6\\lib\\X11\\fonts\\Type1" },
  /* fpTeX */
  { "$`kpsewhich -expand-path=$HOMETEXMF`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFLOCAL`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFMAIN`\\fonts\\type1!" },
  { "$`kpsewhich -expand-path=$TEXMFDIST`\\fonts\\type1!" },
  { NULL }
  };
  #endif

  [...]

  /* Fallback: Should work for unix */
  #ifndef FONTPATHSET
  static const struct path_table fontpath_tbl[] =
  {
  /* teTeX or TeXLive */
  { "$`kpsexpand '$HOMETEXMF'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFLOCAL'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFMAIN'`/fonts/type1!" },
  { "$`kpsexpand '$TEXMFDIST'`/fonts/type1!" },
  /* Linux paths */
  { "/usr/X11R6/lib/X11/fonts/Type1" },
  { "/usr/X11R6/lib/X11/fonts/truetype" },
  /* HP-UX */
  { "/usr/lib/X11/fonts!"},
  /* Ghostscript */
  { "/usr/share/ghostscript/fonts" },
  { "/usr/local/share/ghostscript/fonts" },
  { NULL }
  };
  #endif

  [...]

switch (action) {
case ACTION_CLEAR:
/* Clear fontpath, fall through to init */
FPRINTF((stderr, "Clear fontpath\n"));
free(fontpath);
fontpath = p = last = NULL;
/* HBB 2726: 'limit' has to be initialized to NULL, too! */
limit = NULL;
case ACTION_INIT:
/* Init fontpath from environment */
FPRINTF((stderr, "Init fontpath from environment\n"));
assert(fontpath == NULL);
if (!fontpath)
{
char *envlib = getenv("GNUPLOT_FONTPATH");
if (envlib) {
/* get paths from environment */
int len = strlen(envlib);
fontpath = gp_strdup(envlib);
/* point to end of fontpath */
last = fontpath + len;
/* convert all PATHSEPs to \0 */
PATHSEP_TO_NUL(fontpath);
}
#if defined(HAVE_DIRENT_H) || defined(_Windows)
else {
/* set hardcoded paths */
const struct path_table *curr_fontpath = fontpath_tbl;

  [...]

in src/variable.c.  The above is taken from a recent CVS checkout, but
the 4.0.0 sources for the current Cygwin package have similar lines.

So gnuplot is using kpsexpand to locate some font files.

It looks like there are a couple of options.

One is to set GNUPLOT_FONTPATH in the environment before calling
gnuplot.

Another is to make a wrapper kpsexpand that looks for the real version
and does nothing if the real version is not present:

  #! /bin/sh
  if [ -x /usr/bin/kpsexpand ]; then
exec /usr/bin/kspexpand "$@"
  fi

(though you might want to add some comments about why this is needed).

If the real kpsexpand is not present, then chances are the font files
are not -either, so it should not matter that the corresponding
directories named in the fontpath are bogus.  You could install the
wrapper script in one of the directories in Octave's DEFAULT_EXEC_PATH
(for example, /usr/lib/octave/2.1.72/exec/i686-pc-cygwin, where a
couple of other scripts are already installed), then it would only be
found by Octave and should not introduce any other conflicts.

jwe

--
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: Size difference reported by /proc/partitions and lseek(SEEK_END) on block device

[Loh, Joe]

> Have you tried this with the latest snashot from
http://cygwin.com/snapshots ?
>
>
> Corinna

We just installed the cygwin-inst-20051207.tar.bz2 snapshot.  The output
in //proc/partitions is the same as the Cygwin Kernel 1.5.18.  However,
the lseek(SEEK_END) no longer works.  When I rerun the "C" program it
gave the following error. I even recompiled with the new snapshot just
to make sure, still the same error.  I have also attached the strace
output for the lseekend.

$ ./lseekend.exe /dev/sda
lseek: Invalid argument

Here's the output from the snapshot:

major minor  #blocks  name

8 0  78124095 sda
8 1  15358108 sda1
8 2104422 sda2
8 3  16386300 sda3

Strace for lseekend:

**
Program name: C:\cygwin\home\Administrator\lseekend.exe (pid 3220, ppid
1)
App version:  1005.19, api: 0.147
DLL version:  1005.19, api: 0.147
DLL build:20051207 10:34:08SNP
OS version:   Windows NT-5.2
Heap size:402653184
Date/Time:2005-12-07 11:15:23
**
   74 592 [main] lseekend 3220 set_myself: myself->dwProcessId 3220
   63 655 [main] lseekend 3220 time: 1133975723 = time (0)
  5481203 [main] lseekend 3220 environ_init: GetEnvironmentStrings
returned 0x2458B8 - "=C:=C:\cygwin\bin"
  1861389 [main] lseekend 3220 environ_init: 0x420238:
!C:=C:\cygwin\bin
   791468 [main] lseekend 3220 environ_init: 0x420250:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
   771545 [main] lseekend 3220 environ_init: 0x420288:
APPDATA=C:\Documents and Settings\Administrator\Application Data
   801625 [main] lseekend 3220 environ_init: 0x4202D0:
CLIENTNAME=Console
   771702 [main] lseekend 3220 environ_init: 0x4202E8:
CLUSTERLOG=C:\WINDOWS\Cluster\cluster.log
   781780 [main] lseekend 3220 environ_init: 0x420318:
COLORFGBG=0;default;15
   771857 [main] lseekend 3220 environ_init: 0x420338:
COLORTERM=rxvt-xpm
   781935 [main] lseekend 3220 environ_init: 0x420350:
COMMONPROGRAMFILES=C:\Program Files\Common Files
   782013 [main] lseekend 3220 environ_init: 0x420388:
COMPUTERNAME=P3PANDA
   772090 [main] lseekend 3220 environ_init: 0x4203A8:
COMSPEC=C:\WINDOWS\system32\cmd.exe
   782168 [main] lseekend 3220 environ_init: 0x4203D0:
CVS_RSH=/bin/ssh
   802248 [main] lseekend 3220 set_file_api_mode: File APIs set to
OEM
   402288 [main] lseekend 3220 parse_options: codepage (called func)
   772365 [main] lseekend 3220 parse_options: tty 1001
   782443 [main] lseekend 3220 parse_options: binmode 65536
   772520 [main] lseekend 3220 parse_options: title 1
   762596 [main] lseekend 3220 parse_options: returning
   412637 [main] lseekend 3220 environ_init: 0x4203E8:
CYGWIN=codepage:oem tty binmode title
   772714 [main] lseekend 3220 environ_init: 0x420460: DISPLAY=:0
   772791 [main] lseekend 3220 environ_init: 0x420470: EDITOR=vi
   772868 [main] lseekend 3220 environ_init: 0x420480:
FP_NO_HOST_CHECK=NO
   812949 [main] lseekend 3220 getwinenv: can't set native for HOME=
since no environ yet
   803029 [main] lseekend 3220 mount_info::conv_to_posix_path:
conv_to_posix_path (C:\cygwin\home\Administrator, no-keep-rel,
no-add-slash)
   483077 [main] lseekend 3220 normalize_win32_path:
C:\cygwin\home\Administrator = normalize_win32_path
(C:\cygwin\home\Administrator)
   493126 [main] lseekend 3220 mount_info::conv_to_posix_path:
/home/Administrator = conv_to_posix_path (C:\cygwin\home\Administrator)
  1143240 [main] lseekend 3220 win_env::add_cache: posix
/home/Administrator
   413281 [main] lseekend 3220 win_env::add_cache: native
HOME=C:\cygwin\home\Administrator
   413322 [main] lseekend 3220 posify: env var converted to
HOME=/home/Administrator
   773399 [main] lseekend 3220 environ_init: 0x4204C0:
HOME=/home/Administrator
   773476 [main] lseekend 3220 environ_init: 0x420498: HOMEDRIVE=C:
   773553 [main] lseekend 3220 environ_init: 0x420610:
HOMEPATH=\Documents and Settings\Administrator
   783631 [main] lseekend 3220 environ_init: 0x420648:
HOSTNAME=P3PANDA
   773708 [main] lseekend 3220 environ_init: 0x420660:
INFOPATH=/usr/local/info:/usr/share/info:/usr/info:
   793787 [main] lseekend 3220 environ_init: 0x420698:
LOGONSERVER=\\P3PANDA
   773864 [main] lseekend 3220 environ_init: 0x4206B8:
MAKE_MODE=unix
   783942 [main] lseekend 3220 environ_init: 0x4206D0:
MANPATH=/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man
   784020 [main] lseekend 3220 environ_init: 0x420718:
NUMBER_OF_PROCESSORS=2
   774097 [main] lseekend 3220 environ_init: 0x420738:
OLDPWD=/usr/bin
   774174 [main] lseekend 3220 environ_init: 0x420750: OS=Windows_NT
  1344308 [main] lseekend 3220 getwinenv: can't set native for PATH=
since no environ yet
   504358 [main] lseekend 3220 normalize_posix_path: s

Re: octave-forge dependency?

[James R. Phillips]

Chris Taylor wrote:

>...the OP _doesn't_ want his configure scripts picking up tetex...

This is what the OP said:

"If I don't put miktex in the front of my path, then the configury stuff is
happy (finds tetex, uses tetex), but *I'm* not happy because *I* want to call
miktex binaries from my cygwin interactive shell."

I believe a reasonable interpretation of this is that he generally doesn't mind
if packages configure to use tetex and even use tetex, as long as he gets
miktex by default from the command line.  This is the situation my solution is
designed to address.  If, as you claim, he _cannot_ have packages configure to
use tetex, then I admit my solution does not work.


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

Window color change when cygwin telnet to QNX

[AnnMichele Lobello]

I am running cygwin on a Windows 2000 machine.  I have various default colors 
set up for my windows to help distinguish them.  While running a bash shell 
window, I telnet into a QNX machine.  After a few "ls" commands, and/or I 
run "less," the color of the window starts turning black where the text is not 
displayed, and after paging down further, the entire window eventually goes 
black.  The color of the window is immediately restored when I exit the QNX 
telnet session.

When I run telnet, the TERM variable changes to ansi, and changing it to cygwin 
does not retain full functionality of the window.

Does anyone know why this might be happening, and what I can do to be able to 
retain the default color of the window?

Thanks,
AnnMichele


--
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: octave-forge dependency?

[Igor Pechtchanski]

On Wed, 7 Dec 2005, Chris Taylor wrote:

> Two things: Firstly, the OP _doesn't_ want his configure scripts picking
> up tetex, ergo tetex must not be in the path.
> [snip]

As you noted, for tetex to not be in the PATH, it needs to not be
installed.

> The only way to stop this behaviour is to
> a) completely trash the cygwin path, and thus lose 99% of the functionality
> b) install tetex elsewhere (/usr/local/octave-tetex/*hierarchy_here* for
> example).

There's a third way -- read on.

> Neither of these are brilliant solutions, and the latter would actually
> require hacking the cygwin package in order for it to install there, and
> still work (it would probably require tetex to be recompiled). Though
> you could perhaps persuade octave not to install the normal tetex using
> the setup database that tracks what is and isn't installed... (Not
> entirely clear on how that works at the moment though - Igor might be
> able to clear that up?)

The setup database is not sophisticated enough to track package
alternatives.  All it does is record which *packages* are installed.
It's possible to, as you say, hack it when your proposed octave-tetex
package is installed to record that the version of tetex is some
improbably high number, but since the only thing that programmatically
modifies the database is setup itself, this would have to be done by hand.
I don't think it's even possible to do this cleanly in a postinstall
script.

> It may be worth having an either or dependancy for octave..

Setup does not support this kind of dependencies.

> None of this is all that straightforward, but it would mean people
> weren't forced to install tetex..

The third alternative I mentioned is to split out the "legend" command
into a separate package, and have *that* package depend on tetex-bin.
This way, people who want to use octave without tetex (and thus without
"legend") can install the base octave-forge package, and those who do want
to use "legend" can install "octave-legend" with all the gory consequences
(i.e., dragging in tetex-bin).

However...

Chuck, since all "legend" needs is kpsexpand, why not simply make setup
convinced that tetex-bin *is* installed (hack installed.db by hand)?
That way, "legend" will even pick up the kpsexpand from MikTeX, and setup
will never try to install tetex-bin automatically...  This will solve your
particular problem right now, but can't be expected of each and every user
of octave-forge, of course.

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

--
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: octave-forge dependency?

[Chris Taylor]

James R. Phillips wrote:

Chris Taylor wrote:



This doesn't solve the core problem that configure will pick up the >presence


of cygwin's tetex and expect it - the cygwin tetex install >would need to be
masked entirely in order to use miktex and not >have configure expect tetex..


OK, it seems an elaboration of the idea could though.  The autoconf/automake
environment needs to be like octave, while the rest of the time, you want
miktex in the front of the path.  Wouldn't executing

export PATH=$PATH_FOR_OCTAVE

before starting ./configure work for that purpose?

jrp



No.

Two things: Firstly, the OP _doesn't_ want his configure scripts picking 
up tetex, ergo tetex must not be in the path.
Secondly, tetex installs (at least last time I checked) in such a way 
that it's located automatically by configure scripts (given that it's in 
the default path).

The only way to stop this behaviour is to
a) completely trash the cygwin path, and thus lose 99% of the functionality
b) install tetex elsewhere (/usr/local/octave-tetex/*hierarchy_here* for 
example).


Neither of these are brilliant solutions, and the latter would actually 
require hacking the cygwin package in order for it to install there, and 
still work (it would probably require tetex to be recompiled). Though 
you could perhaps persuade octave not to install the normal tetex using 
the setup database that tracks what is and isn't installed... (Not 
entirely clear on how that works at the moment though - Igor might be 
able to clear that up?)


It may be worth having an either or dependancy for octave.. tetex-bin or 
octave-tetex, the latter being the minimal set required to use 
octave-forge fully, and installing in a different path in order to 
separate it from the standard path. You'd then need to have some sort of 
wrapper that could tell octave where it was - an expansion of the basic 
script you gave would probably be sufficient - perhaps testing for it in 
/usr/bin, and if it didn't exist, appending or prepending the 
octave-tetex path. Of course, the octave-tetex would have to conflict 
with tetex-bin, and tetex-bin would have to effectively supplant it if 
it was selected, or was already installed...



None of this is all that straightforward, but it would mean people 
weren't forced to install tetex..


--

Spinning complacently in the darkness, covered and blinded by a blanket
of little lives, false security has lulled the madness of this world
into a slumber. Wake up! An eye is upon you, staring straight down and
keenly through, seeing all that you are and everything that you will
never be. Yes, an eye is upon you, an eye ready to blink. So face
forward, with arms wide open and mind reeling. Your future has
arrived... Are you ready to go?

--
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: octave-forge dependency?

[Christopher Faylor]

On Wed, Dec 07, 2005 at 04:22:57PM +0100, Corinna Vinschen wrote:
>On Dec  6 13:47, James R. Phillips wrote:
>> FWIW, the 12-04 and 12-05 cygwin1.dll snapshots seem to cause
>> octave-2.1.72-1 to hang on exit, but only if some significant
>> computations and plots are done.  Just starting and then exiting
>> doesn't trigger the problem.  This is a regression relative to the
>> 11-30 snapshot.
>
>That's fine, but you remember vaguely what I wrote in my call for
>testing, right?  If you want the hang to persist in the next Cygwin
>version, just don't give us any more information.  What about basic
>debugging, strace, gdb, cygcheck output, ... a simple testcase?

It would be interesting to find out where this fails.  There are other
snapshots between 12-04 and 11-30.  Does it also fail with those?

cgf

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

Re: octave-forge dependency?

[James R. Phillips]

Chris Taylor wrote:

>This doesn't solve the core problem that configure will pick up the >presence
of cygwin's tetex and expect it - the cygwin tetex install >would need to be
masked entirely in order to use miktex and not >have configure expect tetex..


OK, it seems an elaboration of the idea could though.  The autoconf/automake
environment needs to be like octave, while the rest of the time, you want
miktex in the front of the path.  Wouldn't executing

export PATH=$PATH_FOR_OCTAVE

before starting ./configure work for that purpose?

jrp

--
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: octave-forge dependency?

[Corinna Vinschen]

On Dec  6 13:47, James R. Phillips wrote:
> FWIW, the 12-04 and 12-05 cygwin1.dll snapshots seem to cause
> octave-2.1.72-1 to hang on exit, but only if some significant
> computations and plots are done.  Just starting and then exiting
> doesn't trigger the problem.  This is a regression relative to the
> 11-30 snapshot.

That's fine, but you remember vaguely what I wrote in my call for
testing, right?  If you want the hang to persist in the next Cygwin
version, just don't give us any more information.  What about basic
debugging, strace, gdb, cygcheck output, ... a simple testcase?


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: octave-forge dependency?

[Chris Taylor]

James R. Phillips wrote:

Charles Wilson wrote:



But apparently I can't use octave.



Hm, actually we wouldn't want to lose such a knowledgeable user.  We need users
like you in order to improve octave.

Would this work for you?  Prior to putting miktex at the front of your path,
say in your .profile, it should be possible to save the unmodified path in an
environmental variable, say PATH_FOR_OCTAVE.

Then write a short shell script named "octave" to start octave, and put it in
/usr/local/bin; something like

===
#!/bin/sh

export PATH=$PATH_FOR_OCTAVE
/usr/bin/octave
===

When typing "octave" from the command line, the shell script should be found in
the path prior to the octave binary in /usr/bin. octave/octave-forge should
then use the cygwin-native tetex binaries.  I don't see any reason why this
wouldn't work.

Hope you don't give up on octave.

jrp




This doesn't solve the core problem that configure will pick up the 
presence of cygwin's tetex and expect it - the cygwin tetex install 
would need to be masked entirely in order to use miktex and not have 
configure expect tetex..



Chris

--

Spinning complacently in the darkness, covered and blinded by a blanket
of little lives, false security has lulled the madness of this world
into a slumber. Wake up! An eye is upon you, staring straight down and
keenly through, seeing all that you are and everything that you will
never be. Yes, an eye is upon you, an eye ready to blink. So face
forward, with arms wide open and mind reeling. Your future has
arrived... Are you ready to go?

--
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: octave-forge dependency?

[James R. Phillips]

Charles Wilson wrote:

>But apparently I can't use octave.

Hm, actually we wouldn't want to lose such a knowledgeable user.  We need users
like you in order to improve octave.

Would this work for you?  Prior to putting miktex at the front of your path,
say in your .profile, it should be possible to save the unmodified path in an
environmental variable, say PATH_FOR_OCTAVE.

Then write a short shell script named "octave" to start octave, and put it in
/usr/local/bin; something like

===
#!/bin/sh

export PATH=$PATH_FOR_OCTAVE
/usr/bin/octave
===

When typing "octave" from the command line, the shell script should be found in
the path prior to the octave binary in /usr/bin. octave/octave-forge should
then use the cygwin-native tetex binaries.  I don't see any reason why this
wouldn't work.

Hope you don't give up on octave.

jrp



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

[ANNOUNCEMENT] Updated: curl-7.15.1-1, curl-devel-7.15.1-1, libcurl3-7.15.1-1

[Brian Dessent]

I've updated the cURL and libcurl packages to 7.15.1-1.

This is a new upstream release, which fixes a buffer overflow
vulnerability: 

cURL is a command line tool for transferring files with URL syntax,
supporting FTP, FTPS, TFTP, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE and
LDAP. curl supports HTTPS certificates, HTTP POST, HTTP PUT, FTP
uploading, HTTP form based upload, proxies, cookies, user+password
authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file
transfer resume, proxy tunneling and a busload of other useful tricks.  

See  for more information about cURL, and
 for a list of what has changed. 
SSL/TLS support via OpenSSL is enabled in these packages.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

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

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


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

RE: encoding scripts (so that user can't see passwords easily)?

[Buchbinder, Barry \(NIH/NIAID\) [E]]

Ehud Karni wrote:
> On Tue, 06 Dec 2005 20:36:07 +0100, Tomasz Chmielewski wrote:
>> 
>> It is to be a measure to prevent an accidental viewing of
>> usernames/passwords rather than some "military grade" tool which
>> takes 100 years to break on a supercomputer.
> 
> [I think this discussion is off topic for cygwin]
> 
> Here are 2 simple bash scripts that do what you want. Both are
> filters (i.e. read standard input, write to standard output). The
> first one just obscures the input to all numeric string. The second
> one uses gpg, so you can do "real strong encryption", with encryption
> done by anyone while decryption done by the privileged user.
> 
> Ehud
> 
> 
> #! /bin/bash -e
> # simple conversion to all numeric and back #
> -- 
> 
> OP="$1"# requested operation (--encrypt/--decrypt)
> INP=`cat`  # input to encrypt/decrypt
> LEN=${#INP}# Length of input
> OUT="" # output (almost final)
> 
> case "$OP" in
>"--encrypt" )
>while [ "$INP" != "" ]
>do
>CH=${INP:0:1}   # 1st char of input
>INP=${INP:1:$LEN}   # rest of input
>OCT=`echo "$CH" | od -An -to1 -N1`  # convert to octal
>EON=`expr 789 - $OCT`   # not too obvious
>OUT="$OUT$EON"
>done;;  # OUT ready
> 
>"--decrypt" )
>while [ "$INP" != "" ]
>do
>   EON=${INP:0:3}   # 1st "inverted" octal
>   of input INP=${INP:3:$LEN}# rest of
>   input OCT=`expr 789 - $EON`# octal
>   OUT="$OUT"'\'"$OCT"  # add \ for decoding
>octals ' done;;  # OUT ready
> 
>* ) echo "OP (1st arg) is |$OP|. should be --encrypt or --decrypt"
>exit 1  ;;
> esac
> 
> echo -e "$OUT" # echo
> encrypted/decrypted to USER 
> 
> ## end of simple-crypt.sh
> ## 
> 
> 
> #! /bin/bash -e
> # gpg encryption/decryption, must have gpg keys (public & private) #
>  
> 
> KEY=$1 # gpg key, should be in
> pubring.gpg/secring.gpg 
> OP=$2  # requested operation (--encrypt/--decrypt)
> PSP="$3"   # passphrase (needed for --decrypt only)
> or empty 
> 
> GPGOPT="--default-recipient-self --batch --no-tty --always-trust
> --no-options --output -" 
> if [ "$PSP" != "" ] ; then # do only when passphrase given
> exec 3<&0  # trick, save stdin stream
> 
> echo "${PSP" |
> (  exec 4<&0 ; # set fd 4 to read from echo
>exec 0<&3 ; # restore original stdin (for gpg input)
>gpg --default-key $KEY $GPGOPT --passphrase-fd 4 $OP ) else
> gpg --default-key $KEY $GPGOPT $OP
> fi
> 
> ## end of gpg-crypt.sh
> ## 

Are we forgetting the classic?  As long as we don't care how strong the
encryption is, what about rot13?

#!/bin/sh
tr 'A-Za-z' 'N-ZA-Mn-za-m'

(Maybe I should ITP rot13.)  And there's always uuencode/uudecode.

:-)

- Barry

--
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: A problem with setup.exe

[Max Bowsher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

petro wrote:
> I've been an off and on user of Cygwin for a long time, and over the
> years the setup program (and process) has incrementally gotten better.
> I'm not all that great at development, and I really hate whinging about
> free software that more-or-less works because basically I can't do any
> better, but I've hit (what I consider) a bug in the setup program three
> or 4 times today, and it's got me a tad annoyed.
> 
> When selecting packages, if one hits the arrow keys (at least the down
> arrow, I'm not sure about the others, and I'm in the middle of a lengthy
> selection process, so I'm not testing it right now) it closes all of the
> trees and sets all of the selections to the default. Was this
> deliberate, or is a bug?

I suspect that what is happening is that it is triggering a 'click'
event to the Keep/Curr/Prev/Exp radio buttons.

So, I guess it really falls into the category of 'unplanned feature'. Of
course, if the chooser control was made able to take focus, this would
not happen.


Max.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDltSUfFNSmcDyxYARAgnqAKCPp/Q/61WvCn/NO4KuuZo3OnPdygCfY58K
aW6SqdE3ZVubxHhlSTR1s18=
=tUwq
-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: encoding scripts (so that user can't see passwords easily)?

[Ehud Karni]

On Tue, 06 Dec 2005 20:36:07 +0100, Tomasz Chmielewski wrote:
>
> It is to be a measure to prevent an accidental viewing of
> usernames/passwords rather than some "military grade" tool which takes
> 100 years to break on a supercomputer.

[I think this discussion is off topic for cygwin]

Here are 2 simple bash scripts that do what you want. Both are filters
(i.e. read standard input, write to standard output). The first one
just obscures the input to all numeric string. The second one uses gpg,
so you can do "real strong encryption", with encryption done by anyone
while decryption done by the privileged user.

Ehud


#! /bin/bash -e
# simple conversion to all numeric and back
# --

OP="$1"# requested operation (--encrypt/--decrypt)
INP=`cat`  # input to encrypt/decrypt
LEN=${#INP}# Length of input
OUT="" # output (almost final)

case "$OP" in
   "--encrypt" )
   while [ "$INP" != "" ]
   do
   CH=${INP:0:1}   # 1st char of input
   INP=${INP:1:$LEN}   # rest of input
   OCT=`echo "$CH" | od -An -to1 -N1`  # convert to octal
   EON=`expr 789 - $OCT`   # not too obvious
   OUT="$OUT$EON"
   done;;  # OUT ready

   "--decrypt" )
   while [ "$INP" != "" ]
   do
  EON=${INP:0:3}   # 1st "inverted" octal of input
  INP=${INP:3:$LEN}# rest of input
  OCT=`expr 789 - $EON`# octal
  OUT="$OUT"'\'"$OCT"  # add \ for decoding octals '
   done;;  # OUT ready

   * ) echo "OP (1st arg) is |$OP|. should be --encrypt or --decrypt"
   exit 1  ;;
esac

echo -e "$OUT" # echo encrypted/decrypted to 
USER

## end of simple-crypt.sh 
##


#! /bin/bash -e
# gpg encryption/decryption, must have gpg keys (public & private)
# 

KEY=$1 # gpg key, should be in pubring.gpg/secring.gpg
OP=$2  # requested operation (--encrypt/--decrypt)
PSP="$3"   # passphrase (needed for --decrypt only) or empty

GPGOPT="--default-recipient-self --batch --no-tty --always-trust --no-options 
--output -"
if [ "$PSP" != "" ] ; then # do only when passphrase given
exec 3<&0  # trick, save stdin stream

echo "${PSP" |
(  exec 4<&0 ; # set fd 4 to read from echo
   exec 0<&3 ; # restore original stdin (for gpg input)
   gpg --default-key $KEY $GPGOPT --passphrase-fd 4 $OP )
else
gpg --default-key $KEY $GPGOPT $OP
fi

## end of gpg-crypt.sh 
##


--
 Ehud Karni   Tel: +972-3-7966-561  /"\
 Mivtach - Simon  Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D Better Safe Than Sorry

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

Bug report: time functions in emulation layer

[Brandt, Servatius]

Hi,

I found a Cygwin time problem which seems to be caused by the Linux API
emulation layer.  The actual problem occurred when using the svnserve
process from the Subversion package that comes with Cygwin.  After
running more than 49.7 days without rebooting the machine, the time
stamps in the Subversion repository got wrong.  There was a time shift
of just these 49.7 days backwards.  It seems that the emulation layer
uses the GetTickCount() function, which causes errors in the Linux API
time functions when the machine (or: the process running under Cygwin?)
runs longer than 49.7 days.

I'll solve my problem by switching to the native Windows svnserve
command, but I thought the Cygwin developers might be interested to
improve the emulation layer.  I quote below two remarks which Ben
Collins-Sussman, one of the Subversion developers, sent to me:

> This is a famous bug in the GetTickCount() windows API -- it overflows
> after 49 days, being a 32-bit number.  You can read about it here, in
> the commentary:
> 
>
http://www.techspot.com/news/15637-microsoft-servers-leave-800-planes-in
-the-air.html

When I suspected the Subversion code uses GetTickCount() itself and
asked to work around the GetTickCount() limitation, Ben answered:

> I don't think this is a Subversion bug, because it doesn't call
> GetTickCount() anywhere at all.  I think it is more likely a bug in
> Cygwin's "unix translation" layer.  My suspicion is that Subversion
> calls the APR time functions to get the current system time, then APR
> calls the standard unix time functions, and then Cygwin translates the
> unix call into a windows GetTickCount().

Regards,
Servatius


Cygwin Configuration Diagnostics
Current System Time: Wed Dec 07 12:32:22 2005

Windows 2003 Server Ver 5.2 Build 3790 

Path:   C:\Data\Something\Cygwin\usr\local\bin
C:\Data\Something\Cygwin\bin
C:\Data\Something\Cygwin\bin
C:\Data\Something\Cygwin\usr\X11R6\bin
c:\Programme\Windows Resource Kits\Tools\
c:\Programme\WebTransactionsV7\weblab
c:\Programme\WebTransactionsV7\lib
c:\Programme\Gemeinsame
Dateien\FujitsuSiemensComputers\BizTransactions70\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Programme\Microsoft SQL Server\80\Tools\BINN
c:\Programme\jwsdp-1.5\jwsdp-shared\bin

Output from C:\Data\Something\Cygwin\bin\id.exe (nontsec)
UID: 500(Administrator) GID: 513(Kein)
0(root) 513(Kein)   544(Administratoren)
545(Benutzer)

Output from C:\Data\Something\Cygwin\bin\id.exe (ntsec)
UID: 500(Administrator) GID: 513(Kein)
0(root) 513(Kein)   544(Administratoren)
545(Benutzer)

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

USER = `Administrator'
PWD = `/cygdrive/c/Data/Something'
HOME = `/home/Administrator'
MAKE_MODE = `unix'

HOMEPATH = `\Dokumente und Einstellungen\Administrator'
MANPATH =
`/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/X11R6/man'
APPDATA = `C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten'
HOSTNAME = `somehost'
TERM = `cygwin'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 4 Stepping 1, GenuineIntel'
WINDIR = `C:\WINDOWS'
OLDPWD = `/home/Administrator'
USERDOMAIN = `SOMEHOST'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users'
TEMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien'
USERNAME = `Administrator'
CLUSTERLOG = `C:\WINDOWS\Cluster\cluster.log'
PROCESSOR_LEVEL = `15'
SYSTEMDRIVE = `C:'
JAVA_HOME = `C:\Programme\j2sdk1.4.2_06'
USERPROFILE = `C:\Dokumente und Einstellungen\Administrator'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\SOMEHOST'
PROCESSOR_ARCHITECTURE = `x86'
!C: = `C:\Data\Something\Cygwin\bin'
SHLVL = `1'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `C:'
PROMPT = `$P$G'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
TMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
SYSTEMROOT = `C:\WINDOWS'
PRINTER = `Lexmark C752 PS3'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0401'
PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig'
INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = `C:\Programme'
NUMBER_OF_PROCESSORS = `4'
SESSIONNAME = `Console'
COMPUTERNAME = `SOMEHOST'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\Data\Something\Cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solution

[ANNOUNCEMENT] Updated: smartmontools-5.33cvs20051205-1

[Christian Franke]

I've updated smartmontools to CVS snapshot 2005-12-05.

The regular expression error message reported recently is now fixed.

Christian


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

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

Please read *all* of the information on unsubscribing that is available 

starting at the above URL.



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

[ANNOUNCEMENT] Updated: vorbis-tools-1.1.1-5

[Corinna Vinschen]

I have updated vorbis-tools to 1.1.1-5.

This package is now linked against the latest libcurl3 for security
reasons.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

[EMAIL PROTECTED]

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

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

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

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:cygwin@cygwin.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: Error reported dd'ing close of end of block device with skip

[Corinna Vinschen]

On Dec  6 15:56, Loh, Joe wrote:
> Hello Folks,
> Here's the second part of the problem.  The follow on from a previous
> issue observed as reported in "Size difference reported by
> /proc/partitions and lseek(SEEK_END) on block device."

Searching the archive 

  http://cygwin.com/cgi-bin/htsearch?config=htdig&words=dd+eom

reveals a thread "Bug in dd ?? at EOM" which starts here:

  http://sourceware.org/ml/cygwin/2005-09/msg00878.html

Btw, have you tried the latest snapshot 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: Size difference reported by /proc/partitions and lseek(SEEK_END) on block device

[Corinna Vinschen]

On Dec  6 13:45, Loh, Joe wrote:
> Hello folks,
> We have created the following test case to illustrate the behavior that
> we observed.  Hopefully someone out there can shed some light into the
> subject matter.This behavior is observed running "CYGWIN_NT-5.2
> P3PANDA 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin".

Have you tried this with the latest snashot 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/