Re: offline cygwin install question

[Corinna Vinschen]

On Jun 26 16:16, LMH wrote:
> I have a win7 64-bit machine that is not online and I want to update
> the cygwin install. What is the best method for doing this? Can I
> just copy the current cygwin install off of my XP 32-bit machine and
> drop it into the 64-bit win7 rig, or will that create a problem?

The easiest way, especially if you have more than one machine, is
IMHO to create a local mirror of the Cygwin distro first:

  
  mkdir cygwin
  rsync -av --delete-after cygwin.com:cygwin/ cygwin

This creates a local mirror of the 32 and 64 bit Cygwin versions.
The 32 bit version is more complete and runs on 32 and 64 bit,
as cgf pointed out.

The 64 bit version is not as complete yet as the 32 bit version,
but it's pretty stable already and a mirror of that only takes
9 Gigs:

  mkdir -p cygwin/64bit
  rsync -av --delete-after cygwin.com:cygwin/64bit cygwin/64bit

Copy this stuff over to an USB drive.  If you want to use the 64 bit
release, there's setup64.exe already in the cygwin/64bit directory.
If you want to use the 32 bit release, you also have to copy
http://cygwin.com/setup.exe to the USB drive.

Now, on the offline machine, plug in the USB drive (let's use u: as
drive letter as in cgf's example), and run either setup.exe for 32 bit
or setup64.exe for the 64 bit release.

Note that, if it already *has* a Cygwin install, it's almost 100% sure
that it's the 32 bit release.  So, run setup.exe in this case.

In the second dialog, choose "Install from Locale Directory".

In the fourth dialog, choose U:\cygwin as "Local Package Directory".

The rest should work as usual.


HTH,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Is there SCSI ioctl() support in cygwin? Where is sg.h?

[Corinna Vinschen]

On Jun 26 15:04, Christopher Faylor wrote:
> On Wed, Jun 26, 2013 at 05:30:51PM +0200, Corinna Vinschen wrote:
> >On Jun 26 08:31, Peter Allen wrote:
> >> I've searched the archives and the net and haven't found any
> >> information about using ioctl() to send commands to a SCSI disk.
> >> 
> >> I'm porting an application that needs structures defined in sg.h,
> >> (sg_io_hdr_t) but can't find that header in any cygwin package.
> >> 
> >> Is there support for this in cygwin?
> >
> >No, sorry, there isn't.  While Windows offers SCSI passthrough
> >capability using some DeviceIoControl control code, we don't support the
> >/dev/sg* devices and the translation from sg to underlying Windows
> >device.
> >
> >I played with the SCSI passthrough stuff a couple years ago.  I'd say,
> >the real problem is not to support passthrough, but the device
> >translation.  There's pretty certainly a way to offer that, but off the
> >top of my head I don't know how to.
> >
> >Adding a Cygwin fhandler for sg devices and SCSI passthrough would
> >probably be a nice side project for somebody who's interested in this
> >stuff.  It wouldn't really collide with anything which is already
> >implemented.
> 
> So when, exactly, do you expect to have this implemented then?  Next
> Thursday?

Let's say, it will be *a* Thursday, just don't expect me to say the
exact year...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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

Failure with fork()

[Arjen Markus]

Hello,

the bug I am reporting here on behalf of Alan Irwin surfaced in the
combination wine and Cygwin (Alan summarised it here:
http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
has to do with the way Cygwin handles forks.

The bug can be illustrated with this small program:

int main(void) {
while(!fork());
return 0;
}

It is meant to enable infinite forking, but on Cygwin it immediately
stops. I tried
it on both Cygwin (not via wine but simply Windows 7) and Linux:
- On Linux the program continues without any problem
- On Cygwin it stops immediately with an error message that the child process
  terminated unexpectedly with some weird return code.

Can anyone shed light on this? This bug is a showstopper for the
combination wine
and Cygwin.

Regards,

Arjen

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

Problems with patch

[Alexey Pavlov]

Prereq:
Having two files with the same name in directory. One file without
extension, second with ".exe". For example: "configure" and
"configure.exe".
I want patch "configure".
During patch Cygwin delete "configure.exe" and I have only "configure".

Regards,
Alexey.

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

[ANNOUNCEMENT] Updated: sed-4.2.2-2

[Corinna Vinschen]

I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.

This is an update of sed to use the latest regex implementation from
gnulib, thus implementing "rational ranges" for non-C locales per the
gnulib changes from 2012-12-30.

With sed 4.2.2-1 and earlier versions:

  $ LC_COLLATE=en_US.utf8
  $ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
  ab__eA___E

With sed 4.2.2-2 (as on Fedora 18 and similar newer Linux distros):

  $ LC_COLLATE=en_US.utf8
  $ echo abcdeABCDE | sed -e 's/[B-D]/_/g'
  abcdeA___E


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

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com

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

http://sourceware.org/lists.html#unsubscribe-simple

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

-- 
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: Problems with patch

[marco atzeri]

Il 6/27/2013 12:49 PM, Alexey Pavlov ha scritto:

Prereq:
Having two files with the same name in directory. One file without
extension, second with ".exe". For example: "configure" and
"configure.exe".
I want patch "configure".
During patch Cygwin delete "configure.exe" and I have only "configure".

Regards,
Alexey.


Alexey,
do not use two files in the same directory with and
without ".exe" extension

http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-exe

It is a cygwin limitation to solve "magically" the need of ".exe"
for binary programs.

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

Re: Problems with patch

[Earnie Boyd]

On Thu, Jun 27, 2013 at 7:13 AM, marco atzeri wrote:
> Il 6/27/2013 12:49 PM, Alexey Pavlov ha scritto:
>
>> Prereq:
>> Having two files with the same name in directory. One file without
>> extension, second with ".exe". For example: "configure" and
>> "configure.exe".
>> I want patch "configure".
>> During patch Cygwin delete "configure.exe" and I have only "configure".
>>
>> Regards,
>> Alexey.
>
>
> Alexey,
> do not use two files in the same directory with and
> without ".exe" extension
>

Regardless, Cygwin should not go deleting the .exe when the basename
file exists.  A work-around may be to append a '.' character to the
end of the file name.  I've used this method in the past but have not
tested it with recent Cygwin's.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: Failure with fork()

[Ryan Johnson]

On 27/06/2013 5:35 AM, Arjen Markus wrote:

Hello,

the bug I am reporting here on behalf of Alan Irwin surfaced in the
combination wine and Cygwin (Alan summarised it here:
http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
has to do with the way Cygwin handles forks.

The bug can be illustrated with this small program:

int main(void) {
 while(!fork());
 return 0;
}

It is meant to enable infinite forking, but on Cygwin it immediately
stops. I tried
it on both Cygwin (not via wine but simply Windows 7) and Linux:
- On Linux the program continues without any problem
- On Cygwin it stops immediately with an error message that the child process
   terminated unexpectedly with some weird return code.

Can anyone shed light on this? This bug is a showstopper for the
combination wine and Cygwin.
Out of curiosity, why do you need a fork bomb? Does the script just 
capture the effect of multiple fork calls in quick succession? How many 
forks can you pull off before it croaks, and is that number consistent 
from run to run? I'd be shocked if it really died "immediately" -- as in 
"zero forked children" -- so it would be interesting to see if the issue 
is related to the number of fork calls (resource exhaustion of some 
kind), or just to how quickly they run back to back (data race of some 
kind).


Ryan


--
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: Failure with fork()

[Corinna Vinschen]

On Jun 27 07:20, Ryan Johnson wrote:
> On 27/06/2013 5:35 AM, Arjen Markus wrote:
> >Hello,
> >
> >the bug I am reporting here on behalf of Alan Irwin surfaced in the
> >combination wine and Cygwin (Alan summarised it here:
> >http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
> >has to do with the way Cygwin handles forks.
> >
> >The bug can be illustrated with this small program:
> >
> >int main(void) {
> > while(!fork());
> > return 0;
> >}
> >
> >It is meant to enable infinite forking, but on Cygwin it immediately
> >stops. I tried
> >it on both Cygwin (not via wine but simply Windows 7) and Linux:
> >- On Linux the program continues without any problem
> >- On Cygwin it stops immediately with an error message that the child process
> >   terminated unexpectedly with some weird return code.
> >
> >Can anyone shed light on this? This bug is a showstopper for the
> >combination wine and Cygwin.
> Out of curiosity, why do you need a fork bomb? Does the script just
> capture the effect of multiple fork calls in quick succession? How
> many forks can you pull off before it croaks, and is that number
> consistent from run to run? I'd be shocked if it really died
> "immediately" -- as in "zero forked children" -- so it would be
> interesting to see if the issue is related to the number of fork
> calls (resource exhaustion of some kind), or just to how quickly
> they run back to back (data race of some kind).

It dies after somewhat below 500 forks and I think I found the reason.
Stay tuned.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Problems with patch

[Corinna Vinschen]

On Jun 27 13:49, Alexey Pavlov wrote:
> Prereq:
> Having two files with the same name in directory. One file without
> extension, second with ".exe". For example: "configure" and
> "configure.exe".
> I want patch "configure".
> During patch Cygwin delete "configure.exe" and I have only "configure".

This is by design.  .exe files are handled by Cygwin as if they don't
have a .exe suffix in all circumstances, no matter what.  This has been
discussed already on this list in past.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Problems with patch

[marco atzeri]

Il 6/27/2013 1:17 PM, Earnie Boyd ha scritto:

On Thu, Jun 27, 2013 at 7:13 AM, marco atzeri wrote:

Il 6/27/2013 12:49 PM, Alexey Pavlov ha scritto:


Prereq:
Having two files with the same name in directory. One file without
extension, second with ".exe". For example: "configure" and
"configure.exe".
I want patch "configure".
During patch Cygwin delete "configure.exe" and I have only "configure".

Regards,
Alexey.



Alexey,
do not use two files in the same directory with and
without ".exe" extension



Regardless, Cygwin should not go deleting the .exe when the basename
file exists.  A work-around may be to append a '.' character to the
end of the file name.  I've used this method in the past but have not
tested it with recent Cygwin's.



The workaround is "do not do it".
For cygwin "configure.exe" is also "configure", trying to outsmart this
fact is prone to failure.

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

Re: Failure with fork()

[Arjen Markus]

According to the original thread it has to do with handling the stack.
The small program is
meant to show that there is a discrepancy between the way Cygwin
handles this versus
the way Linux does that - something to do with accessing more memory
pages than expected,
but this is not an area I am familiar with ;).

> It dies after somewhat below 500 forks and I think I found the reason.
> Stay tuned.
>

I will. It would be great if this can be solved.

Regards,

Arjen

--
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.20: cygicons-0.dll has gone missing

[Nellis, Kenneth]

From: Buchbinder, Barry (NIH/NIAID) [E] gone missing

> The cygutils package was recently split into cygutils-extra and
> cygutils-x11.  Install cygutils-extra.

Doesn't this suggest that cygicons-0.dll should be included
in the base cygwin package?

--Ken Nellis

--
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: offline cygwin install question

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

<... wrote:
> I have a win7 64-bit machine that is not online and I want to update
> the cygwin install. What is the best method for doing this? Can I just
> copy the current cygwin install off of my XP 32-bit machine and drop
> it into the 64-bit win7 rig, or will that create a problem?

Do the experiment.

I copy 32 bit cygwin between my desktop and laptop (Windows 7, 64
bit) (using a network drive as an intermediary) and it work fine for
me.  I use xcopy followed by a Windows mirroring utility (mirror -
) in a cmd batch file.  For a first
install xcopy alone or a copy using Windows Explorer should work
fine.

This all assumes that that both installation are at equivalent
locations, e.g., C:\cygwin.  When I, on occasional, run it from
H:\cygwin, it runs but seems to have problems finding customizations.
I've never tried tracking it down but mounts set in fstab to C: are a
possible problem, as are lack of environmental variables set in
Windows.

Good luck,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.



--
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.20: cygicons-0.dll has gone missing

[marco atzeri]

Il 6/27/2013 2:19 PM, Nellis, Kenneth ha scritto:

From: Buchbinder, Barry (NIH/NIAID) [E] gone missing


The cygutils package was recently split into cygutils-extra and
cygutils-x11.  Install cygutils-extra.


Doesn't this suggest that cygicons-0.dll should be included
in the base cygwin package?

--Ken Nellis


base does not needs icons, so in IMHO no.

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

sed match DOS end of line

[Paul Becker]

> From: On Behalf Of Corinna Vinschen
> Sent: Thursday, June 27, 2013 6:49 AM
> Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> 
> I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.

Since this 'sed' change, I noticed that "$" does not match a dos formatted file 
end-of-line anymore.

example:
echo "endofline^M" | sed "s/e$/X/"

sed 4.2.1 returns
   endoflinX

sed 4.2.2 returns
   endofline

I don’t know if this is better or worse, or expected or not, but it is easy 
enough to fix my broken scripts.
Scripts will be less portable between windows and linux now unless I take this 
into consideration.
(and replace "$" with "^M*$")

$ echo $LC_COLLATE

$ echo $LANG
en_US.UTF-8

--
Paul

Re: sed match DOS end of line

[Corinna Vinschen]

On Jun 27 13:28, Paul Becker wrote:
> > From: On Behalf Of Corinna Vinschen
> > Sent: Thursday, June 27, 2013 6:49 AM
> > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> > 
> > I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.
> 
> Since this 'sed' change, I noticed that "$" does not match a dos formatted 
> file end-of-line anymore.
> 
> example:
> echo "endofline^M" | sed "s/e$/X/"
> 
> sed 4.2.1 returns
>endoflinX
> 
> sed 4.2.2 returns
>endofline

This seems to be an upstream change.  The Cygwin 4.2.1 and 4.2.2
releases are build the same way.  4.2.1-2 (-3 on 64 bit) and 4.2.2-1 are
both built from just the vanilla upstream sources.

While 4.2.2-2 adds the latest upstream gnulib regex, it behaves
otherwise identically to 4.2.2-1.  And both 4.2.2 releases show the same
behaviour in terms of CRLF line endings.

But it's really puzzeling.  There's no indication for this change
in the sources.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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

autoreconf/gettext puzzle (was Re: sed match DOS end of line)

[Corinna Vinschen]

On Jun 27 16:24, Corinna Vinschen wrote:
> On Jun 27 13:28, Paul Becker wrote:
> > > From: On Behalf Of Corinna Vinschen
> > > Sent: Thursday, June 27, 2013 6:49 AM
> > > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> > > 
> > > I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.
> > 
> > Since this 'sed' change, I noticed that "$" does not match a dos formatted 
> > file end-of-line anymore.
> > 
> > example:
> > echo "endofline^M" | sed "s/e$/X/"
> > 
> > sed 4.2.1 returns
> >endoflinX
> > 
> > sed 4.2.2 returns
> >endofline
> 
> This seems to be an upstream change.  The Cygwin 4.2.1 and 4.2.2
> releases are build the same way.  4.2.1-2 (-3 on 64 bit) and 4.2.2-1 are
> both built from just the vanilla upstream sources.
> 
> While 4.2.2-2 adds the latest upstream gnulib regex, it behaves
> otherwise identically to 4.2.2-1.  And both 4.2.2 releases show the same
> behaviour in terms of CRLF line endings.
> 
> But it's really puzzeling.  There's no indication for this change
> in the sources.

Ok, here's me, even more puzzled.  FIW, the 4.2.2 packages have *not*
been built the same way as the 4.2.1 package.  The difference is running
autoreconf (4.2.2) vs. not running autoreconf (4.2.1).

If I build sed with the auto configury unchanged, I'm back to an sed
which handles the CR just as the old sed 4.2.1 package:

  $ sed --version | head -1
  sed (GNU sed) 4.2.2
  $ od -c eol
  000   e   n   d   o   f   l   i   n   e  \r  \n
  013
  $ sed 's/e$/X/' < eol
  endoflinX

However, 4.2.2-1 and 4.2.2-2 packages have been built running autoreconf
first, which, besides other things, updates the included gettext stuff
from version 0.17 to version 0.18.1.

So I'm wondering if the latest gettext is the culprit here, but I'm not
fluent enough in the differences within gettext to see where the problem
is.

Chuck?  Yaakov?  Do you have any explanation or, even better, a
workaround for this phenomenon, other than not running autoreconf?

Anyway, for the time being, I'll upload 4.2.2-3 packages shortly which
has been build without running autoreconf, which will fix the CRLF vs.
LF problem.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: autoreconf/gettext puzzle (was Re: sed match DOS end of line)

[Corinna Vinschen]

On Jun 27 16:49, Corinna Vinschen wrote:
> On Jun 27 16:24, Corinna Vinschen wrote:
> > On Jun 27 13:28, Paul Becker wrote:
> > > > From: On Behalf Of Corinna Vinschen
> > > > Sent: Thursday, June 27, 2013 6:49 AM
> > > > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> > > > 
> > > > I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.
> > > 
> > > Since this 'sed' change, I noticed that "$" does not match a dos 
> > > formatted file end-of-line anymore.
> > > 
> > > example:
> > > echo "endofline^M" | sed "s/e$/X/"
> > > 
> > > sed 4.2.1 returns
> > >endoflinX
> > > 
> > > sed 4.2.2 returns
> > >endofline
> > 
> > This seems to be an upstream change.  The Cygwin 4.2.1 and 4.2.2
> > releases are build the same way.  4.2.1-2 (-3 on 64 bit) and 4.2.2-1 are
> > both built from just the vanilla upstream sources.
> > 
> > While 4.2.2-2 adds the latest upstream gnulib regex, it behaves
> > otherwise identically to 4.2.2-1.  And both 4.2.2 releases show the same
> > behaviour in terms of CRLF line endings.
> > 
> > But it's really puzzeling.  There's no indication for this change
> > in the sources.
> 
> Ok, here's me, even more puzzled.  FIW, the 4.2.2 packages have *not*
> been built the same way as the 4.2.1 package.  The difference is running
> autoreconf (4.2.2) vs. not running autoreconf (4.2.1).
> 
> If I build sed with the auto configury unchanged, I'm back to an sed
> which handles the CR just as the old sed 4.2.1 package:
> 
>   $ sed --version | head -1
>   sed (GNU sed) 4.2.2
>   $ od -c eol
>   000   e   n   d   o   f   l   i   n   e  \r  \n
>   013
>   $ sed 's/e$/X/' < eol
>   endoflinX
> 
> However, 4.2.2-1 and 4.2.2-2 packages have been built running autoreconf
> first, which, besides other things, updates the included gettext stuff
> from version 0.17 to version 0.18.1.
> 
> So I'm wondering if the latest gettext is the culprit here, but I'm not
> fluent enough in the differences within gettext to see where the problem
> is.
> 
> Chuck?  Yaakov?  Do you have any explanation or, even better, a
> workaround for this phenomenon, other than not running autoreconf?
> 
> Anyway, for the time being, I'll upload 4.2.2-3 packages shortly which
> has been build without running autoreconf, which will fix the CRLF vs.
> LF problem.

Easier said than done.  This only fixed CRLF handling for the 64 bit
version.  The 32 bit version, built without autoreconf, still doesn't
recognize the CR.

Help?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: autoreconf/gettext puzzle (was Re: sed match DOS end of line)

[Yaakov (Cygwin/X)]

On 2013-06-27 09:49, Corinna Vinschen wrote:

Ok, here's me, even more puzzled.  FIW, the 4.2.2 packages have *not*
been built the same way as the 4.2.1 package.  The difference is running
autoreconf (4.2.2) vs. not running autoreconf (4.2.1).


Were these natively compiled or cross-compiled?  The latter pulls in 
gnulib functions in place of libc's (Cygwin) without intervention during 
configure.



If I build sed with the auto configury unchanged, I'm back to an sed
which handles the CR just as the old sed 4.2.1 package:

   $ sed --version | head -1
   sed (GNU sed) 4.2.2
   $ od -c eol
   000   e   n   d   o   f   l   i   n   e  \r  \n
   013
   $ sed 's/e$/X/' < eol
   endoflinX

However, 4.2.2-1 and 4.2.2-2 packages have been built running autoreconf
first, which, besides other things, updates the included gettext stuff
from version 0.17 to version 0.18.1.

So I'm wondering if the latest gettext is the culprit here, but I'm not
fluent enough in the differences within gettext to see where the problem
is.


I doubt it; as long as libintl is dynamically linked, the gettext build 
infrastructure just handles .po.mo rules.



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: autoreconf/gettext puzzle (was Re: sed match DOS end of line)

[Corinna Vinschen]

On Jun 27 10:42, Yaakov (Cygwin/X) wrote:
> On 2013-06-27 09:49, Corinna Vinschen wrote:
> >Ok, here's me, even more puzzled.  FIW, the 4.2.2 packages have *not*
> >been built the same way as the 4.2.1 package.  The difference is running
> >autoreconf (4.2.2) vs. not running autoreconf (4.2.1).
> 
> Were these natively compiled or cross-compiled?  The latter pulls in
> gnulib functions in place of libc's (Cygwin) without intervention
> during configure.
> 
> >If I build sed with the auto configury unchanged, I'm back to an sed
> >which handles the CR just as the old sed 4.2.1 package:
> >
> >   $ sed --version | head -1
> >   sed (GNU sed) 4.2.2
> >   $ od -c eol
> >   000   e   n   d   o   f   l   i   n   e  \r  \n
> >   013
> >   $ sed 's/e$/X/' < eol
> >   endoflinX
> >
> >However, 4.2.2-1 and 4.2.2-2 packages have been built running autoreconf
> >first, which, besides other things, updates the included gettext stuff
> >from version 0.17 to version 0.18.1.
> >
> >So I'm wondering if the latest gettext is the culprit here, but I'm not
> >fluent enough in the differences within gettext to see where the problem
> >is.
> 
> I doubt it; as long as libintl is dynamically linked, the gettext
> build infrastructure just handles .po.mo rules.

Yeah, I seem to be entirely on the wrong track, sorry about that.

I'm just inspecting the sources and it seems that the read mode of
files has changed from "rt" to "r" between 4.2.1 and 4.2.2 for some
reason.

I'm still digging, and I'm unsure how I could create a version of
sed 4.2.2 which did the right thing at all a couple of minutes ago.

Still digging...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Is there SCSI ioctl() support in cygwin? Where is sg.h?

[Larry Hall (Cygwin)]

On 6/27/2013 4:33 AM, Corinna Vinschen wrote:

On Jun 26 15:04, Christopher Faylor wrote:

On Wed, Jun 26, 2013 at 05:30:51PM +0200, Corinna Vinschen wrote:

On Jun 26 08:31, Peter Allen wrote:

I've searched the archives and the net and haven't found any
information about using ioctl() to send commands to a SCSI disk.

I'm porting an application that needs structures defined in sg.h,
(sg_io_hdr_t) but can't find that header in any cygwin package.

Is there support for this in cygwin?


No, sorry, there isn't.  While Windows offers SCSI passthrough
capability using some DeviceIoControl control code, we don't support the
/dev/sg* devices and the translation from sg to underlying Windows
device.

I played with the SCSI passthrough stuff a couple years ago.  I'd say,
the real problem is not to support passthrough, but the device
translation.  There's pretty certainly a way to offer that, but off the
top of my head I don't know how to.

Adding a Cygwin fhandler for sg devices and SCSI passthrough would
probably be a nice side project for somebody who's interested in this
stuff.  It wouldn't really collide with anything which is already
implemented.


So when, exactly, do you expect to have this implemented then?  Next
Thursday?


Let's say, it will be *a* Thursday, just don't expect me to say the
exact year...


This isn't another issue involving kittens, is it?

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in 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: Is there SCSI ioctl() support in cygwin? Where is sg.h?

[Corinna Vinschen]

On Jun 27 11:55, Larry Hall (Cygwin) wrote:
> On 6/27/2013 4:33 AM, Corinna Vinschen wrote:
> >On Jun 26 15:04, Christopher Faylor wrote:
> >>On Wed, Jun 26, 2013 at 05:30:51PM +0200, Corinna Vinschen wrote:
> >>>On Jun 26 08:31, Peter Allen wrote:
> I've searched the archives and the net and haven't found any
> information about using ioctl() to send commands to a SCSI disk.
> 
> I'm porting an application that needs structures defined in sg.h,
> (sg_io_hdr_t) but can't find that header in any cygwin package.
> 
> Is there support for this in cygwin?
> >>>
> >>>No, sorry, there isn't.  While Windows offers SCSI passthrough
> >>>capability using some DeviceIoControl control code, we don't support the
> >>>/dev/sg* devices and the translation from sg to underlying Windows
> >>>device.
> >>>
> >>>I played with the SCSI passthrough stuff a couple years ago.  I'd say,
> >>>the real problem is not to support passthrough, but the device
> >>>translation.  There's pretty certainly a way to offer that, but off the
> >>>top of my head I don't know how to.
> >>>
> >>>Adding a Cygwin fhandler for sg devices and SCSI passthrough would
> >>>probably be a nice side project for somebody who's interested in this
> >>>stuff.  It wouldn't really collide with anything which is already
> >>>implemented.
> >>
> >>So when, exactly, do you expect to have this implemented then?  Next
> >>Thursday?
> >
> >Let's say, it will be *a* Thursday, just don't expect me to say the
> >exact year...
> 
> This isn't another issue involving kittens, is it?

You know how kittens have no sense of time.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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

[ANNOUNCEMENT] Updated: sed-4.2.2-3

[Corinna Vinschen]

I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-3.

This version fixes the CR/LF line ending problem reported in
http://cygwin.com/ml/cygwin/2013-06/msg00673.html

Other than that, it's the same as version 4.2.2-2, see
http://cygwin.com/ml/cygwin-announce/2013-06/msg00036.html


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

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com

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

http://sourceware.org/lists.html#unsubscribe-simple

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

-- 
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: offline cygwin install question

[Christopher Faylor]

On Thu, Jun 27, 2013 at 10:32:33AM +0200, Corinna Vinschen wrote:
>On Jun 26 16:16, LMH wrote:
>> I have a win7 64-bit machine that is not online and I want to update
>> the cygwin install. What is the best method for doing this? Can I
>> just copy the current cygwin install off of my XP 32-bit machine and
>> drop it into the 64-bit win7 rig, or will that create a problem?
>
>The easiest way, especially if you have more than one machine, is
>IMHO to create a local mirror of the Cygwin distro first:
>
>  
>  mkdir cygwin
>  rsync -av --delete-after cygwin.com:cygwin/ cygwin
>
>This creates a local mirror of the 32 and 64 bit Cygwin versions.
>The 32 bit version is more complete and runs on 32 and 64 bit,
>as cgf pointed out.

Yow.  Please don't encourage people to perform high-bandwith-consuming
operations to cygwin.com.  I don't want to have to start limiting rsync
access to cygwin.com because everyone thinks that doing full copies of
the release area is a good idea.

You could use an rsync mirror (see http://cygwin.com/mirrors.html) for
this but this seems like severe overkill for what the OP wanted.
Duplicating their installation from one system to another shouldn't
involve downloading the whole Cygwin release, whether it is 32-bit or
64-bit.

cgf

--
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: Failure with fork()

[Corinna Vinschen]

On Jun 27 13:34, Arjen Markus wrote:
> According to the original thread it has to do with handling the stack.
> The small program is
> meant to show that there is a discrepancy between the way Cygwin
> handles this versus
> the way Linux does that - something to do with accessing more memory
> pages than expected,
> but this is not an area I am familiar with ;).
> 
> > It dies after somewhat below 500 forks and I think I found the reason.
> > Stay tuned.
> >
> 
> I will. It would be great if this can be solved.

Should be fixed in CVS.  Thanks for the report.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Failure with fork()

[Christopher Faylor]

On Thu, Jun 27, 2013 at 01:34:04PM +0200, Arjen Markus wrote:
>According to the original thread it has to do with handling the stack.

The original thread even pointed to the problem.  I introduced a change
back on 2013-06-18 which was supposed to fix this but Corinna found one
more place where there was a problem.

--
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: autoreconf/gettext puzzle (was Re: sed match DOS end of line)

[Corinna Vinschen]

On Jun 27 17:51, Corinna Vinschen wrote:
> On Jun 27 10:42, Yaakov (Cygwin/X) wrote:
> > On 2013-06-27 09:49, Corinna Vinschen wrote:
> > >Ok, here's me, even more puzzled.  FIW, the 4.2.2 packages have *not*
> > >been built the same way as the 4.2.1 package.  The difference is running
> > >autoreconf (4.2.2) vs. not running autoreconf (4.2.1).
> > 
> > Were these natively compiled or cross-compiled?  The latter pulls in
> > gnulib functions in place of libc's (Cygwin) without intervention
> > during configure.
> > 
> > >If I build sed with the auto configury unchanged, I'm back to an sed
> > >which handles the CR just as the old sed 4.2.1 package:
> > >
> > >   $ sed --version | head -1
> > >   sed (GNU sed) 4.2.2
> > >   $ od -c eol
> > >   000   e   n   d   o   f   l   i   n   e  \r  \n
> > >   013
> > >   $ sed 's/e$/X/' < eol
> > >   endoflinX
> > >
> > >However, 4.2.2-1 and 4.2.2-2 packages have been built running autoreconf
> > >first, which, besides other things, updates the included gettext stuff
> > >from version 0.17 to version 0.18.1.
> > >
> > >So I'm wondering if the latest gettext is the culprit here, but I'm not
> > >fluent enough in the differences within gettext to see where the problem
> > >is.
> > 
> > I doubt it; as long as libintl is dynamically linked, the gettext
> > build infrastructure just handles .po.mo rules.
> 
> Yeah, I seem to be entirely on the wrong track, sorry about that.
> 
> I'm just inspecting the sources and it seems that the read mode of
> files has changed from "rt" to "r" between 4.2.1 and 4.2.2 for some
> reason.
> 
> I'm still digging, and I'm unsure how I could create a version of
> sed 4.2.2 which did the right thing at all a couple of minutes ago.
> 
> Still digging...

I have no idea how I screwed up so badly while testing.  It was actually
just a missing "t" flag in a call to fopen which has been lost between
4.2.1 and 4.2.2.

I just uploaded and announced 4.2.2-3 which should fix this issue, and I
sent the patch upstream.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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

gdb hangs when it calls tcsetpgrp.

[jojelino]

I was using gdb for debugging ffmpeg raising SIGFPE. but gdb hangs after 
entering command among of s,n,si,ni.
gdb has same pgrp over pgrp of debuggee. when tcsetpgrp is called in 
gdb, you already know it sends __SIGSETPGRP signal to suspended 
debuggee. but the debugger already suspended all thread of debuggee 
without distinguishing whether the victim thread is wait_sig or not. so 
the suspend process doesn't wake up until debugger handles debug event. 
which is the cause of hang.
Although it seems that cygwin developers have already aware of sort of 
this issue according to fhandler_termios.cc:85, so, it would be good if 
cygwin can defer sending signal that would block for sure.


--
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: gdb hangs when it calls tcsetpgrp.

[Christopher Faylor]

On Fri, Jun 28, 2013 at 02:30:42AM +0900, jojelino wrote:
>I was using gdb for debugging ffmpeg raising SIGFPE. but gdb hangs after 
>entering command among of s,n,si,ni.
>gdb has same pgrp over pgrp of debuggee. when tcsetpgrp is called in 
>gdb, you already know it sends __SIGSETPGRP signal to suspended 
>debuggee. but the debugger already suspended all thread of debuggee 
>without distinguishing whether the victim thread is wait_sig or not. so 
>the suspend process doesn't wake up until debugger handles debug event. 
>which is the cause of hang.
>Although it seems that cygwin developers have already aware of sort of 
>this issue according to fhandler_termios.cc:85, so, it would be good if 
>cygwin can defer sending signal that would block for sure.

Yep.  I've mentioned this issue here several times.  You should use
mintty for debugging.  It does not have this problem.

cgf

--
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: offline cygwin install question

[LMH]

I have win7 64-bit computers set up in another location. It would seem 
that the easiest option would be to make sure that one of those is up to 
date and then just tar up the cygwin directory and move it. I have also 
found that you can just tar up the local package directory and then run 
a local install, but this seems to have issues if there are packages in 
the local install dir from more than one mirror.


If I download the normal setup.exe to a 64-bit windows install, will it 
automatically install the 4-bit version? have never seen the setup64.exe 
that was mentioned in a previous post. Where would that be located?


I have to assume at this point that the cygwin I have running on w7 
64-bit installs is the 32-bit version of cygwin, since I didn't do 
anything special when I set those up. I know that many 32-bit 
applications run perfectly well on a w7 64-bit install. What specific 
advantages would there be in running the 64-bit version of cygwin?


The main thing I want to do is to upgrade to the minty terminal and make 
sure I am using the most current version of cygwin. I think that the 
version on this rig is pretty old.


Thanks for the advice,

LMH


Christopher Faylor wrote:

On Thu, Jun 27, 2013 at 10:32:33AM +0200, Corinna Vinschen wrote:

On Jun 26 16:16, LMH wrote:

I have a win7 64-bit machine that is not online and I want to update
the cygwin install. What is the best method for doing this? Can I
just copy the current cygwin install off of my XP 32-bit machine and
drop it into the 64-bit win7 rig, or will that create a problem?


The easiest way, especially if you have more than one machine, is
IMHO to create a local mirror of the Cygwin distro first:

  
  mkdir cygwin
  rsync -av --delete-after cygwin.com:cygwin/ cygwin

This creates a local mirror of the 32 and 64 bit Cygwin versions.
The 32 bit version is more complete and runs on 32 and 64 bit,
as cgf pointed out.


Yow.  Please don't encourage people to perform high-bandwith-consuming
operations to cygwin.com.  I don't want to have to start limiting rsync
access to cygwin.com because everyone thinks that doing full copies of
the release area is a good idea.

You could use an rsync mirror (see http://cygwin.com/mirrors.html) for
this but this seems like severe overkill for what the OP wanted.
Duplicating their installation from one system to another shouldn't
involve downloading the whole Cygwin release, whether it is 32-bit or
64-bit.

cgf

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




--
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: where was mention of what creates NUL files?

[g]

Daniel Barclay  fgm.com> writes:

> 
> Does anyone recall a mention of what in CygWin (or possibly Emacs) creates
> files with a simple name of "NUL"?
> 
> Thanks,
> Daniel
> 
> 


This has been driving me nuts for years. Finally tracked it down.
These are created by emacs' man.el code when you get a man page.
Reproduce: 
In emacs, do:
M-x man 

Now, you'll see a NUL file in the directory.

Root cause:
construction of the 'man' command that is passed to the shell includes:
(concat " %s 2>" null-device)

The variable `null-device' is platform specific and defaults to a pure-copy
of "/dev/null" which, apparently, becomes "NUL" on windows.

It is a defvar in files.el and 'set' again in dos-w32.el.

Resolution:
In your .emacs file, do:

   (require 'dos-w32) ;; load this first to avoid it undo'ing the next line
   (setq null-device "c:/tmp/emacs-dev-null.txt") ;; set to anything

Happy days!




--
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: Failure with fork()

[Alan W. Irwin]

I have been following this thread with great interest via the archive,
but now I have newly subscribed to this list to ask additional
questions.

Corinna said "Should be fixed in CVS.  Thanks (to Arjen) for the report."

My thanks to Arjen for getting this thread started, and
my thanks to Corinna for so swiftly finding the fix.

I would now like to test this fix from a broader perspective of
attempting to run the fixed setup.exe version on Wine.

My background is I have had considerable success with using the
combination of MinGW, MSYS, and Wine as a build and test platform for
free software.  I would like to similarly attempt to use the
combination of Cygwin and Wine as a build and test platform for free
software but I was stopped from doing that because the last stage of
running Cygwin setup.exe on Wine ran into this fork issue.

The only Windows platform available to me is Wine.  And I have
no Cygwin on Wine experience at this stage because this fork bug shut
me out.  But now that it is fixed in CVS, how do I get access to
the fixed version of setup.exe?

Are there daily snapshot builds of the CVS version I could access?

Or do I have to build the CVS version of Cygwin from scratch on (the
Wine version of) Windows using MinGW and MSYS, and if so is there a
website with directions for how to do that?

Sorry for the Cygwin newbie questions, but I am quite experienced with
the Unix command line and building software both on Linux and on the
bash.exe command line accessible with MinGW/MSYS/Wine so I hope I will
only need hints to get started with (a) building the CVS version
of Cygwin with the fork fix, and (b) building and testing software for
the Cygwin on Wine platform.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
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: where was mention of what creates NUL files?

[Ken Brown]

On 6/26/2013 2:53 PM, g wrote:




Daniel Barclay  fgm.com> writes:



Does anyone recall a mention of what in CygWin (or possibly Emacs) creates
files with a simple name of "NUL"?

Thanks,
Daniel





This has been driving me nuts for years. Finally tracked it down.
These are created by emacs' man.el code when you get a man page.
Reproduce:
In emacs, do:
 M-x man 
 
Now, you'll see a NUL file in the directory.


I can't reproduce this with Cygwin emacs.  You must be using native 
Windows emacs.



Root cause:
construction of the 'man' command that is passed to the shell includes:
(concat " %s 2>" null-device)

The variable `null-device' is platform specific and defaults to a pure-copy
of "/dev/null" which, apparently, becomes "NUL" on windows.

It is a defvar in files.el and 'set' again in dos-w32.el.

Resolution:
In your .emacs file, do:

(require 'dos-w32) ;; load this first to avoid it undo'ing the next line
(setq null-device "c:/tmp/emacs-dev-null.txt") ;; set to anything


Just to be clear, users of Cygwin emacs should *not* do this.

Ken

--
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: Failure with fork()

[marco atzeri]

Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:

I have been following this thread with great interest via the archive,
but now I have newly subscribed to this list to ask additional
questions.

Corinna said "Should be fixed in CVS.  Thanks (to Arjen) for the report."

My thanks to Arjen for getting this thread started, and
my thanks to Corinna for so swiftly finding the fix.

I would now like to test this fix from a broader perspective of
attempting to run the fixed setup.exe version on Wine.

My background is I have had considerable success with using the
combination of MinGW, MSYS, and Wine as a build and test platform for
free software.  I would like to similarly attempt to use the
combination of Cygwin and Wine as a build and test platform for free
software but I was stopped from doing that because the last stage of
running Cygwin setup.exe on Wine ran into this fork issue.

The only Windows platform available to me is Wine.  And I have
no Cygwin on Wine experience at this stage because this fork bug shut
me out.  But now that it is fixed in CVS, how do I get access to
the fixed version of setup.exe?

Are there daily snapshot builds of the CVS version I could access?


daily not, but on reasonable schedule
(aka when Corinna or Christopher release one)

http://cygwin.com/snapshots/

just wait for the next cygwin1-20130xxx.dll.bz2
and replace the installed cygwin1.dll with the new one



Or do I have to build the CVS version of Cygwin from scratch on (the
Wine version of) Windows using MinGW and MSYS, and if so is there a
website with directions for how to do that?

Sorry for the Cygwin newbie questions, but I am quite experienced with
the Unix command line and building software both on Linux and on the
bash.exe command line accessible with MinGW/MSYS/Wine so I hope I will
only need hints to get started with (a) building the CVS version
of Cygwin with the fork fix, and (b) building and testing software for
the Cygwin on Wine platform.

Alan
__
Alan W. Irwin



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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 11:35-0700 Alan W. Irwin wrote:


The only Windows platform available to me is Wine.  And I have
no Cygwin on Wine experience at this stage because this fork bug shut
me out.  But now that it is fixed in CVS, how do I get access to
the fixed version of setup.exe?

Are there daily snapshot builds of the CVS version I could access?


Never mind.  I have now found the snapshots page, and the latest one
contains

013-06-18  Christopher Faylor  

* dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
stack pointer since getstack() already does that.

Could someone confirm that is the fork fix of interest here?

I am somewhat confused by the remark
at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
that "You cannot use Cygwin Setup to install a snapshot."

So what exactly is installed by a snapshot?  Is it just the core part
of Cygwin?  Is there enough included in cygwin-inst-MMDD.tar.bz2
so I can run setup.exe from the installed version of that tarball to
download and install or update additional Cygwin components that I
might need?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
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: Failure with fork()

[marco atzeri]

Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:

On 2013-06-27 11:35-0700 Alan W. Irwin wrote:


The only Windows platform available to me is Wine.  And I have
no Cygwin on Wine experience at this stage because this fork bug shut
me out.  But now that it is fixed in CVS, how do I get access to
the fixed version of setup.exe?

Are there daily snapshot builds of the CVS version I could access?


Never mind.  I have now found the snapshots page, and the latest one
contains

013-06-18  Christopher Faylor  

* dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
stack pointer since getstack() already does that.

Could someone confirm that is the fork fix of interest here?


Of course not. Corinna solved the problem today
and cygwin1-20130619.dll.bz2 was built last 19th June
so you need to wait the next one.



I am somewhat confused by the remark
at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
that "You cannot use Cygwin Setup to install a snapshot."

So what exactly is installed by a snapshot?  Is it just the core part
of Cygwin?


It is just the core cygwin1.dll
The easy way is copy the new one on the current one.
Of course all cygwin processes must be shutdown before..


Is there enough included in cygwin-inst-MMDD.tar.bz2
so I can run setup.exe from the installed version of that tarball to
download and install or update additional Cygwin components that I
might need?

Alan
__
Alan W. Irwin




--
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: offline cygwin install question

[Christopher Faylor]

On Thu, Jun 27, 2013 at 01:52:20PM -0400, LMH wrote:
>I have win7 64-bit computers set up in another location. It would seem 
>that the easiest option would be to make sure that one of those is up to 
>date and then just tar up the cygwin directory and move it.

http://cygwin.com/ml/cygwin/2013-06/msg00657.html

>I have also 
>found that you can just tar up the local package directory and then run 
>a local install, but this seems to have issues if there are packages in 
>the local install dir from more than one mirror.

I don't see why.  If the directory is duplicated precisely I don't see
how it could matter.

>If I download the normal setup.exe to a 64-bit windows install, will it 
>automatically install the 64-bit version?

No.

>I have never seen the setup64.exe that was mentioned in a previous
>post.  Where would that be located?

64-bit Cygwin is currently still in beta.  setup64 is in the '64bit'
directory on any mirror.  You can't use it to change a Cygwin
installation from 32 - 64 bit though.

cgf

--
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: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 21:00+0200 marco atzeri wrote:


Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:

Are there daily snapshot builds of the CVS version I could access?


daily not, but on reasonable schedule
(aka when Corinna or Christopher release one)

http://cygwin.com/snapshots/

just wait for the next cygwin1-20130xxx.dll.bz2
and replace the installed cygwin1.dll with the new one


I haven't even gotten as far as an initial install because
of this fork bug.


From the Linux command line here is what I did some time ago (for a

wine-git version very close to wine-1.6.0-rc1 and for (presumably) the
latest stable release of setup.exe downloaded from
http://cygwin.com/setup.exe) when I first ran into the fork bug:

wineconsole setup.exe

The setup GUI fired up, I went through all the screens without issues, but
then the final screen completely bombed out due to this fork bug.  Any
attempts to use setup.exe afterward failed immediately (presumably
because that aborted last screen of the GUI did not complete some
critical task.)

So I think I have to do a complete installation from
cygwin-inst-MMDD.tar.bz2, and assuming that contains setup.exe,
run that version from wineconsole to obtain a a Cygwin system where I
select the further packages I need to have installed (the build tools
as well as some important library dependencies such as pango, cairo,
and Qt4) so that I can build further software on the Cygwin platform.
Do you agree this is the right approach?

Also, I think the current snapshot actually does contain
the fork bug fix, but I have asked for confirmation of
that in my last post.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
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: Failure with fork()

[Achim Gratz]

Alan W. Irwin writes:
> I haven't even gotten as far as an initial install because
> of this fork bug.

If you've never installed Cygwin then this is going to be a bit
more difficult, but here it is anyway...

You'll need a cygwin package that has the snapshot files built in.  To
do this, unpack the files from the current cygwin package into a
temporary directory, then unpack the snapshot files into the same
directory (which updates the directory with the filesfrom the snapshot),
package the directory up again as a tar.bz2 file, note the md5sum and
change the entry in setup.ini for the package to have the correct
filename (if you've changed it) and checksum.  You should then be able
to use setup.exe just fine to install a new Cygwin instance.


Here's a Makefile that will do the packaging, adjust the locations:

--8<---cut here---start->8---
.PHONY: all install clean force-clean clean-install snapshot install-snapshot 
snapshot-debuginfo install-snapshot-debuginfo

CV ?= 1.7.19
CR ?= 1
CVR = $(CV)-$(CR)
SD ?= 20130627

CYGMIR   = /mnt/mirror/cygwin/release/cygwin
CYGDEB   = $(CYGMIR)/cygwin-debuginfo
SNAPSHOT = $(PWD)/snapshot-$(SD)
SNAPDEB  = $(PWD)/snapshot-debuginfo-$(SD)
SNAPMIR  = /mnt/mirror/snapshot
PATCH= /mnt/mirror/patch/release/cygwin
PATCHDEB = $(PATCH)/cygwin-debuginfo

all:snapshot snapshot-debuginfo
install:clean-install clean install-snapshot install-snapshot-debuginfo 
force-clean
clean force-clean:
rm -fr $(SNAPSHOT)
rm -fr $(SNAPDEB)
clean-install:  clean
rm -f  $(PATCH)/cygwin-$(CVR)s$(SD).tar.bz2 
$(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.bz2

snapshot:
mkdir   -p $(SNAPSHOT)
tar -C $(SNAPSHOT) -xf $(CYGMIR)/cygwin-$(CVR).tar.bz2
tar -C $(SNAPSHOT) -xf 
/mnt/mirror/snapshot/cygwin-inst-$(SD).tar.bz2
install-snapshot:   snapshot
tar -C $(SNAPSHOT) -cf $(PATCH)/cygwin-$(CVR)s$(SD).tar.bz2 etc/ 
usr/

snapshot-debuginfo:
mkdir   -p $(SNAPDEB)
tar -C $(SNAPDEB)  -xf $(CYGDEB)/cygwin-debuginfo-$(CVR).tar.bz2
bunzip2 -c $(SNAPMIR)/cygwin1-$(SD).dbg.bz2 > 
$(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg
touch   -r $(SNAPMIR)/cygwin1-$(SD).dbg.bz2 
$(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg
install-snapshot-debuginfo: snapshot-debuginfo
tar -C $(SNAPDEB) -cf 
$(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.bz2 usr/
--8<---cut here---end--->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra


--
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: offline cygwin install question

[LMH]

I don't see why.  If the directory is duplicated precisely I don't see
how it could matter.


What I was referring to here was to just copy the cygwin local package 
directory that contains setup.exe and the http% mirror directories, not 
the directory that contains installed cygwin. When I moved the local 
package directory to a new machine and ran setup.exe with install from 
local directory, there sometimes were problems.


If there was only one http% directory

/http%3a%2f%2fwww.gtlib.gatech.edu%2fpub%2fcygwin%2f
/setup.exe
/setup.log

(meaning all of the cygwin install on the machine where I took the 
setup.exe dir from had been done from the same mirror)


then running setup.exe worked fine and I got a functional cygwin.

If found that if there were several mirror directories,

/http%3a%2f%2fcygutils.fruitbat.org%2fITP%2fmingw-gcc%2f
/http%3a%2f%2fmirror.cs.vt.edu%2fpub%2fcygwin%2fcygwin%2f
/http%3a%2f%2fwww.gtlib.gatech.edu%2fpub%2fcygwin%2f
/setup.exe
/setup.log

then running setup.exe would install only the packages in the last 
mirror used and there would be a number of things missing from the 
install (like the cygwin.dll). I did this before I knew that I could 
just move the entire installed cygwin directory to a different machine.



Regarding this set of instructions,
http://cygwin.com/ml/cygwin/2013-06/msg00657.html

they seem to be a bit more involved than is necessary. My cygwin install 
directory is less than 1GB, so what is the need to use tar? I believe 
that when I last re-installed my current OS, I just copied my cygwin 
folder to a backup drive and then copied it back to C: after my 
re-install. Is there some reason why that is a bad idea?


LMH




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




--
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: Failure with fork()

[gmt]

on Thu, 27 Jun 2013, at 12:22, Alan W. Irwin thusly quipped:
> On 2013-06-27 21:00+0200 marco atzeri wrote:
> 
>> Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:
>>> Are there daily snapshot builds of the CVS version I could access?
>> 
>> daily not, but on reasonable schedule
>> (aka when Corinna or Christopher release one)
>> 
>> http://cygwin.com/snapshots/
>> 
>> just wait for the next cygwin1-20130xxx.dll.bz2
>> and replace the installed cygwin1.dll with the new one
> 
> I haven't even gotten as far as an initial install because
> of this fork bug.
> 
> From the Linux command line here is what I did some time ago (for a
> wine-git version very close to wine-1.6.0-rc1 and for (presumably) the
> latest stable release of setup.exe downloaded from
> http://cygwin.com/setup.exe) when I first ran into the fork bug:
> 
> wineconsole setup.exe

I haven't tried this myself (yet), but if you "can't wait", and have access to 
a mingw64 cross-compiler, you can likely get cygwin cvs here: 
http://cygwin.com/cvs.html, and, from there, follow a fairly typical 
cross-compiling configure && make && make install DESTDIR=foo && tar type of 
process to create your own "ghetto" snapshot, that you could drop into place on 
top of your your half-completed nascent cyg-wine install.  From there, you 
could run setup.exe, uncheck the "cygwin" and "newlib" packages, and then, when 
setup.exe prompts you to put those packages back in, uncheck the box (by 
default, checked) specifying to add them.

Assuming you get that far, successfully, you'd then expect to see some results 
-- either finding the next bug, discovering the bug still exists, somehow, or 
that everything is magically fixed... what-have-you.

Alternatively, you could try to create a cross-cygport.  Not sure how easy/hard 
that is, but I'd guess it's fairly straightforward.  Cygport by default 
generates "setup.exe"-compatible package-trees that, if I'm not mistaken, by 
following easily-google-able advice, can be overlaid into your setup.exe's 
package-set so that you could follow a standard setup.exe process without 
having to uncheck those core packages.

No idea what results you'll get -- very likely an anticlimax where you simply 
find the next bug -- but one of the above would probably allow you to proceed; 
worst-case you'd at least have a build environment, for future testing/hacking, 
that you could recycle. 

-gmt


--
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: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 21:13+0200 marco atzeri wrote:


Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:

I have now found the snapshots page, and the latest one
contains

013-06-18  Christopher Faylor  

* dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
stack pointer since getstack() already does that.

Could someone confirm that is the fork fix of interest here?


Of course not. Corinna solved the problem today
and cygwin1-20130619.dll.bz2 was built last 19th June
so you need to wait the next one.


Sorry about that.  Didn't check the date, and it looked promising
because of that reference to fork and the stack.



I am somewhat confused by the remark
at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
that "You cannot use Cygwin Setup to install a snapshot."

So what exactly is installed by a snapshot?  Is it just the core part
of Cygwin?


It is just the core cygwin1.dll
The easy way is copy the new one on the current one.
Of course all cygwin processes must be shutdown before..


I think you keep assuming I have some version of Cygwin already
installed when that is not the case.  It is the last stage of the
initial attempt at installation using setup.exe that fails on Wine due
to the fork bug. Furthermore, when I download setup.exe from
http://cygwin.com/setup.exe it contains the fork bug. That version is
self-contained, i.e., only setup.exe needs to be downloaded, not
cygwin1.dll in addition.  I presume that is because setup.exe uses a
static version of the cygwin library as a matter of convenience rather
than depending on an external cygwin1.dll that could be separately
downloaded.

I have looked at the table of contents of the latest
cygwin-inst-20130619.tar.bz2 since that appears to be the most
complete recent snapshot version.  Although it does contain a number
of *.exe files and other core components of cygwin as advertised it is
missing many components of Cygwin that I need.  Also, it is missing
the key setup.exe core component which precludes any chance of
installing the rest of what I need based on this snapshot version of
Cygwin.

So the question still remains how do I gain access to a version of
setup.exe with the fork fix that will allow me to not only initialize
my Cygwin distribution for Wine without the fork abort, but also
subsequently update it to install all components of Cygwin that I
need?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
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: Failure with fork()

[Christopher Faylor]

On Thu, Jun 27, 2013 at 01:33:53PM -0700, Alan W. Irwin wrote:
>On 2013-06-27 21:13+0200 marco atzeri wrote:
>
>> Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:
>>> I have now found the snapshots page, and the latest one
>>> contains
>>> 
>>> 013-06-18  Christopher Faylor  
>>> 
>>> * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
>>> stack pointer since getstack() already does that.
>>> 
>>> Could someone confirm that is the fork fix of interest here?
>>
>> Of course not. Corinna solved the problem today
>> and cygwin1-20130619.dll.bz2 was built last 19th June
>> so you need to wait the next one.
>
>Sorry about that.  Didn't check the date, and it looked promising
>because of that reference to fork and the stack.

http://cygwin.com/ml/cygwin/2013-06/msg00684.html

--
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: offline cygwin install question

[Christopher Faylor]

On Thu, Jun 27, 2013 at 04:17:05PM -0400, LMH wrote:
>> I don't see why.  If the directory is duplicated precisely I don't see
>> how it could matter.
>
>What I was referring to here was to just copy the cygwin local package 
>directory that contains setup.exe and the http% mirror directories,

Yes, I knew what you meant.

I read your description of the problem but I can't offer any explanation
for it.

>Regarding this set of instructions,
>http://cygwin.com/ml/cygwin/2013-06/msg00657.html
>
>they seem to be a bit more involved than is necessary. My cygwin install 
>directory is less than 1GB, so what is the need to use tar? I believe 
>that when I last re-installed my current OS, I just copied my cygwin 
>folder to a backup drive and then copied it back to C: after my 
>re-install. Is there some reason why that is a bad idea?

Using tar rather than a Windows utility will make sure that things like
symlinks are preserved.  And, a tar file will take up less space and be
quicker to create than duplicated directory structure.

cgf

--
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: Failure with fork()

[Larry Hall (Cygwin)]

On 6/27/2013 4:33 PM, Alan W. Irwin wrote:



I think you keep assuming I have some version of Cygwin already
installed when that is not the case.  It is the last stage of the
initial attempt at installation using setup.exe that fails on Wine due
to the fork bug. Furthermore, when I download setup.exe from
http://cygwin.com/setup.exe it contains the fork bug. That version is
self-contained, i.e., only setup.exe needs to be downloaded, not
cygwin1.dll in addition.  I presume that is because setup.exe uses a
static version of the cygwin library as a matter of convenience rather
than depending on an external cygwin1.dll that could be separately
downloaded.


No not really.  'setup.exe' is a pure Windows executable.  It doesn't
rely on cygwin1.dll at all.  However, as part of the installation process
for individual packages, there are (possible) preremove and postinstall
scripts.  These are shell scripts that invoke Cygwin utilities.  These
utilities, therefore, use cygwin1.dll.  This is where you were seeing
the problem.


I have looked at the table of contents of the latest
cygwin-inst-20130619.tar.bz2 since that appears to be the most
complete recent snapshot version.  Although it does contain a number
of *.exe files and other core components of cygwin as advertised it is
missing many components of Cygwin that I need.  Also, it is missing
the key setup.exe core component which precludes any chance of
installing the rest of what I need based on this snapshot version of
Cygwin.


'setup.exe' is built from separate sources.  See
 for details.  But I don't
think this is really what you want.


So the question still remains how do I gain access to a version of
setup.exe with the fork fix that will allow me to not only initialize
my Cygwin distribution for Wine without the fork abort, but also
subsequently update it to install all components of Cygwin that I
need?


Since you want to just run 'setup.exe', you need a new cygwin package
(i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
without any extra effort on your part.  So unless you're willing to
build your own version of this package and put it in your download
directory in the appropriate spot (after you've downloaded the
packages you want), you want to just wait for the next announcement
for the cygwin package.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in 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: Failure with fork()

[Peter Rosin]

On 2013-06-27 22:33, Alan W. Irwin wrote:
> I think you keep assuming I have some version of Cygwin already
> installed when that is not the case.  It is the last stage of the
> initial attempt at installation using setup.exe that fails on Wine due
> to the fork bug. Furthermore, when I download setup.exe from
> http://cygwin.com/setup.exe it contains the fork bug. That version is
> self-contained, i.e., only setup.exe needs to be downloaded, not
> cygwin1.dll in addition.  I presume that is because setup.exe uses a
> static version of the cygwin library as a matter of convenience rather
> than depending on an external cygwin1.dll that could be separately
> downloaded.

I think the real reason is that setup has downloaded and installed
cygwin1.dll, and is using it when running the post-install scripts.
There is no statically linked cygwin library in setup.exe.

> So the question still remains how do I gain access to a version of
> setup.exe with the fork fix that will allow me to not only initialize
> my Cygwin distribution for Wine without the fork abort, but also
> subsequently update it to install all components of Cygwin that I
> need?

If the procedure in [1] is too complicated, you will have to wait for
a new cygwin package to be released.

Cheers,
Peter

[1] http://cygwin.com/ml/cygwin/2013-06/msg00697.html


--
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: Failure with fork()

[Thrall, Bryan]

Larry Hall (Cygwin) wrote on 2013-06-27:
> On 6/27/2013 4:33 PM, Alan W. Irwin wrote:
>> So the question still remains how do I gain access to a version of
>> setup.exe with the fork fix that will allow me to not only initialize
>> my Cygwin distribution for Wine without the fork abort, but also
>> subsequently update it to install all components of Cygwin that I
>> need?
> 
> Since you want to just run 'setup.exe', you need a new cygwin package
> (i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
> without any extra effort on your part.  So unless you're willing to
> build your own version of this package and put it in your download
> directory in the appropriate spot (after you've downloaded the
> packages you want), you want to just wait for the next announcement
> for the cygwin package.

Since the fork bug is only affecting the execution of the postinstall
scripts, couldn't the OP install the snapshot in the partially-complete
Cygwin install, then run setup.exe to finish the postinstall scripts?

--
Bryan Thrall
Principal Software Engineer
FlightSafety International * Visual Simulation Systems * 5695 Campus
Parkway  * Hazelwood, MO 63042
Tel: (314) 551-8413 * Fax: (314) 551-8444
bryan.thr...@flightsafety.com * www.flightsafety.com * A Berkshire
Hathaway company



--
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: Failure with fork()

[Yaakov (Cygwin/X)]

On 2013-06-27 15:33, Alan W. Irwin wrote:

I think you keep assuming I have some version of Cygwin already
installed when that is not the case.  It is the last stage of the
initial attempt at installation using setup.exe that fails on Wine due
to the fork bug. Furthermore, when I download setup.exe from
http://cygwin.com/setup.exe it contains the fork bug. That version is
self-contained, i.e., only setup.exe needs to be downloaded, not
cygwin1.dll in addition.  I presume that is because setup.exe uses a
static version of the cygwin library as a matter of convenience rather
than depending on an external cygwin1.dll that could be separately
downloaded.


There is no such thing as static linkage of Cygwin.  setup.exe is in 
fact a native Windows (MinGW) executable, due to the fact that it needs 
to be able to run before Cygwin is installed, or while upgrading 
cygwin1.dll.


Therefore, if you are seeing fork() errors when running setup, they are 
actually coming from the postinstall scripts which are run after 
installing files.  In that case, the best solution may be something 
along the lines of (untested):


1) Open the Wine equivalent of taskmgr.exe.
2) Run setup.exe again and install just the Base packages.
3) During postinstall, kill any bash.exe processes ASAP.
4) setup.exe should list some postinstall errors before completion, 
which can be ignored for now.
5) After setup.exe is finished, replace C:\cygwin\bin\cygwin1.dll with 
the latest snapshot DLL.
6) Run setup.exe again with the same options; the postinstall scripts 
should (in theory) run properly this time.

7) Launch Cygwin Terminal once to set up your environment.
8) Run setup.exe one more time to install additional packages.

HTH,


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: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 15:56-0500 Yaakov (Cygwin/X) wrote:


On 2013-06-27 15:33, Alan W. Irwin wrote:

I think you keep assuming I have some version of Cygwin already
installed when that is not the case.  It is the last stage of the
initial attempt at installation using setup.exe that fails on Wine due
to the fork bug. Furthermore, when I download setup.exe from
http://cygwin.com/setup.exe it contains the fork bug. That version is
self-contained, i.e., only setup.exe needs to be downloaded, not
cygwin1.dll in addition.  I presume that is because setup.exe uses a
static version of the cygwin library as a matter of convenience rather
than depending on an external cygwin1.dll that could be separately
downloaded.


There is no such thing as static linkage of Cygwin.  setup.exe is in fact a 
native Windows (MinGW) executable, due to the fact that it needs to be able 
to run before Cygwin is installed, or while upgrading cygwin1.dll.


Therefore, if you are seeing fork() errors when running setup, they are 
actually coming from the postinstall scripts which are run after installing 
files.  In that case, the best solution may be something along the lines of 
(untested):


1) Open the Wine equivalent of taskmgr.exe.
2) Run setup.exe again and install just the Base packages.
3) During postinstall, kill any bash.exe processes ASAP.
4) setup.exe should list some postinstall errors before completion, which can 
be ignored for now.
5) After setup.exe is finished, replace C:\cygwin\bin\cygwin1.dll with the 
latest snapshot DLL.
6) Run setup.exe again with the same options; the postinstall scripts should 
(in theory) run properly this time.

7) Launch Cygwin Terminal once to set up your environment.
8) Run setup.exe one more time to install additional packages.



Once the relevant snapshot is released I will let you know how far I
get with a variant of the above I have thought of which is replacing
cygwin1.dll on the fly when the individual step of the initial run of
setup.exe that installs cygwin1.dll is completed.  That method takes
advantage of the fact that the fork issue only occurs during the final
step of the install and presumably nothing is using cygwin1.dll when
the prior step that installs cygwin1.dll is completed.  So ideally
this method would be completely error free, but I will see about that,
and if not I will fall back to trying your method.

Thanks to you and the many (!) other posters here for clarifying the
issue (i.e., that the fork issue I see as a result of running
setup.exe is in one of the invoked commands that are linked to
cygwin1.dll that is downloaded by setup.exe and not in setup.exe
itself.)

More later.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
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: Failure with fork()

[Yaakov (Cygwin/X)]

http://cygwin.com/acronyms/#PPIOSPE !

On 2013-06-27 16:52, Alan W. Irwin wrote:

Once the relevant snapshot is released I will let you know how far I


The 20130627 snapshot is now available.


get with a variant of the above I have thought of which is replacing
cygwin1.dll on the fly when the individual step of the initial run of
setup.exe that installs cygwin1.dll is completed.  That method takes
advantage of the fact that the fork issue only occurs during the final
step of the install and presumably nothing is using cygwin1.dll when
the prior step that installs cygwin1.dll is completed.  So ideally
this method would be completely error free, but I will see about that,
and if not I will fall back to trying your method.


That might just work, if you get the timing right.


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: where was mention of what creates NUL files?

[wynfield]

I do not have the problem using emacs built on cygwin either.


> On 6/26/2013 2:53 PM, g wrote:
> >
> >
> >
> > Daniel Barclay  fgm.com> writes:
> >
> >>
> >> Does anyone recall a mention of what in CygWin (or possibly Emacs) creates
> >> files with a simple name of "NUL"?
> >>
> >> Thanks,
> >> Daniel
> >>
> >>
> >
> >
> > This has been driving me nuts for years. Finally tracked it down.
> > These are created by emacs' man.el code when you get a man page.
> > Reproduce:
> > In emacs, do:
> >  M-x man 
> >  
> > Now, you'll see a NUL file in the directory.
> 
> I can't reproduce this with Cygwin emacs.  You must be using native
> Windows emacs.
> 
> > Root cause:
> > construction of the 'man' command that is passed to the shell includes:
> > (concat " %s 2>" null-device)
> >
> > The variable `null-device' is platform specific and defaults to a pure-copy
> > of "/dev/null" which, apparently, becomes "NUL" on windows.
> >
> > It is a defvar in files.el and 'set' again in dos-w32.el.
> >
> > Resolution:
> > In your .emacs file, do:
> >
> > (require 'dos-w32) ;; load this first to avoid it undo'ing the next line
> > (setq null-device "c:/tmp/emacs-dev-null.txt") ;; set to anything
> 
> Just to be clear, users of Cygwin emacs should *not* do this.
> 
> Ken
> 
> 

--
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: Failure with fork()

[Larry Hall (Cygwin)]

On 6/27/2013 4:55 PM, Thrall, Bryan wrote:

Larry Hall (Cygwin) wrote on 2013-06-27:

On 6/27/2013 4:33 PM, Alan W. Irwin wrote:

So the question still remains how do I gain access to a version of
setup.exe with the fork fix that will allow me to not only initialize
my Cygwin distribution for Wine without the fork abort, but also
subsequently update it to install all components of Cygwin that I
need?


Since you want to just run 'setup.exe', you need a new cygwin package
(i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
without any extra effort on your part.  So unless you're willing to
build your own version of this package and put it in your download
directory in the appropriate spot (after you've downloaded the
packages you want), you want to just wait for the next announcement
for the cygwin package.


Since the fork bug is only affecting the execution of the postinstall
scripts, couldn't the OP install the snapshot in the partially-complete
Cygwin install, then run setup.exe to finish the postinstall scripts?


As Yaakov said, if you time it just right, which may or may not be
tricky.  There are other alternatives as well but they all require
some effort to get right.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in 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

SportsBeat.com makes Eteamz Obsolete

[SportsBeat.com]

June's release of http://www.SportsBeat.com will shift athletes, coaches and 
parents away from old school and socially inept Team Management websites like 
Eteamz, TeamSnap and Shutterfly.

SportsBeat brings a completely free advanced media tool that allows its users 
to manage all of their teams, save every picture and moment while building a 
community around each team.  


Key Features:
--
- Unlimited Free Teams, Centralized on One Dashboard
- Schedules, Availability, Email Reminders and Stats
- Player, Coach, Parent, Family and Friend accounts include everyone
- Rich Social Media Capabilities, including Linking with Teammates and Opponents


Athletes:
--
- Keep all of your teams organized from calendars and reminders to stats and 
photos
- Network and follow teammates, opponents and competition


Coaches:
--
- Manage your team's schedule and roster while building your legacy.
- Know every player you have coached, coached against and stats from every game


Parents:
--
- Organize the schedule of all of your kids' teams in one location
- Join the parents on both teams of each game in uploading pictures & comments 
to a joint team page


Join SportsBeat - The Heart of All Sports

http://www.sportsbeat.com



Thank you



.




--
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: Failure with fork()

[Alan W. Irwin]

I am getting absolutely nowhere.

A script run by setup.exe in the latter part of the install steps
appears to hang now with or without updating cygwin1.dll to the
fork-fixed version.  I got this result for two versions of
wine which I have heavily tested in other ways, wine-1.5.19, and
a wine-git version near wine-1.6.0-rc1.

Here are the last few messages before the hang:

Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzgrep.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzless.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzmore.1.gz
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
Extracting from
file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.bz2
Installing file cygfile:///usr/bin/cygz.dll
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
Visited: 51 nodes out of 2986 while creating dependency order.
Dependency order of packages: base-cygwin sed gzip libpcre0 gettext
grep libmpfr4 gawk tzcode libgmp3 libattr1 libncurses10 texinfo _update-info-dir
libreadline7 terminfo libstdc++6 libncursesw10 libiconv2
libintl8 bash coreutils cygwin libgcc1 dash rebase _autorebase
alternatives findutils base-files libbz2_1 bzip2 libpopt0 cygutils diffutils
dos2unix editrights zlib0 file groff ipc-utils less liblzma5 login xz man
mintty run tar vim-minimal which
running: Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile
"/etc/postinstall/000-cygwin-post-install.sh"

There is no obvious chance that I can see before that hang where I can
overwrite cygwin1.dll with the corrected version.  However, if I exit
the hang, overwrite cygwin1.dll, and run the above script
by hand it still hung (no cpu activity and no change in the
cygwin tree that changes its total size as measured to
the nearest byte with "du -s --bytes cygwin") for ~20 minutes
before I gave up.

By the way, after exiting after the first hang, if I simply
overwrite cygwin1.dll with the corrected version, then
run setup.exe the install stage errors out immediately with
the message "Can't open package database for writing.  File exists."
It's for that reason that I tried to run the hanging script by hand
to see if I could get any further.

I didn't get these hangs a month ago when I tried all this
before with wine-1.5.19.  Instead, at that time I got the exact error
message when running the above script concerning an unhandled page
fault that others have described at
http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed
cygwin1.dll is supposed to fix.  So presumably Cygwin's
bash.exe or some application executed by the above script has
changed in the last month to cause the different wine symptoms.
Or I am inadvertently doing something different than I did a month
ago.

So unless someone can suggest a method to get around the "Can't open
package database for writing.  File exists." message, and assuming
that method doesn't subsequently run into the script hang (which is a
big if), then I think it is time for someone with a lot more wine and
cygwin expertise than me to take over here to attempt to try and
figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
overwriting the buggy version.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

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