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

[Louis Lecaroz]

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

>>That's two requests that you follow the guidelines at this page now and
>>you still haven't completely complied.
I will try to fully complied to the guidelines in my next communication.

>>Since you have now (finally) informed us that you are using a non-cygwin
>>binaries, then please read Brian Ford's response to your question.  Cygwin
>>now uses a more efficient mechanism for communicating the environment to
>>cygwin processes.  It does not fill out the windows environment if it
>>knows that the process being started is using the cygwin DLL.

That's explain that I felt, as the child process was inheriting from the parent 
environment everytime but not non-cygwin DLLs introduced through the LD_PRELOAD 
in these child process... Is there a flag or a way to enable environment 
variable to be propaged throught the Win32 environment as done before on 
1.5.18-x or do I have to use  DECLARE_CYGWIN_DLL(Entry) & other mechanisms for 
having my DllMain called as I do specifics initializations for processes & 
threads.  but that's means compiling all my source containing also assembler & 
lot of specifics things under gcc :(

Or do this code will help me for having Cygwin environment variables propagated 
& set in my MSVC dll loaded throught LD_PRELOAD ? by calling the code below is 
the child process will have his Win32 environment settings set correctly & 
"retrievable" through GetEnvironmentString() & other Win32 std apis?
Or should I have also to call throught getprocaddress() (after having called 
LoadLibrary on cygwin1.dll) some cygwin C std methods like getenv() for 
retrieving cygwin environment variables without porting my code under gcc & 
staying with microsoft dev studio 2003 ?

HMODULE h = LoadLibrary("cygwin1.dll");
void (*init)() = GetProcAddress(h, "cygwin_dll_init");
init();

>From your point of view, what is the best way for retrieving & inheriting in 
>non cygwin DLL loaded throught LD_PRELOAD of cygwin environment variables ?
thx in advance for your future answers,
Louis

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

Re: sshd password authentication results in identity of NT AUTHORITY\SYSTEM

[Corinna Vinschen]

On Jan 30 12:57, Perdue, Dave T.  CIV NAVAIR 5.4.3, Bldg 2035, Rm 205, Cube 200 
wrote:
>   The Cygwin "whoami" command reports the correct username,
>   however the Window Resource kit "whoami.exe" reports "NT
>   Authority\SYSTEM" for the username when using a password
>   authenticated ssh login.  The user's SID is identical, just the
>   username is different.  I have read responses in the Cygwin mail
>   lists that indicated that RSA authenticated logins should act
>   this way (no access to network shares due to incomplete user
>   impersonation) however it also indicated that password
>   authentication should provide network share access.  A minimal
>   installation of Cygwin to support ssh (Cygwin with cygrunsrv and
>   openssh) shows proper user context switching for Cygwin-1.5.12-1
>   but fails using Cygwin-1.5.19-4.  I do not have access to
>   versions 13-17 so I cannot determine at what point full support
>   of password authentication "broke".

I don't know what's wrong on your machine, but I tried on two different
machines under Windows 2000 and under XP, and the user context switch
works as expected in both cases; a native whoami returns SYSTEM for a
password-less login and the user name for a password login.


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/

Bash got messed after update

[Ismael Valladolid Torres]

I just installed using setup.exe the readline devel package, and as
usual some other packages got updated. Later when opening an xterm
I've noticed some oddities in my bash session, i.e. cwd is `/' instead
of `~', running `ls --color' gives a strange color to directories, `.' is
in my path when I'm not putting it there in any of my setup files,
`/usr/local/bin' is no longer in my path, etc.

All these symptoms even after rebooting.

Checking /var/log/setup.log I see errors related to bash:

2006/01/31 09:42:03 Running preremove script for  base-files
2006/01/31 09:42:03 running: C:\cygwin\bin\bash.exe -c 
/etc/preremove/base-files.sh
2006/01/31 09:42:03 abnormal exit: exit code=0

2006/01/31 09:42:12 Installing 
file://C:\cygwin/http%3a%2f%2fftp.rediris.es%2fmirror%2fcygwin/release/bash/bash-3.0-14.tar.bz2
2006/01/31 09:42:12 io_stream_cygfile: fopen failed 13 Permission denied
2006/01/31 09:42:12 Failed to open cygfile:///usr/bin/bash.exe for writing.
2006/01/31 09:42:12 Scheduled reboot replacement of file 
C:\cygwin/bin//bash.exe with C:\cygwin/bin//bash.exe.new

Yes, an xterm window running bash was open, this should not be an
issue, should it?

2006/01/31 09:42:16 Installing 
file://C:\cygwin/http%3a%2f%2fftp.rediris.es%2fmirror%2fcygwin/release/cygwin/cygwin-1.5.19-4.tar.bz2
2006/01/31 09:42:17 io_stream_cygfile: fopen failed 13 Permission denied
2006/01/31 09:42:17 Failed to open cygfile:///usr/bin/cygwin1.dll for writing.
2006/01/31 09:42:20 Scheduled reboot replacement of file 
C:\cygwin/bin//cygwin1.dll with C:\cygwin/bin//cygwin1.dll.new

The same as before.

2006/01/31 09:42:55 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/00bash.sh
2006/01/31 09:43:00 running: cmd.exe /c C:\cygwin\etc\postinstall\01bash.bat
2006/01/31 09:43:00 abnormal exit: exit code=0
2006/01/31 09:43:00 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/base-files-mketc.sh
2006/01/31 09:43:00 abnormal exit: exit code=0
2006/01/31 09:43:00 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/base-files-profile.sh
2006/01/31 09:43:07 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/coreutils.sh
2006/01/31 09:43:09 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/iu-config.sh
2006/01/31 09:43:09 abnormal exit: exit code=0
2006/01/31 09:43:09 running: C:\cygwin\bin\bash.exe -c 
/etc/postinstall/update-info-dir.sh
2006/01/31 09:43:13 abnormal exit: exit code=0
2006/01/31 09:43:15 mbox note: Installation Complete
2006/01/31 09:43:16 Ending cygwin install

Any way to correct this? Would running again the postinstall scripts
help?

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

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


pgpkRjR2FxHIm.pgp
Description: PGP signature

RE: Bash got messed after update

[Dave Korn]

On 31 January 2006 09:50, Ismael Valladolid Torres wrote:

> I just installed using setup.exe the readline devel package, and as usual
> some other packages got updated. Later when opening an xterm I've noticed
> some oddities in my bash session, i.e. cwd is `/' instead of `~', running
> `ls --color' gives a strange color to directories, `.' is in my path when
> I'm not putting it there in any of my setup files, `/usr/local/bin' is no
> longer in my path, etc. 
> 
> All these symptoms even after rebooting.
> 
> Checking /var/log/setup.log I see errors related to bash:

  All that detail, but no cygcheck.out.  Sigh.

> Any way to correct this? Would running again the postinstall scripts help?

  It'd be worth a) checking if any postinstall scripts didn't complete (re-run 
any that don't have .done on the end) b) re-running
setup and just clicking right through so it'll pick up any dependencies it 
might have missed first time round c) attaching your
cygcheck.out when you post with a problem ...

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: Running grep and other cygwin commands from cmd.exe

[Dave Korn]

On 31 January 2006 06:20, Tzuriel wrote:

> I hope I am asking this correctly.  I would like to be able to open a
> regular cmd.exe (Windows shell) window and run cygwin commands from there
> without opening bash in it's own command window.  Can this be done? 
> Basically, I want to use .cmd and .bat scripts that use grep within
> scripts that run in a Windows environment.  I hope this makes sense!


  NP.  Just add C:\cygwin\bin (or whereever your cygwin /bin dir lives) to the 
%PATH% setting in your windows system environment
variables.


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-4 exec family of functions find wrong file to execute

[Dave Korn]

On 30 January 2006 19:23, Martin wrote:

> Any response?
> TIA
> --- Martin <[EMAIL PROTECTED]> wrote:
> 
>> I am attempting to invoke a command with execvp/execlp.  If a file
>> appears in my PATH before the executable desired and has the same name
>> as the executable, the first occurrence of the file name is used as
>> the executable to invoke.  Even though the first file is NOT marked as
>> executable. 

>> Is this normal behavior for execlp/execvp?
>> Shouldn't the execution permission be set in order to execute it?


  Depends on your mountpoints.  If the file is found under a mountpoint with 
the cygexec flag set, it will be assumed to be
executable regardless of the x bit in the file's perms.


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: Bash got messed after update

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ismael Valladolid Torres on 1/31/2006 2:49 AM:
> I just installed using setup.exe the readline devel package, and as
> usual some other packages got updated. Later when opening an xterm
> I've noticed some oddities in my bash session, i.e. cwd is `/' instead
> of `~', running `ls --color' gives a strange color to directories, `.' is
> in my path when I'm not putting it there in any of my setup files,
> `/usr/local/bin' is no longer in my path, etc.

Sounds like your installation lost track of where $HOME should be set to,
so it is not picking up any of your setup files, explaining the follow-on
behavior changes.

> 
> All these symptoms even after rebooting.

Rebooting won't rerun postinstall scripts.  It is easiest to explicitly
rerun setup.exe and reinstall the packages (such as bash) that had botched
postinstall runs.  If, after that, you still have problems, the attached
output of cygcheck -svr is essential to us helping you.

> 
> Yes, an xterm window running bash was open, this should not be an
> issue, should it?

Actually, it would be an issue.  Bash can't upgrade itself while bash is
running, which makes all postinstall scripts suspect.  Upgrades work best
when all cygwin processes are halted.

> 
> 2006/01/31 09:42:16 Installing 
> file://C:\cygwin/http%3a%2f%2fftp.rediris.es%2fmirror%2fcygwin/release/cygwin/cygwin-1.5.19-4.tar.bz2
> 2006/01/31 09:42:17 io_stream_cygfile: fopen failed 13 Permission denied
> 2006/01/31 09:42:17 Failed to open cygfile:///usr/bin/cygwin1.dll for writing.
> 2006/01/31 09:42:20 Scheduled reboot replacement of file 
> C:\cygwin/bin//cygwin1.dll with C:\cygwin/bin//cygwin1.dll.new
> 
> The same as before.

You aren't quite painting an accurate picture - you upgraded more than
just bash; you also picked up an upgrade to cygwin.

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

iD8DBQFD32Np84KuGfSFAYARAhzuAKC6dGP3tM4lfL9lSGhZAl8CAH3OZACgsQy5
tYPnv7jyYVpYfoy85aj5ik0=
=RYFU
-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/

Tiny Errors in Mirrors

[big one]

There are several insignificant errors at Mirrors:

1. /DLL/cygwin/release/foo

What is this file?

2. /DLL/cygwin/release/gperf

2 of the files are in ".gz" format, not ".bz2".
Can someone change the format of the file?

3. /DLL/cygwin/release/GNOME/gtk2-x11-engines/

The checksum of 2 files are missing from the "md5.sum" file.

4. /DLL/cygwin/release/tetex/tetex-x11/

There is a "setup.hint~" file on the "md5.sum" file.

Can someone fix the problem?
Thank you.

_
= You want FREE web-based email ? 
= You want your own @qon.lao.net address??
= Then you want LaoNet's WebMail !
= Get it at http://webmail.lao.net !!

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

ReactOS + Cygwin LiveCD

[big one]

If the ReactOS project is finished/reached Beta version, is it possible to 
combine Cygwin and ReactOS for creating a LiveCD?

Thank you.

http://www.reactos.org/en/index.html


_
= You want FREE web-based email ? 
= You want your own @qon.lao.net address??
= Then you want LaoNet's WebMail !
= Get it at http://webmail.lao.net !!

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

chdir on remote win98

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"cvs up -P" dies a horrible death when trying to update a hierachy where a
directory exists in the upstream repository, but contains no files so that
the directory has been pruned on the local checkout.  This happens only
when I access my local checkout on a Win98 machine via remote access
driven by XP (in other words, running the same command locally on the
Win98 has no problems, it is only the remote network access failing):

$ uname -a
CYGWIN_NT-5.1 LOUNGE 1.5.19(0.150/4/2) 2006-01-16 15:01 i686 Cygwin
$ cd win98/coreutils
$ cvs up -dP
M Makefile.in
cvs [update aborted]: could not chdir to config: Invalid request code

I traced this to the fact that cvs expects ENOENT, and chokes when chdir
returns EBADRQC instead.  A simple strace shows that cygwin1.dll could
probably be taught that a bad request return from a remote Win9x
filesystem during chdir() should be treated as the expected ENOENT:

$ strace bash -c 'cd ~/win98/coreutils/config'
...
   34  514661 [main] bash 2536 chdir: dir 'config'
   28  514689 [main] bash 2536 normalize_posix_path: src config
   29  514718 [main] bash 2536 cwdstuff::get: posix
/cygdrive/j/cygwin/home/eblake/coreutils
   29  514747 [main] bash 2536 cwdstuff::get:
(/cygdrive/j/cygwin/home/eblake/coreutils) = cwdstuff::get (0x22E610, 260,
1, 0), errno 54
  108  514855 [main] bash 2536 normalize_posix_path:
/cygdrive/j/cygwin/home/eblake/coreutils/config = normalize_posix_path
(config)
   33  514888 [main] bash 2536 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive/j/cygwin/home/eblake/coreutils/config)
   33  514921 [main] bash 2536 mount_info::cygdrive_win32_path: src
'/cygdrive/j/cygwin/home/eblake/coreutils/config', dst
'j:\cygwin\home\eblake\coreutils\config'
   29  514950 [main] bash 2536 set_flags: flags: binary (0x2)
   28  514978 [main] bash 2536 mount_info::conv_to_win32_path: src_path
/cygdrive/j/cygwin/home/eblake/coreutils/config, dst
j:\cygwin\home\eblake\coreutils\config, flags 0x2A, rc 0
 1539  516517 [main] bash 2536 symlink_info::check: GetFileAttributes
(j:\cygwin\home\eblake\coreutils\config) failed
  108  516625 [main] bash 2536 geterrno_from_win_error: windows error 2 ==
errno 2
 1388  518013 [main] bash 2536 symlink_info::check: GetFileAttributes
(j:\cygwin\home\eblake\coreutils\config.lnk) failed
  173  518186 [main] bash 2536 geterrno_from_win_error: windows error 2 ==
errno 2
   32  518218 [main] bash 2536 symlink_info::check: 0 = symlink.check
(j:\cygwin\home\eblake\coreutils\config, 0x22E2D0) (0x2A)
 2435  520653 [main] bash 2536 mount_info::conv_to_win32_path:
conv_to_win32_path (/cygdrive/j/cygwin/home/eblake/coreutils)
   74  520727 [main] bash 2536 mount_info::cygdrive_win32_path: src
'/cygdrive/j/cygwin/home/eblake/coreutils', dst
'j:\cygwin\home\eblake\coreutils'
   31  520758 [main] bash 2536 set_flags: flags: binary (0x2)
   28  520786 [main] bash 2536 mount_info::conv_to_win32_path: src_path
/cygdrive/j/cygwin/home/eblake/coreutils, dst
j:\cygwin\home\eblake\coreutils, flags 0x2A, rc 0
 1549  522335 [main] bash 2536 symlink_info::check: not a symlink
  109  522444 [main] bash 2536 symlink_info::check: 0 = symlink.check
(j:\cygwin\home\eblake\coreutils, 0x22E2D0) (0x2A)
   35  522479 [main] bash 2536 path_conv::check:
this->path(j:\cygwin\home\eblake\coreutils\config), has_acls(0)
 1350  523829 [main] bash 2536 seterrno_from_win_error:
/netrel/src/cygwin-1.5.19-1/winsup/cygwin/path.cc:3965 windows error 1
  137  523966 [main] bash 2536 geterrno_from_win_error: windows error 1 ==
errno 54
   30  523996 [main] bash 2536 __set_errno: void
seterrno_from_win_error(const char*, int, DWORD):310 val 54
   32  524028 [main] bash 2536 chdir: -1 = chdir() cygheap->cwd.posix
'/cygdrive/j/cygwin/home/eblake/coreutils' native
'j:\cygwin\home\eblake\coreutils\config'
bash: line 0: cd: config: Invalid request code
...

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

iD8DBQFD32jI84KuGfSFAYARAseFAKCv8E0io02NJI/WR4LYIBNFVHGErACfYsna
4K2BEodNiEe7i1lB43YKKPQ=
=ssIG
-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: Tiny Errors in Mirrors

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to big one on 1/31/2006 6:20 AM:
> There are several insignificant errors at Mirrors:
> 
> 1. /DLL/cygwin/release/foo
> 
> What is this file?

An empty file placed there to make you ask questions, obviously!  Now deleted.

> 
> 2. /DLL/cygwin/release/gperf
> 
> 2 of the files are in ".gz" format, not ".bz2".
> Can someone change the format of the file?

I won't touch them.  setup.exe is capable of either compression format,
and packages that have not been upgraded in a LONG time still use .gz
without any problems.  I once volunteered to take over maintainership of
gperf, but cgf insisted that he still owns it.  Even though gperf

> 
> 3. /DLL/cygwin/release/GNOME/gtk2-x11-engines/
> 
> The checksum of 2 files are missing from the "md5.sum" file.

OK, should be fixed.

> 
> 4. /DLL/cygwin/release/tetex/tetex-x11/
> 
> There is a "setup.hint~" file on the "md5.sum" file.

OK, should be fixed.

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

iD8DBQFD32rK84KuGfSFAYARAmw4AKCfK/lakthmOBuPnUetbtg6kvDVJwCggvF4
mKjUzLsrkz7nD0G4ymuT5V4=
=EOyp
-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: Tiny Errors in Mirrors

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Eric Blake on 1/31/2006 6:48 AM:
> 
> I won't touch them.  setup.exe is capable of either compression format,
> and packages that have not been upgraded in a LONG time still use .gz
> without any problems.  I once volunteered to take over maintainership of
> gperf, but cgf insisted that he still owns it.  Even though gperf

Argh - I hit send too early.

Even though gperf is now at 3.0.1 upstream, cygwin is stuck with
gperf-2.7.2 unless its maintainer decides to release an upgrade.

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

iD8DBQFD32wn84KuGfSFAYARAuf0AKCnV879gxo6nmiqT2yfNmEGDmHTgQCg1384
h7eI+XXs0n/dmkNaE/F0yI4=
=M10K
-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: csh script hangs only on cygwin

[Corinna Vinschen]

On Jan 30 13:17, Stewart Midwinter wrote:
> Corinna Vinschen wrote:
> >WFM.  I tried it for > 3 hours with no hang.
> 
> Corinna, what OS and type of box are you running that on?  My problem
> arose ONLY when running on a Xeon and with Windows Server 2003.  On
> other boxes, and other operating systems, e.g Windows 2000, there was
> no problem.

I tried on XP SP2 on a 2Megs AMD Athlon, and, just finished, on 2K3 on
1.8 Gigs AMD Opteron for almost 5 hours.

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


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: 1.5.19-4 exec family of functions find wrong file to execute

[Igor Peshansky]

On Tue, 31 Jan 2006, Dave Korn wrote:

> On 30 January 2006 19:23, Martin wrote:
>
> > Any response?
> > TIA
> > --- Martin <[EMAIL PROTECTED]> wrote:
> >
> >> I am attempting to invoke a command with execvp/execlp.  If a file
> >> appears in my PATH before the executable desired and has the same name
> >> as the executable, the first occurrence of the file name is used as
> >> the executable to invoke.  Even though the first file is NOT marked as
> >> executable.
>
> >> Is this normal behavior for execlp/execvp?
> >> Shouldn't the execution permission be set in order to execute it?
>
>   Depends on your mountpoints.  If the file is found under a mountpoint
> with the cygexec flag set, it will be assumed to be executable
> regardless of the x bit in the file's perms.

Also, on FAT filesystems, there are no permission bits[*]...  Your file
may be tripping the executable file detection heuristics, though.
Igor
[*] Cygwin can simulate them for you on pure FAT with "ntea", but with
FAT32 you're SOL.
-- 
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/

Building .so files for Apache 2.2.0 on Cygwin 1.5.19-4

[Jacco]

Hey there

I'm a complete newbie to cygwin and a "more-or-less" newbie with linux.

But I came with the idea to create my own apache module. And linux is
obviuous the platform to go for.

Apache 2.2.0 compiled, installed and works fine.

However when I try to get the (ultra basic) module from
http://threebit.net/tutorials/apache2_modules/tut1/tutorial1.html
working, I get the error:
"Warning! dlname not found" (see attachement for complete output)

I have a '.a' and '.la' file, but no .so file

As far as I can tell this problem has notting to do with my module since the
same problem seems to arise with PHP5, mod_security and others on cygwin.
>From various threads I've read there seems to be an issue with libtool??
However nobody seems to have a definitive solution for this. (and all the
things I tried didn't work) and the cygwin mailing list archives didn't come
up with the cause of the error either.

So I came to the point where I, with my limited knowledge, am at a complete
loss.
I thought that it maybe has something to do with the w2k-platform expecting
.dll files but there is nothing pointing in that direction.

Is there anyone out there who can point me in the right direction here ?
and maybe even provide a solution?

-greetings-
Jacco
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="prompt_dump.txt"

fi90aHJlZWJpdC10dXRvcmlhbHMNCiQgdGFyIHp4ZiB0dXRvcmlhbHMudGFyLmd6DQoNCn4vdGhy
ZWViaXQtdHV0b3JpYWxzDQokIGNkIGFwYWNoZTJfbW9kdWxlcy90dXQxDQoNCn4vdGhyZWViaXQt
dHV0b3JpYWxzL2FwYWNoZTJfbW9kdWxlcy90dXQxDQokIGFjbG9jYWwNCg0Kfi90aHJlZWJpdC10
dXRvcmlhbHMvYXBhY2hlMl9tb2R1bGVzL3R1dDENCiQgbGlidG9vbGl6ZQ0KDQp+L3RocmVlYml0
LXR1dG9yaWFscy9hcGFjaGUyX21vZHVsZXMvdHV0MQ0KJCBhdXRvY29uZg0KDQp+L3RocmVlYml0
LXR1dG9yaWFscy9hcGFjaGUyX21vZHVsZXMvdHV0MQ0KJCBhdXRvbWFrZSAtYQ0KY29uZmlndXJl
LmluOiBpbnN0YWxsaW5nIGAuL2luc3RhbGwtc2gnDQpjb25maWd1cmUuaW46IGluc3RhbGxpbmcg
YC4vbWlzc2luZycNCk1ha2VmaWxlLmFtOiBpbnN0YWxsaW5nIGAuL2RlcGNvbXAnDQoNCn4vdGhy
ZWViaXQtdHV0b3JpYWxzL2FwYWNoZTJfbW9kdWxlcy90dXQxDQokIC4vY29uZmlndXJlIC0td2l0
aC1hcGFjaGU9L3Vzci9sb2NhbC9hcGFjaGUyLw0KY2hlY2tpbmcgZm9yIGEgQlNELWNvbXBhdGli
bGUgaW5zdGFsbC4uLiAvdXNyL2Jpbi9pbnN0YWxsIC1jDQpjaGVja2luZyB3aGV0aGVyIGJ1aWxk
IGVudmlyb25tZW50IGlzIHNhbmUuLi4geWVzDQpjaGVja2luZyBmb3IgZ2F3ay4uLiBnYXdrDQpj
aGVja2luZyB3aGV0aGVyIG1ha2Ugc2V0cyAkKE1BS0UpLi4uIHllcw0KY2hlY2tpbmcgZm9yIGdj
Yy4uLiBnY2MNCmNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRlZmF1bHQgb3V0cHV0IGZpbGUgbmFt
ZS4uLiBhLmV4ZQ0KY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciB3b3Jrcy4uLiB5ZXMN
CmNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIGNyb3NzIGNvbXBpbGluZy4uLiBubw0KY2hlY2tpbmcg
Zm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcy4uLiAuZXhlDQpjaGVja2luZyBmb3Igc3VmZml4IG9m
IG9iamVjdCBmaWxlcy4uLiBvDQpjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05V
IEMgY29tcGlsZXIuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIGdjYyBhY2NlcHRzIC1nLi4uIHll
cw0KY2hlY2tpbmcgZm9yIGdjYyBvcHRpb24gdG8gYWNjZXB0IEFOU0kgQy4uLiBub25lIG5lZWRl
ZA0KY2hlY2tpbmcgZm9yIHN0eWxlIG9mIGluY2x1ZGUgdXNlZCBieSBtYWtlLi4uIEdOVQ0KY2hl
Y2tpbmcgZGVwZW5kZW5jeSBzdHlsZSBvZiBnY2MuLi4gZ2NjMw0KY2hlY2tpbmcgYnVpbGQgc3lz
dGVtIHR5cGUuLi4gaTY4Ni1wYy1jeWd3aW4NCmNoZWNraW5nIGhvc3Qgc3lzdGVtIHR5cGUuLi4g
aTY4Ni1wYy1jeWd3aW4NCmNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRl
IG91dHB1dC4uLiAvdXNyL2Jpbi9zZWQNCmNoZWNraW5nIGZvciBlZ3JlcC4uLiBncmVwIC1FDQpj
aGVja2luZyBmb3IgbGQgdXNlZCBieSBnY2MuLi4gL3Vzci9pNjg2LXBjLWN5Z3dpbi9iaW4vbGQu
ZXhlDQpjaGVja2luZyBpZiB0aGUgbGlua2VyICgvdXNyL2k2ODYtcGMtY3lnd2luL2Jpbi9sZC5l
eGUpIGlzIEdOVSBsZC4uLiB5ZXMNCmNoZWNraW5nIGZvciAvdXNyL2k2ODYtcGMtY3lnd2luL2Jp
bi9sZC5leGUgb3B0aW9uIHRvIHJlbG9hZCBvYmplY3QgZmlsZXMuLi4gLXINCmNoZWNraW5nIGZv
ciBCU0QtY29tcGF0aWJsZSBubS4uLiAvdXNyL2Jpbi9ubSAtQg0KY2hlY2tpbmcgd2hldGhlciBs
biAtcyB3b3Jrcy4uLiB5ZXMNCmNoZWNraW5nIGhvdyB0byByZWNvZ25pc2UgZGVwZW5kZW50IGxp
YnJhcmllcy4uLiBmaWxlX21hZ2ljIF54ODYgYXJjaGl2ZSBpbXBvcnR8DQpeeDg2IERMTA0KY2hl
Y2tpbmcgaG93IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IuLi4gZ2NjIC1FDQpjaGVja2luZyBm
b3IgQU5TSSBDIGhlYWRlciBmaWxlcy4uLiB5ZXMNCmNoZWNraW5nIGZvciBzeXMvdHlwZXMuaC4u
LiB5ZXMNCmNoZWNraW5nIGZvciBzeXMvc3RhdC5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0ZGxp
Yi5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0cmluZy5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIG1l
bW9yeS5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0cmluZ3MuaC4uLiB5ZXMNCmNoZWNraW5nIGZv
ciBpbnR0eXBlcy5oLi4uIHllcw0KY2hlY2tpbmcgZm9yIHN0ZGludC5oLi4uIHllcw0KY2hlY2tp
bmcgZm9yIHVuaXN0ZC5oLi4uIHllcw0KY2hlY2tpbmcgZGxmY24uaCB1c2FiaWxpdHkuLi4geWVz
DQpjaGVja2luZyBkbGZjbi5oIHByZXNlbmNlLi4uIHllcw0KY2hlY2tpbmcgZm9yIGRsZmNuLmgu
Li4geWVzDQpjaGVja2luZyBmb3IgZysrLi4uIGcrKw0KY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUg
dXNpbmcgdGhlIEdOVSBDKysgY29tcGlsZXIuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIGcrKyBh
Y2NlcHRzIC1nLi4uIHllcw0KY2hlY2tpbmcgZGVwZW5kZW5jeSBzdHlsZSBvZiBnKysuLi4gZ2Nj
Mw0KY2hlY2tpbmcgaG93IHRvIHJ1biB0aGUgQysrIHByZXByb2Nlc3Nvci4uLiBnKysgLUUNCmNo
ZWNraW5nIGZvciBnNzcuLi4gbm8NCmNoZWNraW5nIGZvciBmNzcuLi4gbm8NCmNoZWNraW5nIGZv
ciB4bGYuLi4gbm8NCmNoZWNraW5nIGZvciBmcnQuLi4gbm8NCmNoZWNraW5nIGZvciBwZ2Y3Ny4u
LiBubw0KY2hlY2tpbmcgZm9yIGZvcnQ3Ny4uLiBubw0KY2hlY2tpbmcgZm9yIGZsMzIuLi4gbm8N
CmNoZWNraW5nIGZvciBhZjc

Re: chdir on remote win98

[Corinna Vinschen]

On Jan 31 06:40, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> "cvs up -P" dies a horrible death when trying to update a hierachy where a
> directory exists in the upstream repository, but contains no files so that
> the directory has been pruned on the local checkout.  This happens only
> when I access my local checkout on a Win98 machine via remote access
> driven by XP (in other words, running the same command locally on the
> Win98 has no problems, it is only the remote network access failing):
> 
> $ uname -a
> CYGWIN_NT-5.1 LOUNGE 1.5.19(0.150/4/2) 2006-01-16 15:01 i686 Cygwin
> $ cd win98/coreutils
> $ cvs up -dP
> M Makefile.in
> cvs [update aborted]: could not chdir to config: Invalid request code
> 
> I traced this to the fact that cvs expects ENOENT, and chokes when chdir
> returns EBADRQC instead.  A simple strace shows that cygwin1.dll could
> probably be taught that a bad request return from a remote Win9x
> filesystem during chdir() should be treated as the expected ENOENT:

Thanks, I've applied a patch which explicitely tests this condition.


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/

Cygwin on XP disapearing terminal mystery

[Harry Putnam]

I've been running cygwin in a laptop running XP home.  It was working
as expected.  However its been a while since I used it and not sure
what all has happened that might effect cygwin... but can think of
nothing off hand.

However, now when I click the bash icon a terminal appears and just as
quickly disappears.  I can't use any cygwin tools since the terminal
just flashes once and is gone.

What on earth might cause such behavior?


--
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 disapearing terminal mystery

[Eric Blake]

> However, now when I click the bash icon a terminal appears and just as
> quickly disappears.  I can't use any cygwin tools since the terminal
> just flashes once and is gone.
> 
> What on earth might cause such behavior?

Deja vu!  http://cygwin.com/ml/cygwin/2006-01/msg01363.html

If you expect help, then try opening a plain cmd.com window
first, running bash there and seeing if any error messages
appear.  Also, send, as a text attachment, the output of
'cygcheck -svr'.

--
Eric Blake
volunteer cygwin bash maintainer

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

Using grep from within a .cmd or .bat file in Windows

[Tzuriel]

Hi,

You folks were so helpful with my first question, 
I hope you can help me now also!

I am writing a .cmd script in Windows (same behavior in XP and Server 2003) 
and instead of grep executing the search, it is just 
printing to standard input the command in the .cmd.  
For example the lines:

grep --help
pause

inside a file called grep.cmd,

results in the line "grep --help" printing infinitely 
to the command window instead of the help text being displayed.  
Any variation of this results in the same thing.  
Whenever grep is used, it just prints the text following the grep
infinitely to the command window.

What do I need to add to the script to get 
this to act like it would if I typed
it in the command window manually?

Thank you!

Tzuriel


--
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: Using grep from within a .cmd or .bat file in Windows

[Keith Moore]

Tzuriel wrote:

> grep --help
> pause
> 
> inside a file called grep.cmd,

"grep.cmd" is getting executed recursively. You
need to name your .cmd file something other than
"grep".

KM



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

[Chet Ramey]

Bob Rossi wrote:

> So, when I give readline a PTY, if the size of the LINES and COLUMNS are 
> different then that of stdout, then ncurses get's confused.
> 
> Chet, do you consider this desired functionality? I don't think readline
> should modify the LINES and COLUMNS environment variables if the PTY
> it's using is not stdout. What do you think? 

I'd have to think about it some more, but my first impression is that
the calling application should know the screen size readline is dealing
with, and the LINES and COLUMNS environment variables are an appropriate
mechanism.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live Strong.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/

--
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-4 exec family of functions find wrong file to execute

[Martin]

In response to your comments:
I ran the testcase from ~/testcases directory. I believe my cygwin.out
file indicates /home is mounted from D:\home (HOME=/home/test). Also,
D: is NTFS.  Also, there is nothing special about mount point (no -x
flag was used).  This is all shown in cygwin.out.

Martin

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

> On Tue, 31 Jan 2006, Dave Korn wrote:
> 
> > On 30 January 2006 19:23, Martin wrote:
> >
> > > Any response?
> > > TIA
> > > --- Martin <[EMAIL PROTECTED]> wrote:
> > >
> > >> I am attempting to invoke a command with execvp/execlp.  If a
> file
> > >> appears in my PATH before the executable desired and has the
> same name
> > >> as the executable, the first occurrence of the file name is used
> as
> > >> the executable to invoke.  Even though the first file is NOT
> marked as
> > >> executable.
> >
> > >> Is this normal behavior for execlp/execvp?
> > >> Shouldn't the execution permission be set in order to execute
> it?
> >
> >   Depends on your mountpoints.  If the file is found under a
> mountpoint
> > with the cygexec flag set, it will be assumed to be executable
> > regardless of the x bit in the file's perms.
> 
> Also, on FAT filesystems, there are no permission bits[*]...  Your
> file
> may be tripping the executable file detection heuristics, though.
>   Igor
> [*] Cygwin can simulate them for you on pure FAT with "ntea", but
> with
> FAT32 you're SOL.
> -- 
>   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/
> 
> 







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

Re: Using grep from within a .cmd or .bat file in Windows

[Stein Somers]

Keith Moore wrote:

Tzuriel wrote:



grep --help
pause

inside a file called grep.cmd,



"grep.cmd" is getting executed recursively. You
need to name your .cmd file something other than
"grep".


Or invoke "grep.exe --help".  Or if you want to experiment, specify the exact path to grep.  Or 
if you love to experiment, make sure grep.cmd is not in the current directory and not in any 
PATH entry, so that you have to invoke it with an explicit path.


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/

ssh session w/reduced credentials;whoami shows OurSrvr064\sshd_server

[Tom Rodman]

Last week I loaded cygwin 1.5.19 on a new Windows 2003 Server 
(Standard Edition; service pack 1).  

When I ssh'd to this host, I had insuffient rights to "cd"
to a network share. I was able to fix this, using Pierre A. Humblet's
approach, by running the 'id -G' command at the console, and then adding
my username to the "userlist" [4th field] in /etc/group for each group
listed by 'id -G'.

  see: http://cygwin.com/ml/cygwin/2005-07/msg01287.html

After the fix: in ssh, you could cd to the network share, and write to
directories as expected. This fix worked fine, until..:

-- The Problem --

On Monday several compilers were loaded on this host (OurSrvr064);
because of this, 4 new local groups were created. So, I updated
/etc/group, by running 'mkgroup -ld', and subsequently re-doing
Pierre's approach- adding the username ("staffuser2", a domain user) into
the "userlist" [4th field] in /etc/group for each group listed by 'id -G'.
Unfortunately this failed. Also, the ssh session showed one
*additional* local group (gid 1008) for user staffuser2; additional w/r to
the (non ssh session) Terminal Services bash session 'id -G' output.
Also notable, was that whoami shown: "OurSrvr064\sshd_server", instead of
"staffuser2".

Please help me fix this again.

overview of problem, and attempt to fix: {

  $ cygcheck -s  |egrep '^Runni'
  Running in Terminal Service session
  $ uname -a
  CYGWIN_NT-5.2 OurSrvr064 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin
  $ mkgroup -ld > /etc/group ;( mkpasswd -l; mkpasswd -d -u $(id -un) ) 
>/etc/passwd
  $ grep $(id -un) /etc/passwd
  staffuser2:unused_by_nt/2000/xp:15776:10513:staffuser2 
tcm,U-DOMxx1\staffuser2,S-1-5-21-1390067357-1202660629-682003330-5776:/home/staffuser2:/bin/bash
  $ 
  --snip (exited and restarted bash in same Terminal Service session)
  $ : we will be using Pierre's group listing program, that I named "_mygroups"
  $ : to see the code, search ahead for "_mygroups.c"
  $ : next I cat a script that will (eventually) show the problem
  $ : ("OurServer108" below is a remote host)
  $ cat /cygdrive/c/adm/ssh_test_my_rights00 
  #!/bin/bash -x

  cd //OurServer108/tcm 
  id -G
  id
  :
  whoami

  /cygdrive/c/adm/_mygroups |grep 'use: 2'
  :
  /cygdrive/c/adm/_mygroups 

  $ : next, will run test script, it works just fine in a Terminal Service 
session:
  $ /cygdrive/c/adm/ssh_test_my_rights00
  + cd //OurServer108/tcm
  + id -G
  10513 544 545 1010 19858 19968 16025 16027 16024
  + id
  uid=15776(staffuser2) gid=10513(Domain Users) 
groups=544(Administrators),545(Users),1010(Debugger 
Users),19858(ABC_NA-CTX-Notepad-A),19968(ABC_NA-DOMxx0-tcm-Users-A),10513(Domain
 Users),16025(XYZ_BLD_MGR),16027(XYZ_ES_STAFF),16024(XYZ_Users)
  + :
  + whoami
  staffuser2
  + /cygdrive/c/adm/_mygroups
  + grep 'use: 2'
  0: Domain Users, DOMxx1, use: 2 attribs: 7
  11: XYZ_ES_STAFF, DOMxx1, use: 2 attribs: 7
  12: XYZ_BLD_MGR, DOMxx1, use: 2 attribs: 7
  13: ABC_NA-CTX-Notepad-A, DOMxx1, use: 2 attribs: 7
  14: ABC_NA-DOMxx0-tcm-Users-A, DOMxx1, use: 2 attribs: 7
  15: XYZ_Users, DOMxx1, use: 2 attribs: 7
  + :
  + /cygdrive/c/adm/_mygroups
  0: Domain Users, DOMxx1, use: 2 attribs: 7
  1: Everyone, , use: 5 attribs: 7
  2: Debugger Users, OurSrvr064, use: 4 attribs: 7
  3: Administrators, BUILTIN, use: 4 attribs: f
  4: Users, BUILTIN, use: 4 attribs: 7
  5: REMOTE INTERACTIVE LOGON, NT AUTHORITY, use: 5 attribs: 7
  6: INTERACTIVE, NT AUTHORITY, use: 5 attribs: 7
  7: Authenticated Users, NT AUTHORITY, use: 5 attribs: 7
  8: This Organization, NT AUTHORITY, use: 5 attribs: 7
  9: 5 0 4217733 attribs: c007
  10: LOCAL, , use: 5 attribs: 7
  11: XYZ_ES_STAFF, DOMxx1, use: 2 attribs: 7
  12: XYZ_BLD_MGR, DOMxx1, use: 2 attribs: 7
  13: ABC_NA-CTX-Notepad-A, DOMxx1, use: 2 attribs: 7
  14: ABC_NA-DOMxx0-tcm-Users-A, DOMxx1, use: 2 attribs: 7
  15: XYZ_Users, DOMxx1, use: 2 attribs: 7
  16: ABC_NA-DL-CTX-Notepad Users-A, DOMxx1, use: 4 attribs: 2007
  17: CERTSVC_DCOM_ACCESS, DOMxx1, use: 4 attribs: 2007
  18: RILOE_SCM, DOMxx1, use: 4 attribs: 2007
  $ 
  $ : so far so good, now try test in ssh, notice the 'cd' fails, notice 
'whoami' and 'id -G' output
  $ ssh localhost /cygdrive/c/adm/ssh_test_my_rights00 
  [EMAIL PROTECTED]'s password: 
  + cd //OurServer108/tcm
  /cygdrive/c/adm/ssh_test_my_rights00: line 3: cd: //OurServer108/tcm: 
Permission denied
  + id -G
  10513 544 545 1010 1008
  + id
  uid=15776(staffuser2) gid=10513(Domain Users) 
groups=544(Administrators),545(Users),1010(Debugger 
Users),1008(OWS_2416084231_admin),10513(Domain Users)
  + :
  + whoami
  OurSrvr064\sshd_server
  + /cygdrive/c/adm/_mygroups
  + grep 'use: 2'
  5: Domain Users, DOMxx1, use: 2 attribs: 7
  + :
  + /cygdrive/c/adm/_mygroups
  0: Everyone, , use: 5 attribs: 7
  1: Authenticated Users, NT AUTHORITY, use: 5 attribs: 7
  2: LOCAL, , use: 5 attribs: 7
  3: SERVICE, NT AUTHORITY, use: 5 attribs: 7
  4: 5 0 9916154 attribs: c007
  5: Domain Users, DOMxx1, use: 2 attrib

Re: Using grep from within a .cmd or .bat file in Windows

[Tzuriel]

Both perfect suggestions!  Thanks for taking the time to help.

> 
> Keith Moore wrote:

> > "grep.cmd" is getting executed recursively. You
> > need to name your .cmd file something other than
> > "grep".

Stein Somers  opnet.com> writes:

> Or invoke "grep.exe --help".  Or if you want to experiment, specify the exact
path to grep.  Or 
> if you love to experiment, make sure grep.cmd is not in the current directory
and not in any 
> PATH entry, so that you have to invoke it with an explicit path.
> 
> 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: 1.5.19-4 exec family of functions find wrong file to execute

[Dave Korn]

On 31 January 2006 16:23, Martin wrote:

> In response to your comments:
> I ran the testcase from ~/testcases directory. I believe my cygwin.out
> file indicates /home is mounted from D:\home (HOME=/home/test). Also, D:
> is NTFS.  Also, there is nothing special about mount point (no -x flag
> was used).  This is all shown in cygwin.out.  
> 

  Yeh?  Guess we'll have to take your word for it! ;)


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/

Installation Errors

[jgriffin]

Eric, 
I appreciate your response. When I run setup.exe, I'm downloading to a specfic 
folder. I have installed Cygwin numerous times this way and never had any 
problems. The one thing I'm doing different is burning the packages (along 
with the setup.exe app) to a CD. So, in my mind, I need to ensure that the 
cygpopt-0.dll is being transfered 1) from the mirror site to the harddrive and 
then 2) from the hard drive to the CD - because I know its not being 
installed. What package contains the dll? I did run cygcheck -svr and compared 
it to a working cygwin install - nothing jumped out ( I can't post the file 
for other reasons). The "-p" option is not recogized by cygcheck. 

Thanks for your help! 

Joseph 

On Mon, 30 Jan 2006 21:19:01 -0700, Eric Blake wrote 
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
> 
> According to jgriffin on 1/30/2006 11:29 AM: 
> > I'm trying to install Cygwin on a stand alone computer. Here is what I'm 
doing: 
> 
> Most of this looked okay.  However, you probably installed without wiping 
> out the previous installation, or with a second cygwin1.dll somewhere 
> in the path.  Attaching the output of cygcheck -svr, as a text 
> attachment, would help. 
> 
> > 
> > Errors 
> > Most of the errors are coming from the post-install scripts. I get an 
error 
> > dialog stating that cygpopt-0.dll could not be found. 
> 
> Somehow, you missed a dependency when building your cd.  Without all 
> the required packages, you can't expect the installation to work properly. 
> Try again (also, you can use cygcheck -p cygpopt-0.dll to find out what 
> package you missed). 
> 
> - -- 
> 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 
> 
> iD8DBQFD3uU184KuGfSFAYARAjU/AKCM6+DY/6Neyu+i7FW7UdyL/Jb6UwCgwHzd 
> R/4TPB4YsGM7xBnHHWFTO1Q= 
> =iTvL 
> -END PGP SIGNATURE- 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by PCLNET, and is 
> believed to be clean. 


--
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-4 exec family of functions find wrong file to execute

[Igor Peshansky]

Ugh, top-posting...  Reformatted.

On Tue, 31 Jan 2006, Martin wrote:

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

.  Thanks.

> > On Tue, 31 Jan 2006, Dave Korn wrote:
> >
> > > On 30 January 2006 19:23, Martin wrote:
> > >
> > > > Any response?
> > > > TIA
> > > > --- Martin <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> I am attempting to invoke a command with execvp/execlp.  If a
> > > >> file appears in my PATH before the executable desired and has the
> > > >> same name as the executable, the first occurrence of the file
> > > >> name is used as the executable to invoke.  Even though the first
> > > >> file is NOT marked as executable.
> > >
> > > >> Is this normal behavior for execlp/execvp?
> > > >> Shouldn't the execution permission be set in order to execute it?
> > >
> > >   Depends on your mountpoints.  If the file is found under a
> > > mountpoint with the cygexec flag set, it will be assumed to be
> > > executable regardless of the x bit in the file's perms.
> >
> > Also, on FAT filesystems, there are no permission bits[*]...  Your
> > file may be tripping the executable file detection heuristics, though.
> > Igor
> > [*] Cygwin can simulate them for you on pure FAT with "ntea", but with
> > FAT32 you're SOL.
>
> In response to your comments:
> I ran the testcase from ~/testcases directory. I believe my cygwin.out
> file indicates /home is mounted from D:\home (HOME=/home/test). Also,
> D: is NTFS.  Also, there is nothing special about mount point (no -x
> flag was used).  This is all shown in cygwin.out.

Then you'll just have to run this under strace, and see why it selects
that file to execute.
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: 1.5.19-4 exec family of functions find wrong file to execute

[Dave Korn]

On 31 January 2006 17:58, Igor Peshansky wrote:


>> In response to your comments:
>> I ran the testcase from ~/testcases directory. I believe my cygwin.out
>> file indicates /home is mounted from D:\home (HOME=/home/test). Also,
>> D: is NTFS.  Also, there is nothing special about mount point (no -x
>> flag was used).  This is all shown in cygwin.out.
> 
> Then you'll just have to run this under strace, and see why it selects
>   that file to execute. Igor


  I'll just add at this point that when I went back over the thread (looking 
for that cygcheck.out), I found your test case and
can't exactly reproduce your results:

[EMAIL PROTECTED] /test/exec> gcc test2.c -o test2
[EMAIL PROTECTED] /test/exec> PATH=/usr/bin:.
[EMAIL PROTECTED] /test/exec> test2 nopathnoext
NoPath
[EMAIL PROTECTED] /test/exec> touch echo
[EMAIL PROTECTED] /test/exec> ls -l echo
-rw-r--r--  1 dk Domain Users 0 Jan 31 18:32 echo
[EMAIL PROTECTED] /test/exec> test2 nopathnoext
NoPath
[EMAIL PROTECTED] /test/exec> PATH=.:/usr/bin
[EMAIL PROTECTED] /test/exec> test2 nopathnoext
nopathnoext: Permission denied
[EMAIL PROTECTED] /test/exec> rm -f echo
[EMAIL PROTECTED] /test/exec> test2 nopathnoext
NoPath
[EMAIL PROTECTED] /test/exec> echo garbage > echo
[EMAIL PROTECTED] /test/exec> test2 nopathnoext
nopathnoext: Permission denied
[EMAIL PROTECTED] /test/exec> ls -l echo
-rw-r--r--  1 dk Domain Users 8 Jan 31 18:33 echo
[EMAIL PROTECTED] /test/exec> test2 nopathext
NoPathExt
[EMAIL PROTECTED] /test/exec> test2 path
Usage: test2 nopathnoext|nopathext|pathnoext|pathext
[EMAIL PROTECTED] /test/exec>


  This is at least partly down to the fact that you either a) forged your 
results rather than cutting and pasting them or b)
attached a different program from the one you actually used as a testcase when 
you sent your email!


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/

Fatal error C1083 when make install prefix...

[Elin Aronsen]

Hi !

I sincerely hope you can help me. I am innstalling Geant4 with Microsoft
Visual .NET 2003 and WIRED on Windows XP operating system. I do not 
understand why in the configuration of the CLHEP library they tell me I 
have a i686-pc-system. May be I chose a wrong compiler. It seems to me
that I should have a standard C++ giving me in the configuration 
checking
for std::stlyes, but instead I have no. Is this that #include 
 is obsolete in the folder config of the library on line 12 of
CLHEP.h.? I tried to change it to #include  and using namespace 
std; without success.
Very greatful for help.

 Elin Aronsen

Cygwin Configuration Diagnostics
Current System Time: Mon Jan 30 11:10:13 2006

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\Bin
c:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
c:\WINDOWS
c:\WINDOWS\SYSTEM32
c:\ORAWIN95\BIN
C:\cygwin\lib\lapack

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1007(Chinsoo Hong_2) GID: 513(None)
0(root)   513(None) 544(Administrators)
545(Users)1004(Debugger Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1007(Chinsoo Hong_2) GID: 513(None)
0(root)   513(None) 544(Administrators)
545(Users)1004(Debugger Users)

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

USER = 'Chinsoo Hong_2'
PWD = '/home/Chinsoo Hong_2'
CYGWIN = 'tty nontea nosmbntsec nontsec'
HOME = '/home/Chinsoo Hong_2'
MAKE_MODE = 'unix'

HOMEPATH = '\Documents and Settings\Chinsoo Hong_2'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\Chinsoo Hong_2\Application Data'
HOSTNAME = 'ISOMERS'
VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 9, GenuineIntel'
WINDIR = 'C:\WINDOWS'
OLDPWD = '/usr/bin'
USERDOMAIN = 'ISOMERS'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/cygdrive/c/DOCUME~1/CHINSO~2/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\SDK\v1.1\Lib\;C:\DO\cygwin\Microsoft Visual Studio .NET 
2003\SDK\v1.1\Lib\;C:\DO\cygwin\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
USERNAME = 'Chinsoo Hong_2'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
__COMPAT_LAYER = 'DisableCicero '
USERPROFILE = 'C:\Documents and Settings\Chinsoo Hong_2'
CLIENTNAME = 'Console'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\ISOMERS'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/cygdrive/c/DOCUME~1/CHINSO~2/LOCALS~1/CHINSO~1'
SYSTEMROOT = 'C:\WINDOWS'
PRINTER = 'hp deskjet 5600 series'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0209'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = 'localhost:0'
NUMBER_OF_PROCESSORS = '2'
INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 
2003\SDK\v1.1\include\;C:\DO\cygwin\Microsoft Visual Studio .NET 
2003\SDK\v1.1\include\;C:\DO\cygwin\Microsoft Visual Studio .NET 
2003\SDK\v1.1\include\'
SESSIONNAME = 'Console'
COMPUTERNAME = 'ISOMERS'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\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
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd N/AN/A
c:  hd  NTFS114408Mb  17% CP CS UN PA FC 
d:  cd  CDFS   600Mb 100%CS UN   G4CD-4.0

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

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwi

Re: Building .so files for Apache 2.2.0 on Cygwin 1.5.19-4

[Jacco]

Hmmm,

Seems my attachement was damaged.
here it is again
~/threebit-tutorials
$ tar zxf tutorials.tar.gz

~/threebit-tutorials
$ cd apache2_modules/tut1

~/threebit-tutorials/apache2_modules/tut1
$ aclocal

~/threebit-tutorials/apache2_modules/tut1
$ libtoolize

~/threebit-tutorials/apache2_modules/tut1
$ autoconf

~/threebit-tutorials/apache2_modules/tut1
$ automake -a
configure.in: installing `./install-sh'
configure.in: installing `./missing'
Makefile.am: installing `./depcomp'

~/threebit-tutorials/apache2_modules/tut1
$ ./configure --with-apache=/usr/local/apache2/
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic ^x86 archive import|
^x86 DLL
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 8192
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC...
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared
 libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared
 libraries... yes
checking for g++ option to produce PIC...
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe) supports shared
 libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking for Apache directory... APACHE found!
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands

~/threebit-tutorials/apache2_modules/tut1
$ make
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"\" -DPACKAGE

Re: Installation Errors

[Igor Peshansky]

Ugh, top-posting...  Reformatted.

On Tue, 31 Jan 2006, jgriffin wrote:

> On Mon, 30 Jan 2006 21:19:01 -0700, Eric Blake wrote
> >
> > According to jgriffin on 1/30/2006 11:29 AM:
> >
> > > I'm trying to install Cygwin on a stand alone computer. Here is what
> > > I'm doing:
> >
> > Most of this looked okay.  However, you probably installed without
> > wiping out the previous installation, or with a second cygwin1.dll
> > somewhere in the path.  Attaching the output of cygcheck -svr, as a
> > text attachment, would help.
> >
> > > Errors
> > > Most of the errors are coming from the post-install scripts. I get
> > > an error dialog stating that cygpopt-0.dll could not be found.
> >
> > Somehow, you missed a dependency when building your cd.  Without all
> > the required packages, you can't expect the installation to work
> > properly. Try again (also, you can use cygcheck -p cygpopt-0.dll to
> > find out what package you missed).
>
> Eric,
>
> I appreciate your response. When I run setup.exe, I'm downloading to a
> specfic folder. I have installed Cygwin numerous times this way and
> never had any problems. The one thing I'm doing different is burning the
> packages (along with the setup.exe app) to a CD. So, in my mind, I need
> to ensure that the cygpopt-0.dll is being transfered 1) from the mirror
> site to the harddrive and then 2) from the hard drive to the CD -
> because I know its not being installed.

One thing to keep in mind (and which people trying to make Cygwin CDs
using setup.exe keep forgetting) is that setup.exe is not a mirroring
tool.  It will not download packages that are already installed on the
system, even in download mode.  So, if you have "the package that contains
cygpopt-0.dll" (see below) installed on your system, but the tarball for
it is somehow missing from your package cache, it will not be
re-downloaded.  If you want to make setup download stuff, move your Cygwin
directory out of the way before downloading (you can move it back
afterwards without any loss of information -- just delete the
newly-created Cygwin root folder).

> What package contains the dll?

As Eric said, "cygcheck -p" should work for a sufficiently recent version
of Cygwin (1.5.19+).  Otherwise, there's always the Cygwin package search
page at .

> I did run cygcheck -svr and compared it to a working cygwin install -
> nothing jumped out ( I can't post the file for other reasons).

Unless you store plaintext passwords in the environment, nothing in the
cygcheck output should be a security hole.  However, we should probably
have an FAQ page on what can be sanitized in the cygcheck output and how
to sanitize it without losing information...  Any volunteers? :-)

> The "-p" option is not recogized by cygcheck.

It is for Cygwin 1.5.19 or newer.
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: Fatal error C1083 when make install prefix...

[Dave Korn]

On 31 January 2006 18:50, Elin Aronsen wrote:

> Hi !
> 
> I sincerely hope you can help me. I am innstalling Geant4 with Microsoft
> Visual .NET 2003 and WIRED on Windows XP operating system. I do not
> understand why in the configuration of the CLHEP library they tell me I
> have a i686-pc-system. 

  So what _do_ you have?  Is it not an intel based system with a Pentium 2 or 
above cpu?

> May be I chose a wrong compiler. 

  Absolutely you did.  You need the cygwin version of gcc and make.  The error 
message you list comes from Microsoft's compiler.


> It seems to me
> that I should have a standard C++ giving me in the configuration checking
> for std::stlyes, but instead I have no. Is this that #include
>  is obsolete in the folder config of the library on line 12 of
> CLHEP.h.? I tried to change it to #include  and using namespace
> std; without success.  

  Attempting to get Visual C and NMAKE to run a posix shell script from a GNU 
makefile is pretty much bound to fail.



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: MSYS path behavior in Cygwin

[tom]

Alright -- thanks so much for the clarificaiton.  From your suggestions I should
be able to create a script that will do the job well enough.

Thanks again -Tom


--
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: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)

[Gerrit P. Haase]

Peter schrieb:

> On Mon, Jan 23, 2006 at 10:01:44PM +0100, Peter Ekberg wrote:
>> On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
>> > On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
>> > > Hello!
>> > > 
>> > > I recently tried to build a package that was using cpp for other
>> > > purposes than preprocessing C files. Its configure script was
>> > > looking for a way to not have cpp predefine anything, and it
>> > > specifically tried the -undef option, but failed. From reading the
>> > > docs, I couldn't figure out why. Here's a quote from "info cpp":
>> > > 
>> > > '-undef'
>> > >  Do not predefine any system-specific or GCC-specific macros.  The
>> > >  standard predefined macros remain defined.  *Note Standard
>> > >  Predefined Macros::.
>> > > 
>> > > So I searched the web a bit and figured that I could probably fix
>> > > it in the specs file. I realise that the specs file probably isn't
>> > > the canonical place to change this, but I'll leave that to the gcc
>> > > maintainer.
>> > > 
>> > > Attached is a patch for the specs file that wraps all old define
>> > > rules for cpp inside the following:
>> > > 
>> > > %{!undef:old define rules}
>> > > 
>> > > I don't know if this is the correct thing to do, but it works for
>> > > me.
>> > 
>> > GCC maintainer, are you there? Can you come out and play, please? :-)
>> 
>> Ping.

> Pong.

Peng.


Looks like a reasonable approach to fix this.  However, the specs should
not override -undef, looks like a bug in cpp.  Have you reported this as
a bug to the gcc bug tracker?


Gerrit
-- 
=^..^=


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

Re: i686-pc-cygwin on an i586

[Gerrit P. Haase]

Corinna wrote:

> On Jan 28 01:33, Christopher Faylor wrote:
>> 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.

> Same here, same for the net distro itself.  AFAIK we're generating
> i686-opimized code by default for at least three years, don't we?


The GCC release is compiled to support 486 and up targets.  386 is not
supported anymore.  Building binaries optimized for i686 may create not
working binaries if you have eg. an i586 compatible AMD processor,
howwever, the only time I had problems was with GCC itself optimized for
i686 which was crashing on my old AMD box.


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: gcc problem - cygwin-1.5.19-4

[Gerrit P. Haase]

Hi,

COLLETTE wrote:

> Hello,

> I've a problem with gcc: sometimes gcc can't find some include files.

> TestSpeedMetric.cpp:46:26: ParetoSoft.hpp: No such file or directory
> TestSpeedMetric.cpp: In function `int main()':
> TestSpeedMetric.cpp:155: error: `ParetoSoft' undeclared (first use this
> function)
> TestSpeedMetric.cpp:155: error: (Each undeclared identifier is reported
> only once for each function it appears in.)
> TestSpeedMetric.cpp:155: error: expected primary-expression before "int"
> TestSpeedMetric.cpp:155: error: expected `;' before "int"
> make[1]: *** [TestSpeedMetric] Error 1

> If I do a new "make", everything works fine. This is not a Makefile 
> problem, but more a gcc problem. Gcc version is 3.4.4 (cygwin special).

I don't think so.  Maybe the header is a generated file or it is copied
and you use make -j3, so it may be that make tries to invoke gcc to
compile the file before another make process has finished its work and
the file is actually not there where it is expected?

What flags do you use to invoke make?  What is the according rule in the
Makefile?  How is the actual command line?  More details needed to
narrow this down.


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: Perl under cygwin in CPAN problem

[Gerrit P. Haase]

Linda wrote:> Was trying to load some new packages in CPAN under perl  > in 
cygwin.  I noticed a problem when it asked for prereqs:> It wouldn't accept 
"CR" to terminate the input -- only "LF".I don't think I get this right.  
How do I distinguish between LF and CR?  Just hitting  at the keyboard 
should do it?  > I tried reloading CPAN -- that pulled up the reconfigure  
> dialog for some new parameters -- then I find the same  > problem in the 
config dialog where CPAN wants all of it's  > parameters (to create a new 
"~/.cpan/CPAN/Myconfig.pm").  > I try typing the first param and hitting "LF" 
and the the  > configure dialogue whips by takin the defaults for all of  > the 
configure questions.> At this point, I don't know if it is "cygwin", 
cygwin-perl  > or something else.  I don't get the same behavior on my  > linux 
box but the installed packages are not identical.> Anyone else seeing 
problems like this or have ideas  > how to find where the problem might be?
http://cygwin.com/problems.html  Gerrit  --   =^..^=
 http://nyckelpiga.de/donate.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: Cyrus IMAP

[Gerrit P. Haase]

pobox wrote:> Has anybody compiled successfully Cyrus IMAP under cygwin.
Yes.  Gerrit  --   =^..^= 
http://nyckelpiga.de/donate.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: Cyrus IMAP

[Gerrit P. Haase]

pobox wrote:

> Has anybody compiled successfully Cyrus IMAP under cygwin.

Sorry, my mailer messed up the previous reply.

Yes I have compiled it, though it is about a year ago and they changed
the build system quite a lot.  Not sure if it still works today.


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: Perl under cygwin in CPAN problem

[Gerrit P. Haase]

Hello,

sorry, my mailer is stupid and doesn't know how to create
linefeed in UTF-8, however it sends mail in UTF-8 quite
happily ;)

reformatted:

Linda wrote:

> Was trying to load some new packages in CPAN under perl
> in cygwin.  I noticed a problem when it asked for prereqs:

> It wouldn't accept "CR" to terminate the input -- only "LF".


I don't think I get this right.  How do I distinguish between
LF and CR?  Just hitting  at the keyboard should do it?


> I tried reloading CPAN -- that pulled up the reconfigure
> dialog for some new parameters -- then I find the same
> problem in the config dialog where CPAN wants all of it's
> parameters (to create a new "~/.cpan/CPAN/Myconfig.pm").
> I try typing the first param and hitting "LF" and the the
> configure dialogue whips by takin the defaults for all of
> the configure questions.

> At this point, I don't know if it is "cygwin", cygwin-perl
> or something else.  I don't get the same behavior on my
> linux box but the installed packages are not identical.

> Anyone else seeing problems like this or have ideas
> how to find where the problem might be?

http://cygwin.com/problems.html


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.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: Installation Errors

[jgriffin]

On Tue, 31 Jan 2006 14:07:16 -0500 (EST), Igor Peshansky wrote
> Ugh, top-posting...  Reformatted.
> 
> On Tue, 31 Jan 2006, jgriffin wrote:
> 
> > On Mon, 30 Jan 2006 21:19:01 -0700, Eric Blake wrote
> > >
> > > According to jgriffin on 1/30/2006 11:29 AM:
> > >
> > > > I'm trying to install Cygwin on a stand alone computer. Here is what
> > > > I'm doing:
> > >
> > > Most of this looked okay.  However, you probably installed without
> > > wiping out the previous installation, or with a second cygwin1.dll
> > > somewhere in the path.  Attaching the output of cygcheck -svr, as a
> > > text attachment, would help.
> > >
> > > > Errors
> > > > Most of the errors are coming from the post-install scripts. I get
> > > > an error dialog stating that cygpopt-0.dll could not be found.
> > >
> > > Somehow, you missed a dependency when building your cd.  Without all
> > > the required packages, you can't expect the installation to work
> > > properly. Try again (also, you can use cygcheck -p cygpopt-0.dll to
> > > find out what package you missed).
> >
> > Eric,
> >
> > I appreciate your response. When I run setup.exe, I'm downloading to a
> > specfic folder. I have installed Cygwin numerous times this way and
> > never had any problems. The one thing I'm doing different is burning the
> > packages (along with the setup.exe app) to a CD. So, in my mind, I need
> > to ensure that the cygpopt-0.dll is being transfered 1) from the mirror
> > site to the harddrive and then 2) from the hard drive to the CD -
> > because I know its not being installed.
> 
> One thing to keep in mind (and which people trying to make Cygwin CDs
> using setup.exe keep forgetting) is that setup.exe is not a mirroring
> tool.  It will not download packages that are already installed on the
> system, even in download mode.  So, if you have "the package that contains
> cygpopt-0.dll" (see below) installed on your system, but the tarball 
> for it is somehow missing from your package cache, it will not be re-
> downloaded.  If you want to make setup download stuff, move your 
> Cygwin directory out of the way before downloading (you can move it 
> back afterwards without any loss of information -- just delete the 
> newly-created Cygwin root folder).
> 
> > What package contains the dll?
> 
> As Eric said, "cygcheck -p" should work for a sufficiently recent version
> of Cygwin (1.5.19+).  Otherwise, there's always the Cygwin package search
> page at .
> 
> > I did run cygcheck -svr and compared it to a working cygwin install -
> > nothing jumped out ( I can't post the file for other reasons).
> 
> Unless you store plaintext passwords in the environment, nothing in the
> cygcheck output should be a security hole.  However, we should probably
> have an FAQ page on what can be sanitized in the cygcheck output and 
> how to sanitize it without losing information...  Any volunteers? :-)
> 
> > The "-p" option is not recogized by cygcheck.
> 
> It is for Cygwin 1.5.19 or newer.
> HTH,
>   Igor

Igor,
That fixed the problem.

Thanks,


--
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-4 exec family of functions find wrong file to execute

[Corinna Vinschen]

On Jan 23 11:12, Martin wrote:
> I am attempting to invoke a command with
> execvp/execlp.  If a file appears in my PATH before
> the executable desired and has the same name as the
> executable, the first occurrence of the file name is
> used as the executable to invoke.  Even though the
> first file is NOT marked as executable.
> 
> The attached testcase illustrates this.
> Here's a simple shell log:
> 
> bash-3.00$ gcc test2.c -o test2
> bash-3.00$ PATH=/usr/bin:.
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ touch echo
> bash-3.00$ ls -l echo
> -rw-r--r-- 1 test None 0 Jan 21 15:39 echo
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ PATH=.:/usr/bin
> bash-3.00$ test2 nopathnoext
> nopathnoext: No such device or address
> bash-3.00$ rm -f echo
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ echo garbage > echo
> bash-3.00$ test2 nopathnoext
> nopathnoext: Permission denied
> bash-3.00$ ls -l echo
> -rw-r--r-- 1 test None 8 Jan 21 15:40 echo
> bash-3.00$ test2 nopathext
> NoPathExt
> bash-3.00$ test2 path
> Path
> 
> Is this normal behavior for execlp/execvp?
> Shouldn't the execution permission be set in order to
> execute it?

There was a tiny bug in the path evaluation.  I've applied a fix.  Please
give the next developer's snapshot a try.  http://cygwin.com/snapshots/


Thanks for the report and the testcase,
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: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)

[Peter Ekberg]

On Tue, Jan 31, 2006 at 09:37:05PM +0100, Gerrit P. Haase wrote:
> Peter schrieb:
> 
> > On Mon, Jan 23, 2006 at 10:01:44PM +0100, Peter Ekberg wrote:
> >> On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
> >> > On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> >> > > Hello!
> >> > > 
> >> > > I recently tried to build a package that was using cpp for other
> >> > > purposes than preprocessing C files. Its configure script was
> >> > > looking for a way to not have cpp predefine anything, and it
> >> > > specifically tried the -undef option, but failed. From reading the
> >> > > docs, I couldn't figure out why. Here's a quote from "info cpp":
> >> > > 
> >> > > '-undef'
> >> > >  Do not predefine any system-specific or GCC-specific macros.  The
> >> > >  standard predefined macros remain defined.  *Note Standard
> >> > >  Predefined Macros::.
> >> > > 
> >> > > So I searched the web a bit and figured that I could probably fix
> >> > > it in the specs file. I realise that the specs file probably isn't
> >> > > the canonical place to change this, but I'll leave that to the gcc
> >> > > maintainer.
> >> > > 
> >> > > Attached is a patch for the specs file that wraps all old define
> >> > > rules for cpp inside the following:
> >> > > 
> >> > > %{!undef:old define rules}
> >> > > 
> >> > > I don't know if this is the correct thing to do, but it works for
> >> > > me.
> >> > 
> >> > GCC maintainer, are you there? Can you come out and play, please? :-)
> >> 
> >> Ping.
> 
> > Pong.
> 
> Peng.

Pang.

> Looks like a reasonable approach to fix this.  However, the specs should
> not override -undef, looks like a bug in cpp.  Have you reported this as
> a bug to the gcc bug tracker?

I have now, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26052

Let's see what happens.

Cheers,
Peter

--
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: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)

[Shankar Unni]

Peter Ekberg wrote:


I have now, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26052


Indeed, as one of the adds to this bug said, this is a target (i.e. 
cygwin)-specific issue.


On Linux, gcc (at least 4.0.x, which Redhat FC4 comes with) prints out 
only __STDC_HOSTED__=1 when you do


  cpp -undef -dM < /dev/null

I'm guessing this should be taken to cygwin-apps now?



--
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: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)

[Christopher Faylor]

On Tue, Jan 31, 2006 at 02:32:11PM -0800, Shankar Unni wrote:
>Peter Ekberg wrote:
>
>>I have now, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26052
>
>Indeed, as one of the adds to this bug said, this is a target (i.e. 
>cygwin)-specific issue.
>
>On Linux, gcc (at least 4.0.x, which Redhat FC4 comes with) prints out 
>only __STDC_HOSTED__=1 when you do
>
>  cpp -undef -dM < /dev/null
>
>I'm guessing this should be taken to cygwin-apps now?

Why would it be taken to cygwin-apps?  This isn't a packaging issue.

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

[Jon Dixon]

Hi Corinna,

I have tested the cygwin-inst-20060130.tar.bz2 snapshot. 
Unfortunately, this snapshot runs the same way as release 1.5.19-4. 
Cygwin does however behave differently on Windows 2000 Server than on
Windows 2003 Server.

The following describes the behavior of Cygwin (release or snapshot)
running on Windows 2000 Server sp 4.

The SSH local port forwarding is activated with the command line statement:
   ssh -L2001:server.com:23 server.com.

If another program is executed that also listens on port 2001, the
program immediately throws the bind error exception: Address already
in use.

Cygwin (release or snapshot) running on Windows 2003 Server sp 1
however does not throw a bind exception.

(If two copies of a port listening program are executed and listen on
the same port, the second copy will always throw a bind exception on
either operating system).

Ideally, I would like Cygwin to exclusively bind the port forwarding
listening port.  This would prevent the potential hijacking of plain
text data.

Jon

Cygwin Configuration Diagnostics
Current System Time: Tue Jan 31 15:14:24 2006

Windows 2000 Server Ver 5.0 Build 2195 Service Pack 4

Path:   C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
c:\j2sdk1.4.1_04\bin
C:\Program Files\Symantec\pcAnywhere\
d:\intv\sys
d:\intv\dll
d:\intvsock
d:\xmlConfigurator
d:\Luengine
C:\Program Files\Common Files\Adaptec Shared\System
c:\KeyTools
D:\Program Files\Rational\common
c:\WINNT\Microsoft.Net\Framework\v1.1.4322
d:\cygwin\bin
D:\Sun\AppServer\bin
D:\Program Files\Intervoice\InVision Studio\dll
D:\Program Files\Intervoice\InVision Studio\

Output from D:\cygwin\bin\id.exe (nontsec)
UID: 500(Administrator) GID: 513(None)
0(root) 513(None)   544(Administrators)
545(Users)

Output from D:\cygwin\bin\id.exe (ntsec)
UID: 500(Administrator) GID: 513(None)
0(root) 513(None)   544(Administrators)
545(Users)

SysDir: C:\WINNT\system32
WinDir: C:\WINNT

CYGWIN = 'ntsec tty'
HOME = 'D:\cygwin\home\Administrator'
Path = 
'C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;c:\j2sdk1.4.1_04\bin;C:\Program
 
Files\Symantec\pcAnywhere\;d:\intv\sys;d:\intv\dll;d:\intvsock;d:\xmlConfigurator;d:\Luengine;C:\Program
 Files\Common Files\Adaptec Shared\System;c:\KeyTools;D:\Program 
Files\Rational\common;c:\WINNT\Microsoft.Net\Framework\v1.1.4322;d:\cygwin\bin;D:\Sun\AppServer\bin;D:\Program
 Files\Intervoice\InVision Studio\dll;D:\Program Files\Intervoice\InVision 
Studio\'

ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\Administrator.IVLAB001\Application Data'
classpath = 'd:\intv\dll;c:\KeyTools;c:\tnemulator'
CommonProgramFiles = 'C:\Program Files\Common Files'
COMPUTERNAME = 'IVLAB001'
ComSpec = 'C:\WINNT\system32\cmd.exe'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\Administrator.IVLAB001'
INCLUDE = 'd:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\'
intvconf = 'd:\intv\cfg\intvconf.dat'
INTV_APPL = 'd:\intv\appl'
INTV_PATH = 'd:\intv'
JAVA_HOME = 'c:\j2sdk1.4.1_04'
LIB = 'd:\Program Files\Microsoft Visual Studio .NET 
2003\SDK\v1.1\Lib\;d:\intv\lib'
LOGONSERVER = '\\IVLAB001'
NUMBER_OF_PROCESSORS = '1'
OPENSSL_CONF = 'C:\OpenSSL\bin\openssl.cnf'
OS = 'Windows_NT'
Os2LibPath = 'C:\WINNT\system32\os2\dll;'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 7 Stepping 3, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '0703'
ProgramFiles = 'C:\Program Files'
PROMPT = '$P$G'
SystemDrive = 'C:'
SystemRoot = 'C:\WINNT'
TEMP = 'C:\DOCUME~1\ADMINI~1.IVL\LOCALS~1\Temp'
TMP = 'C:\DOCUME~1\ADMINI~1.IVL\LOCALS~1\Temp'
TOMCAT_HOME = 'C:\Program Files\NetBeans IDE 3.5.1\tomcat406'
USERDOMAIN = 'IVLAB001'
USERNAME = 'Administrator'
USERPROFILE = 'C:\Documents and Settings\Administrator.IVLAB001'
VS71COMNTOOLS = 'd:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
windir = 'C:\WINNT'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'D:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'D:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'D:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus So

RE: 1.5.19-4 exec family of functions find wrong file to execute

[Martin]

It's not perfect.  But I think you got the gist of it.

Thanks,
Martin

--- Dave Korn <[EMAIL PROTECTED]> wrote:

> On 31 January 2006 17:58, Igor Peshansky wrote:
> 
> 
> >> In response to your comments:
> >> I ran the testcase from ~/testcases directory. I believe my
> cygwin.out
> >> file indicates /home is mounted from D:\home (HOME=/home/test).
> Also,
> >> D: is NTFS.  Also, there is nothing special about mount point (no
> -x
> >> flag was used).  This is all shown in cygwin.out.
> > 
> > Then you'll just have to run this under strace, and see why it
> selects
> > that file to execute. Igor
> 
> 
>   I'll just add at this point that when I went back over the thread
> (looking for that cygcheck.out), I found your test case and
> can't exactly reproduce your results:
> 
> [EMAIL PROTECTED] /test/exec> gcc test2.c -o test2
> [EMAIL PROTECTED] /test/exec> PATH=/usr/bin:.
> [EMAIL PROTECTED] /test/exec> test2 nopathnoext
> NoPath
> [EMAIL PROTECTED] /test/exec> touch echo
> [EMAIL PROTECTED] /test/exec> ls -l echo
> -rw-r--r--  1 dk Domain Users 0 Jan 31 18:32 echo
> [EMAIL PROTECTED] /test/exec> test2 nopathnoext
> NoPath
> [EMAIL PROTECTED] /test/exec> PATH=.:/usr/bin
> [EMAIL PROTECTED] /test/exec> test2 nopathnoext
> nopathnoext: Permission denied
> [EMAIL PROTECTED] /test/exec> rm -f echo
> [EMAIL PROTECTED] /test/exec> test2 nopathnoext
> NoPath
> [EMAIL PROTECTED] /test/exec> echo garbage > echo
> [EMAIL PROTECTED] /test/exec> test2 nopathnoext
> nopathnoext: Permission denied
> [EMAIL PROTECTED] /test/exec> ls -l echo
> -rw-r--r--  1 dk Domain Users 8 Jan 31 18:33 echo
> [EMAIL PROTECTED] /test/exec> test2 nopathext
> NoPathExt
> [EMAIL PROTECTED] /test/exec> test2 path
> Usage: test2 nopathnoext|nopathext|pathnoext|pathext
> [EMAIL PROTECTED] /test/exec>
> 
> 
>   This is at least partly down to the fact that you either a) forged
> your results rather than cutting and pasting them or b)
> attached a different program from the one you actually used as a
> testcase when you sent your email!
> 
> 
> 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/
> 
> 







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

Re: 1.5.19-4 exec family of functions find wrong file to execute

[Christopher Faylor]

On Tue, Jan 31, 2006 at 06:49:41PM -0500, Martin wrote:
>It's not perfect.  But I think you got the gist of it.

AFAICT, your test application executes the same on linux and on cygwin
(NTFS) with Corinna's patch, so I think we got all of it.

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: Perl under cygwin in CPAN problem

[Linda Walsh]

Hi Gerrit,

   Yeah, for most purposes hitting Enter gives
you what you need, but something was weird was
going on.  The problem went away after I - (ug)
rebooted.  Have no idea how it happened -- had closed
out the CMD-window and started with fresh windows,
exiting all cygwin programs, but that didn't make it
go away.  Then I tried a reboot, since I couldn't think
of anything else and the problem went away.

   I don't usually think of rebooting to solve a problem
on XP, as it isn't the standard "catchall" like it was
under Win9x based systems.

   The nuances of Enter not being the same as a CR-LF
are usually only important in something other than the
standard "cooked" tty mode.  I believe the CPAN scripts
may have been using one of these modes.

Gerrit P. Haase wrote:


I don't think I get this right.  How do I distinguish between
LF and CR?  Just hitting  at the keyboard should do it?
  

In the unix or linux tty-based world, ENTER, usually, is the same
as a control-m, while linefeed is usually a control-j.  In
the standard "cooked" input mode, a control-m is accepted the
same as though one typed control-j.

Linda

--
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 session w/reduced credentials; simple TEST CASE to show problem

[Tom Rodman]

simple test case:
  

  Please use an account in the local administrators group.
  Mine was a direct member, ie the account itself shows up if
  you run 'net localgroup administrators'.  Next verify you can
  'ssh localhost' OK.

  To create the problem, create any empty localgroup, say for example
  "toss_soon".  Then run:

net localgroup toss_soon /add administrators

  Now try 'ssh localhost', as the same user.  Once you have a shell
  prompt, type 'whoami' - if the problem shows up the output is: 

YOURHOSTSNAME\sshd_server.

  To make the problem go away, run:

net localgroup toss_soon /delete administrators

BTW, we're unable to remove administrators from the group in
our case, and I prefer not to have to add the user to the group -
the account is already in the local administrators group.

--
thanks,
Tom

pls see a comment or two below:

On Tue 1/31/06 10:32 CST Tom Rodman wrote:
--snip
> -- The Problem --
> 
> On Monday several compilers were loaded on this host (OurSrvr064);
> because of this, 4 new local groups were created. So, I updated
> /etc/group, by running 'mkgroup -ld', and subsequently re-doing
> Pierre's approach- adding the username ("staffuser2", a domain user) into
> the "userlist" [4th field] in /etc/group for each group listed by 'id -G'.
> Unfortunately this failed. Also, the ssh session showed one
> *additional* local group (gid 1008) for user staffuser2; additional w/r to
> the (non ssh session) Terminal Services bash session 'id -G' output.
> Also notable, was that whoami shown: "OurSrvr064\sshd_server", instead of
> "staffuser2".
--snip
> $ : next, will run test script, it works just fine in a Terminal Service 
> session:
>   $ /cygdrive/c/adm/ssh_test_my_rights00
>   + cd //OurServer108/tcm
>   + id -G
>   10513 544 545 1010 19858 19968 16025 16027 16024
>   + id
>   uid=15776(staffuser2) gid=10513(Domain Users) 
> groups=544(Administrators),545(Users),1010(Debugger 
> Users),19858(ABC_NA-CTX-Notepad-A),19968(ABC_NA-DOMxx0-tcm-Users-A),10513(Domain
>  Users),16025(XYZ_BLD_MGR),16027(XYZ_ES_STAFF),16024(XYZ_Users)
>   + :
>   + whoami
>   staffuser2
--snip
>   $ : Notice that next test fails again even though groups for staffuser2 
> more than match,
>   $ : the groups staffuser2 is in within a Term Service session (1008 is the 
> extra local group).
>   $ ssh localhost /cygdrive/c/adm/ssh_test_my_rights00 
>   [EMAIL PROTECTED]'s password: 
>   + cd //OurServer108/tcm
>   /cygdrive/c/adm/ssh_test_my_rights00: line 3: cd: //OurServer108/tcm: 
> Permission denied
>   + id -G
>   10513 544 545 1010 1008 19858 19968 16025 16027 16024
>   + id
>   uid=15776(staffuser2) gid=10513(Domain Users) 
> groups=544(Administrators),545(Users),1010(Debugger 
> Users),1008(OWS_2416084231_admin),19858(ABC_NA-CTX-Notepad-A),19968(ABC_NA-DOMxx0-tcm-Users-A),10513(Domain
>  Users),16025(XYZ_BLD_MGR),16027(XYZ_ES_STAFF),16024(XYZ_Users)

OWS_2416084231_admin (1008) is the problem group; ie it
shows up in the ssh session, but not in a simple
Terminal Services session

--snip
> -- The new local groups, and their members; these groups were added on Monday 
> -- {
> 
-snip
>   C:\>net localgroup OWS_2416084231_admin
>   Alias name OWS_2416084231_admin
>   CommentMicrosoft SharePoint role 'admin' for web 'http://OurSrvr064'
> 
>   Members
> 
>   
> ---
>   Administrators
>   The command completed successfully.
> 
--snip

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

Ref http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html

[Anders Brandén]

Hi,

referring http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html

I have a comment,

the problem seems to be more of a general kind(files that doesn't exist 
already don't get created for writing) as these things happen on my Cygwin 
system (running under Server 2003):


This is the new thing I've found, note that without the pipe(i.e. | cat) the 
command runs just fine:



tar -cf /proc/self/fd/1 syntax.c | cat
tar: /proc/self/fd/1: Cannot write: Bad file descriptor
tar: Error is not recoverable: exiting now


and this is what happens on my system with the command referred in the link 
above, note that the error messages are the same!



$ tar -cf >(cat) syntax.c
tar: /proc/self/fd/63: Cannot write: Bad file descriptor
tar: Error is not recoverable: exiting now


Both of these commands effectively creates a temporary file for both reading 
and writing and that seems to be the problem, this command runs just fine 
because I create a file for writing:



$ tar -cf >(cat) syntax.c 63>temp


and, once created, this command runs fine too, however note that the 
redirection of input also redirects output though it really shouldn't (try 
it without having the temp file first, and then with an empty temp file and 
check the contents afterward):



$ tar -cf >(cat) syntax.c 63

So without the temp file, this fails every time:


$ tar -cf >(cat) syntax.c 63temp
bash: temp: No such file or directory


But this always works:


$ tar -cf >(cat) syntax.c 63>temp 63

Writing to temp gives >(cat temp) nothing to read:


$ tar -cf >(cat temp) syntax.c 63>temp 63


$ tar -cf >(cat temp) syntax.c 63temp


However there is obviously also something wrong with the redirection of 
standard input for
(cat) because I get no output with either of these statements even after 
the temp file is created (writing to temp2 while attempting to read from 
temp):



$ tar -cf >(cat) syntax.c 63>temp2 63


$ tar -cf >(cat) syntax.c 63temp2


So only these gives the expected output:


$ tar -cf >(cat temp) syntax.c 63>temp2 63


$ tar -cf >(cat temp) syntax.c 63temp2


Hope this helps in pinpointing the problem.


Regards,
Anders Brandén



--
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 disapearing terminal mystery

[Larry Hall (Cygwin)]

Harry Putnam wrote:

I've been running cygwin in a laptop running XP home.  It was working
as expected.  However its been a while since I used it and not sure
what all has happened that might effect cygwin... but can think of
nothing off hand.

However, now when I click the bash icon a terminal appears and just as
quickly disappears.  I can't use any cygwin tools since the terminal
just flashes once and is gone.

What on earth might cause such behavior?




It's not something on Earth.  It has to do with the phase of the Moon. ;-)

The standard approach to this kind of problem is to open a cmd.exe window
and then run cygwin.bat from here.  If there are error messages, you'll now
be able to see and address them.


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

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

Re: Cygwin on XP disapearing terminal mystery

[Harry Putnam]

[EMAIL PROTECTED] (Eric Blake) writes:

> If you expect help, then try opening a plain cmd.com window
> first, running bash there and seeing if any error messages
> appear.  Also, send, as a text attachment, the output of
> 'cygcheck -svr'.

When trying the cmd shell approach it became apparent that bash had
disappeared off the system thanks.


--
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.bat improvements (was Re: Cygwin on XP disapearing terminal mystery)

[Brian Dessent]

Harry Putnam wrote:
> 
> [EMAIL PROTECTED] (Eric Blake) writes:
> 
> > If you expect help, then try opening a plain cmd.com window
> > first, running bash there and seeing if any error messages
> > appear.  Also, send, as a text attachment, the output of
> > 'cygcheck -svr'.
> 
> When trying the cmd shell approach it became apparent that bash had
> disappeared off the system thanks.

Since this seems to come up every so often, what if we made a couple of
small changes to cygwin.bat to aid in debugging this?  Specifically, I
was thinking that cygwin.bat could create a marker file (say something
like ".uncleanstartup") in the same directory as the .bat file, and add
something to the base-files rc files that deletes this file at the end
of the startup procedure.  Then cygwin.bat can check for existence of
this marker after executing bash, and if found it can print a short
message and then run "pause" so that the user can see any error messages
on the screen.  The message could perhaps say a few words about PATH
settings or cygcheck and the mailing list, etc.

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: cygwin.bat improvements (was Re: Cygwin on XP disapearing terminal mystery)

[Christopher Faylor]

On Tue, Jan 31, 2006 at 07:38:31PM -0800, Brian Dessent wrote:
>Harry Putnam wrote:
>> 
>> [EMAIL PROTECTED] (Eric Blake) writes:
>> 
>> > If you expect help, then try opening a plain cmd.com window
>> > first, running bash there and seeing if any error messages
>> > appear.  Also, send, as a text attachment, the output of
>> > 'cygcheck -svr'.
>> 
>> When trying the cmd shell approach it became apparent that bash had
>> disappeared off the system thanks.
>
>Since this seems to come up every so often, what if we made a couple of
>small changes to cygwin.bat to aid in debugging this?  Specifically, I
>was thinking that cygwin.bat could create a marker file (say something
>like ".uncleanstartup") in the same directory as the .bat file, and add
>something to the base-files rc files that deletes this file at the end
>of the startup procedure.  Then cygwin.bat can check for existence of
>this marker after executing bash, and if found it can print a short
>message and then run "pause" so that the user can see any error messages
>on the screen.  The message could perhaps say a few words about PATH
>settings or cygcheck and the mailing list, etc.

Couldn't it just replace the bash line with:

  if exist bash.exe goto ok
  echo  bash.exe is missing - please install it
  pause
  :ok
  bash --login -i

?

cgf

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

Re: cygwin.bat improvements (was Re: Cygwin on XP disapearing terminal mystery)

[Brian Dessent]

Christopher Faylor wrote:

> Couldn't it just replace the bash line with:
> 
>   if exist bash.exe goto ok
>   echo  bash.exe is missing - please install it
>   pause
>   :ok
>   bash --login -i

Well that would certainly work for the case of a missing bash.  I guess
I was thinking that the marker file method would work for a wider range
of brokenness where for whatever reason the shell fails to start and/or
complete its initialization.  Having never experienced this personally I
can't really come up with a set of possible scenarios of brokenness, but
it seems we get do get a lot of "bash window flashes briefly and then
disappears" reports.  Are they all just missing bash.exe?

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/

bash process substitution [Was: Ref http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html]

[Eric Blake]

[Picking a better subject line]

From: Anders Brandén
> Hi,
> 
> referring http://www.cygwin.com/ml/cygwin/2005-04/msg00651.html
> 
> I have a comment,
> 
> the problem seems to be more of a general kind(files that doesn't exist 
> already don't get created for writing) as these things happen on my Cygwin 
> system (running under Server 2003):

There is a distinct difference between disk files and pipes.

> 
> This is the new thing I've found, note that without the pipe(i.e. | cat) the 
> command runs just fine:
> 
> >tar -cf /proc/self/fd/1 syntax.c | cat
> >tar: /proc/self/fd/1: Cannot write: Bad file descriptor
> >tar: Error is not recoverable: exiting now

Here, the pipe operator tells bash to create a pipe and use the write
end of that pipe as tar's stdout, so tar is started with fd 1 as a pipe.
Inside tar, cygwin is apparently getting the read end of /proc/self/fd/1
instead of the write end, leading to tar complaining about a write
failure when it tries to put output on a read-only fd.

> 
> and this is what happens on my system with the command referred in the link 
> above, note that the error messages are the same!
> 
> >$ tar -cf >(cat) syntax.c
> >tar: /proc/self/fd/63: Cannot write: Bad file descriptor
> >tar: Error is not recoverable: exiting now

Here, bash creates a pipe for the command substitution, which
is named /proc/self/fd/63, then we are once again at the point
where tar opens the read end of fd 63 instead of the write end,
explaining the same error as before.

> 
> Both of these commands effectively creates a temporary file for both reading 
> and writing and that seems to be the problem, this command runs just fine 
> because I create a file for writing:
> 
> >$ tar -cf >(cat) syntax.c 63>temp

Whoa.  Your explanation has a hole.  Here, bash handles the
process substitution first, creating a pipe (fd 63), of which the
write end will be handed to tar and the read end handed to
cat.  Then bash does the redirection, opening the file temp
(whether pre-existing or not) for writing as fd 63.  Now
cat still has the read end of the pipe, but the write end has
been lost (so cat becomes a no-op), and tar now has a file
rather than a pipe at /proc/self/fd/63, and cygwin correctly
treats a file open for writing as a writable fd.

> 
> and, once created, this command runs fine too, however note that the 
> redirection of input also redirects output though it really shouldn't (try 
> it without having the temp file first, and then with an empty temp file and 
> check the contents afterward):
> 
> >$ tar -cf >(cat) syntax.c 63 
> So without the temp file, this fails every time:
> 
> >$ tar -cf >(cat) syntax.c 63temp
> >bash: temp: No such file or directory

The first redirection (63 
> But this always works:
> 
> >$ tar -cf >(cat) syntax.c 63>temp 63 
> Writing to temp gives >(cat temp) nothing to read:
> 
> >$ tar -cf >(cat temp) syntax.c 63>temp 63 
> >$ tar -cf >(cat temp) syntax.c 63temp

Likewise racy.  Don't try it - it won't be predictable.

> 
> However there is obviously also something wrong with the redirection of 
> standard input for
> >(cat) because I get no output with either of these statements even after 
> >the temp file is created (writing to temp2 while attempting to read from 
> >temp):
> 
> >$ tar -cf >(cat) syntax.c 63>temp2 63 
> >$ tar -cf >(cat) syntax.c 63temp2
> 
> So only these gives the expected output:
> 
> >$ tar -cf >(cat temp) syntax.c 63>temp2 63 
> >$ tar -cf >(cat temp) syntax.c 63temp2
> 
> Hope this helps in pinpointing the problem.

What problem?  The original mail was about cygwin treating
/proc/self/fd/nnn as read-only if it refers to a pipe, whether
or not the process was handed the write end of that pipe; but
the last half of your email has been complaining about fds
referring to files and not pipes.

--
Eric Blake
volunteer cygwin bash maintainer

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

Re: gcc problem - cygwin-1.5.19-4

[COLLETTE Yann]

Hello,

It's not a flag problem: sometimes when I invoke "make" this problem 
happens and the, 1 or 2 seconds after, if I invoke again "make", it 
works fine without any modifications. I have never meet this problem 
with the preceding version of cygwin. It happened since 1.5.19.

Could it be a transient network problem ?

Your sincerely,

Yann COLLETTE

Gerrit P. Haase a écrit :

Hi,

COLLETTE wrote:

  

Hello,



  

I've a problem with gcc: sometimes gcc can't find some include files.



  

TestSpeedMetric.cpp:46:26: ParetoSoft.hpp: No such file or directory
TestSpeedMetric.cpp: In function `int main()':
TestSpeedMetric.cpp:155: error: `ParetoSoft' undeclared (first use this
function)
TestSpeedMetric.cpp:155: error: (Each undeclared identifier is reported
only once for each function it appears in.)
TestSpeedMetric.cpp:155: error: expected primary-expression before "int"
TestSpeedMetric.cpp:155: error: expected `;' before "int"
make[1]: *** [TestSpeedMetric] Error 1



  
If I do a new "make", everything works fine. This is not a Makefile 
problem, but more a gcc problem. Gcc version is 3.4.4 (cygwin special).



I don't think so.  Maybe the header is a generated file or it is copied
and you use make -j3, so it may be that make tries to invoke gcc to
compile the file before another make process has finished its work and
the file is actually not there where it is expected?

What flags do you use to invoke make?  What is the according rule in the
Makefile?  How is the actual command line?  More details needed to
narrow this down.


Gerrit
  




-- Disclaimer 
Ce message ainsi que les eventuelles pieces jointes constituent une 
correspondance privee et confidentielle a l'attention exclusive du destinataire 
designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une 
personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute 
divulgation, distribution ou copie de cette transmission est strictement 
interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en 
informer l'expediteur par telephone ou de lui retourner le present message, 
puis d'effacer immediatement ce message de votre systeme.
***
This e-mail and any attachments is a confidential correspondence intended only 
for use of the individual or entity named above. If you are not the intended 
recipient or the agent responsible for delivering the message to the intended 
recipient, you are hereby notified that any disclosure, distribution or copying 
of this communication is strictly prohibited. If you have received this 
communication in error, please notify the sender by phone or by replying this 
message, and then delete this message from your system.