snapshots (archive files) are too big ... Why?

[Houder]

Hi Corinna,

Just curious if there is a reason ...

I was able to extract cygpath.exe from cygwin-inst-20160121.tar.xz 
(snapshots)

in order to test your last modification to cygpath.cc. No problem here.

However, when examining the contents of the archive, I was surprised to 
find

the SAME version of cygpath.exe at least three times ...

The size of cygwin-inst-.tar.xz (and cygwin-src-.tar.xz) has 
grown

(suddenly) by a factor of 3 or 4 since 2015-07-20 ...

The same applies to winsup-src-.tar.xz (since 2016-01-15) ...

In all cases it is because the archive contains the SAME version of a 
file at

least three times (as far as I can tell).

To summarize: No, I am not reporting a problem here; I am just _curious_ 
as to
why these archive are so much bigger than they (apparently) need to be 
...


Regards,
Henri

--
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: Using Perl on Cygwin; how to prevent display of unwanted usage/error message?

[Andrey Repin]

Greetings, Kenneth Wolcott!

>   I'm using a qx call to "net user username /DOMAIN" (probably should
> use system instead) to determine whether a person having an active
> account in an application is still an employee.

>   I get two messages back (error and/or usage) when a username is not found.

> "The user name could not be found."

> and

> "More help is available by typing NET HELPMSG 2221."

> I'd like to hide (not display, not print) these two messages.

> Coming from a UNIX/Linux background, I'd do a "2>&1 > /dev/null"
> operation to dispose of STDOUT and STDERR, but "1<&2 > NUL" (suggested
> by

> "https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true";

> does not seem to work.

That's... I don't know how to qualify this article, but it's just doesn't
quite work that way.
The semantics of redirection are same on Windows as on Linux.

net user username /DOMAIN > /dev/null 2>&1

or, under native shell (cmd)

net user username /DOMAIN > nul: 2>&1

>   I tried file descriptor 3, but that resulted in an error regarding
> unsupported file handle,. or something like that.

>   I was considering using IPC::Run3, but I don't think that will help
> with suppressing error message and usage message.

> Perhaps there is a Perl module that is native to Cygwin that will
> perform this kind of lookup for me?  Maybe a Perl module that is NOT
> native to Cygwin?

Another solution is to assign your own handles to the underlying process, but
considering you don't want the output at all, I don't see it viable.


-- 
With best regards,
Andrey Repin
Saturday, January 23, 2016 15:42:00

Sorry for my terrible english...


--
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: Compiling gcc trunk under cygwin

[Roger Orr]

David Wohlferd  LimeGreenSocks.com> writes:

> Until recently, I've been able to build gcc under cygwin just fine. But 
> (relatively) recent checkins (232454 &  232071) are causing problems.

Have you reported the problems with 232454 to gcc yet?

I've already reported the 232071 problem, on the original bug report this
was trying to fix. See gcc's bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
 
Roger.


--
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: snapshots (archive files) are too big ... Why?

[Andrey Repin]

Greetings, Houder!

Judging from

tar tf cygwin-inst-20160121.tar.xz

the archive is composed in more than one step.
The packaging script is really ought for a thorough investigation.


-- 
With best regards,
Andrey Repin
Saturday, January 23, 2016 17:23:33

Sorry for my terrible english...


--
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: snapshots (archive files) are too big ... Why?

[Andrey Repin]

Greetings, Houder!

> Just curious if there is a reason ...

> I was able to extract cygpath.exe from cygwin-inst-20160121.tar.xz 
> (snapshots)
> in order to test your last modification to cygpath.cc. No problem here.

> However, when examining the contents of the archive, I was surprised to 
> find
> the SAME version of cygpath.exe at least three times ...

> The size of cygwin-inst-.tar.xz (and cygwin-src-.tar.xz) has 
> grown
> (suddenly) by a factor of 3 or 4 since 2015-07-20 ...

> The same applies to winsup-src-.tar.xz (since 2016-01-15) ...

> In all cases it is because the archive contains the SAME version of a 
> file at
> least three times (as far as I can tell).

> To summarize: No, I am not reporting a problem here; I am just _curious_ 
> as to
> why these archive are so much bigger than they (apparently) need to be 
> ...

But this is actually a problem.

http://cygwin.com/snapshots/x86/cygwin-inst-20160121.tar

All tools reporting from 3 to 5 entries of each file in the archive.


-- 
With best regards,
Andrey Repin
Saturday, January 23, 2016 17:17:59

Sorry for my terrible english...


--
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: Problem with dlsym against libicu

[Ken Brown]

On 1/22/2016 10:49 PM, Sam Habiel wrote:

Hello all.

I am porting GT.M
(https://www.fisglobal.com/Solutions/Services/Database-Engine) to run
on Cygwin x86. My changes are here:
https://github.com/shabiel/fis-gtm/. GT.M is used in healthcare and
banking; I happen to work in the former field.

The problem I am having is that GT.M opens libicuio via dlopen, and
then loads the function pointers into a data structure via function
name using dlsym. For the curious, the code is in gtm_icu_init() in
gtc_icu.c

I took me a while, but I eventually figured out that dlls that are
opened via dlopen need to be in the PATH in Cygwin. I saw this in an
earlier Cygwin mailing list message.

However, no matter what I do, I can't seem to get a non-null reference
to a named symbol in libicuio via dlsym. Here's what I tried:

0. nm shows the symbols in the file I want to open; strace shows me
opening it (it's /usr/lib/cygicuio56.dll).
1. Compiled libicu from source with a flag for Cygwin:
http://site.icu-project.org/
2. Used underscores in front of the symbol
3. Tried creating an import library using the instructions at
https://cygwin.com/cygwin-ug-net/dll.html#dll-build at the bottom and
then add the archive to the gcc compile command as a source file.
(These instructions need to be improved! I had no idea what to do with
a .a file after I got it).

Here's a test program that I have written. Note that dlsym returns the
obscure error message "no such process", which doesn't make any sense
to me, as I am not looking for a "process" but a symbol.

sam@horus ~/fis-gtm-cygwin
$ cat test.c
#include 
#include 
#include 


int main (int arg, char **argv)
{
 void *ptr = dlopen("cygicuio.dll", RTLD_LAZY);
 if (ptr != NULL)
 {
 printf("%p\n",ptr);
 }
 else
 {
 printf("%s",dlerror());
 exit(1);
 }

 void *ptr2 = dlsym(ptr,"uset_open");

 if (ptr2 != NULL)
 {
 printf("%p\n",ptr2);
 }
 else
 {
 printf("%s",dlerror());
 exit(1);
 }

 return 0;
}


I can't answer your questions, but I have some comments and questions.

First, there's no /usr/lib/cygicuio56.dll in the Cygwin icu 
distribution.  The DLL is /usr/bin/cygicuio56.dll, with the 
corresponding import library /usr/lib/libicuio56.dll.a (provided by the 
libicu-devel-56.1 package).  And there's also a symlink 
/usr/lib/libicuio.dll.a -> libicuio56.dll.a.


Next, can you show the nm command by which you found uset_open?  I 
couldn't find it.  I tried


$ nm /usr/lib/libicuio56.dll.a | grep uset_open

and got nothing.  On the other hand:

$ strings /usr/bin/cygicuio56.dll | grep uset_open
uset_open_56

Could the problem be that uset_open (or uset_open_56) isn't exported?

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: snapshots (archive files) are too big ... Why?

[Houder]

Hi Andrey,

On 2016-01-23 15:21, Andrey Repin wrote:


But this is actually a problem.


Not sure ...extraction appears NOT to be a problem ... (yes, the same
file is extracted multiple times).

On the other hand, the "big" archive file might indicate there is room
for improvement ...

However, it might be so that the person who wrote the script believes
that she/he can only rely on Lamport's clock:

The "version" of the file, that survives the extraction process, will
be the one that was last appended to the archive file ...

http://www.gnu.org/software/tar/manual/tar.html#SEC59

See 4.2.2.2 Multiple Members with the Same Name.

Of course, I am just guessing ... that is why I wrote: I am curious.

Regards,
Henri

--
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: Performance of "ls -F"

[Corinna Vinschen]

On Jan 22 22:04, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Just a hint:  ls -F requires to stat every single file.  stat in turn
> > requires to load not only the usual metadata but also to fetch the ACL
> > and convert it to POSIX permissions.
> 
> The timings are from shares mounted with the noacl option, so that bit
> of code shouldn't be involved.  I will try the same operations on an ACL
> enabled mount of the same share later and I also need to find a share
> that is exported from a true NTFS server for comparison.
> 
> > Assuming this slow access only occurs under 2.4.0,
> 
> No, the behaviour is quite a bit older, although I didn't time it since
> I didn't recognize the connection to the aliased ls.  In any case, it
> really is just the determination of whether or not the file is
> executable that takes up all that time.

In the noacl case, Cygwin tries to find out if files are scripts.  It
opens the file and checks the first two bytes in the file for a shebang
(and other stuff).  This may take a lot of time, more so on network
drives.  Can you try adding the "notexec" mount option to the "noacl"
share and see if that helps?

This test is done for a looong time to accommodate FAT filesystems in
the first place.  It might be prudent to disable it by default these
days...


Corinna

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


signature.asc
Description: PGP signature

Re: snapshots (archive files) are too big ... Why?

[Corinna Vinschen]

On Jan 23 13:59, Houder wrote:
> Hi Corinna,
> 
> Just curious if there is a reason ...
> 
> I was able to extract cygpath.exe from cygwin-inst-20160121.tar.xz
> (snapshots)
> in order to test your last modification to cygpath.cc. No problem here.
> 
> However, when examining the contents of the archive, I was surprised to find
> the SAME version of cygpath.exe at least three times ...
> 
> The size of cygwin-inst-.tar.xz (and cygwin-src-.tar.xz) has
> grown
> (suddenly) by a factor of 3 or 4 since 2015-07-20 ...
> 
> The same applies to winsup-src-.tar.xz (since 2016-01-15) ...
> 
> In all cases it is because the archive contains the SAME version of a file
> at
> least three times (as far as I can tell).
> 
> To summarize: No, I am not reporting a problem here; I am just _curious_ as
> to
> why these archive are so much bigger than they (apparently) need to be ...

I found out why this happens, I just don't know why it only occurs since
2015-07-20.

The reason is the script is using an expression along the lines of

  find ... | tar -T - --no-recursion -cjf ...

It turns out that the --no-recursion option only works for me, if it
comes *prior* to the expression specifying the filenames to archive.
That is, I had to change the script to use

  find ... | tar --no-recursion -T - -cjf ...

instead.  Funny enough, `info tar' still contains an example using
the original order...


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: snapshots (archive files) are too big ... Why?

[Houder]

On 2016-01-23 19:10, Corinna Vinschen wrote:

On Jan 23 13:59, Houder wrote:

Hi Corinna,

Just curious if there is a reason ...

I was able to extract cygpath.exe from cygwin-inst-20160121.tar.xz
(snapshots)
in order to test your last modification to cygpath.cc. No problem 
here.


However, when examining the contents of the archive, I was surprised 
to find

the SAME version of cygpath.exe at least three times ...

The size of cygwin-inst-.tar.xz (and cygwin-src-.tar.xz) 
has

grown
(suddenly) by a factor of 3 or 4 since 2015-07-20 ...

The same applies to winsup-src-.tar.xz (since 2016-01-15) ...

In all cases it is because the archive contains the SAME version of a 
file

at
least three times (as far as I can tell).

To summarize: No, I am not reporting a problem here; I am just 
_curious_ as

to
why these archive are so much bigger than they (apparently) need to be 
...


I found out why this happens, I just don't know why it only occurs 
since

2015-07-20.

The reason is the script is using an expression along the lines of

  find ... | tar -T - --no-recursion -cjf ...

It turns out that the --no-recursion option only works for me, if it
comes *prior* to the expression specifying the filenames to archive.
That is, I had to change the script to use

  find ... | tar --no-recursion -T - -cjf ...

instead.  Funny enough, `info tar' still contains an example using
the original order...


Ah, thank you for the effort you took and for your explanation. (yes,
the reason for the "big" files was simpler than I was guessing at).

However, I cannot confirm your finding at my end (using Cygwin). Still,
I am sure you will take another look at the size of a snapshot when you
create one the next time :-)

Thanks!

Regards,
Henri

--
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: snapshots (archive files) are too big ... Why?

[Corinna Vinschen]

On Jan 23 20:09, Houder wrote:
> On 2016-01-23 19:10, Corinna Vinschen wrote:
> >On Jan 23 13:59, Houder wrote:
> >>Hi Corinna,
> >>
> >>Just curious if there is a reason ...
> >>
> >>I was able to extract cygpath.exe from cygwin-inst-20160121.tar.xz
> >>(snapshots)
> >>in order to test your last modification to cygpath.cc. No problem here.
> >>
> >>However, when examining the contents of the archive, I was surprised to
> >>find
> >>the SAME version of cygpath.exe at least three times ...
> >>
> >>The size of cygwin-inst-.tar.xz (and cygwin-src-.tar.xz) has
> >>grown
> >>(suddenly) by a factor of 3 or 4 since 2015-07-20 ...
> >>
> >>The same applies to winsup-src-.tar.xz (since 2016-01-15) ...
> >>
> >>In all cases it is because the archive contains the SAME version of a
> >>file
> >>at
> >>least three times (as far as I can tell).
> >>
> >>To summarize: No, I am not reporting a problem here; I am just _curious_
> >>as
> >>to
> >>why these archive are so much bigger than they (apparently) need to be
> >>...
> >
> >I found out why this happens, I just don't know why it only occurs since
> >2015-07-20.
> >
> >The reason is the script is using an expression along the lines of
> >
> >  find ... | tar -T - --no-recursion -cjf ...
> >
> >It turns out that the --no-recursion option only works for me, if it
> >comes *prior* to the expression specifying the filenames to archive.
> >That is, I had to change the script to use
> >
> >  find ... | tar --no-recursion -T - -cjf ...
> >
> >instead.  Funny enough, `info tar' still contains an example using
> >the original order...
> 
> Ah, thank you for the effort you took and for your explanation. (yes,
> the reason for the "big" files was simpler than I was guessing at).
> 
> However, I cannot confirm your finding at my end (using Cygwin). Still,
> I am sure you will take another look at the size of a snapshot when you
> create one the next time :-)

Of course I created local test snapshots using the above change.  They
only have one version of each file and are considerably smaller than the
previous versions.  I'm building on Fedora Linux if that matters.


Corinna

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


signature.asc
Description: PGP signature

Re: snapshots (archive files) are too big ... Why?

[Houder]

On 2016-01-23 20:25, Corinna Vinschen wrote:

On Jan 23 20:09, Houder wrote:

On 2016-01-23 19:10, Corinna Vinschen wrote:



>I found out why this happens, I just don't know why it only occurs since
>2015-07-20.
>
>The reason is the script is using an expression along the lines of
>
>  find ... | tar -T - --no-recursion -cjf ...
>
>It turns out that the --no-recursion option only works for me, if it
>comes *prior* to the expression specifying the filenames to archive.
>That is, I had to change the script to use
>
>  find ... | tar --no-recursion -T - -cjf ...
>
>instead.  Funny enough, `info tar' still contains an example using
>the original order...

Ah, thank you for the effort you took and for your explanation. (yes,
the reason for the "big" files was simpler than I was guessing at).

However, I cannot confirm your finding at my end (using Cygwin). 
Still,
I am sure you will take another look at the size of a snapshot when 
you

create one the next time :-)


Of course I created local test snapshots using the above change.  They
only have one version of each file and are considerably smaller than 
the

previous versions.  I'm building on Fedora Linux if that matters.


@@ mkdir x
@@ cd x
@@ tar xJf ../cygwin-inst-20160121.tar.xz
@@ find etc usr | wc -l
381

# preferred order (options)? tar manual: 6.9 Descending into 
Directories)

@@ find etc usr | tar --no-recursion -T- -cJf ../foo.tar.xz

# NOT the preferred order (options)?
@@ find etc usr | tar -T- --no-recursion -cJf ../foo2.tar.xz
@@ tar tvJf ../foo.tar.xz > foo1
@@ tar tvJf ../foo2.tar.xz > foo2
@@ diff foo1 foo2
@@ wc -l foo*
  381 foo1
  381 foo2
  762 total
@@

Did the same test on FC19. Same result.

But, let it rest for the moment, I would advice. Next time when you will
build a snapshot, you (we) will know.

Regards,
Henri

--
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: snapshots (archive files) are too big ... Why?

[Achim Gratz]

Corinna Vinschen writes:
> I found out why this happens, I just don't know why it only occurs since
> 2015-07-20.

Looks like this patch

http://pkgs.fedoraproject.org/cgit/rpms/tar.git/commit/?id=132f2c79628ff5f11bb7d41c5c34f94228d63c54

and the following two fixups would be a likely source of that change in
behaviour and it was probably the following package update that threw
the script off course.


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: snapshots (archive files) are too big ... Why?

[Achim Gratz]

Houder writes:
> Did the same test on FC19. Same result.

The patch most likely responsible is only applied to FC21/22/23 best I
can tell.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: snapshots (archive files) are too big ... Why?

[Houder]

On 2016-01-23 21:18, Achim Gratz wrote:

Houder writes:

Did the same test on FC19. Same result.


The patch most likely responsible is only applied to FC21/22/23 best I
can tell.


As I realized, that Corinna is using "the latest and the greatest" of 
the

Fedora distribution, I go myself

 tar-1.27.1-8.fc21.i686.rpm

and extracted the tar program from it.

Again using FC19, but now the tar program that I extracted:

@@ pwd
/home/henri/x
@@ ls -l
total 7172
-rwxr-xr-x 1 henri henri 6952352 Jan 23 20:28 
cygwin-inst-20160121.tar.xz

drwxr-xr-x 3 henri henri4096 Jan 21 18:42 etc
-rwxr-xr-x 1 henri henri  377916 Jan 23 22:38 tar
drwxr-xr-x 7 henri henri4096 Jan 21 18:42 usr
@@ ./tar --version
tar (GNU tar) 1.27.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
.

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
@@ find etc usr | ./tar -T - --no-recursion -cJf foo.tar.xz
@@ find etc usr | ./tar --no-recursion -T - -cJf foo2.tar.xz
@@ ./tar tvJf foo.tar.xz > foo1
@@ ./tar tvJf foo2.tar.xz > foo2
@@ wc -l foo1 foo2
  1429 foo1 < Oh, ah!
   381 foo2
  1810 total
@@

As noted by Achim, this modification of tar took place in July 2015.

That tells it all, does it not, Corinna?

Thanks, Achim.

Regards,
Henri

--
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: Any progress on "Fork issues ith long command lines and long $PATH"?

[Ken Brown]

On 1/21/2016 8:18 AM, Ken Brown wrote:

In the meantime, I'm looking into patching emacs so that the Cygwin
build will accept Windows file names, at least under some circumstances.
  If I can do that without breaking anything else, I'll put out a test
release.


This is done now.  Please test.

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

[ANNOUNCEMENT] Updated: emacs-24.5-3 (TEST)

[Ken Brown]

The following packages have been updated in the Cygwin distribution as
test releases:

* emacs-24.5-3
* emacs-X11-24.5-3
* emacs-w32-24.5-3
* emacs-el-24.5-3

Emacs is a powerful, customizable, self-documenting, modeless text 
editor.  Emacs contains special code editing features, a scripting 
language (elisp), and the capability to read mail, news, and more 
without leaving the editor.


This is a rebuild of the 24.5-2 packages, patched to allow native 
Windows paths like C:\foo or C:/foo in situations where file names are 
expected.


If you are interested in this feature, please try the test release and 
let me know whether it works the way you expect.  If you are not 
interested in this feature, please try the test release anyway to make 
sure I haven't broken anything.


CYGWIN NOTES


1. The emacs, emacs-w32, and emacs-X11 packages each provide an Emacs 
binary.  These are emacs-nox.exe, emacs-w32.exe, and emacs-X11.exe, 
respectively, in order of increasing priority.  The postinstall scripts 
use the `alternatives' system to create a symlink /usr/bin/emacs that 
resolves to the highest-priority binary that you have installed.  Thus 
the command `emacs' will start emacs-X11.exe if you've installed the 
emacs-X11 package; otherwise, it will start emacs-w32.exe if you've 
installed emacs-w32; otherwise, it will start emacs-nox.exe.  Similar 
remarks apply to emacsclient.


If you have installed both emacs-w32 and emacs-X11 and prefer to give 
higher priority to emacs-w32, run the script


  /usr/bin/set-emacs-default-w32.sh

You can later restore emacs-X11 as the default by running

  /usr/bin/set-emacs-default-X11.sh

2. Install emacs-X11 if you want to use the X11 GUI.  You can then type 
'emacs&' in an xterm window, and emacs will start in a new window.


3. Install emacs-w32 if you want to use the native Windows GUI instead 
of X11.


4. If you have sshd running and want to be able to run emacs-X11 from a 
remote machine, you need to enable X11 forwarding by adding the 
following line to /etc/sshd_config:


  X11Forwarding yes

You might also need to have the cygserver service running.

5. The script /usr/bin/make-emacs-shortcut can be used to create a 
shortcut for starting emacs.  See /usr/share/doc/emacs/README.Cygwin for 
details.


Ken Brown
Cygwin's Emacs maintainer

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