Re: rpcgen question

[Christian Gagneraud]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christian Gagneraud on 1/26/2006 9:41 AM:

I think that the rpcgen from RH comes from the glibc and rpcgen from
cygwin comes from the "stand alone" package "Sun RPC".

My main problem is that i was using -M option (multithread support) -N
option (allow multiple args) and that cygwin version of rpcgen doesn't
support them.

So i can't reuse my current .x file (and some glue code) in cygwin.

Is there a glibc based version of rpcgen that run with cygwin?


Cygwin does not use glibc; instead it is based on newlib.  But since
newlib and glibc both provide a similar set of functions, it may be
possible that the RH rpcgen package can be compiled on cygwin.  All I can
do is recommend trying it yourself.


Hi Eric,

On GNU/Linux, rpcgen comes from the glibc, so if cygwin is based on newlib, i 
think it should be hard to build RH's version on cygwin.


Since yesterday, i have made some investigation, and i have found that rpcgen 
comes from the same package (both on RH and cygwin), but it's a problem of version:

- RH: /* @(#)rpc.h2.4 89/07/11 4.0 RPCSRC; from 1.9 88/02/08 SMI */
- Cygwin: /* @(#)rpc.h2.3 88/08/10 4.0 RPCSRC; from 1.9 88/02/08 SMI */

And finaly, i will try to keep the generated code on linux and try to build/use 
it on cygwin... Don't know if it's a good or bad idea! :(


Christian




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

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

iD8DBQFD2adk84KuGfSFAYARAsiYAJ9EZSJeyQackjRrnkcrtT9TL1HWJQCgpcG7
F1fT5idWWGjBMwEyKuDi3lY=
=QcxD
-END PGP SIGNATURE-



--
+-+
| Chritian Gagneraud  |
|  SW Test & QA Engineer, 3G Linux Platform   |
| CELAD on behalf of Freescale Semiconductor - WBSG EMEA  |
| Phone:  33-(0)5.61.19.99.74 |
| eMail:  [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/

Re: Please assist with details regarding uninstalling [Attn FAQ maintainer]

[Corinna Vinschen]

On Jan 26 21:06, Joshua Daniel Franklin wrote:
> On 1/25/06, Reini Urban wrote:
> > postgresql is of the same kind as inetd.
> > In the recommended way the service is run via cygrunsrv, but a few
> > people might also have installed the cygwin version via pg_ctl as
> > service starter.
> > Mentioning it after apache would help a bit.
> >
> > =>
> > "sshd, cron, cygserver, inetd, apache, postgresql and so on."
> 
> OK, done. Do I understand correctly that all these packages now
> recommend using cygrunsrv?

Inetd still has the service code integrated, it just can now also
be installed using cygrunsrv, when using the -D option.


Corinna

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

--
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: SSH Local Port Forwarding

[Corinna Vinschen]

On Jan 26 16:53, Jon Dixon wrote:
>I have Cygwin version 1.5.18-1 installed on a Windows 2003 Server
> System.  My question is in regard to the SSH Local Port Forwarding
> feature.  I activate the ssh local port forwarding with the command
> line statement:
> 
>ssh ?L2001:server.com:23 server.com.
> 
> At this point, an application can connect to Cygwin listening on port
> 2001.   However if another program is executed and also listens on
> port 2001, it too will run.  Is there an option available where by SSH
> can open up the Local Port Forwarding listening port in exclusive mode
> (i.e. SO_EXCLUSIVEADDRUSE) so no other programs can simultaneously
> listen on the same port?

Unfortunately not.  WinSock behaves somewhat different than one would
expect in terms of port reuse.  I will look into this issue at some
later point, as time permits, and see if SO_EXCLUSIVEADDRUSE could help
here.


Corinna

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

--
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: Calling shell script from DOS

[Ismael Valladolid Torres]

David Christensen escribe:
> Pinaki Mukherjee wrote:
> > I have installed Cygwin. I want to invoke a shell
> > script from the DOS/Windows command prompt (instead of
> > opening Cygwin Window first and calling it from
> > there). How can I do this?
> > Thanks for any help.
> 
> This is a batch file that I use to launch a Bash script that backs up my
> machines:
> 
> [EMAIL PROTECTED]:~/mydocuments/backup-p42800e$ cat backup-all.bat
> @echo off
> 
> C:
> chdir C:\cygwin\bin
> 
> bash /backup/bin/backup-all

Use bash -i or bash --login if you also want your .bashrc or your
.bash_profile to be sourced.

Cordially, Ismael
-- 
Tout fourmille de commentaries, d'auteurs il en est grande chert?

 http://lamediahostia.blogspot.com/
 http://www.flickr.com/photos/ivalladt/


pgpbBGsdxgKJR.pgp
Description: PGP signature

Re: Please assist with details regarding uninstalling [Attn FAQ maintainer]

[Reini Urban]

2006/1/27, Corinna Vinschen <[EMAIL PROTECTED]>:
> On Jan 26 21:06, Joshua Daniel Franklin wrote:
> > On 1/25/06, Reini Urban wrote:
> > > postgresql is of the same kind as inetd.
> > > In the recommended way the service is run via cygrunsrv, but a few
> > > people might also have installed the cygwin version via pg_ctl as
> > > service starter.
> > > Mentioning it after apache would help a bit.
> > >
> > > =>
> > > "sshd, cron, cygserver, inetd, apache, postgresql and so on."
> >
> > OK, done. Do I understand correctly that all these packages now
> > recommend using cygrunsrv?

Yes for postgresql, esp for the SIGINT handler on shutdown and the
env CYGWIN=server, which is not yet included in the default service handler
in the native Win32 method via pg_ctl.

> Inetd still has the service code integrated, it just can now also
> be installed using cygrunsrv, when using the -D option.
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/

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

Cygwin on XP-Prof and ssh

[guy . j . maurel]

Hello Corinna!

I red the message:
  http://www.cygwin.com/ml/cygwin/2004-08/msg00702.html

on Thu, 19 Aug 2004 13:21:23 +0200, where you are writting:


I found the culprit.  It's a miscalculation bug in Cygwin which happens

Now, I use the version I got from yesterday:
OpenSSH_4.2p1, OpenSSL 0.9.8a, 11 Oct 2005

and the Problem with
> debug1: temporarily_use_uid: 1005/513 (e=1005/513)
> seteuid 1005: Permission denied

is still existing.

What can you say on it?

Thanks for helping

guy


--
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: [ANNOUNCEMENT] Updated: coreutils-5.93-3

[Angelo Graziosi]

Some days ago, I installed coreutils 5.93-3 as exp. package.

After upgrading to base-files-3.7-1, I reinstalled coreutils-5.93-3 but I
discovered that /etc/DIR_COLORS was that of base-files-3.6-1 and not
3.7-1. (and the command 'cygcheck -c coreutils base-files' said 'OK')

So after many tries I reinstalled:


   base-files-3.6-1
   coreutils-5.3.0-9

   basefile-3.7-1
   coreutils-5.93-3


After this, /etc/DIR_COLORS was that of 3.7-1!

Now having 

   alias ls='ls --color --show-control-chars'

(I have tried also alias ls='ls --color=auto') never is changed in
diplaying the colors, i.e. the directory with all permission

  drwxrwxrwx+  4 Administrator Administrators0 Jan 12 21:47 home


is displayed blue on green background.

Is this the default behaviour of /etc/DIR_COLORS ?


Thanks,

angelo.


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

Re: Cygwin on XP-Prof and ssh

[Corinna Vinschen]

On Jan 27 10:55, [EMAIL PROTECTED] wrote:
> 
> Hello Corinna!
> 
> I red the message:
>   http://www.cygwin.com/ml/cygwin/2004-08/msg00702.html
> 
> on Thu, 19 Aug 2004 13:21:23 +0200, where you are writting:
> 
> 
> I found the culprit.  It's a miscalculation bug in Cygwin which happens
> 
> Now, I use the version I got from yesterday:
> OpenSSH_4.2p1, OpenSSL 0.9.8a, 11 Oct 2005
> 
> and the Problem with
> > debug1: temporarily_use_uid: 1005/513 (e=1005/513)
> > seteuid 1005: Permission denied
> 
> is still existing.
> 
> What can you say on it?

Nothing.  Try http://cygwin.com/problems.html


Corinna

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

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

Native letters in Cygwin zsh

[Wojciech Pietron]

WinXP Pro,
ZSH_VERSION=4.2.6
Cygwin.dll 1.5.19
charset cp1250
TERM=rxvt

Hello,

I am impressed by zsh abilities so I have decided to implement it into
my computer life lately. Despite I am new user there were no problems
with Linux and Solaris environment.

The only problem is with Cygwin and displaying Polish native letters. I
usually use AltGr modifier (right Alt on standard PC keyboard) to have them
typed. And seven of nine Polish native letters are displayed OK. Problem is
with AltGr-S and AltGr-X. Instead of displaying Polish letters I can see
two strange-looking chars (it looks like German 'umlaut' and 'SS') in the
case of normal and capital letters. Similar problem with typing in vi.

There is no problem with it in the case of standard Windows application
(notepad, Word, and so on).

After a few hours spent in 'bindkey', 'stty' and similar stuff I am not
very familiar with, I found out that after running a command 'setopt nozle'
I am able to produce all Polish letters. Of course, I loose all
functionality associated with 'Zsh Line Editor' module as well. What is more,
problem remains in vi editor.

Is there any simpler command to be able to enable Polish letters associated
with AltGr-X and AltGr-S and not to loose all the functionality of 'zle'
module?

I would appreciate any links, commands and advises that help me solve my
problem.

Best regards,
Wojciech Pietron

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

binutils testsuite failures? (was: Re: Errors compiling cdrtools under cygwin 1.5.19)

[Yitzchak Scott-Thoennes]

On Tue, Jan 24, 2006 at 10:28:50PM -0500, Christopher Faylor wrote:
> I should point out that I didn't rebuild my packages under 1.5.19 either
> so I'm just as guilty as any other package maintainer in this regard.

Speaking of which, in the course of making a small patch to ld (which
I hope the binutils folk will apply and will find its way into an
updated cygwin package at some point) I tried building binutils and
got 2 unexpected test failures and 1 unexpected pass for ld (see
attached).  I didn't revert to 1.5.18 to see if that made any
difference though.  I probably just have something not set up
correctly.
make[1]: Entering directory `/usr/src/binutils-20050610-1/ld'
Making check in po
make[2]: Entering directory `/usr/src/binutils-20050610-1/ld/po'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/usr/src/binutils-20050610-1/ld/po'
make[2]: Entering directory `/usr/src/binutils-20050610-1/ld'
make  check-DEJAGNU
make[3]: Entering directory `/usr/src/binutils-20050610-1/ld'
Making a new site.exp file...
srcroot=`cd .././ld && pwd`; export srcroot; \
r=`pwd`; export r; \
LC_COLLATE=; LC_ALL=; LANG=; export LC_COLLATE LC_ALL LANG; \
EXPECT=expect; export EXPECT; \
if [ -f ./../expect/expect ]; then \
  TCL_LIBRARY=`cd .././ld/../tcl/library && pwd`; \
  export TCL_LIBRARY; \
fi; \
runtest=runtest; \
if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then \
  $runtest --tool ld --srcdir ${srcroot}/testsuite \
CC="gcc -L/usr/src/binutils-20050610-1/./ld" CFLAGS="-g -O2" \
CXX="c++ -L/usr/src/binutils-20050610-1/./ld" CXXFLAGS="-g -O2" \
CC_FOR_HOST="gcc" CFLAGS_FOR_HOST="-g -O2" \
OFILES="ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o 
ldwrite.o ldexp.o  ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o ei386pe.o 
deffilep.o pe-dll.o" BFDLIB="../bfd/.libs/libbfd.a" \
LIBIBERTY="../libiberty/libiberty.a ./../intl/libintl.a" LIBS="" \
; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
WARNING: Couldn't find the global config file.
WARNING: Couldn't find tool init file
Test Run By sthoenna on Fri Jan 27 00:23:25 2006
Native configuration is i686-pc-cygwin

=== ld tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/binutils-20050610-1/ld/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-alpha/alpha.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-arm/arm-elf.exp ...
Running 
/usr/src/binutils-20050610-1/ld/testsuite/ld-auto-import/auto-import.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest with -Ur
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-checks/checks.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cris/cris.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-crx/crx.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cygwin/exe-export.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-d10v/d10v.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-discard/discard.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/exclude.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/frame.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/sec64k.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfcomm/elfcomm.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfvers/vers.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfvsb/elfvsb.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfweak/elfweak.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-fastcall/fastcall.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/fdpic.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/frv-elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/tls.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-h8300/h8300.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-i386/i386.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-ia64/ia64.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-linkonce/linkonce.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-m68hc11/m68hc11.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-maxq/maxq.exp ...
Running 
/usr/src/binutils-20050610-1/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-mips-elf/mips-elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-mmix/mmix.exp ...
Running /usr/src/binutils-20050610-1/ld/tests

RE: Calling shell script from DOS

[Herb Martin]

> I have installed Cygwin. I want to invoke a shell
> script from the DOS/Windows command prompt (instead of
> opening Cygwin Window first and calling it from
> there). How can I do this?
> 
> Thanks for any help.

The following seems the naive way -- someone else
may offer other options:

Make the shell (itself) the command and add the
script as a parameter...

bash script-file-name

Worked for me.  Other command processors should
work too.

--
Herb Martin


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

Re: Problems with cygwin cvs over ssh.

[James Courtier-Dutton]

On 26/01/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:
> >
> > Remote CVS server is Solaris, local ssh and Cygwin dll versions are
> > latest released.
>
> Then you have misunderstood the original problem.  The problem is with the
> CVS server running on Cygwin.  CVS in client mode works just fine.
> Igor

Exactly. Problem is not client side, it is server site.
Install cygwin (cvs and openssh) on a Windows box, and have the
Windows box be the cvs server.

James

--
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: Calling shell script from DOS

[Brett Serkez]

 > I have installed Cygwin. I want to invoke a shell
 > > script from the DOS/Windows command prompt (instead of opening
 > > Cygwin Window first and calling it from there). How can I do this?
 > >
 > > Thanks for any help.
 >
 > The following seems the naive way -- someone else may offer other
 > options:
 >
 > Make the shell (itself) the command and add the script as a
 > parameter...
 >
 >   bash script-file-name
 >
 > Worked for me.  Other command processors should work too.

I name all of my bash scripts with a .sh extension, althought not
necessary from Cygwin's point of view, it allows me to associate .sh
files with c:\cygwin\bin\bash in Windows.  I then customize the icon for
this association with the Cygwin icon, and these files then show up with
this icon in Explorer and I can simply double click to run.

Brett

Brett C. Serkez, Techie


--
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: rpcgen question

[Brett Serkez]

> Since yesterday, i have made some investigation, and i have found that
> rpcgen comes from the same package (both on RH and cygwin), but it's a
> problem of version: - RH: /* @(#)rpc.h2.4 89/07/11 4.0 RPCSRC;
> from 1.9 88/02/08 SMI */ - Cygwin: /* @(#)rpc.h2.3 88/08/10 4.0
> RPCSRC; from 1.9 88/02/08 SMI */

Correct, the features in question were added later.

> And finaly, i will try to keep the generated code on linux and try to
> build/use it on cygwin... Don't know if it's a good or bad idea! :(

A good idea.  It may not be necessary to regenerate the code for every
platform.  Working on projects in the past, it was the norm to generate
and check-in the generated code on the primary UNIX platform, and only
compile on the various UNIXies/Linux.  Much of the upgraded
functionality is in the code generator, althought threading depends upon
the appropriate threading libraries availability on each platform.

Brett

Brett C. Serkez, Techie


--
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: [ANNOUNCEMENT] Updated: coreutils-5.93-3

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Angelo Graziosi on 1/27/2006 3:39 AM:
> 
> Some days ago, I installed coreutils 5.93-3 as exp. package.
> 
> After upgrading to base-files-3.7-1, I reinstalled coreutils-5.93-3 but I
> discovered that /etc/DIR_COLORS was that of base-files-3.6-1 and not
> 3.7-1. (and the command 'cygcheck -c coreutils base-files' said 'OK')
> 
> So after many tries I reinstalled:
> 
> 
>base-files-3.6-1
>coreutils-5.3.0-9
> 
>basefile-3.7-1
>coreutils-5.93-3
> 
> 
> After this, /etc/DIR_COLORS was that of 3.7-1!

Thanks for the howto.  It boils down to the fact that base-files will only
replace /etc/DIR_COLORS on upgrade if it matches
/etc/defaults/etc/DIR_COLORS, but by upgrading coreutils first,
/etc/defaults/etc/DIR_COLORS was changed first.  A shorter path to
reverting, then reinstalling, both packages would have been to manually
run "cp /etc/defaults/etc/DIR_COLORS /etc/DIR_COLORS" after both new
packages are installed and cygcheck reports OK.

> 
> Now having 
> 
>alias ls='ls --color --show-control-chars'
> 
> (I have tried also alias ls='ls --color=auto') never is changed in
> diplaying the colors, i.e. the directory with all permission
> 
>   drwxrwxrwx+  4 Administrator Administrators0 Jan 12 21:47 home
>
>
> is displayed blue on green background.

Reread the release notes for coreutils-5.93 - there are new categories
added to dircolors/ls, and one of these is OTHER_WRITABLE.  Any directory
that is world-writable, but does not have the sticky bit set, is a
security risk, since anyone else can replace files in that directory that
you have created with their own.  ls colors them differently by default to
warn you of that fact.  If it bothers you, you can use a custom input file
to dircolors that sets the color of that category to match the DIR
category coloration.

> 
> Is this the default behaviour of /etc/DIR_COLORS ?

Yes, /etc/DIR_COLORS lists the default category colors that will be
applied by "ls --color" if you don't run dircolors to set LS_COLORS in
your environment.  It takes a customization of /etc/DIR_COLORS (or an
alternate file) to change the category colors, then run dircolors to set
the LS_COLORS environment variable appropriately, before ls will then use
your desired colors instead of its defaults.

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

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

iD8DBQFD2hoT84KuGfSFAYARAlBmAKCTpBuf45AWVoR/jIsEA9mSEUYjwgCfQJ5Z
uhyYeuisktK/R0B+QXk3g7M=
=TmMU
-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/

i686-pc-cygwin on an i586

[James McLaughlin]

Hi,

Cygwin contains several files/folders with names
including the string "i686-pc-cygwin". I'm using it on
an i586, and I've been wondering if I'm supposed to be
- should I have deduced from this name that there
would be problems trying to use Cygwin on a 586? (I do
have a few problems when using Cygwin, such as gcc-g++
being very slow to compile, but for all I know that
could just be because I've got a very slow machine)

Thanks,

James McLaughlin.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Setup and gcc-g++ problems

[James McLaughlin]

I'm not sure if it's considered a breach of forum
etiquette to make a posting concerning problems with
two different pieces of software, but the problems do
seem to be related to each other. I'll begin with the
problems I had when I used setup.exe recently to
update gcc (from 3.4.1 to 3.4.4) and to install some
new stuff, mainly so I could use pdflatex.

I used setup.exe version 2.510.2.2, which was a later
version then the one I'd originally used. As I had
when I first installed Cygwin, I used "Download
Without Installing", then took the packages home to
install on my PC. Everything ran OK until Cygwin Setup
reached 99%. After this, nothing seemed to be
happening for a long time - it just stayed at 99%
declaring:

Running...
No package
/etc/postinstall/
post-texmf.sh

Eventually I pressed Cancel, and was given this dialog
box:

-
|Cygwin Setup   |
-
|Installation Complete  |
|   |
| OK|
-

(takes a look at notes) I thought I'd got a complete
set of notes on the problem with me, but it turns out
I haven't recorded when this dialog occurred/occurs:

--
Error Starting Program
--
 ^
/!\  The CYGICONV_2.DLL file is
---  linked to missing export
 CYGWIN1.DLL: _impure_ptr.

   OK
--

Sorry - it's just that all this happened in December,
but I've been too busy with exams etc to report it
until now, and unfortunately that's one detail I
forgot in the meantime.

Anyway, pdflatex keeps crashing (sometimes it freezes,
sometimes I get a BSOD) - though it may not have
anything to do with this - and whenever I try to use
g++, this happens:

g++ -ansi -std=c++98 -pedantic -o mcpre.exe
mc_pre1.cpp
g++: installation problem, cannot exec
'/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe'.
Function not implemented.

(This is probably where the dialog I mentioned
occurs.)

Does anyone have any idea re what's going on? I did
suggest in a posting a few minutes ago that it might
be because of problems with i686-pc-cygwin on an i586,
but I don't really know.

Thanks,

James McLaughlin.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

RE: i686-pc-cygwin on an i586

[Dave Korn]

On 27 January 2006 15:36, James McLaughlin wrote:

> Hi,
> 
> Cygwin contains several files/folders with names including the string
> "i686-pc-cygwin". I'm using it on an i586, and I've been wondering if I'm
> supposed to be - should I have deduced from this name that there would be
> problems trying to use Cygwin on a 586? (I do have a few problems when
> using Cygwin, such as gcc-g++ being very slow to compile, but for all I
> know that could just be because I've got a very slow machine)


  Nope, don't worry about it, that's a bit of a red-herring.  By default, the 
code gcc generates is good for everything from '486
up.  The instruction scheduling and choice of which instructions to use may be 
tuned to be optimal for a 686 and so may be
less-than-optimal on a '586, but there should not be any actual 
backward-compatibility issues.

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: SIGALRM is ignored in generated code blocks (using mmap) - testcase included

[Lee Moore]

Hi Chris


This may be fixed in the latest snapshot, which I'm generating right now.


I checked out the source from CVS re-built and the fix you have made does 
fix my reported problem.
Unfortunately it has uncovered another issue, I wonder if you could give 
some advice.


I have made my own (local) changes to some of the cygwin sources in order 
to be able to provide the

'context' to 'sigaction' when an exception occurs (file diffs.txt attached).
This appears to work fine except for the case when SIGALRM occurs.

it appears that for SIGALRM neither the _cygtls::call_signal_handler nor 
the _cygtls::handle_exceptions

get involved - is this correct ?

when my signal handler for the alarm is called I cannot get the context, it 
has clearly come through a
different path. What I need to do is change the cygwin code so that the 
context is saved when the SIGALRM

occurs, in the same way it is for my other exceptions

All suggestions welcome
Thx
LeeIndex: cygwin/exceptions.cc
===
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.279
diff -r1.279 exceptions.cc
34a35,37
> // IMPERAS
> #include 
> 
457a461,462
> // IMPERAS
>   si.si_context = (void *) in;
1314c1319,1320
< sigact (thissig, &thissi, NULL);
---
> // IMPERAS
> sigact (thissig, &thissi, (void *)thissi.si_context);
Index: cygwin/include/cygwin/signal.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/signal.h,v
retrieving revision 1.11
diff -r1.11 signal.h
10a11
> 
98c99,105
< void *si_addr;/* faulting address */
---
> struct
> {
>   void *si_addr;  /* faulting address */
>   /* IMPERAS Register Window access */
>   void *si_context;   /* context pointer */
> };
> 
99a107
> 
--
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_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

[Louis Lecaroz]

Hi Christophe,
First, let met apologize if there were many misunderstanding between you & me.
I was really calm when I wrote my previous mail, there was no agression but 
maybe some missing smiley.

Next for your email address, I understand your concerned, I just copied & past 
it from the changelog & the source code where it was written & did not take 
care of this as these code & so your email address are publicly accessible from 
cvs :( but I understand that robots could use it for spamming.

Next, I troubleshoot my issue a little bit, maybe my first mail was too quick 
on the investigation.
I now found the origin of my issue, sure, you're right the LD_PRELOAD is 
propaged correctly (as you corrrected it als form in the snapshot referenced 
below).

But... As I use manu environment variable, for example, one called FILELOG_PORT 
(which is used by the injected code/dll for communciation with external 
process), It appears, I don't know why, that this variable is not replicated in 
all sub/child process ! :(

Do you have an idea on this ?
For your information, I retrieve this environment variable from the getenv() 
microsoft C APi as my injected DLL is written with the Microsoft C runtime & 
not cygwin one. But I suppose that you fix environment variable for child 
process... 

Looking a little bit better inside & drilling in the issue, here is what I 
found :
from cmd.exe
->Start bash
-->All environment variables from cmd.exe were propaged in bash 
environment+.profiles one.
-->Start "vi sample.txt" from this bash instance
>A new instance of bash is loaded with also all environment variables.
->A VIM.exe instance is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, 
WINDIR !

I tried also to verify with the win32 system routine called 
GetEnvironmentStrings(), but it is exactly the same data retrieved with 
getenv() !
So it (I feel) seems that this new version of cygwin did not propaged all 
environment variable to all child process !
Don't know why :( but I Just tested it on the 1.5.18 patched with the snapshot 
mentioned below, just reinstall the 1.5.19-4 over it (after having removed the 
previous), & my conclusion (but I am not the Cygwin Expert ;) ), is that 
LD_PRELOAD since 1.5.19-4 & previuous does have the same behavior as 
environment variable appears to be correctly propagated in 1.5.18-x & not in 
1.5.19-4.

So, let me also apologize for my first bad investigation, but anyway, it 
appears that there is an issue in this build (environment variables not 
propagated).
I reported it as an LD_PRELOAD issue, as I uses this TCP port defined in the 
environment variable to communicate & send traces. & so because, the 
environment port called FILELOG_PORT was not propagated to child process, I was 
not able to see my dll traces considering this issue as an LD_PRELOAD issue 
instead of an environment variable propagation.

I am sure that you will be able to help me on this ;)
Thx a lot in advance,
Louis

-Original Message-
From: Christopher Faylor
[mailto:[EMAIL PROTECTED]
Sent: jeudi 26 janvier 2006 19:37
To: cygwin@cygwin.com
Subject: Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library
in child process


On Thu, Jan 26, 2006 at 11:37:18AM +0100, Louis Lecaroz wrote:
>Hi all CygWin champions developers ;)
>
>Since this version, the LD_PRELOAD tag is no more replicated to
>subprocess (Win32 version of cygwin).  That means, if I set the
>LD_PRELOAD variable, only the parent process calls the LoadLibrary &
>load the DLL defined in LD_PRELOAD.
>
>In this case, when starting bash, the LD_PRELOAD command is executed.
>but when starting a cp.exe, cat.exe or another cygwin command from the
>bash shell, the LD_PRELOAD is no more executed !

Please CALM DOWN.

>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>$cp toto.txt titi.txt (no mydll.dll loaded !)
>
>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>$cmd
>c:\cp toto.txt titi.txt (mydll.dll loaded)
>
>So, it works now in this last build of cygwin as it was working
>previously the snapshot #20050811
>
>To correct this, a snapshot has been provided, snapshot #20050811, See
>ChangeLog in winsup\cygwinChangeLog :
>2005-08-11  Christopher Faylor  <[EMAIL PROTECTED]>

Please don't send my email address to public mailing lists.

> * dcrt0.cc: Remove ld_preload declaration.
> * winsup.h: Move ld_preload declaration here.
> * fork.cc (fork_child): Call ld_preload() before returning.
>
>So this issue was corrected by ffork.cc version 1.158 of ffork.ccd I
>took a quick look into the ffork.cc, & I saw that the
>fixup_hooks_after_fork () & _my_tls.fixup_after_fork () are now called
>after ld_preload instead of before as deliverd in snapshot #20050811.
>I don't know exactly if this is the reason of my issue.

I'm sorry but I don't really understand this report.  I implemented
LD_PRELOAD because I have software which needs it.  I would notice if 

RE: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

[Louis Lecaroz]

For your information, I tried to set the FILELOG_PORT environment variable in 
bash throught export FILELOG_PORT=1234
& it does not resolve my issue. normaly I set the FILELOG_PORT environment 
variable inside cmd.exe before loading bash from it.
I just tried also the last snasphot provided on the site & it does not correct 
this :(
I also tried to add FILELOG_PORT in .profile & other files but no success :(

The preloaded library from LD_PRELOAD does not appears to inherit from parent 
environment if using Win32 Microsoft std APis

-Original Message-
From: Louis Lecaroz 
Sent: vendredi 27 janvier 2006 18:31
To: 'cygwin@cygwin.com'
Subject: RE: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library
in child process


Hi Christophe,
First, let met apologize if there were many misunderstanding between you & me.
I was really calm when I wrote my previous mail, there was no agression but 
maybe some missing smiley.

Next for your email address, I understand your concerned, I just copied & past 
it from the changelog & the source code where it was written & did not take 
care of this as these code & so your email address are publicly accessible from 
cvs :( but I understand that robots could use it for spamming.

Next, I troubleshoot my issue a little bit, maybe my first mail was too quick 
on the investigation.
I now found the origin of my issue, sure, you're right the LD_PRELOAD is 
propaged correctly (as you corrrected it als form in the snapshot referenced 
below).

But... As I use manu environment variable, for example, one called FILELOG_PORT 
(which is used by the injected code/dll for communciation with external 
process), It appears, I don't know why, that this variable is not replicated in 
all sub/child process ! :(

Do you have an idea on this ?
For your information, I retrieve this environment variable from the getenv() 
microsoft C APi as my injected DLL is written with the Microsoft C runtime & 
not cygwin one. But I suppose that you fix environment variable for child 
process... 

Looking a little bit better inside & drilling in the issue, here is what I 
found :
from cmd.exe
->Start bash
-->All environment variables from cmd.exe were propaged in bash 
environment+.profiles one.
-->Start "vi sample.txt" from this bash instance
>A new instance of bash is loaded with also all environment variables.
->A VIM.exe instance is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, 
WINDIR !

I tried also to verify with the win32 system routine called 
GetEnvironmentStrings(), but it is exactly the same data retrieved with 
getenv() !
So it (I feel) seems that this new version of cygwin did not propaged all 
environment variable to all child process !
Don't know why :( but I Just tested it on the 1.5.18 patched with the snapshot 
mentioned below, just reinstall the 1.5.19-4 over it (after having removed the 
previous), & my conclusion (but I am not the Cygwin Expert ;) ), is that 
LD_PRELOAD since 1.5.19-4 & previuous does have the same behavior as 
environment variable appears to be correctly propagated in 1.5.18-x & not in 
1.5.19-4.

So, let me also apologize for my first bad investigation, but anyway, it 
appears that there is an issue in this build (environment variables not 
propagated).
I reported it as an LD_PRELOAD issue, as I uses this TCP port defined in the 
environment variable to communicate & send traces. & so because, the 
environment port called FILELOG_PORT was not propagated to child process, I was 
not able to see my dll traces considering this issue as an LD_PRELOAD issue 
instead of an environment variable propagation.

I am sure that you will be able to help me on this ;)
Thx a lot in advance,
Louis

-Original Message-
From: Christopher Faylor
[mailto:[EMAIL PROTECTED]
Sent: jeudi 26 janvier 2006 19:37
To: cygwin@cygwin.com
Subject: Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library
in child process


On Thu, Jan 26, 2006 at 11:37:18AM +0100, Louis Lecaroz wrote:
>Hi all CygWin champions developers ;)
>
>Since this version, the LD_PRELOAD tag is no more replicated to
>subprocess (Win32 version of cygwin).  That means, if I set the
>LD_PRELOAD variable, only the parent process calls the LoadLibrary &
>load the DLL defined in LD_PRELOAD.
>
>In this case, when starting bash, the LD_PRELOAD command is executed.
>but when starting a cp.exe, cat.exe or another cygwin command from the
>bash shell, the LD_PRELOAD is no more executed !

Please CALM DOWN.

>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>$cp toto.txt titi.txt (no mydll.dll loaded !)
>
>If I performed :
>SET LD_PRELOAD=/cygdrive/d/mydll.dll
>c:\bash (mydll.dll loaded correctly)
>$cmd
>c:\cp toto.txt titi.txt (mydll.dll loaded)
>
>So, it works now in this last build of cygwin as it was working
>previously the snapshot #20050811
>
>To correct this, a snapshot has been provided, snapshot #20050811, See
>ChangeLog in winsup\cygwinChang

Re: bug report: abort in g++ 3.4.4 generated DLL & client

[Stein Somers]

FYI, this problem persists in the latest cygwin release.  Or as I would 
put it, "cygwin 1.5.17-1 good, 1.5.19-4 bad".  I'll around get to it as 
soon as I'm retired, I promise...


Source file 1: ==> testdll.cpp <==
   #include 
   std::string test() { return std::string(); }

Source file 2: ==> main.cpp <==
   #include 
   std::string test();

   int main() {
   puts("hello");
   test();
   puts("goodbye");
   return 0;
   }

Commands applied:

   g++ -Wall testdll.cpp -shared -o test.dll
   g++ -Wall main.cpp test.dll
   ./a.exe

--
Stein

--
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: Calling shell script from DOS

[Igor Peshansky]

On Thu, 26 Jan 2006, Pinaki Mukherjee wrote:

> I have installed Cygwin. I want to invoke a shell
> script from the DOS/Windows command prompt (instead of
> opening Cygwin Window first and calling it from
> there). How can I do this?

In addition to what others said, use "bash -c" instead of "bash" to honor
the shebang ("#!") line.  This would then work for tcsh, ksh, perl,
python, [you name it] scripts, as well as symlinks.  In fact, whenever you
need to invoke a Cygwin program from the DOS prompt, and you don't know if
it's a script, a symlink, or an actual .exe, you can't go wrong with "bash
-c progname".

Adding --login (-l) is optional, but may be useful for scripts that make
assumptions about your environment.
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

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

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

Re: cygwin-1.5.19-2: mkdir returns inconsistent errno

[Alex Riesen]

Alex Riesen, Thu, Jan 26, 2006 17:21:21 +0100:
> > > > > This is highly unexpected, does not match linux behaviour
> > > > > (it returns EEXIST), and actually breaks git (git clone,
> > > > > creation of pathnames, to be precise).
> > > >
> > > > Then git has a bug.  Report it there.  To be portable
> > > > when making pathnames, you must first check
> > > > for directory existance rather than relying on an
> > > > errno of EEXIST to tell you the directory exists.
> > >
> > > How do you do it race-free?
> >
> > chdir().  If chdir() succeeded, then the directory existed,
> > regardless of the errno that mkdir() reported.
> > Take a look at gnulib's mkdir-p.c module:
> > http://cvs.savannah.gnu.org/viewcvs/gnulib/lib/mkdir-p.c?rev=1.5&root=gnulib&view=auto
> 
> Very interesting! Thank you for this and the other references.
> I'm given hope! :)

This was a bit prematurely. There is a big problem with this aproach:
it changes current directory of the process. So you can't really use
it in multithreaded or signalled environment.
So chdir is not a real solution. Is it really that hard to workaround
the problem in cygwin?


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

csh script hangs only on cygwin

[Stewart Midwinter]

I've been able to isolate a problem with csh on cygwin running on
Windows Server 2003 on a Xeon.  The following script hangs after a
certain period of time ranging from a few minutes to a few hours.

---
#!/bin/csh

while (1)
set year = `date +%y`
set month = `date +%m`
set day = `date +%d`
set hour = `date +%H`
set minute = `date +%M`
set second = `date +%S`
set stamp = "$year$month$day $hour : $minute : $second"
echo $stamp
sleep 2
end


The equivalent script in bash doesn't hang even after a day or more.

-
#!/bin/bash

while [ 1 ]; do
echo $(date +%Y%m%d.%H%M%S)
sleep 2
done
-

Has anyone else had problems with csh scripts on cygwin? Yes, I know
that some people don't recommend using csh (see "Csh programming
considered harmful",
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/), but I'm stuck
with a whole lot of csh scripts and don't have time to port them all
at the moment.

thanks,
--
Stewart Midwinter
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Skype, GoogleTalk, iChatAV, MSN, Yahoo: midtoad
AIM:midtoad1

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

After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[Karr, David]

I have a desktop icon for running Xemacs 21.4.13.  This has been working
fine.  Just today, I upgraded Cygwin from 1.5.18 to 1.5.19.  Now when I
double-click the icon, it does nothing.  I then tried pasting the path
to it into a DOS cmd prompt, and it still does nothing.  I then executed
it directly from a bash prompt, and that worked.

I have a similar icon for 21.4.18, and that doesn't demonstrate the same
problem, although 21.4.18 always runs a cmd window in the background,
which 21.4.13 does 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: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

[Christopher Faylor]

On Fri, Jan 27, 2006 at 06:31:29PM +0100, Louis Lecaroz wrote:
>First, let met apologize if there were many misunderstanding between
>you & me.  I was really calm when I wrote my previous mail, there was
>no agression but maybe some missing smiley.

Your continued use of exclamation points would really suggest otherwise.  In 
fact,
you seem even more excited in this message.

>Next for your email address, I understand your concerned, I just copied
>& past it from the changelog & the source code where it was written &
>did not take care of this as these code & so your email address are
>publicly accessible from cvs :( but I understand that robots could use
>it for spamming.

http://cygwin.com/acronyms/#PCYMTNQREAIYR

>Looking a little bit better inside & drilling in the issue, here is
>what I found : from cmd.exe ->Start bash -->All environment variables
>from cmd.exe were propaged in bash environment+.profiles one.  -->Start
>"vi sample.txt" from this bash instance >A new instance of bash is
>loaded with also all environment variables.  ->A VIM.exe instance
>is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, WINDIR !

Once again, you seem pretty excited.

I don't know why a vi session would start a new version of bash but I
couldn't duplicate this in any way.

Maybe reading http://cygwin.com/problems.html will be of some help.

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: 1.5.19-3 parent socket binding remains after closing when spawning child process

[Martin]

I tried snapshot cygwin-inst-20060127.tar.bz2.  This testcase still
fails for me.  I could be doing something wrong.  Please, give this
another try.  Your efforts are appreciated.

Thanks,
Martin
--- Corinna Vinschen <[EMAIL PROTECTED]> wrote:

> On Jan 20 11:53, Martin wrote:
> > Well, this is a strange one.
> > I open a socket in a parent process, bind it and
> > listen.
> > I set the socket to close-on-exec with the FD_CLOEXEC
> > flag.
> > A child process is spawned, which doesn't inherit the
> > socket.
> > I then close the server socket in the parent process.
> > For a laugh, I attempt to connect to the port
> > associated with the server socket.  I would expect
> > this connection request to fail, since I just closed
> > the socket.  It doesn't.
> > 
> > The attached test case illustrates this.
> > Please let me know if I'm doing something wrong.
> 
> Thanks very much for the testcase.  I found that when duplicating
> sockets between processes using the WSADuplicateSocket/WSASocket
> method,
> the duplicated socket is inheritable by child processes again, even
> when
> the original socket has the inheritance flag removed.  So, what
> basically happend behind the scenes was this:
> 
>   sock = socket()
>   SetHandleInformation(sock, DONT_INHERIT);
> 
>   fork()
> WSADuplicateSocket(sock)in parent
> sock = WSASocketin child, BUT sock is inheritable
> again.
> 
> exec()
>   close_on_exec is set?  Yes, don't duplicate socket.
>   ... but sock was inheritable, so the exec'ed process got a
>   valid handle to a valid, listening socket.  Bummer.
> 
> I've checked in a patch to CVS which resets the inheritance for the
> duplicated socket in the child process, so there's no valid, open
> handle
> to the listening socket anymore, after the parent called close() and
> the
> forked child exec'ed.  Consequentially the 2nd connect call fails
> now.
> 
> 
> Thanks again for the testcase, it was highly appreciated,
> Corinna
> 
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin
> to
> Cygwin Project Co-Leader  cygwin AT cygwin DOT com
> Red Hat
> 
> --
> 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/
> 
> 







__ 
Find your next car at http://autos.yahoo.ca

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

Cygwin Bash window disappear?!

[Daniel mark]

Hello all:

I met a very strange problem as follows:

After I finish installing the latest version of cygwin on my computer, I try to
run C:\cygwin\cygwin.bat. The only thing I got is a black window splash for a
second and then immediately disappear.

I have fully installed all cygwin package and test all package without problem
by using the package test tool provided by cygwin.

I have tried to install it for 3 times!! still the same problem

My machine is using AMD chip with XP professional


Thank you
-Daniel


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

Re: Problems with cygwin cvs over ssh.

[Frank-Michael Moser]

I have encountered the same problem, have investigated it a bit and came
out with two interesting facts:

A) Without changing anything else than replacing cygwin1.dll, using the
snaphot cygwin1-20050928.dll works fine while using cygwin1-20050929.dll
produces the problem.

B) Also without changing anything else than replacing cygwin1.dll, using
the snaphot cygwin1-20050928.dll "mkdir /tmp/foo/." runs fine while with
cygwin1-20050929.dll you see:

> $ mkdir /tmp/foo/.
> mkdir: cannot create directory `/tmp/foo/.': No such file or directory


Frank-Michael


Igor Peshansky wrote:
> On Wed, 25 Jan 2006, René Berber wrote:
> 
>> Igor Peshansky wrote:
>> [snip]
>>> FWIW, I could reproduce the original problem, either with or without
>>> ":ext:".
>> The combination cvs/ssh has no problem :
>>
>> $ echo $CVS_RSH
>> ssh
>> $ echo $CVSROOT
>> :ext:[EMAIL PROTECTED]:/export/home0/cvsrep
>> $ cvs co junit-test
>> cvs server: Updating junit-test
>> U junit-test/.classpath
>> U junit-test/.project
>> cvs server: Updating junit-test/lib
>> ...
>>
>> Remote CVS server is Solaris, local ssh and Cygwin dll versions are
>> latest released.
> 
> Then you have misunderstood the original problem.  The problem is with the
> CVS server running on Cygwin.  CVS in client mode works just fine.
>   Igor
> 



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

Re: bug report: abort in g++ 3.4.4 generated DLL & client

[Brian Dessent]

Stein Somers wrote:

> FYI, this problem persists in the latest cygwin release.  Or as I would
> put it, "cygwin 1.5.17-1 good, 1.5.19-4 bad".  I'll around get to it as
> soon as I'm retired, I promise...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196

--
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_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

[Brian Ford]

On Fri, 27 Jan 2006, Christopher Faylor wrote:

> On Fri, Jan 27, 2006 at 06:31:29PM +0100, Louis Lecaroz wrote:
> >Looking a little bit better inside & drilling in the issue, here is
> >what I found : from cmd.exe ->Start bash -->All environment variables
> >from cmd.exe were propaged in bash environment+.profiles one.  -->Start
> >"vi sample.txt" from this bash instance >A new instance of bash is
> >loaded with also all environment variables.  ->A VIM.exe instance
> >is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, WINDIR !
>
> I don't know why a vi session would start a new version of bash but I
> couldn't duplicate this in any way.

Wouldn't the method he is using to "detect" this simply be detecting the
fork of bash before the exec?

And isn't this just another case of:

http://cygwin.com/ml/cygwin/2006-01/msg00938.html

?  Wasn't he testing this using Windows calls to get the environment?

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

--
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: Setup and gcc-g++ problems

[Brian Dessent]

James McLaughlin wrote:

> Running...
> No package
> /etc/postinstall/
> post-texmf.sh

The texmf postinstall script can take quite a long time to run, as it
does a lot of font regeneration stuff.  On the other hand I have seen
reports on the list of it hanging.  I don't know squat about TeX but you
can manually run its postinstall script from a regular bash prompt to
find out what the delay/problem is.  It shouldn't have anything to do
with the other problems you have reported.

>  ^
> /!\  The CYGICONV_2.DLL file is
> ---  linked to missing export
>  CYGWIN1.DLL: _impure_ptr.

This means you've got an older and incompatible version of cygwin1.dll
on your system.  Either you didn't reboot when setup.exe said that it
was necessary, or you have some other software installed that includes
its own cygwin1.dll in the PATH, or something else along these lines
occured.

Please read and follow  for
instructions on how to report problems -- particularly about attaching
the output of cygcheck.

> Anyway, pdflatex keeps crashing (sometimes it freezes,
> sometimes I get a BSOD) - though it may not have
> anything to do with this - and whenever I try to use
> g++, this happens:

A BSOD sounds like a hardware or driver problem.

> g++ -ansi -std=c++98 -pedantic -o mcpre.exe
> mc_pre1.cpp
> g++: installation problem, cannot exec
> '/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe'.
> Function not implemented.

This seems like a symptom of having an ancient cygwin1.dll somewhere in
your PATH.

> Does anyone have any idea re what's going on? I did

Not without more information, i.e. cygcheck.

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: After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[René Berber]

Karr, David wrote:

> I have a desktop icon for running Xemacs 21.4.13.  This has been working
> fine.  Just today, I upgraded Cygwin from 1.5.18 to 1.5.19.  Now when I
> double-click the icon, it does nothing.  I then tried pasting the path
> to it into a DOS cmd prompt, and it still does nothing.  I then executed
> it directly from a bash prompt, and that worked.

And the command you are running is?

> I have a similar icon for 21.4.18, and that doesn't demonstrate the same
> problem, although 21.4.18 always runs a cmd window in the background,
> which 21.4.13 does not.

I think what affected your installation is a change of version of Xemacs not the
Cygwin dll.

This works for me with no problem:

  C:\cygwin\bin\run.exe xemacs

that is the target of the shortcut.  If you set the icon of this shortcut to use
the xemacs executable icon (i.e. C:\Cygwin\bin\xemacs-21.4.18.exe) that will
show the icon until the next change of version.

HTH
-- 
René Berber


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

RE: Re: After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[Karr, David]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of René Berber
> 
> Karr, David wrote:
> 
> > I have a desktop icon for running Xemacs 21.4.13.  This has been 
> > working fine.  Just today, I upgraded Cygwin from 1.5.18 to 
> 1.5.19.  
> > Now when I double-click the icon, it does nothing.  I then tried 
> > pasting the path to it into a DOS cmd prompt, and it still does 
> > nothing.  I then executed it directly from a bash prompt, and that 
> > worked.
> 
> And the command you are running is?

C:\cygwin\usr\local\bin\i686-pc-cygwin\xemacs-21.4.13.exe

> > I have a similar icon for 21.4.18, and that doesn't demonstrate the 
> > same problem, although 21.4.18 always runs a cmd window in the 
> > background, which 21.4.13 does not.
> 
> I think what affected your installation is a change of 
> version of Xemacs not the Cygwin dll.
> 
> This works for me with no problem:
> 
>   C:\cygwin\bin\run.exe xemacs

I did not upgrade Xemacs.  Executing the icon (which uses the path given 
above), or pasting that path into a cmd window, does nothing.  It just returns 
to the prompt and the window doesn't appear.  The upgrade of Cygwin did not 
affect the execution of 21.4.18 at all, only 21.4.13.  I'm not using 21.4.18 
regularly yet for other reasons.

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

Re: Problems with cygwin cvs over ssh.

[Igor Peshansky]

Ugh, top-posting...   Reformatted.

On Fri, 27 Jan 2006, Frank-Michael Moser wrote:

> Igor Peshansky wrote:
>
> > The problem is with the CVS server running on Cygwin.  CVS in client
> > mode works just fine.
>
> I have encountered the same problem, have investigated it a bit and came
> out with two interesting facts:
>
> A) Without changing anything else than replacing cygwin1.dll, using the
> snaphot cygwin1-20050928.dll works fine while using cygwin1-20050929.dll
> produces the problem.
>
> B) Also without changing anything else than replacing cygwin1.dll, using
> the snaphot cygwin1-20050928.dll "mkdir /tmp/foo/." runs fine while with
> cygwin1-20050929.dll you see:
>
> > $ mkdir /tmp/foo/.
> > mkdir: cannot create directory `/tmp/foo/.': No such file or directory

Right.  I missed the "." in the original message.  The change that
prompted this behavior seems to be
.  I'm assuming the
motivation for this patch was to duplicate Linux's behavior (which doesn't
allow trailing "." in a path passed to mkdir).

There must be some Cygwin-specific code in cvs that adds that trailing
dot.  I'll take a look at the cvs sources later.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

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

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

Re: i686-pc-cygwin on an i586

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dave Korn on 1/27/2006 9:34 AM:
>   Nope, don't worry about it, that's a bit of a red-herring.  By default, the 
> code gcc generates is good for everything from '486
> up.  The instruction scheduling and choice of which instructions to use may 
> be tuned to be optimal for a 686 and so may be
> less-than-optimal on a '586, but there should not be any actual 
> backward-compatibility issues.

Speaking of which, should the next release of cygwin gcc be configured to
generate code tuned for 686, rather than penalizing most modern CPUs with
386-compatible but slower code sequences?

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

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

iD8DBQFD2pl084KuGfSFAYARAv9xAJwKnFa+ozzb2o3i38va0yCgWPtz8gCfYDgL
WgTpPBIZaP3NFORDtVb4Nyg=
=P/nR
-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/

readline-5.1 && CGDB

[Bob Rossi]

Hi,

I finally managed to compile CGDB with readline-5.1 statically. I
compiled against a version of readline that has multibyte turned on, and
a version with it turned off.

In both cases I have the same results. CGDB is displayed awkardly in the
curses window. I have finally discovered that this appears to be a
LINES/COLS bug. If I connect via putty into the windows machine, and set
the putty window to be 25/80 LINES/COLUMNS, then all works. Otherwise,
the terminal is the wrong size.

I'm convinced the problem is the call into readline. Is it possible
there were any changes to readline that would effect this? I'm sure
other curses apps will notice this problem, so it would be nice to fix
it before the next readline minor release.

I'm still working on it ...

Thanks,
Bob Rossi

--
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: SIGALRM is ignored in generated code blocks (using mmap) - testcase included

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lee Moore on 1/27/2006 9:57 AM:
> 
> I have made my own (local) changes to some of the cygwin sources in
> order to be able to provide the
> 'context' to 'sigaction' when an exception occurs (file diffs.txt
> attached).

Diffs are much easier to read in unified format (diff -u); context is
important.  Also, the cygwin-patches list is a better forum for posting
patches, and you should be aware of copyright assignment rules:
http://cygwin.com/contrib.html

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

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

iD8DBQFD2pqL84KuGfSFAYARAg/JAJ4icQ+bhNBIl/40mtrFH3+b4EbZzgCePCcT
l3WQfO/PQi3GG2VA8hvunrw=
=ak64
-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: After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[René Berber]

Karr, David wrote:
[snip]
>>And the command you are running is?
> 
> 
> C:\cygwin\usr\local\bin\i686-pc-cygwin\xemacs-21.4.13.exe

This is not the xemacs distributed by Cygwin... or is it?

>>>I have a similar icon for 21.4.18, and that doesn't demonstrate the 
>>>same problem, although 21.4.18 always runs a cmd window in the 
>>>background, which 21.4.13 does not.

Use run.exe to avoid the command window.

> I did not upgrade Xemacs.  Executing the icon (which uses the path given 
> above),
> or pasting that path into a cmd window, does nothing.  It just returns to the
prompt
> and the window doesn't appear.  The upgrade of Cygwin did not affect the 
> execution
> of 21.4.18 at all, only 21.4.13.  I'm not using 21.4.18 regularly yet for
other reasons.

Continuing with the guess work, did you move the old xemacs to /usr/local?

Have you checked if the old xemacs depends on libraries you don't currently
have? (i.e. cygcheck /usr/local/bin/i686-pc-cygwin/xemacs-21.4.13)

Please keep replies to the list.
-- 
René Berber


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

Re: cygwin-1.5.19-2: mkdir returns inconsistent errno

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Alex Riesen on 1/27/2006 11:26 AM:
> 
> This was a bit prematurely. There is a big problem with this aproach:
> it changes current directory of the process. So you can't really use
> it in multithreaded or signalled environment.
> So chdir is not a real solution. Is it really that hard to workaround
> the problem in cygwin?

If the Austin Group API set 2 is approved
(http://www.opengroup.org/austin/mailarchives/ag/msg08954.html), you will
have mkdirat() that creates directories relative to an open file
descriptor on an existing directory; that would alleviate the
non-threadsafe use of chdir().  Until then, I don't know of ANY race-free
way to create a directory immediately followed by chdir() or open() that
guarantees that you used the same directory already made by mkdir().
Maybe if you call mkdir() restricting the access to just the user, then
open(O_NOFOLLOW), then fchmod().  What would be cool would be something
like giving valid semantics to open(O_CREAT|O_DIRECTORY) that acts as
mkdir(), but I doubt that will happen, either, thanks to current Linux
semantics (http://lkml.org/lkml/2005/9/24/8).  Meanwhile, you can always
spawn mkdir(1) and have another process, with no restrictions on using
chdir(), do the directory creation for you.

If it is really that much of a problem for you, you should consider
raising a defect against the POSIX standard requesting that mkdir() be
guaranteed to fail with EEXIST on an existing directory, even if EROFS or
EACCES or EPERM would also otherwise apply.

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

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

iD8DBQFD2p8Q84KuGfSFAYARAvITAKCHIEaVqyvIiEYnBDVM6Ihy2QyRmQCfZ+z0
p8JdUvzJYfWr3f/a2BV8dIw=
=+t2b
-END PGP SIGNATURE-

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

Re: Cygwin Bash window disappear?!

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Daniel mark on 1/27/2006 2:04 PM:
> Hello all:
> 
> I met a very strange problem as follows:
> 
> After I finish installing the latest version of cygwin on my computer, I try 
> to
> run C:\cygwin\cygwin.bat. The only thing I got is a black window splash for a
> second and then immediately disappear.

Try opening a regular Windows console (cmd.com), and starting bash there.
 Perhaps that will give you a clue of what is failing.  Also, consider
following the directions here, of attaching, as a text file, the output of
cygcheck -svr:

> Problem reports:   http://cygwin.com/problems.html

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

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

iD8DBQFD2p9284KuGfSFAYARAqW3AJwJDl0ENc7eqvWLua1zdpKhz3uyAgCgqyGh
1+qC5101Y2c8frB3z6bszgI=
=7TPg
-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: readline-5.1 && CGDB

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Rossi on 1/27/2006 3:08 PM:
> Hi,
> 
> I finally managed to compile CGDB with readline-5.1 statically. I
> compiled against a version of readline that has multibyte turned on, and
> a version with it turned off.
> 
> In both cases I have the same results. CGDB is displayed awkardly in the
> curses window. I have finally discovered that this appears to be a
> LINES/COLS bug. If I connect via putty into the windows machine, and set
> the putty window to be 25/80 LINES/COLUMNS, then all works. Otherwise,
> the terminal is the wrong size.
> 

Can you provide any more details?  How about a simple, reproducible test
case?  Otherwise, you are pretty much debugging this on your own.

> I'm convinced the problem is the call into readline. Is it possible
> there were any changes to readline that would effect this? I'm sure
> other curses apps will notice this problem, so it would be nice to fix
> it before the next readline minor release.

Consider asking upstream, at bug-bash AT gnu DOT org.  I'm not aware of
any cygwin-specific changes, so it would be an upstream change.

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

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

iD8DBQFD2qBj84KuGfSFAYARAgZ7AKCHfNfLQ+f83z44MtXxF/Zm3ski7ACgiyw1
rq7foFB74CRWKbFFcfhQm6M=
=bGNo
-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: Re: After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[Karr, David]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of René Berber
> 
> Karr, David wrote:
> [snip]
> >>And the command you are running is?
> > 
> > 
> > C:\cygwin\usr\local\bin\i686-pc-cygwin\xemacs-21.4.13.exe
> 
> This is not the xemacs distributed by Cygwin... or is it?

This is the Xemacs built for Cygwin, but not distributed through cygwin.

> Continuing with the guess work, did you move the old xemacs 
> to /usr/local?

No, I didn't manually move anything.

> Have you checked if the old xemacs depends on libraries you 
> don't currently have? (i.e. cygcheck 
> /usr/local/bin/i686-pc-cygwin/xemacs-21.4.13)

I verified that all the dlls listed in this output exist (just piped it to 
"xargs ls").

Remember that the only change I made was upgrading Cygwin from 1.5.18 to 
1.5.19.  I didn't intentionally remove any libraries.

--
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: Calling shell script from DOS

[Herb Martin]

> > I have installed Cygwin. I want to invoke a shell
> > script from the DOS/Windows command prompt (instead of
> > opening Cygwin Window first and calling it from
> > there). How can I do this?
> 
> In addition to what others said, use "bash -c" instead of 
> "bash" to honor
> the shebang ("#!") line.  This would then work for tcsh, ksh, perl,
> python, [you name it] scripts, as well as symlinks.  In fact, 
> whenever you
> need to invoke a Cygwin program from the DOS prompt, and you 
> don't know if
> it's a script, a symlink, or an actual .exe, you can't go 
> wrong with "bash
> -c progname".

Excellent!!!  I had noticed that things like 
"ls", "dir", "d" didn't work (without that -c).

Now they do too!

Or course, they would just run anyway without the
bash but you are correct that one must otherwise
know "what type" of command it is.

> Adding --login (-l) is optional, but may be useful for 
> scripts that make
> assumptions about your environment.

cool.

--
Herb Martin

> 


--
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: Warning: Never use M$ files+settings transfer wizard to move a cygwin installation.

[Tom Rodman]

On Thu 1/26/06 17:57 GMT "Dave Korn" wrote:
--snip
>   I made the terrible mistake of trying to use M$ migwiz.exe to
> recover my old cygwin installation from a dead machine's drive to a
> new one.
>
>   I thought it might be just a simple archiver that would conveniently
> help move all my stuff across without losing ACLs and so on.

I use ntbackup (backing up to a file), it preserves the DACL, owner and
posix group. I have a wrapper bash script for ntbackup , so I can call
it from with in an ssh session.

If your moving to a new domain, you can do all sorts of DACL, owner,
and posix group, (recursive) edits with "setacl":

  http://setacl.sourceforge.net/html/examples.html

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

Re: After update from 1.5.18 to 1.5.19, xemacs 21.4.13 can only run from bash

[René Berber]

Karr, David wrote:
[snip]
> I verified that all the dlls listed in this output exist (just piped it to 
> "xargs ls").
> 
> Remember that the only change I made was upgrading Cygwin from 1.5.18 to 
> 1.5.19.  I didn't intentionally remove any libraries.

There was a change in postgresql that broke my xemacs a month or two ago: the
old xemacs used a library named "pq.dll" that was changed, in the new postgres,
to "cygpq.dll".

The fix was very simple at the time, I just made a hard link from cygpq.dll to
pq.dll; with the new version of xemacs the dependency is only to cygpq.dll, I
even deleted the link.

HTH
-- 
René Berber



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

Re: Cygwin Bash window disappear?!

[Daniel mark]

Eric Blake  byu.net> writes:

> Try opening a regular Windows console (cmd.com), and starting bash there.
>  Perhaps that will give you a clue of what is failing.  Also, consider
> following the directions here, of attaching, as a text file, the output of
> cygcheck -svr:
> 

There are no error at all.

Now I can see the bash window(I don't know why), but all applications except

'ls' don't work.

It even cannot find my root directory.
but it always tells me that "Install complete"

so strange!

My user account name is "XXX YYY". Does it prevent cygwin from installing 
correctly?

thank you
-Daniel


--
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 Bash window disappear?!

[Eric Blake]

> > following the directions here, of attaching, as a text file, the output of
> > cygcheck -svr:

Until you do this, I have no idea how to help you further.

> 
> My user account name is "XXX YYY". Does it prevent cygwin from installing 
> correctly?

No, although spaces in user names tend to cause other problems, so
it is worth editing /etc/passwd to come up with an alternate username
without spaces for use by cygwin.

> Problem reports:   http://cygwin.com/problems.html

Please read and follow these instructions.

--
Eric Blake

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

Cygwin heap problems

[Ian Elbury]

I have been having all kinds of problems with cygwin recently that have 
manifested themselves with some the of the following errors:

- stack write copy failed, 0x22E960..0x23, done 0, windows pid 2287764, 
Win32 error 5 bash: fork: No error
- fatal error - couldn't allocate heap, Win32 error 487
- Post install shell scripts not completing etc.
- ++ more ... what a gong show!

I think that I have located the source of the heap allocation problem (at 
least in my case) and it appears to be the Logitech camera driver. I noticed 
that all processes loaded a DLL (LVPrcInj.dll - Logitech Helper DLL) and that 
when the sh.exe and bash.exe processes hung, there was a thread that was 
spending a lot of time in RtlConvertUiListToApiList(). Now that I have removed 
the driver, cygwin appears to be working correctly again.

I am not sure if this is the cause of other peoples problems in this area, but 
they want to verify if the have V9 of the Logitech drivers installed? I have 
another machine with a similar configuration and older Logitech drivers and it 
appears to work Ok.

Hopefully this helps in tracking down the heap problems or solves the heap 
problem

Cheers


--
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 Bash window disappear?!

[Brett Serkez]

> I met a very strange problem as follows:
>
> After I finish installing the latest version of cygwin on my computer,
> I try to run C:\cygwin\cygwin.bat. The only thing I got is a black
> window splash for a second and then immediately disappear.

Try running the script from a DOS command prompt so you can see what is
happening.  You can start a command prompt using start -> run, enter
cmd and enter.  Then type c:\cygwin\cygwin.bat and see what errors you
are getting.

Brett

Brett C. Serkez, Techie


--
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 Bash window disappear?!

[Daniel mark]

Hello Eric:

> > > following the directions here, of attaching, as a text file, the output of
> > > cygcheck -svr:

I downloaded the install package from 
mirror.mcs.anl.gov with size of 104M
After I finish full installation.

cygcheck -svr

I got the following staff;

thank you again
//
Cygwin Configuration Diagnostics
Current System Time: Thu Apr 27 22:16:49 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\Program Files\texmf\miktex\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\UltraEdit
C:\Program Files\MATLAB704\bin\win32
c:\matlab6p5\bin\win32
C:\Program Files\Diskeeper Corporation\Diskeeper\
C:\Program Files\JMF2.1.1e\lib
C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
C:\Program Files\Microsoft Visual Studio\Common\Tools
C:\Program Files\Microsoft Visual Studio\VC98\bin
C:\Program Files\SSH Communications Security\SSH Secure Shell
C:\Program Files\j2sdk1.4.2_09\bin
.

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

Path = 'C:\Program
Files\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
C:\Program
Files\UltraEdit;C:\Program
Files\MATLAB704\bin\win32;c:\matlab6p5\bin\win32;C:\Program Files\Diskeeper
Corporation\Diskeeper\;C:\Program Files\JMF2.1.1e\lib;C:\Program Files\Microsoft
Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual
Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual
Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin;C:\Program
Files\SSH Communications Security\SSH Secure Shell;C:\Program
Files\j2sdk1.4.2_09\bin;'

ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\XXX YY\Application Data'
CLASSPATH =
'C:\PROGRA~1\JMF21~1.1E\lib\sound.jar;C:\PROGRA~1\JMF21~1.1E\lib\jmf.jar;
C:\PROGRA~1\JMF21~1.1E\lib;C:\WINDOWS\java\classes;.'
CommonProgramFiles = 'C:\Program Files\Common Files'
COMPUTERNAME = 'DANCINGA-B7822D'
ComSpec = 'C:\WINDOWS\system32\cmd.exe'
FP_NO_HOST_CHECK = 'NO'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\XXX YY'
include = 'C:\Program Files\Microsoft Visual Studio\VC98\atl\include;
C:\Program
Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft 
Visual
Studio\VC98\include'
lib = 'C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program
Files\Microsoft Visual Studio\VC98\lib'
LOGONSERVER = '\\DANCINGA-B7822D'
MSDevDir = 'C:\Program Files\Microsoft Visual Studio\Common\MSDev98'
NUMBER_OF_PROCESSORS = '1'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 12 Stepping 0, AuthenticAMD'
PROCESSOR_LEVEL = '15'
PROCESSOR_REVISION = '0c00'
ProgramFiles = 'C:\Program Files'
PROMPT = '$P$G'
SESSIONNAME = 'Console'
SystemDrive = 'C:'
SystemRoot = 'C:\WINDOWS'
USERNAME = 'XXX YY'
USERPROFILE = 'C:\Documents and Settings\XXX YY'
windir = 'C:\WINDOWS'
__COMPAT_LAYER = 'EnableNXShowUI '
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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'C:\cygwin/lib'
  flags = 0x000a

c:  hd  NTFS 29996Mb  84% CP CS UN PA FC notebook_system
d:  hd  NTFS 27227Mb  83% CP CS UN PA FC notebook_data
e:  cd N/AN/A

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

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

  509k 2006/01/11 C:\cygwin\bin\cygfftw3-3.dll - os=4.0 img=1.0 sys=4.0
  "cygfftw3-3.dll" v0.0 ts=2006/1/10 20:24
   69k 2006/01/11 C:\cygwin\bin\cygfftw3_threads-3.dll - os=4.0 img=1.0 sys=4.0
  "cygfftw3_threads-3.dll" v0.0 ts=2006/1/11 7:27
  451k 2005/12/27 C:\cygwin\bi

Re: i686-pc-cygwin on an i586

[Christopher Faylor]

On Fri, Jan 27, 2006 at 03:06:44PM -0700, Eric Blake wrote:
>According to Dave Korn on 1/27/2006 9:34 AM:
>>Nope, don't worry about it, that's a bit of a red-herring.  By default,
>>the code gcc generates is good for everything from '486 up.  The
>>instruction scheduling and choice of which instructions to use may be
>>tuned to be optimal for a 686 and so may be less-than-optimal on a
>>'586, but there should not be any actual backward-compatibility issues.
>
>Speaking of which, should the next release of cygwin gcc be configured
>to generate code tuned for 686, rather than penalizing most modern CPUs
>with 386-compatible but slower code sequences?

Why do you assume that this is not already the case?  I use i686-pc-cygwin
as the target for everything that I build and I use a i686-pc-cygwin-gcc
cross compiler.

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/