Re: Cygwin: texi2dvi stumbles over texinfo.tex

[Ralf Wildenhues]

Hi Karl,

* Karl Berry wrote on Wed, May 24, 2006 at 10:03:39PM CEST:
> 
> Ralf, what is the output if you run
>   tex \\end
>   etex \\end
>   pdfetex \\end

See typescript, attached.

> This shows that texi2dvi is invoking etex.

> This shows that mktexfmt is invoking pdfetex to build etex.fmt.
> 
> This mismatch is causing the error.
> 
> This is controlled by the file fmtutil.cnf.  What does that file look
> like in your installation?

Also attached.

In Cygwin's /usr/share/texmf/web2c, there are *.cygwin-dist and
*.cygwin-orig copies of fmtutil.cnf, mktex.cnf, and texmf.cnf.
The respective copies are all identical, though.

Cheers,
Ralf
Script started on Thu May 25 07:21:22 2006
$ tex \\end
This is TeXk, Version 3.141592 (Web2C 7.5.4)
 file:line:error style messages enabled.
 %&-line parsing enabled.
No pages of output.
Transcript written on texput.log.
$ etex \\end
This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4)
 file:line:error style messages enabled.
 %&-line parsing enabled.
---! /home/ralf/.texmf/var/web2c/etex.fmt was written by pdfetex
(Fatal format file error; I'm stymied)
$ pdfetex \\end
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
 file:line:error style messages enabled.
 %&-line parsing enabled.
entering extended mode
No pages of output.
Transcript written on texput.log.
$ file ~/.texmf/var/web2c/etex.fmt
/home/ralf/.texmf/var/web2c/etex.fmt: data
$ mv ~/.texmf/var/web2c/etex.fmt ~/.texmf/var/web2c/etex.fmt-broken
$ etex \\end
This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4)
 file:line:error style messages enabled.
 %&-line parsing enabled.
kpathsea: Running mktexfmt etex.fmt
fmtutil: running `pdfetex -ini   -jobname=etex -progname=etex 
-translate-file=cp227.tcx *etex.ini' ...
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX)
 file:line:error style messages enabled.
 %&-line parsing enabled.
 (/usr/share/texmf/web2c/cp227.tcx)
entering extended mode
(/usr/share/texmf/tex/plain/config/etex.ini
(/usr/share/texmf/tex/generic/config/pdftexconfig.tex)
(/usr/share/texmf/tex/plain/etex/etex.src
(/usr/share/texmf/tex/plain/base/plain.tex Preloading the plain format: codes,
registers, parameters, fonts, more fonts, macros, math definitions,
output routines, hyphenation (/usr/share/texmf/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texmf/tex/plain/etex/etexdefs.lib Skipping module "grouptypes";
Loading module "interactionmodes"; Skipping module "nodetypes";
Skipping module "iftypes";) (/usr/share/texmf/tex/plain/config/language.def
(/usr/share/texmf/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended register allocation; 
Recycling: \addlanguage, [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], 
[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL 
PROTECTED] (not defined),
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
Retaining: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]@@d, [EMAIL PROTECTED]@ad, [EMAIL PROTECTED], [EMAIL 
PROTECTED], [EMAIL PROTECTED], \eTeX, \etexhdrchk,
\etexstatus, \module, \uselanguage, [EMAIL PROTECTED], [EMAIL PROTECTED],) )
Beginning to dump on file etex.fmt
 (format=etex 2006.5.25)
2658 strings of total length 38086
7953 memory locations dumped; current usage is 197&7289
1176 multiletter control sequences
\font\nullfont=nullfont
\font\tenrm=cmr10
\font\preloaded=cmr9
\font\preloaded=cmr8
\font\sevenrm=cmr7
\font\preloaded=cmr6
\font\fiverm=cmr5
\font\teni=cmmi10
\font\preloaded=cmmi9
\font\preloaded=cmmi8
\font\seveni=cmmi7
\font\preloaded=cmmi6
\font\fivei=cmmi5
\font\tensy=cmsy10
\font\preloaded=cmsy9
\font\preloaded=cmsy8
\font\sevensy=cmsy7
\font\preloaded=cmsy6
\font\fivesy=cmsy5
\font\tenex=cmex10
\font\preloaded=cmss10
\font\preloaded=cmssq8
\font\preloaded=cmssi10
\font\preloaded=cmssqi8
\font\tenbf=cmbx10
\font\preloaded=cmbx9
\font\preloaded=cmbx8
\font\sevenbf=cmbx7
\font\preloaded=cmbx6
\font\fivebf=cmbx5
\font\tentt=cmtt10
\font\preloaded=cmtt9
\font\preloaded=cmtt8
\font\preloaded=cmsltt10
\font\tensl=cmsl10
\font\preloaded=cmsl9
\font\preloaded=cmsl8
\font\tenit=cmti10
\font\preloaded=cmti9
\font\preloaded=cmti8
\font\preloaded=cmti7
\font\preloaded=cmu10
\font\preloaded=cmmib10
\font\preloaded=cmbsy10
\font\preloaded=cmcsc10
\font\preloaded=cmssbx10
\font\preloaded=cmdunh10
\font\preloaded=cmr7 at 14.51799pt
\font\preloaded=cmtt10 at 14.4pt
\font\preloaded=cmssbx10 at 14.4pt
\font\preloaded=manfnt
14787 words of font info for 50 preloaded fonts
14 hyphenation exceptions
Hyphenation trie of

Re: Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]

[clayne]

On Wed, May 24, 2006 at 07:06:32PM +0100, Dave Korn wrote:
>   YES, THERE IS A WAY!
> 
>   WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS
> THREAD! 
> 
>   THE WAY IS TO USE AN UP-TO-DATE GDB!

BTW:

Myself, I had just updated to CVS gdb. Currently it looks like SIGINT is busted
(well atleast initiating via ctrl-c) and performance under gdb is crap (probably
because I'm trying to debug something with millions of objects - each with their
own mutexes).

-cl

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

cvs emacs

[djh]

Has anyone out there been successfull in finding out how to build
the latest cvs emacs with the cygwin 5.19.4?

I was building emacs with cygwin's x-windows with the following configuration:
./configure --prefix=/usr --mandir=/usr/share/man   
--infodir=/usr/share/info --exec-prefix= --with-jpeg --with-png --with-gtk  
--with-gif  --without-toolkit-scroll-bars --with-xpm --with-tiff 
--x-includes=/usr/X11R6/include/X11  --x-libraries=/usr/X11R6/
lib


I have tried it but ran into problems, such as: 


Compiling /cygdrive/c/emacs/cvs/emacs/lisp/emacs-lisp/byte-opt.el
Fatal error (6)/bin/sh: line 1:  1712 Aborted (core dumped) 
EMACSLOADPATH=/cygdrive/c/emacs/cvs/emacs/lisp ../src/bootstrap-emacs.exe 
-batch --no-site-file --multibyte -f batch-byte-compile-if-not-done $el
make[2]: *** [compile] Error 1
make[2]: Leaving directory `/cygdrive/c/emacs/cvs/emacs/lisp'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/cygdrive/c/emacs/cvs/emacs'
make: *** [bootstrap] Error 2


I was able to build April 28ths cvs emacs on cygwin 5.18..., but not yet with 
5.19.  Wonder if the problem could be something in cygwin??

Have any of you out there ran into and solved this?

Regards,
  Darel Henman

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

Re: slow share = slow scripts?

[Larry Hall (Cygwin)]

mwoehlke wrote:
I'm trying to run some scripts off of a slow network share, and it takes 
*forever* in Cygwin (it's OK in Interix).


Looking at an strace (attached) via 'sort -n' shows a LOT of time being 
spent in read(), apparently just after (caused by?) an fstat(), which 
means this feels like an inefficiency somewhere in Cygwin's POSIX 
emulation. Other than "RTFSC", does anyone have any ideas what I could 
do (workarounds, etc) so that I can run scripts in a reasonable amount 
of time? (Might this have anything to do with my share being non-writable?)



Take a look at the -x, -E, and -X flags of 'mount'. Perhaps these will help
you.



Sorry for the .bz2, but 248k seemed a little excessive :-).



And actually sending unsolicited straces to the list is discouraged.


Somewhat OT, why does 'strace bash -c foo > /foo_strace' generate a file 
with DOS line-endings? None of my mounts are 'textmode'...




'strace' does not use cygwin1.dll.


--
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: slow share = slow scripts?

[Gary R. Van Sickle]

> From: mwoehlke
> 
> I'm trying to run some scripts off of a slow network share, 
> and it takes
> *forever* in Cygwin (it's OK in Interix).
> 
> Looking at an strace (attached) via 'sort -n' shows a LOT of 
> time being spent in read(), apparently just after (caused 
> by?) an fstat(), which means this feels like an inefficiency 
> somewhere in Cygwin's POSIX emulation.

Cygwin's fstat() is slow.  That's a known situation brought on by the POSIX
definition of the function.  Fstating stuff across a slow link is simply
going to exacerbate the problem.

> Other than "RTFSC", 
> does anyone have any ideas what I could do (workarounds, etc) 
> so that I can run scripts in a reasonable amount of time? 
> (Might this have anything to do with my share being non-writable?)
> 

The obvious is to copy everything to a fast (preferably local) drive/share
and do your business there, if that's possible.  It might be a win for you
even if you did a copy-to-local/modify/copy-back sort of deal, depends on
the situation.

-- 
Gary R. Van Sickle
 



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

RE: No postnews or other Usenet news utilities?

[Bruce Wehr]

Let me begin by saying - WOW - this is the LAST type of response I expected.

Let me continue by addressing each of your points.

>   LIAR.  You cannot claim that every single usenet reader in 
> the entire world is interested in Pokemon.  You are just 
> projecting your own personal selfish interests on to the rest 
> of the world, because you have a financial advantage if you 
> pretend that everyone is like you.

Hmmm ... So I'm a liar, am I?  It's interesting that you could come to that
conclusion after just one posting.

Perhaps I misspoke, perhaps you just misunderstood me.  By "universal
appeal," I did not mean to imply that "every single Usenet reader in the
entire world is interested in Pokemon."  Perhaps I should have said "global
appeal."  The point I was trying to make is that the item I'm selling has
followers in every country of the world; there are no arbitrary political or
worldly boundaries beyond which one could find interested parties.

>   GARBAGE.  You are UNQUESTIONABLY a spammer and there is 
> absolutely nothing to debate.

You're right on one point.  Debate is useless and pointless when one party
has such a closed mind, and sees the world in such black and white terms.
"I've already made up my mind.  Please don't bother me with the facts."

> How can you say "all of the 
> forsale groups" and say that's not indiscriminate?

Hmmm ... Perhaps you can enlighten me:  what is the purpose of the *.forsale
groups?  It's not indiscriminate because there are over 100,000 newsgroups I
*could've* spammed.

> It's not 
> up to YOU to decide whether a given post is "appropriate" or 
> not in a given group:

I disagree: as the poster, I have an *obligation* to decide whether or not a
particular group is appropriate for what I'm planning to post.  That's my
responsibility, and my way of showing respect to the entire Usenet
community.

> the group has existed for a long time 
> before you came around and has pre-existing standards, 
> customs and rules that define what is or is not 
> "appropriate".

Oh, so now you presume to know how long I've been around, eh?  Pretty
clairvoyant of you, no?

Since you brought the subject up, let me tell you how long I've been around
Usenet.  (I usually avoid speeches like this; they sound so trite.  But, hey
... You started it. :)

I was introduced to Usenet on or about 1985.  I had been a regular
participant, a respected member of the community for many years.  I invite
you to visit Google Groups and search for me: "Bruce Wehr."  See how many
posts come up.  Read a few.  See if I haven't always respected the Rules of
Netiquette.  Go ahead ... Find fault with any of my posts.  See how many
times I've been flamed.  (Congratulations: you are a now a member of an
elite, exclusive and (thankfully) sparsely populated group: the group of
those who have flamed me.)

Excuse me while I put on my Gieco Cave Man suit and say, "Perhaps you should
do a little research next time."  It has been said, "It is better to keep
your mouth shut and be thought a fool, than to open it and remove all
doubt."  Perhaps that's a lesson you should take to heart.

It's true that it's been many years since I've been active on Usenet.
That's one reason why I was so amazed at the explosion of *.forsale groups.
I bought and sold Pokemon cards when they first came out in 1999.  I found
my eBay auctions did better when I advertised them in *.forsale groups.  Let
me ask one more time: what the hell are *.forsale groups for?

> You clearly intend to ignore all these 
> uncomfortable facts because you believe you are king of the 
> world and that whatever you say automatically becomes true.

,  ... No!  I won't touch that one ... Too easy! :)

> > Wow - there must be *hundreds* of 
> > *.forsale groups!
> 
>   MOST OF WHICH ARE RELATED TO ONE LOCAL AREA OR SPECIFIC 
> KIND OF GOODS.

Oh, really?  You don't say?  Have you even looked lately?  Let me invite you
to look.  I've grepped all the *.forsale groups from my NNTP server's newsrc
file and placed them conveniently for your viewing pleasure:
http://homepage.mac.com/bwehr/forsale.txt.  Go ahead, take a look.  You'll
find a total of 696 groups.  I will leave the determination of how many of
these are dedicated to a specific kind of good as an exercise for you.  (God
knows, you seem to need some exercise.  Or *something*!)

Regarding groups that are dedicated to a specific kind of good: if you
re-read my original posting, I said I manually filtered these out.
Computers, homes, music, beanie-babies ... Yes, I manually filtered all of
those from my target list.  As for groups that are dedicated to a local
area:  are there particular areas where people interested in Pokemon cards
live?  If so, please enlighten me; I promise to limit my ads to those areas.
Last time I looked, I could find Pokemon collectors in every city, in every
state, in every country (yes, my auction is open worldwide), on every
college campus ...  How would you suggest I make my dec

RE: 1.5.19: Problem with ssh

[Harig, Mark]

> -Original Message-
> From: Eric Surjawinata [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 24, 2006 4:33 PM
> To: Harig, Mark
> Subject: Re: 1.5.19: Problem with ssh
> 
> Actually, you are correct. When I typed exit, I am back in the
> original session. I guess the login process was so silent, that I
> didn't even realize that I finally have the correct configuration.
> 

The 'Last login: ...' message is the notice that you will see
that should let you know that you have logged on to the ssh
server, wherever that may be.  You will see that message whether
you specify '-v' to ssh or not.

---


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

RE: 1.5.19: Problem with ssh

[Harig, Mark]

 

> -Original Message-
> From: Eric Surjawinata [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 24, 2006 4:19 PM
> To: Harig, Mark
> Cc: cygwin@cygwin.com
> Subject: Re: 1.5.19: Problem with ssh
> 
> Hi,
> sorry for the implicitness of the message:
> 1. Yes, I redirected all output to the approp passwd and group file
> 2. The end of the verbose session throws me back to the bash prompt.
> no error message that I can detect
> 

Your log said:

> > > debug1: Authentication succeeded (password).
> > >
> > > debug1: channel 0: new [client-session]
> > > debug1: Entering interactive session.
> > >
> > > Last lo> > >gin: Wed May 24 11:02:26 2006 from lt-esurjawinata

What were you expecting different?  You logged on to your
computer, "lt-esurjawinata", via ssh.

> ... throws me back to the bash prompt.

Correct.  So long as you realize that you are now one ssh
level removed from your original login.

---

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

Re: 1.5.19: Problem with ssh

[Eric Surjawinata]

Hi,
sorry for the implicitness of the message:
1. Yes, I redirected all output to the approp passwd and group file
2. The end of the verbose session throws me back to the bash prompt.
no error message that I can detect

On 5/24/06, Harig, Mark <[EMAIL PROTECTED]> wrote:

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Surjawinata
> Sent: Wednesday, May 24, 2006 3:50 PM
> To: cygwin@cygwin.com
> Subject: 1.5.19: Problem with ssh
>
> Hi,
>
> I have problems ssh-ing to a cygwin installed on Windows xp. I know
> this is an old issue, however I scoured all the past issues with this
> and have not found a solution that worked for me (short of finding an
> older cygwin release and re-installing).
>
> Basically I installed Cygwin 1.5.19 and done all of the followings:
>
> install ssh, privilege separation=no, CYGWIN= ntsec tty content of:
>

...

>
> ran mkpasswd -l
>

It's not clear from the above -- did you redirect the
output of 'mkpasswd -l' to /etc/passwd?  That is,

  $ mkpasswd -l > /etc/passwd

...

>
> ran mkpasswd -d -u esurjawinata (for the users I want to use to ssh)
>

Again, did you redirect this to /etc/passwd?

  $ mkpasswd -d -u esurjawinata >> /etc/passwd

...

>
> Output from ssh -v
>
> $ ssh -v [EMAIL PROTECTED]
>



>
> debug1: Next authentication method: password
>
> [EMAIL PROTECTED]'s password:
>
> debug1: Authentication succeeded (password).
>
> debug1: channel 0: new [client-session]
>
> debug1: Entering interactive session.
>
> Last login: Wed May 24 11:02:26 2006 from lt-esurjawinata
>
>
>
> Nothing works! Have I missed anything simple?
>
>

What failed?  From the above, it appears that you
were able to log on.

---



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

Re: python: update soon?

[Yaakov S (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Tishler wrote:
> AFAICT, Cygwin Python uses the normal Python layout.
> 
> On Cygwin, we have:
> 
>  $ ls /usr/lib/python2.4/config
>  Makefile  Setup.config  config.c install-sh  makesetup
>  Setup Setup.local   config.c.in  libpython2.4.dll.a  python.o
> 
> and on Linux, we have:
> 
> $ ls usr/lib/python2.4/config
> Makefile  Setup.config  config.c install-sh  makesetup
> Setup Setup.local   config.c.in  libpython2.4.a  python.o

AFAIK the difference is not in config but in /usr/lib; on Linux,
libpython2.4.so* are installed in /usr/lib, allowing one to link against
python with a simple -lpython2.4, where we need
- -L/usr/lib/python2.4/config also.  Having a copy/symlink of
libpython2.4.dll.a in /usr/lib would help make Cygwin more compatible
with python-dependent autotooled packages, which are not yet sensitive
to this peculiarity.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdL6rpiWmPGlmQSMRAsESAKCmfFcZEpj067YzUaGiLsyq3ySlkgCg7D7U
CAaIJYG2WvtxjBr+JCarPwo=
=Hs4j
-END PGP SIGNATURE-

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

RE: 1.5.19: Problem with ssh

[Harig, Mark]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Surjawinata
> Sent: Wednesday, May 24, 2006 3:50 PM
> To: cygwin@cygwin.com
> Subject: 1.5.19: Problem with ssh
> 
> Hi,
> 
> I have problems ssh-ing to a cygwin installed on Windows xp. I know
> this is an old issue, however I scoured all the past issues with this
> and have not found a solution that worked for me (short of finding an
> older cygwin release and re-installing).
> 
> Basically I installed Cygwin 1.5.19 and done all of the followings:
> 
> install ssh, privilege separation=no, CYGWIN= ntsec tty content of:
> 

...

> 
> ran mkpasswd -l
> 

It's not clear from the above -- did you redirect the
output of 'mkpasswd -l' to /etc/passwd?  That is,

   $ mkpasswd -l > /etc/passwd

...

> 
> ran mkpasswd -d -u esurjawinata (for the users I want to use to ssh)
> 

Again, did you redirect this to /etc/passwd?

   $ mkpasswd -d -u esurjawinata >> /etc/passwd

...

> 
> Output from ssh -v
> 
> $ ssh -v [EMAIL PROTECTED]
> 



> 
> debug1: Next authentication method: password
> 
> [EMAIL PROTECTED]'s password:
> 
> debug1: Authentication succeeded (password).
> 
> debug1: channel 0: new [client-session]
> 
> debug1: Entering interactive session.
> 
> Last login: Wed May 24 11:02:26 2006 from lt-esurjawinata
> 
> 
> 
> Nothing works! Have I missed anything simple?
> 
> 

What failed?  From the above, it appears that you
were able to log on.

---

--
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: texi2dvi stumbles over texinfo.tex (was: failed checks for automake 1.9.6)

[Karl Berry]

  Ok, you got me curious.  How does TeX know what application wrote the file
if it's not "to do with" the contents of that file?

Sorry, I was referring to the one-line source file
\input texinfo @bye

As for the .fmt file, yes, it surely records whether tex, etex, pdfetex,
etc., was used to generate it.  Hence the error.

Ralf, what is the output if you run
  tex \\end
from the command line?  Also
  etex \\end
and
  pdfetex \\end

This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4)

This shows that texi2dvi is invoking etex.

This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX)

This shows that mktexfmt is invoking pdfetex to build etex.fmt.

This mismatch is causing the error.

This is controlled by the file fmtutil.cnf.  What does that file look
like in your installation?

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

1.5.19: Problem with ssh

[Eric Surjawinata]

Hi,

I have problems ssh-ing to a cygwin installed on Windows xp. I know
this is an old issue, however I scoured all the past issues with this
and have not found a solution that worked for me (short of finding an
older cygwin release and re-installing).

Basically I installed Cygwin 1.5.19 and done all of the followings:

install ssh, privilege separation=no, CYGWIN= ntsec tty content of:


original passwd:



SYSTEM:*:18:544:,S-1-5-18::

Administrators:*:544:544:,S-1-5-32-544::

Administrator:unused_by_nt/2000/xp:500:513:U-LT-ESURJAWINATA\Administrator,S-1-5-21-2801439982-2106517767-3757435101-500:/home/Administrator:/bin/bash

ASPNET:unused_by_nt/2000/xp:1010:513:ASP.NET Machine
Account,U-LT-ESURJAWINATA\ASPNET,S-1-5-21-2801439982-2106517767-3757435101-1010:/home/ASPNET:/bin/bash

Guest:unused_by_nt/2000/xp:501:513:U-LT-ESURJAWINATA\Guest,S-1-5-21-2801439982-2106517767-3757435101-501:/home/Guest:/bin/bash

HelpAssistant:unused_by_nt/2000/xp:1007:513:Remote Desktop Help
Assistant 
Account,U-LT-ESURJAWINATA\HelpAssistant,S-1-5-21-2801439982-2106517767-3757435101-1007:/home/HelpAssistant:/bin/bash

MI_Viewer:unused_by_nt/2000/xp:1011:513:MI_Viewer,U-LT-ESURJAWINATA\MI_Viewer,S-1-5-21-2801439982-2106517767-3757435101-1011:/home/MI_Viewer:/bin/bash

sshd:unused_by_nt/2000/xp:1009:513:sshd
privsep,U-LT-ESURJAWINATA\sshd,S-1-5-21-2801439982-2106517767-3757435101-1009:/var/empty:/bin/bash

SUPPORT_388945a0:unused_by_nt/2000/xp:1002:513:CN=Microsoft
Corporation,L=Redmond,S=Washington,C=US,U-LT-ESURJAWINATA\SUPPORT_388945a0,S-1-5-21-2801439982-2106517767-3757435101-1002:/home/SUPPORT_388945a0:/bin/bash

esurjawinata:unused_by_nt/2000/xp:20854:10545:esurjawinata,U-MERC-NET\esurjawinata,S-1-5-21-1788835140-1754742977-925700815-10854:/cygdrive/c/Documents
and Settings/esurjawinata:/bin/bash



original group:



root:S-1-5-32-544:0:

SYSTEM:S-1-5-18:18:

None:S-1-5-21-2801439982-2106517767-3757435101-513:513:

Administrators:S-1-5-32-544:544:

Backup Operators:S-1-5-32-551:551:

Guests:S-1-5-32-546:546:

Network Configuration Operators:S-1-5-32-556:556:

Power Users:S-1-5-32-547:547:

Remote Desktop Users:S-1-5-32-555:555:

Replicator:S-1-5-32-552:552:

Users:S-1-5-32-545:545:

HelpServicesGroup:S-1-5-21-2801439982-2106517767-3757435101-1001:1001:

ORA_DBA:S-1-5-21-2801439982-2106517767-3757435101-1008:1008:

mkgroup-l-d:S-1-5-32-545:10545:



ran mkpasswd –l


SYSTEM:*:18:544:,S-1-5-18::

Administrators:*:544:544:,S-1-5-32-544::

Administrator:unused_by_nt/2000/xp:500:513:U-LT-ESURJAWINATA\Administrator,S-1-5

-21-2801439982-2106517767-3757435101-500:/home/Administrator:/bin/bash

ASPNET:unused_by_nt/2000/xp:1010:513:ASP.NET Machine Account,U-LT-ESURJAWINATA\A

SPNET,S-1-5-21-2801439982-2106517767-3757435101-1010:/home/ASPNET:/bin/bash

Guest:unused_by_nt/2000/xp:501:513:U-LT-ESURJAWINATA\Guest,S-1-5-21-2801439982-2

106517767-3757435101-501:/home/Guest:/bin/bash

HelpAssistant:unused_by_nt/2000/xp:1007:513:Remote Desktop Help Assistant Accoun

t,U-LT-ESURJAWINATA\HelpAssistant,S-1-5-21-2801439982-2106517767-3757435101-1007

:/home/HelpAssistant:/bin/bash

MI_Viewer:unused_by_nt/2000/xp:1011:513:MI_Viewer,U-LT-ESURJAWINATA\MI_Viewer,S-

1-5-21-2801439982-2106517767-3757435101-1011:/home/MI_Viewer:/bin/bash

sshd:unused_by_nt/2000/xp:1009:513:sshd privsep,U-LT-ESURJAWINATA\sshd,S-1-5-21-

2801439982-2106517767-3757435101-1009:/var/empty:/bin/bash

SUPPORT_388945a0:unused_by_nt/2000/xp:1002:513:CN=Microsoft Corporation,L=Redmon

d,S=Washington,C=US,U-LT-ESURJAWINATA\SUPPORT_388945a0,S-1-5-21-2801439982-21065

17767-3757435101-1002:/home/SUPPORT_388945a0:/bin/bash



ran mkpasswd –d –u esurjawinata (for the users I want to use to ssh)


esurjawinata:unused_by_nt/2000/xp:20854:10513:Eric Surjawinata,U-MERC-NET\esurja

winata,S-1-5-21-1788835140-1754742977-925700815-10854://supernova/home2/esurjawi

nata:/bin/bash



ran mkpasswd –d (result too many too list)


observation: no group for '20854', one group for '10513'

Domain Users:S-1-5-21-1788835140-1754742977-925700815-513:10513:



Tried editing passwd and group manually, adding both group 513 and 10513
Tried editing primary group for user esurjawinata to 513, and 10513


Output from ssh –v

$ ssh -v [EMAIL PROTECTED]

OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005

debug1: Reading configuration data /etc/ssh_config

debug1: Connecting to lt-esurjawinata [192.168.13.52] port 22.

debug1: Connection established.

debug1: identity file /cygdrive/c/Documents and Settings/esurjawinata/.ssh/ident

ity type -1

debug1: identity file /cygdrive/c/Documents and Settings/esurjawinata/.ssh/id_rs

a type -1

debug1: identity file /cygdrive/c/Documents and Settings/esurjawinata/.ssh/id_ds

a type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.3

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

deb

Re: Cygwin: texi2dvi stumbles over texinfo.tex

[Ralf Wildenhues]

Hi Dave,

* Dave Korn wrote on Tue, May 23, 2006 at 03:41:51PM CEST:
> On 23 May 2006 13:13, Ralf Wildenhues wrote:
> 
> [ As per cygwin-L tradition, I am replying only to the lists; Ralf, if you see
> this and Karl does not, please feel free to forward it. ]

I'm sure Karl reads bug-texinfo; he may just be busy with more important
issues ATM.  And I guess there was some moderation latency for
bug-automake.

> >> I believe it's a Cygwin problem and/or TeX installation problem on the
> >> particular machine.  In essence, texi2dvi is doing this:
> >>   echo '\input texinfo @bye' >txiversion.tex
> >>   tex txiversion.tex
> >> 
> >> The error message from TeX means that the binary ("tex", which was
> >> hardwired) being run is trying to load a .fmt that was written by
> >> something else ("etex").  It has nothing to do with the contents of the
> >> file.  
> 
>   Ok, you got me curious.  How does TeX know what application wrote the file
> if it's not "to do with" the contents of that file?

I can't answer this.

>   However, I've observed problems with cygwin's web2c/... files before, the
> perms can get messed up somehow and need chowning; they can end up owned by
> 'None', which means that everyone gets the O (out of UGO) perms, which in a
> lot of cases are '---', ie. access for user and group only.  See 
> 
> http://www.cygwin.com/ml/cygwin/2004-03/msg00454.html
> 
> for more; I don't know if this is the cause of your problem but I
> guess it's worth checking the perms on the relevant machine.

Well, that would have been nice if it were the cause of the problem.
Alas, for me it isn't: I'm both the only user and the administrator and
installer of my Cygwin installation, which exists solely to make sure
some supposed-to-be portable software continues to run there as well.

Making all files and directories below /var/lib/texmf and
/usr/share/texmf owned, readable, and writable by the right users and
groups did not help one bit.  Removing etex.fmt and rerunning
$ texi2dvi textutils.texi

manually led to this output, pasted below, and still no DVI.  Although
still PDF builds fine.  If I'm to try something different, please bear
in mind that, to date, I've been blissfully ignorant of how TeX
installations work, mostly because they've always worked for me.

Cheers, and thanks for your help,
Ralf

This is e-TeXk, Version 3.141592-2.2 (Web2C 7.5.4)
 file:line:error style messages enabled.
 %&-line parsing enabled.
---! /home/ralf/.texmf/var/web2c/etex.fmt was written by pdfetex
(Fatal format file error; I'm stymied)
kpathsea: Running mktexfmt etex.fmt
fmtutil: running `pdfetex -ini   -jobname=etex -progname=etex -translate-file=cp
227.tcx *etex.ini' ...
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) (INITEX)
 file:line:error style messages enabled.
 %&-line parsing enabled.
 (/usr/share/texmf/web2c/cp227.tcx)
entering extended mode
(/usr/share/texmf/tex/plain/config/etex.ini
(/usr/share/texmf/tex/generic/config/pdftexconfig.tex)
(/usr/share/texmf/tex/plain/etex/etex.src
(/usr/share/texmf/tex/plain/base/plain.tex Preloading the plain format: codes,
registers, parameters, fonts, more fonts, macros, math definitions,
output routines, hyphenation (/usr/share/texmf/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texmf/tex/plain/etex/etexdefs.lib Skipping module "grouptypes";
Loading module "interactionmodes"; Skipping module "nodetypes";
Skipping module "iftypes";) (/usr/share/texmf/tex/plain/config/language.def
(/usr/share/texmf/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended register allocation;
Recycling: \addlanguage, [EMAIL PROTECTED] (not defined), [EMAIL PROTECTED], 
[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED] (not defined), [EMAIL PROTECTED] (not defined), [EMAIL 
PROTECTED] (not defined),
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
Retaining: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]@@d, [EMAIL PROTECTED]@ad, [EMAIL PROTECTED], [EMAIL 
PROTECTED], [EMAIL PROTECTED], \eTeX, \etexhdrchk,
\etexstatus, \module, \uselanguage, [EMAIL PROTECTED], [EMAIL PROTECTED],) )
Beginning to dump on file etex.fmt
 (format=etex 2006.5.24)
2658 strings of total length 38086
7953 memory locations dumped; current usage is 197&7289
1176 multiletter control sequences
\font\nullfont=nullfont
\font\tenrm=cmr10
\font\preloaded=cmr9
\font\preloaded=cmr8
\font\sevenrm=cmr7
\font\preloaded=cmr6
\font\fiverm=cmr5
\font\teni=cmmi10
\font\preloaded=cmmi9
\font\preloaded=cmmi8
\font\seveni=cmmi7
\font\preloaded=cmmi6
\font\fivei=cmmi5
\font\tensy

Cygwin, gdb and SEH [was RE: 1.5.19: changes have broken Qt3]

[Dave Korn]

On 24 May 2006 17:13, Ralf Habacker wrote:

> Brian Dessent schrieb:
>> Ralf Habacker wrote:
>> 
>> And yes, it used to be that gdb was too dumb to recognise that these
>> faults in IsBadReadPtr were not actual faults, and it would print them
>> as spurious SIGSEGVs, just as it currently does for "myfault"s.  Then it
>> was patched to ignore faults in kernel32.dll.  Now that the handler is
>> in cygwin1.dll, it had to be taught to ignore faults there too, and if
>> you use a CVS GDB, it does.
> 
> This kind of exceptions are handled complete in cygwin itself. Is there
> no way to limit this exceptions to the cygwin library itself and to hide
> them to the rest ?

I'm going to have to start shouting now, because you
clearly can't hear or aren't listening to anything that's being said. 

  YES, THERE IS A WAY!

  WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS
THREAD! 

  THE WAY IS TO USE AN UP-TO-DATE GDB!

  

  You have everything back to front.  The problem is not for cygwin to hide
these exceptions from gdb; the problem is for gdb not to jump in ahead of
cygwin and intercept them.  *That* is why fixing gdb is the right thing.

> This way exceptions are handled looks to me like a specific
> implementation detail, which will worry users more than that it helps to
> find problems in an application.

  Yes, that is why GDB has been patched.  However, there is no way on earth
that an old out-of-date gdb could know about some trick that was only
introduced into the cygwin source years later.  We aim for backward
compatibility, forward is trickier.

> You may say to, this has to be done by gdb, but what about strace ? Do I
> need to run strace through gdb to avoid such exception messages ? Or
> will strace be patched too to hide such messages ?

  Learn to use "grep -v" or RTFM about the --mask option to strace.  The fact
that *you* do not want to see these messages does not mean they are not useful
for others.

> Remember the previously listed examples where those messages occupies
> about 70% of the whole output of an straced application.

  If you attempt to misuse strace as a tool for debugging your applications,
you will run into this kind of problem, and it will be your fault.  RTFM:

http://cygwin.com/cygwin-ug-net/using-utils.html#strace

quite clearly states "This program is mainly useful for debugging the Cygwin
DLL itself."

> Because this exception addresses are located in the cygwin dll it will
> produce many, many obsolate support requests to the cygwin mailing list
> (as I was faced)

  See, this is the *real* problem: you read an obscure internal debugging
message emitted by what is effectively a kernel debugging tool, but then you
just guessed at what it signified, instead of finding out.  The leap to the
false conclusion was yours.

> and will stresses the support people instead that they

  LOL!  What support people?  There are none.

> can give support for the real problems and will eat time from the
> developer.

  You appear to be under the same misunderstanding as the guy from yesterday
who thought cygwin might have a use for "market research".  There is no
company, no support team, and any developers whose employers might assign them
to work on anything related to cygwin are under no obligation to work on other
people's problems.

> And what about the usage of other windows debuggers ? Does they have
> also such specific exception hiding support ? If not will there be a
> manual how to disable this internal messages ?

  Cygwin does not support the use of "other" debuggers.  Cygwin is based
around the GNU toolchain.  We do not attempt compatibility with MSVC or
WinDbg.

> As summary, I don't think that patching gdb is the best solution.

  However your conclusions are based on a faulty understanding of the
situation:

> It
> would be better to limit these exception to the cygwin dll and to hide
> this message to the rest.

  The issue is not "limiting" the exceptions, which are already and always
have been innately limited by their very nature; nothing further up the stack
than the SEH handler frame will ever know the slightest thing about them.  It
is only when a *DEBUGGER* is controlling the flow of the program that it is
even *possible* for anything to get in there ahead of the standard win32
exception handling mechanism that cygwin is already using to do what you ask.

  I recommend you do not post to this thread again until you have read 

1)  The cygwin user guide 
2)  The cygwin FAQ
3)  The MSDN documentation about __try ... __except
3)  Matt Pietrek's classic article from MSJ '97 about the internals of SEH.

because you're just repeating yourself now.

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


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

RE: No postnews or other Usenet news utilities?

[Dave Korn]

On 24 May 2006 18:38, Bruce Wehr wrote:

> First, a little background.  I am currently selling some rare Pokemon cards
> on eBay ... this is an item that has universal appeal.  

  LIAR.  You cannot claim that every single usenet reader in the entire world
is interested in Pokemon.  You are just projecting your own personal selfish
interests on to the rest of the world, because you have a financial advantage
if you pretend that everyone is like you.

> So, I'd like to
> advertise my sale in all of the *.forsale Usenet newsgroups, including all
> the regional groups.  (Whether or not my ads would be considered spam is
> another issue and is debatable, since I'm not indiscriminately posting to
> all newsgroups, but to appropriately selected groups.)

  GARBAGE.  You are UNQUESTIONABLY a spammer and there is absolutely nothing
to debate.  How can you say "all of the forsale groups" and say that's not
indiscriminate?  It's not up to YOU to decide whether a given post is
"appropriate" or not in a given group: the group has existed for a long time
before you came around and has pre-existing standards, customs and rules that
define what is or is not "appropriate".  You clearly intend to ignore all
these uncomfortable facts because you believe you are king of the world and
that whatever you say automatically becomes true.

> currently using Xnews on Windows (God, please give me a job where I don't
> have to use Windows! :).  Wow - there must be *hundreds* of *.forsale
> groups!

  MOST OF WHICH ARE RELATED TO ONE LOCAL AREA OR SPECIFIC KIND OF GOODS.

  http://www.faqs.org/faqs/misc-forsale-faq/posting-ads/section-5.html

> Anyway, Xnews has an arbitrary limit on cross posting to 20 groups at a
> time.  

  It's not arbitrary, it's an attempt to stop spammers like yourself from
exceeding the BI>20 definition of spam.  (If you don't know what that means,
then you don't know what the definition of spam is, so how the hell can you
claim to know whether you are spamming or not?)

>  Yesterday, I spent quite a bit of time going through all the
> *.forsale groups, selecting 20 at a time, excluding item specific ones (like
> computers or homes) and sending my ad.  It took quite a bit of time and was
> insanely repetitive.  Imagine my surprise when I used Google Groups today to
> search Usenet, only to find that my articles never made it out!  
> 
> The only thing I can think of is that the NNTP server I used has a cross
> posting limit, too, of likely less than 20 groups.  If so, Xnews never let
> me know that it got any error responses from the server, and I didn't pay
> attention to the Xnews server status line as I was doing all this posting.

  Either that, or you have been cancelled by the usenet anti-spam bots for
your spamming.  Carry on and it will be your ISP disconnecting you next.

> So, I fire up my bash shell and look around at my Cygwin setup.  Huh - no
> postnews.  Huh - no newsreader.  Huh - I'll have to run Cygwin setup and get
> these things.  Huh?!  What?! No postnews?  nntpd?  No newsreaders but tin?!
> No other Usenet utilities?  What the f ... ?!

  This isn't actually true but the last thing on earth I want to do is offer
any assistance to a spammer.

>   So, all of this leads to my Cygwin question(s): Am I just being
> blind, or are there truly no Usenet utilities available for Cygwin?  If not,
> are there any plans to add them in the future?

  There are certainly no mail-bombing or spamming utilities for cygwin.

> Thanks for your time, and apologies for being so long winded.  Take care and
> God bless.

  Spamming is a sin; it is selfishness and arrogance to the point of
solipsism.  Stop it today.  READ the faq:

http://www.faqs.org/faqs/misc-forsale-faq/posting-ads/

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


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

No postnews or other Usenet news utilities?

[Bruce Wehr]

Hello,
 
Though I am an experienced Unix user (and former admin), I am a relatively
new Cygwin user, so this may be a newbie question.  I swear I did my due
diligence, and am surprised this issue has not been raised in the mailing
list archives. (At least, not that I could find.)
 
First, a little background.  I am currently selling some rare Pokemon cards
on eBay ... this is an item that has universal appeal.  So, I'd like to
advertise my sale in all of the *.forsale Usenet newsgroups, including all
the regional groups.  (Whether or not my ads would be considered spam is
another issue and is debatable, since I'm not indiscriminately posting to
all newsgroups, but to appropriately selected groups.) For a newsreader, I'm
currently using Xnews on Windows (God, please give me a job where I don't
have to use Windows! :).  Wow - there must be *hundreds* of *.forsale
groups!
 
Anyway, Xnews has an arbitrary limit on cross posting to 20 groups at a
time.  Yesterday, I spent quite a bit of time going through all the
*.forsale groups, selecting 20 at a time, excluding item specific ones (like
computers or homes) and sending my ad.  It took quite a bit of time and was
insanely repetitive.  Imagine my surprise when I used Google Groups today to
search Usenet, only to find that my articles never made it out!  
 
The only thing I can think of is that the NNTP server I used has a cross
posting limit, too, of likely less than 20 groups.  If so, Xnews never let
me know that it got any error responses from the server, and I didn't pay
attention to the Xnews server status line as I was doing all this posting.
 
"No problem," I thought.  "I'll just go to Cygwin and use postnews."  I
always go to Cygwin whenever I want to use vi, do some simple text
processing, I'm feeling nostalgic for my good ol' days of using Unix on a
daily basis, or I'm simply pining to see that bash shell prompt just one
more time .  I always go to Cygwin whenever there's something I want
to do that Windows is just too brain dead to handle. (And, none of these
things are terribly complicated things either.  A *pox* on Microsoft! I'd
rather be at home on my Mac! But, I've been working a lot of OT ... :)
 
So, I fire up my bash shell and look around at my Cygwin setup.  Huh - no
postnews.  Huh - no newsreader.  Huh - I'll have to run Cygwin setup and get
these things.  Huh?!  What?! No postnews?  nntpd?  No newsreaders but tin?!
No other Usenet utilities?  What the f ... ?!
 
Okay, maybe tin will be my savior, if it has a command line mode that will
let me post an article.  Then, I can write a script around it and automate
my postings, one group at a time, so I'm not cross posting at all.  So, I
download and install tin.  But, but ... yeah, tin has a "batch" mode - but,
that only lets me check to see if there's any new news or not - it has no
command line post mode!
 
  So, all of this leads to my Cygwin question(s): Am I just being
blind, or are there truly no Usenet utilities available for Cygwin?  If not,
are there any plans to add them in the future?
 
Thanks for your time, and apologies for being so long winded.  Take care and
God bless.
 
---
<>< Bruce Wehr
[EMAIL PROTECTED]




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

Problems with cygwin, "expect" and ssh

[Stepp, Charles]

I have found some interesting behavior regarding the cygwin expect/ssh
problem. I used the little expect script
That Corinna created. It seemed to not see the prompt for the password
from the spawned ssh, so it just timed out. But, when I redirect the
stderr to /dev/null, it behaves correctly. Perhaps ssh is spitting some
spurious bytes to stderr that are causing the expect pattern to not
match:


GOOD:
[EMAIL PROTECTED] ~
$ ./sshtest 2>/dev/null
spawn ssh -t 10.65.16.41 
Before expect for assword:
[EMAIL PROTECTED]'s password: Found assword:
Before send of password
After send of password

Last login: Thu Jan 01 1970 00:00:00 from 

[==]
 Use of this system is explicitly limited to employees...


-
BAD:
[EMAIL PROTECTED] ~
$ ./sshtest 
spawn ssh -t  
Before expect for assword:
[EMAIL PROTECTED]'s password: Spawning failed

[EMAIL PROTECTED] ~


---
SCRIPT:
cat sshtest
#!/usr/bin/expect -f
set timeout 10

spawn ssh -t 
puts "Before expect for assword:"
expect {
  "*assword:" {
puts "Found assword:"
sleep 2
  }
  default {
send_user "Spawning failed\n"
exit
  }
}

puts "Before send of password"
send "xxx\r"
puts "After send of password"
expect {
  -re ".*\\$.* " { }
  default {
send_user "Sending password failed\n"
exit
  }
}

send "ls\n"
expect {
  -re ".*\\$.* " { }
  default {
send_user "Sending ls failed\n"
exit
  }
}

send "exit\n"
expect {
  -re ".*Connection to mycygwinbox closed.*" { }
  default {
send_user "Sending exit failed\n"
exit
  }
}

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

Re: 1.5.19: changes have broken Qt3

[Ralf Habacker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Dessent schrieb:
> Ralf Habacker wrote:
> 
> And yes, it used to be that gdb was too dumb to recognise that these
> faults in IsBadReadPtr were not actual faults, and it would print them
> as spurious SIGSEGVs, just as it currently does for "myfault"s.  Then it
> was patched to ignore faults in kernel32.dll.  Now that the handler is
> in cygwin1.dll, it had to be taught to ignore faults there too, and if
> you use a CVS GDB, it does.

This kind of exceptions are handled complete in cygwin itself. Is there
no way to limit this exceptions to the cygwin library itself and to hide
them to the rest ?

This way exceptions are handled looks to me like a specific
implementation detail, which will worry users more than that it helps to
find problems in an application.

And what about debugging cygwin itself ? It looks to me that disabling
of this exception handling code must be possible ?

You may say to, this has to be done by gdb, but what about strace ? Do I
need to run strace through gdb to avoid such exception messages ? Or
will strace be patched too to hide such messages ?

Remember the previously listed examples where those messages occupies
about 70% of the whole output of an straced application.
Because this exception addresses are located in the cygwin dll it will
produce many, many obsolate support requests to the cygwin mailing list
(as I was faced) and will stresses the support people instead that they
can give support for the real problems and will eat time from the
developer.

And what about the usage of other windows debuggers ? Does they have
also such specific exception hiding support ? If not will there be a
manual how to disable this internal messages ?

As summary, I don't think that patching gdb is the best solution. It
would be better to limit these exception to the cygwin dll and to hide
this message to the rest.

May be an option in the cygwin or other environment var to enable such
message for debugging purpose will be useful.

Regards
Ralf

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdIYToHh+5t8EXncRAjT8AJ4tnrVX6EDj5rynw8MPgd5TXAWeBwCfXVrU
wogfOq23tMiXfHoUTKorKR8=
=J6R+
-END PGP SIGNATURE-

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

Re: 1.5.19: changes have broken Qt3

[Ralf Habacker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Habacker schrieb:
> Hi all,
>  
> If this would be my project I would add such unit test cases as far as
> possible. Because pthread-win32 is also hosted on sources.redhat.com it
> may be possible to relicense the test application to cygwin easier as
> other external sources.
> 

No need for this, the related pthread functions are already in the cvs
dir. See src/winsup/testsuite

Running
/home/Habacker/src/extern/cygwin.com/src/winsup/testsuite/winsup.api/cygload.exp
...
FAIL: cygload (execute)
Running
/home/Habacker/src/extern/cygwin.com/src/winsup/testsuite/winsup.api/winsup.exp
...
FAIL: msgtest.c (execute)
FAIL: resethand.c (execute)
FAIL: semtest.c (execute)
FAIL: shmtest.c (execute)

=== winsup Summary ===

# of expected passes270
# of unexpected failures5
# of expected failures  8


Regards
 Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdH0GoHh+5t8EXncRAoesAJ4gHbZ2OKdciNcj/9sChnAkKAP7RwCeM/XW
t2kzO62zKpUx4KoNtareNVQ=
=5g6q
-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: rsh with command hangs, rlogin works

[Lars Björnfot]

Andrew DeFaria wrote:
> You created? By hand. Or did you use ssh-host-config. Perhaps the sshd
user you created was for privilege separation?

I used ssh-host-config. You're right about sshd too.

> If Local System account is toggle then you are using SYSTEM.

Checked, it's SYSTEM.


>Local:grep -e rsh -e rlogin /etc/inetd.conf
>shell   stream  tcp nowait  root/usr/sbin/in.rshd in.rshd -L
>login   stream  tcp nowait  root/usr/sbin/in.rlogind in.rlogind
>Local:ll /usr/sbin/in.r*
>-rwxr-x---+ 1 defaria Users  9728 Jan 13 02:19 /usr/sbin/in.rexecd.exe*
>-rwxr-x---+ 1 defaria Users 11264 Jan 13 02:19 /usr/sbin/in.rlogind.exe*
>-rwxr-x---+ 1 defaria Users 11264 Jan 13 02:19 /usr/sbin/in.rshd.exe*

$ ls -l /usr/sbin/in.r*
-rwxr-xr-x+ 1 lars Användare  9728 Jan 13 11:19 /usr/sbin/in.rexecd.exe
-rwxr-xr-x+ 1 lars Användare 11264 Jan 13 11:19 /usr/sbin/in.rlogind.exe
-rwxr-xr-x+ 1 lars Användare 11264 Jan 13 11:19 /usr/sbin/in.rshd.exe

Just minor diffs and same for all in.* programs.
I tried chmod 750 with no different result.

But I was more thinking if a file which only in.rshd.exe uses,
and potential problems with _it's_ contents or permissions.
Can't think of any such file though.

>You do realize that if you hope to have rsh be able to remotely
>execute a command you need to configure it such that you can login
>without a password (~/.rhosts or remove your password from your entry
>in /etc/passwd).

Yes, and "rsh localhost" lets me in without typing password, using
~/.rhosts .

>Wait a second. This just in. On my XP Pro desktop here at work
>I have the same situation! rsh localhost works but rsh localhost id
>doesn't! What's going on here? rsh localhost prompts me for a password.
>But rsh localhost id just hangs...

With no .rhosts, wrong permission, or wrong content it prompts me for
password (like it should).

Great that it hangs! At least it increases the chance that either of
us finds a solution. :-)

Lars



--
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: ld terminated with signal 11 [seg fault]

[Dave Korn]

On 23 May 2006 23:22, Michael Williamson wrote:

> The linker crashes when I try to compile the
> camera software LinuxDevKit.tar for SBIG cameras:
> 
> g++ -I . -L . -Wall -o testapp testmain.cpp
> csbigcam.cpp
>   -csbingimg.cpp -lsbigudrv
> collect2: ld terminated with signal 11 [Segmentation
> fault],  core dumped
> 
> Why does this happened?

  There could be a bug in ld.  Or you could be feeding it bad data.  Ot your
computer could have a hardware fault.  It might be worth trying a more recent
binutils version.  Or it might not; you didn't follow the problem-reporting
guidelines so I don't know.

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


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

RE: export arrays from cygwin ksh

[Dave Korn]

On 24 May 2006 09:24, Thorsten Kampe wrote:

> * mwoehlke (2006-05-23 16:37 +)
>> It does seem like this doesn't work - at least, not how I would expect
>> it to - on bash (either on Cygwin or on Linux). Maybe you should try ksh
>> on Cygwin.
> 
> He said he did. Read the subject of this thread.


  Yes, but it turned out to be a misnamed copy of bash.  Read the *content* of
this thread!

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


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

Re: 1.15.19 dlopen() dies with no dlerror()

[Larry Hall (Cygwin)]

Jim Kleckner wrote:



Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:



Larry Hall (Cygwin) wrote:

Jim Kleckner wrote:

Jim Kleckner wrote:

Michael McKerns wrote:

Yes, yes...  I've not given you enough information...
...
See:
http://cygwin.com/cygwin-ug-net/dll.html
http://cygwin.com/faq.html#faq.programming.dll-relocatable
  
I'm seeing a similar problem with python and 1.5.19 and also tried 
the snapshot of 22-May.


CYGWIN_NT-5.1 kleckner2 1.5.20s(0.155/4/2) 20060522 00:51:23 i686 
Cygwin


A simple test case doesn't fail in dlopen().

My code is not simple but has been working prior to the most 
recent update (which also updated python and other packages).
A downrev of python does not make the problem go away.  If I 
downrev cygwin, I get complaints about missing entry points.


What do you recommend as the best way to isolate this?


I tried using "prev" with setup.exe but that didn't make the 
problem go away.


A simple test case with python access to a trivial function works 
fine (can supply if anyone wants).

The complex dll that used to work simply doesn't return from dlopen.

I downloaded the 20060522 snapshot with debug symbols to get a 
backtrace with GDB.
GDB says there is a seg fault and somehow this is preventing any 
information from reaching dlerror().
Without the dlerror() info, it is hard to figure out what needs to 
change with the dll.

It appears that some constructors are having trouble.

Let me know if there is some single stepping that could be helpful.
[snip]
(gdb) bt
#0  0x610b1ff8 in pthread_key_create (key=0x6622f8, destructor=0) at 

^^^
Known issue already fixed in the Cygwin snapshot and in GDB's CVS.  
This

is not fatal.  Just continue until you stop seeing this complaint.



As noted above, this was tested using snapshot 20060522. Should that 
snapshot have the fix you mention?  If it should, then this problem 
still exists in that snapshot.

If not, then which one should I test?


The part of the fix that is Cygwin-specific is in the Cygwin snapshot you
have.  But, like I said, there's another part of the fix that's only in
GDB's CVS version right now.  If you want to be rid of the problem 
right now,
you need both changes and that means you'll need to grab GDB's source 
from

CVS and build it.  But whether you choose to do this or not should not
inhibit your original investigation.  Depending on how many times your
code path takes you through pthread_ket_create(), it may test test your
tolerance level for the current work-around though. ;-)

Thanks for pointing me into the GDB and SIGSEGV discussions.
I didn't see the relationship to the dlopen() problem.

I didn't see discussion of a fix to python which has failing
dlopen() calls presumably because of initializations of mutex objects.
Does python need to do what GDB now does?

Is there a workaround/snapshot in the meantime?


I think if you follow this thread, your questions will be answered.



--
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: export arrays from cygwin ksh

[mwoehlke]

Thorsten Kampe wrote:

* mwoehlke (2006-05-23 16:37 +)
It does seem like this doesn't work - at least, not how I would expect 
it to - on bash (either on Cygwin or on Linux). Maybe you should try ksh 
on Cygwin.


He said he did. Read the subject of this thread.


Sorry, my apologies...
(Maybe he should try the *right* ksh? ;-) ...as per the second instance 
of this thread.)


--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: Visibility of Samba shares after ssh login

[mwoehlke]

, also TOFU reformatted...

Guenter wrote:

mwoehlke wrote:

Guenter Bachler wrote:

I started the ssh-server on the windows client in order to log-on
to a Linux maschine and vice verse. On the Windows client several
SAMBA shares have been mapped and correctly displayed with the
'mount' command  in the cygwin shell.

Now invoking an ssh login session from the Linux machine on the 
Windows client (under my regular Windows account), the mount

command does not display the SAMBA shares anymore (beginning
with drive letters k)

Is there any simple procedure to remount all SAMBA shares 
automatically in the ssh session?


[snip]
Anyway, does 'net use' on your ssh session show all the "missing" 
drives as "unavailable"?


Yes, 'net use' lists all missing drives as 'unavailable'. 


Ok, that's expected (but helps confirm what's going on).


I am currently playing with a python script using
wshnw.MapNetworkDrive to re-map the network connections.
It starts to work but there are still some error messages
concerning denied access to the samba shares. 


Well, without knowing what those errors are, we can't do much to
help.

You could also try something like the solution I posted in follow-up
to my previous message...

--
Matthew
Doom doom dooM doo-DooM dOOm DOom doOM... DOOM! -- Gir


--
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: incorrect time stamps (ls)?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lester Ingber on 5/23/2006 11:01 PM:
> Sorry, the attachment wasn't in the last email.
> 
> I am seeing date stamps at future dates:
> 21:48:21 @lester:/cygdrive/d/Diagoran% ls -l
> total 1676
> dr-x-- 8 ingber None   0 Apr 22  2009 DI/
> 21:48:24 @lester:/cygdrive/d/Diagoran% ls -lu
> total 1676
> dr-x-- 8 ingber None   0 Dec 31  1969 DI/

According to the above output, some of your files have mtime in the
future, but atime in the past.  That seems odd, since usually modifying a
file also changes the access time.

So, what does 'stat /cygdrive/d/Diagoran/DI' show?  That is a faster way
to see the full timestamps that cygwin keeps track of, rather than using
multiple ls calls for truncated timestamps.

> 
> However, under My Computer or under Windows Explorer, I see correct dates,
> all with year 2006 (for both Date Created and Date Modified).
> 

Date Created does not correspond to atime (access time), mtime
(modification time - file contents changed), or ctime (ctime stands for
change time, ie. the last time the file contents or metadata, such as
owner or permissions, changed; and while touch can change fake atime or
mtime to any arbitrary timestamp, it is unable to alter ctime from when
the change took place); it is a fourth date stamp that NTFS keeps and
cygwin ignores.  On limited filesystems, such as FAT, which do not keep a
ctime stamp, cygwin uses the modification time for both mtime and ctime,
which is as close as we can get to POSIX without exposing weird bugs on
Win9x machines.  But I would expect cygwin's notion of mtime to match
Windows Date Modified time, and the atime to match Windows Date Accessed
time.  And the Windows GUI doesn't really have a good view into the NTFS
change time, so on filesystems where change time and modification time are
distinct, cygwin is the easiest way I know to see the last file change time.

> 
> Path: C:\cygwin\usr\local\bin
...
>   c:\Program
>   Files\Windows
>   Resource
>   Kits\Tools\

Your path turned out weird, but that is not the issue here.

> d:  cd  CDFS   199Mb 100%CS UN   NEW

OK, so drive D is a CDROM; perhaps Windows is giving bogus information
back when cygwin asks windows about timestamps on files on the CD?  I
would have to investigate more, but that may be a cygwin bug.  Also, would
you be willing to try a snapshot, as several file handling changes have
been committed that will eventually be part of cygwin 1.5.20, perhaps one
of them affects CD timestamps:
http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots

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

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

iD8DBQFEdFLa84KuGfSFAYARAsZKAJ9JQ8WhbXpBYp+CA77l+OMv2PjE7gCfU2IH
QTM9FG+RSfI46z++IbukZ+U=
=yzX1
-END PGP SIGNATURE-

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

RE: 1.5.19: changes have broken Qt3

[Dave Korn]

On 24 May 2006 13:19, Ralf Habacker wrote:

> This breakpoint is never reached (at least in released gdb) and makes it
> hard to debug cygwin's threading stuff, probably impossible in this area.

  How many times do you have to be told?  The last released gdb is known to
not cope with this.  IT IS A KNOWN BUG.  IT HAS BEEN FIXED.

  No, nobody has yet been able to travel backward in time and fix it in
earlier versions of gdb from before the bug was fixed.  Sorry, but this is not
the fault of the cygwin project.  Please report this to the
[EMAIL PROTECTED] mailing list!
 
> This means to be able to debug the cygwin dll in this area I have to
> recompile a special cygwin version with something like below mentioned.:

  No, in order to debug the cygwin dll you have to use UP TO DATE gdb.

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


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

RE: 1.5.19: changes have broken Qt3

[Dave Korn]

On 24 May 2006 13:07, [EMAIL PROTECTED] wrote:

> On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote:
>>> Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
>>> signal, correct? GDB does what it's told, stops on SIGSEGV by default.
>>> 
>>> -cl
>> 
>>   But it doesn't interact properly with cygwin's exception handling ->
>> signal mechanism, and the task dies, when it should just run on.
>> 
>>   Anyone who's doing any serious debugging on Cygwin very seriously wants
>> to build their own gdb and insight from current CVS.  It's much improved
>> of late. 
> 
> Right, or bless their sanity - as it won't last long. But I'm just trying to
> debate that it's no "lacking" of gdb that it's catching SIGSEGV signals
> which are being artificially generated by cygwin.

  It's not a SIGSEGV.  It's actually a protection fault, which is one variety
of exception.  Cygwin's job is to catch the faulting access using a structured
exception handler and translate it into a signal - if, and only if, the
exception does in fact represent an event that should be reported to userland
as a signal.  If, as in this case, the exception is part of cygwin's internal
access checking and should not be reported as a signal to userland, cygwin's
job is to catch the faulting access and /not/ translate it into a signal.

  Now bear in mind that we're not talking about any old version of gdb here:
we're very specifically discussing the cygwin-targeted version of gdb.  That
means it should understand about cygwin's signal handling mechanism, and it
should know that some exceptions will be translated into signals and others
will not, and it should leave cygwin to handle that and only report a SIGSEGV
(or any other kind of signal) when cygwin decides to turn a particular
exception into a signal, and not when it doesn't.  It's an old
hangover/win32-ism that it intercepts all the windows exceptions and attempts
to interpret them to the user as SIGs of some kind; might make sense if it was
attempting to debug a windows native (msvcrt-based) application, but does not
make sense for a cygwin app these days; long long ago, it was a reasonable
design compromise when gdb was first being targeted at wintel platforms.

> What's the design mechanism for the entire 'check for non-initialized space
> and segfault if uninitialized' when it comes to statically initialized
> pthreads objects in the first place, btw? Why not just have pthread_mutex_t
> (for example actually be a pthread_mutex_t instead of it being a type'd
> pointer to the real pthread_mutex_t? Why dynamically initialize space for
> it at all via the check bunk memory->throw fault->alloc real memory for
> real pthread_mutex_t as opposed to "initialiize the mutex->if bunk space,
> segfault as usual" ? 

  In order to comply with the complex way the POSIX spec allows you to have
*either* static linktime initialisation *or* dynamic runtime initialisation of
all these objects.

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


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

Re: 1.5.19: changes have broken Qt3

[Ralf Habacker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Dessent schrieb:
> Ralf Habacker wrote:
> 
>> There is no segfault, but it does not work as expected e.g.
>> pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct
>> given as parameter.
> 
> How does it not work?  The testcase runs fine for me with no assertion
> failures, neither from a prompt nor in (CVS) gdb.  Even when I modify it
> as follows:
> 
> --- pthread_mutexattr_init.c2006-05-24 02:05:52.523968000 -0700
> +++ pthread_mutexattr_init_2.c  2006-05-24 02:11:27.299406200 -0700
> @@ -9,6 +9,9 @@ main()
>  {
>assert(pthread_mutexattr_init(&mxAttr) == 0);
>assert(pthread_mutexattr_settype(&mxAttr, PTHREAD_MUTEX_ERRORCHECK)
> == 0);
> +  int t;
> +  pthread_mutexattr_gettype(&mxAttr, &t);
> +  assert(t == PTHREAD_MUTEX_ERRORCHECK);
>assert(mutex == NULL);
>assert(pthread_mutex_init(&mutex, &mxAttr) == 0);
>assert(mutex != NULL);
> 
> ...it still runs without failure.
> 
> BTW the whole "myfault" thing was devised specifically to kill the
> IsBadReadPtr() junk that was used before, so asking for that back is
> probably never going to happen.  And with good reason too, because when
> you call IsBadReadPtr is does exactly what "myfault" does, it installs a
> temporary fault handler, tries to read the memory, and then removes that
> temporary fault handler.  Except that if you call IsBadReadPtr a bunch
> of times it has to do this setup/teardown every time, instead of just
> doing it once for the entire lexical scope of the function, as with
> myfault.

Thanks for this info to understand the new exception handling in cygwin.
I was bitten last year by some thread relating problems while porting
qt3 to cygwin and had investigated some time to understand this stuff,
which has changed much in the meantime.

> And yes, it used to be that gdb was too dumb to recognise that these
> faults in IsBadReadPtr were not actual faults, and it would print them
> as spurious SIGSEGVs, just as it currently does for "myfault"s.  Then it
> was patched to ignore faults in kernel32.dll.  Now that the handler is
> in cygwin1.dll, it had to be taught to ignore faults there too, and if
> you use a CVS GDB, it does.
> 

You said that the testcase runs, yes, but do you have tried to debug the
cygwin dll with this exception handling. Please start the above
mentioned testcase in gdb and enter

b main
r
b pthread_mutexattr::pthread_mutexattr()
c

This breakpoint is never reached (at least in released gdb) and makes it
hard to debug cygwin's threading stuff, probably impossible in this area.

This means to be able to debug the cygwin dll in this area I have to
recompile a special cygwin version with something like below mentioned.:

/* FIXME: write and test process shared mutex's.  */
extern "C" int
pthread_mutexattr_init (pthread_mutexattr_t *attr)

old:
  if (pthread_mutexattr::is_good_object (attr))
return EBUSY;

new:
  if (attr && pthread_mutexattr::is_good_object (attr))
return EBUSY;

BTW: This is not to hurt anyone or to bring in miscredit anyones work.
We all try our best to make cygwin as good as possible. It is only that
in this area things could be done better :-)

Regards

Ralf

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdE8ooHh+5t8EXncRAhnRAKCfbhfNKawy70+t18zk56M3WHzuLACeJR1C
2WLX0BBt5N7efXQWuav0tNk=
=xZn9
-END PGP SIGNATURE-

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

Re: 1.5.19: changes have broken Qt3

[Brian Dessent]

[EMAIL PROTECTED] wrote:

> Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV signal,
> correct? GDB does what it's told, stops on SIGSEGV by default.

Not really.  In cases where it is checking parameters or otherwise
expects to dereference an invalid pointer, Cygwin installs a temporary
fault handler that intercepts any fault and returns the correct error
code.  If you run such code outside of gdb you get no indication of a
fault at all, just like a standard try/except block -- unlike an actual
segmentation violation where the program is terminated.  So yes, it is a
defect that gdb treats these as actual SIGSEGVs when they are actually
just part of how Cygwin works internally, and this misperception has
caused countless messages posted to this list insisting that there is
some kind of problem in Cygwin where there is none.

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: 1.5.19: changes have broken Qt3

[clayne]

On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote:
> > Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
> > signal, correct? GDB does what it's told, stops on SIGSEGV by default.
> > 
> > -cl
> 
>   But it doesn't interact properly with cygwin's exception handling -> signal
> mechanism, and the task dies, when it should just run on.
> 
>   Anyone who's doing any serious debugging on Cygwin very seriously wants to
> build their own gdb and insight from current CVS.  It's much improved of late.

Right, or bless their sanity - as it won't last long. But I'm just trying to
debate that it's no "lacking" of gdb that it's catching SIGSEGV signals which
are being artificially generated by cygwin.

What's the design mechanism for the entire 'check for non-initialized space and
segfault if uninitialized' when it comes to statically initialized pthreads
objects in the first place, btw? Why not just have pthread_mutex_t (for example
actually be a pthread_mutex_t instead of it being a type'd pointer to the real
pthread_mutex_t? Why dynamically initialize space for it at all via the check
bunk memory->throw fault->alloc real memory for real pthread_mutex_t as opposed
to "initialiize the mutex->if bunk space, segfault as usual" ?

-cl

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

Re: Re: Java program under cygwin?

[Peter Mueller]

Hi Charli and Jim,

thanks a lot for your advice! 

> An X-server provides a means for client programs (the Java app in
> question) to "draw" on the display.  I use the CygWin/X server all the
> time to do just what you are wanting to do.  Look at the second link
> down on the cygwin home page ( http://www.cygwin.com/ ).

The link really helped!

Best wishes,
Peter


-- 


Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
  Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer


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

RE: 1.5.19: changes have broken Qt3

[Dave Korn]

On 24 May 2006 11:05, [EMAIL PROTECTED] wrote:

> On Wed, May 24, 2006 at 01:49:53AM -0700, Brian Dessent wrote:
>> Sigh.  We've been through this ad nauseum in the archives.  This is how
>> it's supposed to work, there's nothing wrong here.  Gdb doesn't know any
>> better though, and reports it as a SIGSEGV, when it is not.  Did you not
>> notice that when you run the program outside of the debugger it does not
>> fault?  If you use a recent Cygwin snapshot and a gdb built from CVS you
>> see no such fault, because this defect in gdb has been fixed.
>> 
>> Brian
> 
> Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
> signal, correct? GDB does what it's told, stops on SIGSEGV by default.
> 
> -cl

  But it doesn't interact properly with cygwin's exception handling -> signal
mechanism, and the task dies, when it should just run on.

  Anyone who's doing any serious debugging on Cygwin very seriously wants to
build their own gdb and insight from current CVS.  It's much improved of late.

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


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

Re: 1.5.19: changes have broken Qt3

[clayne]

On Wed, May 24, 2006 at 01:49:53AM -0700, Brian Dessent wrote:
> Sigh.  We've been through this ad nauseum in the archives.  This is how
> it's supposed to work, there's nothing wrong here.  Gdb doesn't know any
> better though, and reports it as a SIGSEGV, when it is not.  Did you not
> notice that when you run the program outside of the debugger it does not
> fault?  If you use a recent Cygwin snapshot and a gdb built from CVS you
> see no such fault, because this defect in gdb has been fixed.
> 
> Brian

Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV signal,
correct? GDB does what it's told, stops on SIGSEGV by default.

-cl

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

Re: 1.5.19: changes have broken Qt3

[Brian Dessent]

Ralf Habacker wrote:

> There is no segfault, but it does not work as expected e.g.
> pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct
> given as parameter.

How does it not work?  The testcase runs fine for me with no assertion
failures, neither from a prompt nor in (CVS) gdb.  Even when I modify it
as follows:

--- pthread_mutexattr_init.c2006-05-24 02:05:52.523968000 -0700
+++ pthread_mutexattr_init_2.c  2006-05-24 02:11:27.299406200 -0700
@@ -9,6 +9,9 @@ main()
 {
   assert(pthread_mutexattr_init(&mxAttr) == 0);
   assert(pthread_mutexattr_settype(&mxAttr, PTHREAD_MUTEX_ERRORCHECK)
== 0);
+  int t;
+  pthread_mutexattr_gettype(&mxAttr, &t);
+  assert(t == PTHREAD_MUTEX_ERRORCHECK);
   assert(mutex == NULL);
   assert(pthread_mutex_init(&mutex, &mxAttr) == 0);
   assert(mutex != NULL);

...it still runs without failure.

BTW the whole "myfault" thing was devised specifically to kill the
IsBadReadPtr() junk that was used before, so asking for that back is
probably never going to happen.  And with good reason too, because when
you call IsBadReadPtr is does exactly what "myfault" does, it installs a
temporary fault handler, tries to read the memory, and then removes that
temporary fault handler.  Except that if you call IsBadReadPtr a bunch
of times it has to do this setup/teardown every time, instead of just
doing it once for the entire lexical scope of the function, as with
myfault.

And yes, it used to be that gdb was too dumb to recognise that these
faults in IsBadReadPtr were not actual faults, and it would print them
as spurious SIGSEGVs, just as it currently does for "myfault"s.  Then it
was patched to ignore faults in kernel32.dll.  Now that the handler is
in cygwin1.dll, it had to be taught to ignore faults there too, and if
you use a CVS GDB, it does.

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: Handling special characters (\/:*?"<>|) gracefully

[Brian Dessent]

mwoehlke wrote:

> (Speaking of case sensitivity, is it a Windows limitation that Cygwin
> can't do this? I'm pretty sure it isn't an NTFS limitation, as Interix
> has true case-sensitivity.)

As I understand it, the win32 API preserves case but is not case
sensitive.  The native API is both, so in theory an application that
used only native calls could cope with both README and Readme, but no
win32 app could.  So, from the standpoint of Cygwin this is pretty
useless as A) it would take significant code rewrites to use the native
API everywhere (not to mention backcompat hell for 9x/ME) and B) it
would lead to the situation (which we briefly got a taste of somewhere
in a past 1.5.x release) where Cygwin was able to create files that
could not be deleted by Explorer or any other regular Windows app.

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: 1.5.19: changes have broken Qt3

[Ralf Habacker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Dessent schrieb:
> Ralf Habacker wrote:
> 
>> Running this testcase results in an internal exception in
>> pthread_mutexattr_init()
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
>> ../../../../src/winsup/cygwin/thread.cc:129
>> 129   if ((*object)->magic != magic)
> 
> Sigh.  We've been through this ad nauseum in the archives.  This is how
> it's supposed to work, there's nothing wrong here.  

But in the case of pthread_mutexattr_init() this exception results in an
abort of pthread_mutexattr_init(), which should not be. See my other
mail in this thread.



> Gdb doesn't know any
> better though, and reports it as a SIGSEGV, when it is not.  Did you not
> notice that when you run the program outside of the debugger it does not
> fault?  
There is no segfault, but it does not work as expected e.g.
pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct
given as parameter.

If you use a recent Cygwin snapshot and a gdb built from CVS you
> see no such fault, because this defect in gdb has been fixed.
> 

Ralf

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdCDRoHh+5t8EXncRAkcSAJ0TpZMnh5qhSQKY8nrb688Pq4bxogCfaTG5
9LDqWxCYGtlpmm9LBrKZcac=
=2syh
-END PGP SIGNATURE-

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

Re: 1.5.19: changes have broken Qt3

[Ralf Habacker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christopher Faylor schrieb:
> On Tue, May 23, 2006 at 09:20:28PM +0200, Ralf Habacker wrote:
>> your right, hope the above mentioned stuff help for this.
> 
> Ralf,
> You have the test case.  You have the source code.  You've already
> provided a patch.  What's stopping you from determinging the cause of
> the problem now that you understand that this situation is already
> supposed to be handled?  I appreciate that you have tracked this down
> but I don't understand why you now seem to have given up at this point.

Have I said this ? I only reported about the current state in the hope
someone where bitten by the same issue and had some additional hints,
which seems not the case.

Anyway, the problem is that in

extern "C" int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
  if (pthread_mutexattr::is_good_object (attr))
return EBUSY;

  *attr = new pthread_mutexattr ();

pthread_mutexattr::is_good_object() is called, but attr does not contain
a valid object (it is created later) and the functions aborts, which
should not be.

Is there a replacement for the gone check_valid_pointer() function,
which could be added to pthread_mutexattr_init and was used before the
call to pthread_mutexattr::is_good_object() was introduced
(http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00204.html) ?

BTW: A similar problem is with

pthread_condattr_init ()
pthread_rwlockattr_init ()
pthread_attr_init ()


Regards
 Ralf

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdB/IoHh+5t8EXncRAsD/AJ9n/X9jLNaq0qoU2nFmpJpFLkks9QCeMJDM
a16WqHXFx0EjPu7HA+ORhKI=
=gRfG
-END PGP SIGNATURE-

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

Re: 1.5.19: changes have broken Qt3

[Brian Dessent]

Ralf Habacker wrote:

> Running this testcase results in an internal exception in
> pthread_mutexattr_init()
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
> ../../../../src/winsup/cygwin/thread.cc:129
> 129   if ((*object)->magic != magic)

Sigh.  We've been through this ad nauseum in the archives.  This is how
it's supposed to work, there's nothing wrong here.  Gdb doesn't know any
better though, and reports it as a SIGSEGV, when it is not.  Did you not
notice that when you run the program outside of the debugger it does not
fault?  If you use a recent Cygwin snapshot and a gdb built from CVS you
see no such fault, because this defect in gdb has been fixed.

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: export arrays from cygwin ksh

[Thorsten Kampe]

* mwoehlke (2006-05-23 16:37 +)
> It does seem like this doesn't work - at least, not how I would expect 
> it to - on bash (either on Cygwin or on Linux). Maybe you should try ksh 
> on Cygwin.

He said he did. Read the subject of this thread.


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