Re: Cygwin for Fedora?

[Harry Simons]

My intent is not to emulate the low-level operating system API, it is rather to 
emulate the *environment* consisting of packages and programs, their versions, etc.


For example, instead of just imagining that I have taken care of these 
subtleties ( http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-perm) in my 
programs (and possibly others), I would like to actually be able to test them. 
And, as I said, instead of asking for access to a Windows/Cygwin node from my 
sys admin, it would be wonderful if I could achieve a "Linux on top of Linux", 
weird as it may sound.


So, this need for cross-platform compatibility (of my scripts) (between just the 
two of Windows and Fedora) may not be entirely unwarranted. Somewhat like the 
concept of cross-compilation for C programs without access to a physical target.


On 03/08/2012 01:22 PM, Mike Brown wrote:

On Thu, Mar 08, 2012 at 01:15:20PM +0530, Harry Simons wrote:

Instead of asking for access to a Cygwin/Windows PC just for the above, I
thought it would be terrific if Cygwin could somehow be installed /
emulated on a Fedora.

Linux on top of Linux?  I don't understand the need for that.

MB


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

Re: Cygwin for Fedora?

[Yaakov (Cygwin/X)]

On 2012-03-08 02:20, Harry Simons wrote:

My intent is not to emulate the low-level operating system API, it is
rather to emulate the *environment* consisting of packages and programs,
their versions, etc.

For example, instead of just imagining that I have taken care of these
subtleties ( http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-perm)
in my programs (and possibly others), I would like to actually be able
to test them. And, as I said, instead of asking for access to a
Windows/Cygwin node from my sys admin, it would be wonderful if I could
achieve a "Linux on top of Linux", weird as it may sound.


In short, no.  If you want to do runtime testing of software on Cygwin, 
you'll have to run Cygwin on Windows.  That being said, you could run 
Windows in a hypervisor (such as VirtualBox) and try running Cygwin in 
that VM.



So, this need for cross-platform compatibility (of my scripts) (between
just the two of Windows and Fedora) may not be entirely unwarranted.
Somewhat like the concept of cross-compilation for C programs without
access to a physical target.


A Cygwin cross-compiler toolchain and compatible packages are available 
for Fedora 14 and up.  The release RPM needed to install these via yum 
or PackageKit is available at:


http://sourceforge.net/projects/fedora-cygwin/files


Yaakov

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

Re: Cygwin for Fedora?

[Mike Brown]

On Thu, Mar 08, 2012 at 01:50:37PM +0530, Harry Simons wrote:
> My intent is not to emulate the low-level operating system API, it is 
> rather to emulate the *environment* consisting of packages and programs, 
> their versions, etc.

The problem I see with trying to emulate is that you don't have the MS OS
to test against.

For example, if you were trying to test scripts that were started from cron,
the cygwyn cron program wouldn't have what it needs from the MS OS, because it
isn't there.

As far as scripts are concerned, yes there are differences because of the
forward and backslash differences in path names and using cygwin tools to
convert from one to the other.  I too have Z-shell scripts on my XP boxes.
When running MS programs, the MS paths are needed.

But how do you test running MS programs when the MS programs do not exist?
For example, I have a complicated scripts that is used to doing x264
comiling, with other MS programs getting run to set up some other stuff,
like the audio.  Those are all MS programs.  Impossible to test, other than
on a MS system.

Unless I'm missing something and therefore way off base, I just do not see
the need.  Testing should be done under the actual environment.

Bring up Wine on your system, load the MS and cygwin.  Test away.

MB
-- 
e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII
6082066...@email.uscc.net (140 char limit)   \ / Ribbon Campaign
Visit - URL: http://vidiot.com/   X  Against
 http://vidiot.net/  / \ HTML Email

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Denis Excoffier]

On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
>> Hi Denis,
>> 
>> can you please test this again using the latest developer snapshot or
>> the current from CVS if you build Cygwin by yourself?  It provides a bit
>> more information to find the reason for the permission denied error in
>> _pinfo::dup_proc_pipe.
Thank you cgf (the committer and snapshot maker at least).
>> 
>> In theory, the user should have permissions to duplicate handles into
>> every own process, if the handle has been opened with these permissions,
>> so it's quite interesting to find the reason.
>> 

After about 3 hours of exercising the new snapshot (and shaking it a
little), i met the "something failed" instance only twice:

  1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) 
process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 0x764: 
DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5
503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) 
process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 0x768: 
DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5

I continue, of course.

Regards,

Denis Excoffier.

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

Re: rebase keeps last modification time of DLL unchanged

[Corinna Vinschen]

On Mar  7 23:07, Christian Franke wrote:
> The rebase tool does not change last modification timestamp of each
> DLL even if its data has changed. This is likely because Windows
> "may" not update the timestamp for files written through a memory
> mapped view.
> 
> Is this an intended behavior of rebase?

Why should rebase change the timestamp?  Apart from the rebasing, the
DLL is still the same.  If you want to know when it has been last
rebased, you can look into the file header:

  $ objdump -p cygiconv-2.dll | grep 'Time/Date[^ ]'
  Time/Date   Tue Mar  6 23:24:12 2012


Corinna

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

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

Re: Cygwin for Fedora?

[Corinna Vinschen]

On Mar  8 13:15, Harry Simons wrote:
> (e.g. /usr/bin/file, whose output for Microsoft documents changes
> with versions).

Huh?  What has the POSIX find command to do with Microsoft documents?


Corinna

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

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

Unable to start bash fatal error

[Diederik Faber]

Hi all,

My cygwin installation was running quite happily, until I updated this 
morning (march 8). After installation bash (now version 4.1.10-4) won't 
launch anymore.

When starting it from a DOS box, it gives this output:

D:\cygwin>bash
  0 [main] bash 8168 D:\cygwin\bin\bash.exe: *** fatal error - add_item 
("\??\D:\cygwin", "/", ...) failed, errno 1
Stack trace:
Frame Function  Args
00228908  6102FA3B  (00228908, , , 7C9101DB)
00228BF8  6102FA3B  (6119BD20, 8000, , 6119DB4F)
00229C28  61005F7C  (611D7EA0, 00229C54, , 60FE000C)
00229C48  61005FB8  (611D7EA0, 0022BC70, 0001, 0003000A)
0022CC88  6108FAE4  (60FE000C, 2347, 0022CD58, 61081840)
0022CCB8  610D169F  (48C98787, 01CCFD0F, 004657E0, 61272974)
   1180 [main] bash 8168 exception::handle: Exception: STATUS_ACCESS_VIOLATION


My cygwin installation resides in D:\cygwin, but the add_item parameter 
"\??\D:\cygwin" looks a bit suspicious.
I've located its value in the registry under 
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations\.
If I manually change the value to "D:\cygwin" and then start bash, it 
still gives the same problem. Better yet, the \??\ has returned into the 
registry key. Is this intended behavior?


Similar output is also generated when running cygcheck, so I couldn't 
attach its output.


Does anybody have a similar problem or maybe an idea on how to fix this?

Thanks,
Diederik

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

Re: trouble compiling openssh on cygwin

[Henry S. Thompson]

Edward Girard  writes:

> I am trying to compile openSSH on cygwin to incorporate a syntax
> highlighting patch: https://github.com/mxtommy/Cisco-SSH-Client
>
> I could not compile with the patch, I can not compile a fresh copy
> without the patch applied either.
>
> I have provided links to the ./configure and make ssh output.
>
> Version:
> $ uname -a
> CYGWIN_NT-5.1 NBC-WXP-LT-294 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin
>
>
> ./configure output:
> http://pastebin.com/rRKpDJB4
>
> make ssh output:
> http://pastebin.com/gJf0Nhqe

Either you've heavily edited your outputs, or you're not running from
the Cygwin OpenSSH source package.

To compile OpenSSH, use setup to install the Cygwin-appropriate
sources, and compile them.  Works for me.

If that's what you were trying already, give us the full output, not a
version editted for what you think is relevant.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

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

Re: cygwin-1.7.10-1 fork - address space needed by ... already in use

[Corinna Vinschen]

On Mar  8 09:50, Denis Excoffier wrote:
> On Wed, Mar 07, 2012 at 06:47:49PM +0100, Corinna Vinschen wrote:
> >> Hi Denis,
> >> 
> >> can you please test this again using the latest developer snapshot or
> >> the current from CVS if you build Cygwin by yourself?  It provides a bit
> >> more information to find the reason for the permission denied error in
> >> _pinfo::dup_proc_pipe.
> Thank you cgf (the committer and snapshot maker at least).
> >> 
> >> In theory, the user should have permissions to duplicate handles into
> >> every own process, if the handle has been opened with these permissions,
> >> so it's quite interesting to find the reason.
> >> 
> 
> After about 3 hours of exercising the new snapshot (and shaking it a
> little), i met the "something failed" instance only twice:
> 
>   1 [main] tcsh 7648! _pinfo::dup_proc_pipe: (child_info_spawn::worker) 
> process synchronization failed for pid 7648/0x754, wr_proc_pipe 0x0 vs. 
> 0x764: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5
> 503 [main] tcsh 6148! _pinfo::dup_proc_pipe: (child_info_spawn::worker) 
> process synchronization failed for pid 6148/0x758, wr_proc_pipe 0x0 vs. 
> 0x768: DuplicateHandle winerr 5, WFSO returned 258, Win32 error 5
> 
> I continue, of course.

Thanks, I don't think it's necessary to try further.  What this shows is
that the process handle returned by the call to CreateProcess sometimes,
for some reason, does not allow handle duplication.  That's weird.


Corinna

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

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

Re: 1.7.10 cygrunsrv.exe fails with "fork: 11, Resource temporarily unavailable"

[Ulf-Dietrich Braumann]

Great, Corinna, now cygrunsrv in its new version 1.40-1 works on my Win2k3 
64bit machine. Thanks for the repair - Ulf-Dietrich


On Wed, 7 Mar 2012, Corinna Vinschen wrote:

I just released a new cygrunsrv which fixes the problem for me.  What it 
does is to fork in a separate pthread, for which the stack has been set 
up in the application heap.  This reduceds the chance for collision a 
lot.  Please give it a try.


Corinna


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

Re: Unable to start bash fatal error

[marco atzeri]

On 3/8/2012 10:48 AM, Diederik Faber wrote:

Hi all,

My cygwin installation was running quite happily, until I updated this
morning (march 8). After installation bash (now version 4.1.10-4) won't
launch anymore.
When starting it from a DOS box, it gives this output:

D:\cygwin>bash
0 [main] bash 8168 D:\cygwin\bin\bash.exe: *** fatal error - add_item
("\??\D:\cygwin", "/", ...) failed, errno 1
Stack trace:
Frame Function Args
00228908 6102FA3B (00228908, , , 7C9101DB)
00228BF8 6102FA3B (6119BD20, 8000, , 6119DB4F)
00229C28 61005F7C (611D7EA0, 00229C54, , 60FE000C)
00229C48 61005FB8 (611D7EA0, 0022BC70, 0001, 0003000A)
0022CC88 6108FAE4 (60FE000C, 2347, 0022CD58, 61081840)
0022CCB8 610D169F (48C98787, 01CCFD0F, 004657E0, 61272974)
1180 [main] bash 8168 exception::handle: Exception: STATUS_ACCESS_VIOLATION


My cygwin installation resides in D:\cygwin, but the add_item parameter
"\??\D:\cygwin" looks a bit suspicious.
I've located its value in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations\.
If I manually change the value to "D:\cygwin" and then start bash, it
still gives the same problem. Better yet, the \??\ has returned into the
registry key. Is this intended behavior?

Similar output is also generated when running cygcheck, so I couldn't
attach its output.

Does anybody have a similar problem or maybe an idea on how to fix this?

Thanks,
Diederik


try a rebase
http://cygwin.com/faq-nochunks.html#faq.using.fixing-fork-failures

If does not work, please follow

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


Regards

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

Re: 1.7.10 cygrunsrv.exe fails with "fork: 11, Resource temporarily unavailable"

[Ulf-Dietrich Braumann]

Well, while sshd now can be launched again by cygrunsrv, still the 
mechanism behaves weird, in the event viewer sshd tells me to be stopped 
short after it was started, however in fact it runs. And in the services 
list the "Started" entry is missing, so it cannot be stopped there. - What 
counts at the moment, sshd basically works as service, thanks - 
Ulf-Dietrich



On Thu, 8 Mar 2012, Ulf-Dietrich Braumann wrote:

Great, Corinna, now cygrunsrv in its new version 1.40-1 works on my Win2k3 
64bit machine. Thanks for the repair - Ulf-Dietrich


On Wed, 7 Mar 2012, Corinna Vinschen wrote:

I just released a new cygrunsrv which fixes the problem for me.  What it 
does is to fork in a separate pthread, for which the stack has been set up 
in the application heap.  This reduceds the chance for collision a lot. 
Please give it a try.


Corinna


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

Re: Anamoly with ioctl() in cygwin 1.7.10

[Corinna Vinschen]

On Mar  8 01:35, Lee Collier wrote:
> Jon Clugston  gmail.com> writes:
> > 
> > Don't know if it will fix your problem, but you cannot just create a
> > mutex on the stack and call "lock" on it.  You must initialize it with
> > "pthread_mutex_init()".
> > 
> > Jon
> > 
> > 
> Good catch. I missed that in my haste to scrounge a sample pgm together. With 
> or 
> w/out initializing the mutex the anomaly still occurs.

You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
your executable and try again.  It should work.

This is terribly annoying.  While the executables are large address aware,
the operating system apparently is not!

What happens is that the function GetAdaptersAddresses fails, because
it's running on a thread stack in the large address area.  It doesn't
matter if the addresses given to the function are in the large address
area or not.  It's sufficent that the stack is there.  I'm not holy
myself, but this is really, really bad programming.  Grrr.

But that doesn't help, of course.  I'll try to come up with a solution.


Corinna

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

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

Re: 1.7.10 cygrunsrv.exe fails with "fork: 11, Resource temporarily unavailable"

[Corinna Vinschen]

On Mar  8 11:21, Ulf-Dietrich Braumann wrote:
> Well, while sshd now can be launched again by cygrunsrv, still the
> mechanism behaves weird, in the event viewer sshd tells me to be
> stopped short after it was started,

That doesn't happen for me.  Does your service entry for sshd omit
the -D option?  What does `cygrunsrv -Q sshd' print?  That should
look like:

  $ cygrunsrv -Q sshd
  Service : sshd
  Display name: CYGWIN sshd
  Current State   : [...]
  Command : /usr/sbin/sshd -D


Corinna

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

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

Re: Cygwin for Fedora?

[Harry Simons]

file, not find.

On 03/08/2012 03:03 PM, Corinna Vinschen wrote:

On Mar  8 13:15, Harry Simons wrote:

(e.g. /usr/bin/file, whose output for Microsoft documents changes
with versions).

Huh?  What has the POSIX find command to do with Microsoft documents?


Corinna



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

Re: Cygwin for Fedora?

[Corinna Vinschen]

On Mar  8 19:14, Harry Simons wrote:
> file, not find.
> 
> On 03/08/2012 03:03 PM, Corinna Vinschen wrote:
> >On Mar  8 13:15, Harry Simons wrote:
> >>(e.g. /usr/bin/file, whose output for Microsoft documents changes
> >>with versions).
> >Huh?  What has the POSIX find command to do with Microsoft documents?

Oops.


Corinna

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

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

Re: cygport: How to suppress automatic postinstall script additions

[Ken Brown]

On 3/6/2012 12:40 PM, Ken Brown wrote:

On 3/6/2012 7:28 AM, Ken Brown wrote:

On 3/5/2012 5:50 PM, Ken Brown wrote:

On 3/5/2012 4:23 PM, Yaakov (Cygwin/X) wrote:

On Mon, 2012-03-05 at 12:59 -0500, Ken Brown wrote:

On 3/5/2012 12:32 PM, Yaakov (Cygwin/X) wrote:

OK, here's the fix:

1) Install cygport-0.10.8.1-1 (released just moments ago).

2) Bump collection-basic to $today and build it with newly-downloaded
sources.

3) Bump collection-langcjk to $today, add 'jfontmaps' to ARCH_PKGS,
and
build with newly-downloaded sources.

After installing the new collection-basic with the new postinstall
script, the aforementioned xetex test works.


In your new postinstall script, I wonder if it would be better to
delete
/etc/texmf/web2c/updmap.cfg rather than editing it. The reason is that
the master updmap.cfg in /usr/share/texmf/web2c may have changed
due to
the addition or deletion of TL packages containing fonts, and I don't
think these changes get propagated to /etc/texmf/web2c/updmap.cfg.


The problem with that is any settings in
TEXMFSYSCONFIG/web2c/updmap.cfg
would be lost. What about the attached patch for cygport?


I won't have a chance to test it until tomorrow, but it looks good at
first glance. One question: I don't see where you take account of fonts
that might have been deleted. Shouldn't updmap-sys --syncwithtrees be
run on every postinstall to catch these?


I think it would be enough for texlive-collection-basic to have a custom
postinsall.sh that does this. There's no reason it has to be repeated by
every texlive-collection-* package.


Forget this last suggestion. I think the attached patch to
src_postinstall.cygpart does the right thing.


I've tested the patch in my previous email pretty extensively, and I'm 
pretty sure it's OK except for one detail:  The call to 
`/usr/bin/updmap-sys --nomkmap --enable $map' in the postinstall scripts 
should use the --nohash option.  I'm attaching a revised patch that does 
this.


The following 19 packages need to be updated (because they need to 
enable maps):


texlive-collection-basic
texlive-collection-context
texlive-collection-fontsextra
texlive-collection-fontsrecommended
texlive-collection-games
texlive-collection-langarabic
texlive-collection-langcjk
texlive-collection-langcyrillic
texlive-collection-langczechslovak
texlive-collection-langfrench
texlive-collection-langgreek
texlive-collection-langhebrew
texlive-collection-langindic
texlive-collection-langlithuanian
texlive-collection-langmongolian
texlive-collection-langpolish
texlive-collection-langvietnamese
texlive-collection-latex
texlive-collection-latexextra

I've rebuilt all of them and installed/uninstalled them in various 
combinations and couldn't find any problems involving fonts.


Before I update them in the distro, there's one other thing I thought of 
that the TeX Live postinstall scripts should be doing.  Shouldn't they 
call fc-cache whenever fonts are installed into 
usr/share/texmf-dist/fonts/opentype, 
usr/share/texmf-dist/fonts/truetype, or usr/share/texmf-dist/fonts/type1?


Ken

--- src_postinst.cygpart.orig   2012-03-06 12:28:09.0 -0500
+++ src_postinst.cygpart2012-03-08 09:30:08.116224600 -0500
@@ -263,21 +263,27 @@
 __prep_texlive() {
dodir /etc/postinstall
cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
-   if [ -x /usr/bin/mktexlsr ] && \\
-  [ ! -f /usr/share/texmf-dist/ls-R -o \\
+   if [ ! -f /usr/share/texmf-dist/ls-R -o \\
 \$(find /usr/share/texmf{,-dist} -mindepth 2 -type f 
-cnewer /usr/share/texmf-dist/ls-R 2>/dev/null | wc -l) -gt 0 ]
then
-   /usr/bin/mktexlsr
-   if test -f /etc/texmf/web2c/updmap.cfg; then
- /usr/bin/sed -i -e 's/^#! //g' /etc/texmf/web2c/updmap.cfg
-   fi
-   /usr/bin/updmap-sys --syncwithtrees
+   runfmtutil=1
+   /usr/bin/mktexlsr
+   /usr/bin/updmap-sys --syncwithtrees
+   fi
+   for map in $(__config_get texlive_updmaps)
+   do
+  /usr/bin/updmap-sys --nomkmap --nohash --enable \$map
+   done
+   if [ -n "\$map" ]
+   then
/usr/bin/updmap-sys --nohash
/usr/bin/mktexlsr
+   fi
+   if [ -n "\$runfmtutil" ]
+   then
/usr/bin/fmtutil-sys --all
/usr/bin/mktexlsr
fi
-
_EOF
 }
 # end of conditional __prepetc helpers

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

Re: 1.7.10 cygrunsrv.exe fails with "fork: 11, Resource temporarily unavailable"

[Ulf-Dietrich Braumann]

Thanks, Corinna, for asking if sshd was called with the -D option. This 
was the point, although I do not really know why -D was missing (I used 
ssh-host-config).


This is was came out before (sshd in fact was running):

$ cygrunsrv -Q sshd
Service : sshd
Display name: CYGWIN sshd
Current State   : Stopped
Command : /usr/sbin/sshd

Then I removed the service:

$ sc delete sshd
[SC] DeleteService SUCCESS

Then I rerun the installation script (only selected the service 
re-install, of course using the cyg_server account for Win2k3):


$ ssh-host-config
...
*** Info: Host configuration finished. Have fun!
$ cygrunsrv -S sshd
$ cygrunsrv -Q sshd
Service : sshd
Display name: CYGWIN sshd
Current State   : Running
Controls Accepted   : Stop
Command : /usr/sbin/sshd -D

I guess, when I was installing the service before, I may have changed 
something in the Properties menu of the CYGWIN sshd service, perhaps I 
tested something under the SYSTEM account and then have reverted to the 
cyg_server account, so by this action finally the -D may got lost for the 
call of sshd. BTW, I do not actually understand the meaning of -D (When 
this option is specified, sshd will not detach and does not become a 
daemon. This allows easy monitoring of sshd.)


Thank you again - Ulf-Dietrich


On Thu, 8 Mar 2012, Corinna Vinschen wrote:

That doesn't happen for me.  Does your service entry for sshd omit the 
-D option?  What does `cygrunsrv -Q sshd' print?  That should look like:


 $ cygrunsrv -Q sshd
 Service : sshd
 Display name: CYGWIN sshd
 Current State   : [...]
 Command : /usr/sbin/sshd -D

Corinna




On Mar  8 11:21, Ulf-Dietrich Braumann wrote:

Well, while sshd now can be launched again by cygrunsrv, still the 
mechanism behaves weird, in the event viewer sshd tells me to be 
stopped short after it was started,


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

install issue: have attached error logs

[Kyle Wonderly]

To anyone who can help:

I have tried multiple times to install cygwin without success. I
cannot seem to find any online information about people doing recent
installs or having any recent problems. I have watched videos of
people installing cygwin and done the exact same steps and had no
success. I am sorry if I am repeating a much asked question but I
cannot seem to find any previous support here. My log file has the
following errors (I am only including the two most recent tries in
order to not have a huge email):

2012/03/08 10:00:57 Starting cygwin install, version 2.769
2012/03/08 10:00:57 User has backup/restore rights
2012/03/08 10:00:57 io_stream_cygfile:
fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory
2012/03/08 10:00:57 io_stream_cygfile:
fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory
2012/03/08 10:00:57 io_stream_cygfile: fopen(/etc/setup/extrakeys)
failed 2 No such file or directory
2012/03/08 10:00:57 io_stream_cygfile:
fopen(/etc/setup/chooser_window_settings) failed 2 No such file or
directory
2012/03/08 10:00:57 Current Directory: C:\Documents and
Settings\Administrator\Desktop
2012/03/08 10:00:57 Could not open service McShield for query, start
and stop. McAfee may not be installed, or we don't have access.
2012/03/08 10:01:00 source: network install
2012/03/08 10:02:27 root: C:\cygwin binary system
2012/03/08 10:02:42 Selected local directory: C:\temp
2012/03/08 10:02:45 net: Direct
2012/03/08 10:02:45 io_stream_cygfile: fopen(/etc/setup/mirrors-lst)
failed 2 No such file or directory
2012/03/08 10:04:12 site: http://cygwin.mirrors.hoobly.com/
2012/03/08 10:04:12 site: ftp://cygwin.mirrors.hoobly.com/
2012/03/08 10:04:12 site: http://cygwin.mirrors.pair.com/
2012/03/08 10:04:12 mbox note: Unable to get setup.ini from

2012/03/08 10:04:14 mbox note: Unable to get setup.ini from

2012/03/08 10:04:14 mbox note: Unable to get setup.ini from

2012/03/08 10:05:26 site: ftp://mirror.its.uidaho.edu/
2012/03/08 10:05:26 mbox note: Unable to get setup.ini from

2012/03/08 10:05:31 Ending cygwin install

Any help is appreciated.


Thanks,

Kyle Wonderly
Thanks,

Kyle Wonderly

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

Re: 1.7.10 cygrunsrv.exe fails with "fork: 11, Resource temporarily unavailable"

[Corinna Vinschen]

On Mar  8 16:11, Ulf-Dietrich Braumann wrote:
> I guess, when I was installing the service before, I may have
> changed something in the Properties menu of the CYGWIN sshd service,
> perhaps I tested something under the SYSTEM account and then have
> reverted to the cyg_server account, so by this action finally the -D
> may got lost for the call of sshd. BTW, I do not actually understand
> the meaning of -D (When this option is specified, sshd will not
> detach and does not become a daemon. This allows easy monitoring of
> sshd.)

On UNIX-based systems, service processes usually fork and the child
process runs as the service in the background, while the parent process
exits.  That's what is called starting a daemon process.

The Windows Service Control Manager (SCM) doesn't support this mode of
operation, and cygrunsrv is the actual service process from SCM's point
of view.  cygrunsrv itself starts the *real* service like sshd, but in
the default mode it just forks and execs it off, then waits for the 
process to stop.  That's what the -D option of sshd is for.  It does
not create a daemon process and exits, rather the parent just runs as
the service directly.

Cygrunsrv can also handle daemon services, but that is only useful
if the service doesn't support running non-daemonized.  This also
requires the service to write a pidfile and using the cygrunsrv
--pidfile option.


Corinna

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

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

Re: trouble compiling openssh on cygwin

[Edward Girard]

I assure you I did not edit anything from my output.
It is exactly as it appears on the screen, I only copied and pasted.ssh

I am also using the OpenSSH src as you described, and those are the
outputs I got.

I apologize, but I am next to ignorant on this subject (compiling,
sources, patching).

Could anything be causing missing output?

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

Re: install issue: have attached error logs

[Adam Puckett]

Did you run setup.exe from the command line and choose mirror sites,
or use the GUI?

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

Re: Anamoly with ioctl() in cygwin 1.7.10

[Corinna Vinschen]

On Mar  8 11:33, Corinna Vinschen wrote:
> On Mar  8 01:35, Lee Collier wrote:
> > Jon Clugston  gmail.com> writes:
> > > 
> > > Don't know if it will fix your problem, but you cannot just create a
> > > mutex on the stack and call "lock" on it.  You must initialize it with
> > > "pthread_mutex_init()".
> > > 
> > > Jon
> > > 
> > > 
> > Good catch. I missed that in my haste to scrounge a sample pgm together. 
> > With or 
> > w/out initializing the mutex the anomaly still occurs.
> 
> You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
> your executable and try again.  It should work.
> 
> This is terribly annoying.  While the executables are large address aware,
> the operating system apparently is not!
> 
> What happens is that the function GetAdaptersAddresses fails, because
> it's running on a thread stack in the large address area.  It doesn't
> matter if the addresses given to the function are in the large address
> area or not.  It's sufficent that the stack is there.  I'm not holy
> myself, but this is really, really bad programming.  Grrr.
> 
> But that doesn't help, of course.  I'll try to come up with a solution.

Well, I think I have a solution now.  I applied a patch to CVS and
I'm just generating a new developer snapshot.  Please give the today's
snapshot from http://cygwin.com/snapshots/ a try.

Oh, and, 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

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

Re: trouble compiling openssh on cygwin

[René Berber]

On 3/7/2012 10:43 AM, Edward Girard wrote:

> I am trying to compile openSSH on cygwin to incorporate a syntax
> highlighting patch: https://github.com/mxtommy/Cisco-SSH-Client
> 
> I could not compile with the patch, I can not compile a fresh copy
> without the patch applied either.
> 
> I have provided links to the ./configure and make ssh output.

Wrong command, its not "make ssh", its just "make".
-- 
René Berber


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

Re: rebase keeps last modification time of DLL unchanged

[Christian Franke]

Corinna Vinschen wrote:

On Mar  7 23:07, Christian Franke wrote:

The rebase tool does not change last modification timestamp of each
DLL even if its data has changed. This is likely because Windows
"may" not update the timestamp for files written through a memory
mapped view.

Is this an intended behavior of rebase?

Why should rebase change the timestamp?  Apart from the rebasing, the
DLL is still the same.  If you want to know when it has been last
rebased, you can look into the file header:

   $ objdump -p cygiconv-2.dll | grep 'Time/Date[^ ]'
   Time/Date   Tue Mar  6 23:24:12 2012



It depends: Changing data without changing st_mtime avoids 
(unneeded|required) file copies during incremental backups, rsync, 
robocopy, ...


rebase does not explicitly (re)set the timestamp after rebasing. Is this 
by design?


It relies on weakly defined Windows behavior: "When modifying a file 
through a mapped view, the last modification timestamp *may* not be 
updated automatically."

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366563.aspx

Christian


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

RE: Can't reliably redirect standard output from C# program in recent Cygwin

[James Johnston]

Actually, the problem can be reproduced as follows from a C++ console
program.  The issue is not specific to .NET.  It appears that Cygwin croaks
if you give it a null write (writing zero bytes):

#include 

int _tmain(int argc, _TCHAR* argv[])
{
char * test = "AB";
DWORD written;

// Get standard output file handle
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);

// Do a null write.  This breaks Cygwin when output is redirected.
WriteFile(h, test, 0, &written, NULL);

// Print an "A" and a "B" in two write operations
WriteFile(h, test, 1, &written, NULL);
WriteFile(h, test+1, 1, &written, NULL);
return 0;
}

The correct output of "AB" is not printed when running "echo
`./HelloCPP.exe`" from Cygwin.  If you remove the null write (WriteFile of
zero bytes), then Cygwin captures the output of "AB" as expected.  Also note
that if the null write is moved between the printing of "A" and the printing
of "B", then the output is also as expected; it seems to be having problems
only when null write is the first write.

How is this related to .NET?  It turns out this is the API sequence used
when .NET decides to open standard output:

1.  Call GetStdHandle to get standard output file handle.
2.  Do a null write to test if the handle was opened successfully.  If it
wasn't, then a null stream is used instead of standard output.

There's really no way to disable #2 from a .NET programmer's perspective.
So this new Cygwin appears to have broken every .NET program writing to
standard output, and also every Windows program that does null writes to
standard output.

By the way, maybe these issues exist with standard error.  I didn't test.

1.  I assume this is a bug in Cygwin.  Anything more I should do for
reporting it? (e.g. creating an issue/ticket)
2.  Workaround suggestions?
3.  Which part of Cygwin do I need to roll back to fix this issue for now?

Best regards,

James Johnston

-Original Message-
Sent: Thursday, March 08, 2012 21:17
Subject: Can't reliably redirect standard output from C# program in recent
Cygwin

Hi,

I have had some problems with calling a .NET program written in C# from
Cygwin.  I believe it is a bug introduced in recent versions of Cygwin.  I
have boiled it down to these simple steps to reproduce:

1.  Create a new virtual machine with Windows 7 64-bit RTM installed on it;
don't install any Windows updates.  (Note that I have also reproduced it on
a Windows 7 64-bit host machine that is up-to-date on updates.  I have not
tried on other versions of Windows.)

2.  Create a simple Hello World console application in Visual C# 2008 SP1:
(a) create new console application, (b) add the following line of code to
the Main function:

Console.Write("HelloWorld");

Compile the app as usual; I did the default Debug / Any CPU build.

3.  Install Cygwin: go to Cygwin.com, go to the install page and download
the public "setup.exe".  Install using defaults: nothing changed, and no
additional packages added.

4.  Some test results from the Cygwin prompt:

JamesJ@JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ ./HelloCS.exe
HelloWorld JamesJ@JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $ echo
`./HelloCS.exe`


JamesJ@JTJDEVTOOLS /cygdrive/c/Users/JamesJ/Desktop $

Here's the problem:  the "echo `./HelloCS.exe`" line did NOT print
HelloWorld.  Why not?  What is going on here - is it a bug in .NET or
Cygwin?  My guess is Cygwin... this problem did not occur when I had
previously updated Cygwin in January.

Oddly enough, using "echo `./HelloCS.exe | cat`" works some of the time, but
it's not 100% reliable!  Running "./HelloCS.exe | cat" at the terminal
doesn't always work, either.

Are there any changes to the .NET program that could be added to work around
this bug and get the "echo `./HelloCS.exe`" line to work again?  Any changes
to Cygwin to make?  What package in Cygwin might have introduced this bug
(assuming it is a Cygwin bug) and can I safely roll back my setup to a
working version?

I attached output from cygcheck.out.  I also attached my setup.log file.
These files are from my host development workstation that has more than just
the base Cygwin packages installed.  Note that I ran setup on Feb 29, 2012.
That is when I first noticed the problem.  The previous time I ran setup to
update everything was Jan 18, 2012 - the problem did not exist yet after
that update.

Best regards,

James Johnston



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

Re: cygport: How to suppress automatic postinstall script additions

[Ken Brown]

On 3/8/2012 10:04 AM, Ken Brown wrote:

there's one other thing I thought of
that the TeX Live postinstall scripts should be doing. Shouldn't they
call fc-cache whenever fonts are installed into
usr/share/texmf-dist/fonts/opentype,
usr/share/texmf-dist/fonts/truetype, or usr/share/texmf-dist/fonts/type1?


I've made an attempt to do this, although there may well be a better 
way.  The attached patch replaces my previous one and includes the call 
to fc-cache.


Yaakov, I'll try to refrain from replying to this thread again until 
you've had a chance to look at this.


Ken
--- src_postinst.cygpart.orig   2012-03-05 12:27:39.0 -0500
+++ src_postinst.cygpart2012-03-08 16:44:51.470581100 -0500
@@ -262,22 +262,41 @@
 
 __prep_texlive() {
dodir /etc/postinstall
+   local texfontsdir=/usr/share/texmf-dist/fonts
+   local fcdirs
+   for d in opentype truetype type1
+   do
+   if [ -d ${D}${texfontsdir}/${d} ]
+   then
+   fcdirs+="${texfontsdir}/${d} "
+   fi
+   done
cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
-   if [ -x /usr/bin/mktexlsr ] && \\
-  [ ! -f /usr/share/texmf-dist/ls-R -o \\
+   if [ -n "${fcdirs}" ]
+   then
+   /usr/bin/fc-cache -f ${fcdirs}
+   fi
+   if [ ! -f /usr/share/texmf-dist/ls-R -o \\
 \$(find /usr/share/texmf{,-dist} -mindepth 2 -type f 
-cnewer /usr/share/texmf-dist/ls-R 2>/dev/null | wc -l) -gt 0 ]
then
+   runfmtutil=1
/usr/bin/mktexlsr
-   if test -f /etc/texmf/web2c/updmap.cfg; then
- /usr/bin/sed -i -e 's/^#! //g' /etc/texmf/web2c/updmap.cfg
-   fi
/usr/bin/updmap-sys --syncwithtrees
+   fi
+   for map in $(__config_get texlive_updmaps)
+   do
+   /usr/bin/updmap-sys --nomkmap --nohash --enable \$map
+   done
+   if [ -n "\$map" ]
+   then
/usr/bin/updmap-sys --nohash
/usr/bin/mktexlsr
+   fi
+   if [ -n "\$runfmtutil" ]
+   then
/usr/bin/fmtutil-sys --all
/usr/bin/mktexlsr
fi
-
_EOF
 }
 # end of conditional __prepetc helpers

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

Re: Anamoly with ioctl() in cygwin 1.7.10

[Lee Collier]

Corinna Vinschen  cygwin.com> writes:

> 
> On Mar  8 11:33, Corinna Vinschen wrote: 
> > You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
> > your executable and try again.  It should work.
>
> 
> Well, I think I have a solution now.  I applied a patch to CVS and
> I'm just generating a new developer snapshot.  Please give the today's
> snapshot from http://cygwin.com/snapshots/ a try.
> 
> Oh, and, thanks for the report and the testcase.
> 
> Corinna
> 

No problem. Thanks for your assistance. I am using a 64-bit machine and your 
'peflags -l0' suggestion fixed the problem. I'll give the snapshot a try as 
well 
and report back.

LC





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

Forking a program in a thread

[Enrico Forestieri]

I would like to point out a regression, seemingly introduced in 1.7.10.
If a program is exec'ed after forking in a thread and the program is
a native Windows program, it (seemingly) fails to start.

Please, find attached a test case. You can try it with gvim, for example.
There's no problem with the cygwin version of gvim:

$ ./fork_in_thread /usr/bin/gvim

but trying to start the native windows version:

$ ./fork_in_thread "/cygdrive/c/Program Files/Vim/vim73/gvim"

fails, in the sense that nothing happens and no error is reported.
A workaround here is using env. Indeed, the following works:

$ ./fork_in_thread env "/cygdrive/c/Program Files/Vim/vim73/gvim"

However, what puzzles me is the fact that a wrapper (like the one below)
starting gvim by using system() and compiled with i686-pc-mingw32-gcc
works, too!

All the previous examples were working in 1.7.9.

- wrapper.c -
#include 
int main(void)
{
system("\"C:/Program Files/Vim/vim73/gvim\"");
return 0;
}
-

-- 
Enrico
/*
 *Forks a program in a thread.
 */ 
#include 
#include 
#include 
#include 
#include 

void *start(void *arg)
{
int pid, status;
char **av = (char **)arg;
printf("Forking in a thread to start %s\n", av[0]);
pid = fork();
if (pid == -1) {
perror("fork");
exit(1);
}
if (pid == 0) {
execvp(av[0], av);
perror("execvp");
exit(1);
}
printf("Waiting in thread for %s to finish\n", av[0]);
if (wait(&status) == -1) {
perror("wait");
exit(1);
}
if (WIFEXITED(status) && WEXITSTATUS(status))
fprintf(stderr, "%s returned nonzero status %d", av[0], 
WEXITSTATUS(status));
pthread_exit(NULL);
}

int main (int argc, char *argv[])
{
pthread_t thread;
int i, rc;
char **av;

if (argc < 2) {
printf("Usage: %s  [ ...]\n", argv[0]);
exit(0);
}

/* Build the argument vector for the child */
av = malloc(argc * sizeof(char *));
if (!av) {
fprintf(stderr, "%s: no memory\n", argv[0]);
exit(1);
}
for (i = 0; i < argc - 1; ++i) {
av[i] = strdup(argv[i + 1]);
if (!av[i]) {
fprintf(stderr, "%s: no memory\n", argv[0]);
exit(1);
}
}
av[argc - 1] = NULL;

printf("Main: creating thread for starting %s\n", argv[1]);
rc = pthread_create(&thread, NULL, start, (void *)av);
if (rc) {
fprintf(stderr, "Error: return code from pthread_create() is %d\n", rc);
exit(1);
}
return 0;
}

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

Re: Can't reliably redirect standard output from C# program in recent Cygwin

[Bill Meier]

I've just noticed what sounds like the same issue:

On Windows 7, in a 'cmd' window (at a 'cmd' prompt) doing the following fails
more often than not:

perl -e 'print "abc";' | \cygwin\bin\more


That is: "abc" does not always display on the screen after
the command is executed.


I note that the problem does not seem to happen in a mintty window
or in bash started from a 'cmd' window.

I'm running cygwin perl 5.14 with an up-to-date cygwin.

Bill Meier

(I'm replying using gmane so as to keep the reply threaded
 not knowing how else
to do this).
 
aspell-en   7.1.0-1  OK
base-cygwin 3.0-1OK
base-files  4.1-1OK
base-passwd 3.1-2OK
bash4.1.10-4 OK
binutils2.22.51-1OK
bison   2.4.2-1  OK
build-docbook-catalog   1.5-2OK
bzip2   1.0.6-2  OK
ca-certificates 1.81-1   OK
coreutils   8.15-1   OK
cpio2.11-1   OK
crypt   1.1-1OK
csih0.9.5-1  OK
ctags   5.8-1OK
cygrunsrv   1.40-1   OK
cygutils1.4.8-1  OK
cygwin  1.7.11-1 OK
cygwin-doc  1.7-1OK
dash0.5.7-1  OK
...
patchutils  0.3.2-1  OK
perl5.14.1-2 OK
perl_manpages   5.10.1-5 OK
ping1.0-1OK
...


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

Re: Can't reliably redirect standard output from C# program in recent Cygwin

[marco atzeri]

On 3/9/2012 2:24 AM, Bill Meier wrote:

I've just noticed what sounds like the same issue:

On Windows 7, in a 'cmd' window (at a 'cmd' prompt) doing the following fails
more often than not:

perl -e 'print "abc";' | \cygwin\bin\more


That is: "abc" does not always display on the screen after
the command is executed.


I note that the problem does not seem to happen in a mintty window
or in bash started from a 'cmd' window.

I'm running cygwin perl 5.14 with an up-to-date cygwin.

Bill Meier



I guess it is some type of race.
on my W7/64 with 20120307 it works around 50% of
the times from cmd but 100% from the dash shell

Regards
Marco

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