[ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Corinna Vinschen]

Hi all,


after a rather long period of time of development, we're proud to start
public testing of the upcoming new major release of Cygwin.  The version
number is 1.7.0 for the current test release and will be 1.7.x with some
x yet to be chosen for the final release.  As of today, the planning is
to release the final release at some point in Spring 2009.

This new release will bring quite a few changes, some of them might
require to do accompanying changes in your environment.  The most
intrusive changes are

- No more support for Windows 95/98/Me.  Cygwin 1.7 will not run on any
  of these systems.  We will keep the old 1.5.25 distro on sourceware
  for users of these obsolete Windows versions.

- No more mount points in the registry.  Use a file /etc/fstab instead.

- Some global $CYGWIN options have been dropped, some of them have been
  converted to mount options.

- No more managed mounts.  The implementation for POSIX pathnames
  colliding with forbidden filenames and characters on Windows
  filesystems has changed considerably.

At the end of this mail you will find a more or less complete list of
changes from 1.5.x to 1.7.x.  During the testing phase for this release
we don't expect any behavioural change from the current state except
some behaviour turns out to be unfeasible or is plain buggy.  A few (but
only a few) more features may be included within the test phase, namely
support for wide-char stdio routines, which is work in progess.

One interesting feature for the testers is the fact that you can install
Cygwin 1.7 in parallel to another production 1.5 installation.  They
don't interact with each other, provided you start the processes in
separate Windows, and you *don't* have *both* Cygwin binary paths in the
$PATH variable.  This is unsupported territory.

However, if you want to install services using the service installer
scripts around (inetd-config, ssh-host-config, etc), then keep in mind
that the scripts try to install the services under the same service name
as the former 1.5 script.  Additionally, network related services will
of course try to use the same network port numbers to install themselves
as service.  Bottom line:  If you want to test services, make sure you
have the related 1.5-based services *stopped* before running the same
services in the 1.7 realm.

I would like to stress that this is a *test* release.  Don't use it in a
crucial production environment.  Don't use it for you important personal
or work environment without making sure that you won't suffer loss of
life or money if something goes wrong by using this Cygwin 1.7 test
release.  There's no guarantee that we didn't screw something up
seriously.

If you have more than one physical or virtual Windows machine, it's the
best to install the test release on the machine you don't need for the
production Cygwin install.

Last but not least, please 

- *read* the below list of changes for a start, so you know what we're
  threatening you with,

- *read* the new User's Guide, which you can access via

    http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html
  or
    http://cygwin.com/1.7/cygwin-ug-net.html (one single big file)

  Though it's probably still lacking, it will explain a lot of the new
  behaviour in (hopefully) better words than the old User's Guide.

  Please note that we have no new FAQ.  The reason is simply that
  we don't know yet what questions will be asked frequently in future.

- After having digested the docs, ask yourself if you're willing to
  help testing the next Cygwin release.  If your heart and brain both
  say "yes", then use

    http://cygwin.com/setup-1.7.exe

  to install the test release. Note that it will default to *upgrading*
  an existing installation!  If you don't want that (and I bet you
  won't), make sure to change the installation directory right in the
  second dialog from your old, say, C:/cygwin to, say, C:/cygwin-1.7.

  Note that this setup-1.7.exe tool also has some changes related to the
  1.5 version.  The most noticable is that it is slower than the old
  one.  The reason is that it tries hard to create the files and
  directories with POSIX-like permissions as given in the distribution
  packages.

  Additionally, note that setup-1.7.exe will notice that your Cygwin
  desktop shortcut (if you have one) already exists.  It will not try
  to create a new one in this case, and the Cygwin shortcut will still
  point to the 1.5 installation.  To get a matching 1.7 shortcut, just
  copy your existing shortcut, rename it to, for instance, Cygwin-1.7,
  and change the shortcut target path from the 1.5 distro directory to
  the 1.7 distro directory.

Did I mention that this is a *test* release and that you should make
sure that you don't screw up your existing Cygwin installation unless
you really want to?

Thanks for reading and especially thanks for participating.  I'm quite
nervous given the many many changes in 1.7, but if we live through the
next few months, I'm sure that this new Cygwin is the best Cygwin we
ever had.  (ob-joke for insider:  Except of b20, of course).

Please report bugs to the mailing list cygwin@cygwin.com.  The usual
bug reporting guidelines apply: http://cygwin.com/problems.html

Ok, below you'll find the list of changes since 1.5.25.


Have fun,
Corinna

----------------------------------------------------------------------
                         LIST OF CHANGES
----------------------------------------------------------------------

OS releated changes:
--------------------

- Windows 95, 98 and Me are not supported anymore.  The new DLL will
  not run on any of these systems.

File Access related changes:
----------------------------

- Mount points are no longer stored in the registry.  Use /etc/fstab
  and /etc/fstab.d/$USER instead.  Mount points created with mount(1)
  are only local to the current session and disappear when the last
  Cygwin process in the session exits.

- PATH_MAX is now 4096.  Internally, path names can be as long as the
  underlying OS can handle (32K).
  
- UTF-8 filenames are supported now.  So far, this requires to set
  the environment variable CYGWIN to contain "codepage:utf8". but this
  will likely disappear at one point.  The setting of $LANG or $LC_CTYPE
  will be used instead.

- struct dirent now supports d_type, filled out with DT_REG or DT_DIR.
  All other file types return as DT_UNKNOWN for performance reasons.

- The CYGWIN environment variable options "ntsec" and "smbntsec" have
  been replaced by the per-mount option "acl"/"noacl".

- The CYGWIN environment variable option "ntea" has been removed without
  substitute.

- The CYGWIN environment variable option "check_case" has been removed
  in favor of real case-sensitivity on file systems supporting it.

- Creating filenames with special DOS characters '"', '*', ':', '<',
  '>', '|' is supported.

- Creating files with special DOS device filename components ("aux",
  "nul", "prn") is supported.

- File name are case sensitive if the OS and the underlying file system
  supports it.  Works on NTFS and NFS.  Does not work on FAT and Samba
  shares.  Requires to change a registry key (see the user's guide).
  Can be switched off on a per-mount base.

- Due to the above changes, managed mounts have been removed. 

- unlink(2) and rmdir(2) try very hard to remove files/directories even
  if they are currently accessed or locked.  This is done by utilizing
  the hidden recycle bin directories and marking the files for deletion.

- rename(2) rewritten to be more POSIX conformant.

- Add st_birthtim member to struct stat.

- File locking is now advisory, not mandatory anymore.  The fcntl(2) and
  the new lockf(2) APIs create and maintain locks with POSIX semantics,
  the flock(2) API creates and maintains locks with BSD semantics.
  POSIX and BSD locks are independent of each other.

- Implement atomic O_APPEND mode.

- Handle NTFS native symlinks available since Vista/2008 as symlinks
  (but don't create Vista/2008 symlinks due to unfortunate OS restrictions).

- Recognize NFS shares and handle them using native mechanisms.
  Recognize and create real symlinks on NFS shares.  Get correct
  stat(2) information and set real mode bits on open(2), mkdir(2)
  and chmod(2).

- Recognize Netapp DataOnTap drives and fix inode number handling.

- Recognize Samba version beginning with Samba 3.0.28a using the new
  extended version information negotiated with the Samba developers.

- List servers of all accessible domains and workgroups in // instead of
  just the servers in the own domain/workgroup.

- Support Linux-like extended attributes ([fl]getxattr, [fl]listxattr,
  [fl]setxattr, [fl]removexattr).

- New file conversion API for conversion from Win32 to POSIX path and
  vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list).

- New openat family of functions: openat, faccessat, fchmodat, fchownat,
  fstatat, futimesat, linkat, mkdirat, mkfifoat, mknodat, readlinkat, renameat,
  symlinkat, unlinkat.

- Other new APIs: posix_fadvise, posix_fallocate, funopen, fopencookie,
  open_memstream, fmemopen, fdopendir.

Network related changes:
------------------------

- New implementation for blocking sockets and select on sockets which
  is supposed to allow POSIX-compatible sharing of sockets between
  threads and processes.

- send/sendto/sendmsg now send data in 64K chunks to circumvent an
  internal buffer problem in WinSock (KB 201213).

- IPv6 support.  New API getaddrinfo, getnameinfo, freeaddrinfo,
  gai_strerror, in6addr_any, in6addr_loopback.  On IPv6-less systems,
  replacement functions are available for IPv4.  On systems with IPv6
  enabled, the underlying WinSock functions are used.  While I tried
  hard to get the functionality as POSIXy as possible, keep in mind that
  a *fully* conformant implementation of getaddrinfo and other stuff is
  only available starting with Windows Vista/2008.

- Resolver functions (res_init, res_query, res_search, res_querydomain,
  res_mkquery, res_send, dn_comp, dn_expand) are now part of Cygwin.
  Applications don't have to link against minires anymore.  Actually,
  this *is* the former libminires.a.

- rcmd is now implemented inside of Cygwin, instead of calling the
  WinSock function.  This allows rsh(1) usage on Vista/2008, which
  dropped this function from WinSock.

- Define multicast structures in netinet/in.h.  Note that fully
  conformant multicast support is only available beginning with Vista/2008.

- Improve get_ifconf.  Redefine struct ifreq and subsequent datastructures
  to be able to keep more information.  Support SIOCGIFINDEX, SIOCGIFDSTADDR
  and the Cygwin specific SIOCGIFFRNDLYNAM.  Support real interface flags
  on systems supporting them.

- Other new APIs: bindresvport, bindresvport_sa, iruserok_sa, rcmd_af,
  rresvport_af.  getifaddrs, freeifaddrs, if_nametoindex, if_indextoname,
  if_nameindex, if_freenameindex.

- Add /proc/net/if_inet6.

Device related changes:
-----------------------

- Reworked pipe implementation which uses overlapped IO to create
  more reliable interruptible pipes and fifos.

- The CYGWIN environment variable option "binmode" has been removed.

- Improved fifo handling by using native Windows named pipes.

- Detect when a stdin/stdout which looks like a pipe is really a tty.
  Among other things, this allows a debugged application to recognize that
  it is using the same tty as the debugger.

- Support UTF-8 in console window.

- Support up to 64 serial interfaces using /dev/ttyS0 - /dev/ttyS63.

- Support up to 128 raw disk drives /dev/sda - /dev/sddx.

- New API: posix_openpt.

Other POSIX related changes:
----------------------------

- Implement pthread_kill(thread, 0) as per POSIX.

- New API for POSIX IPC:
  Named semaphores: sem_open, sem_close, sem_unlink.
  Message queues: mq_open, mq_getattr, mq_setattr, mq_notify, mq_send,
  mq_timedsend, mq_receive, mq_timedreceive, mq_close, mq_unlink.
  Shared memory: shm_open, shm_unlink.

- Only declare expected functions in <strings.h>, don't include <string.h>
  from here.

- New APIs: asnprintf, dprintf, _Exit, vasnprintf, vdprintf, confstr,
  posix_madvise, posix_memalign, exp10, exp10f, pow10, pow10f, lrint,
  lrintf, rint, rintf, llrint, llrintf, llrintl, lrintl, rintl insque,
  remque, sys_sigabbrev, strcasestr, stpcpy, stpncpy, wcpcpy, wcpncpy,
  wcstol, wcstoll, wcstoul, wcstoull, wcsxfrm.

Security related changes:
-------------------------

- Getting a domain user's groups is hopefully more bulletproof now.

- Cygwin now comes with a real LSA authentication package.  This must
  be manually installed by a privileged user using the /bin/cyglsa-config
  script.  The advantages and disadvantages are noted in
  http://cygwin.com/ml/cygwin-developers/2006-11/msg00000.html

- Cygwin now allows to store and use user passwords in a hidden area of
  the registry.  This is tried first when Cygwin is called by privileged
  processes to switch the user context.  This allows, for instance,
  ssh public key sessions with full network credentials to access shares
  on other machines.

- The mkpasswd and mkgroup tools have changed behaviour and a couple of
  new options to ease consistent usage in multi-machine or multi-domain
  environments.

Miscellanous:
-------------

- Fallout from the long path names: If the current working directory is
  longer than 260 bytes, or if the current working directory is a virtual
  path (like /proc, /cygdrive, //server), don't call native Win32 programs
  since they don't understand these paths.

- On the first usage of a DOS path (C:\foo, \\foo\bar), the Cygwin DLL
  emits a scary warning that DOS paths shouldn't be used.  There's also
  the new CYGWIN=nodosfilewarning setting to disable that.

- Allow environment of arbitrary size instead of a maximum of 32K.

- Don't force uppercase environment when started from a non-Cygwin process.
  Except for certain Windows and POSIX variables which are always uppercased,
  preserve environment case.  Switch back to old behaviour with the new
  CYGWIN=upcaseenv setting.

- Detect and report a missing DLL on process startup.

- Add /proc/registry32 and /proc/registry64 paths to access 32 bit and
  64 bit registry on 64 bit systems.

- Add the ability to distinguish registry keys and registry values with the
  same name in the same registry subtree.  The key is called "foo" and the
  value will be called "foo%val" in this case.

- Align /proc/cpuinfo more closly to Linux content.

- Optimized strstr and memmem implementation.

- Remove backwards compatibility with old signal masks (some *very* old
  programs which use signal masks may no longer work correctly).

- Numerous bug fixes.

- Probably a couple of entirely new bugs.

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

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Ken Brown]

On 12/10/2008 3:34 PM, Corinna Vinschen wrote:
> At the end of this mail you will find a more or less complete list of
> changes from 1.5.x to 1.7.x.

I think you forgot to mention the change to st_nlink [1], which will 
affect some applications.  For example, the kpathsea search library for 
texlive needs to be patched to accommodate the change.  (I've sent the 
patch to the tlbuild list in case anyone is interested.)  This might 
also apply to cygwin's tetex package, but I haven't tested it.

One other thing I've noticed, which I think is unrelated, is that there 
is a glitch in directory listing in emacs under cygwin 1.7:  If you try 
to list a directory with control-x d, very often the directory listing 
makes it look like the directory is empty when it isn't.  Typing "g" (to 
ask emacs to redisplay the directory) usually results in a correct 
listing.  I initially thought this might also be related to st_nlink, 
but I think emacs simply calls "ls -al" to do the listing, so there's 
probably no connection.  I'm wondering if it might be related to 
whatever changes were made to cygwin so that directory listings are 
faster (as reported in [2]).

This glitch occurs in emacs 22.3, which I built myself.  I haven't 
tested it in the official cygwin release of emacs (which I don't have 
installed), since my build works fine in cygwin 1.5.

Ken

[1] http://cygwin.com/ml/cygwin-developers/2008-04/msg00110.html
[2] http://cygwin.com/ml/cygwin/2008-12/msg00246.html


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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Matt Wozniski]

On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
> One other thing I've noticed, which I think is unrelated, is that there is a
> glitch in directory listing in emacs under cygwin 1.7:  If you try to list a
> directory with control-x d, very often the directory listing makes it look
> like the directory is empty when it isn't.  Typing "g" (to ask emacs to
> redisplay the directory) usually results in a correct listing.  I initially
> thought this might also be related to st_nlink, but I think emacs simply
> calls "ls -al" to do the listing, so there's probably no connection.  I'm
> wondering if it might be related to whatever changes were made to cygwin so
> that directory listings are faster (as reported in [2]).
> [2] http://cygwin.com/ml/cygwin/2008-12/msg00246.html

With no knowledge of cygwin's internals, I'd much sooner guess the
changes to the pipe code...

~Matt

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Corinna Vinschen]

On Dec 11 13:14, Ken Brown wrote:
> On 12/10/2008 3:34 PM, Corinna Vinschen wrote:
>> At the end of this mail you will find a more or less complete list of
>> changes from 1.5.x to 1.7.x.
>
> I think you forgot to mention the change to st_nlink [1], which will affect 
> some applications.  For example, the kpathsea search library for texlive 
> needs to be patched to accommodate the change.  (I've sent the patch to the 
> tlbuild list in case anyone is interested.)  This might also apply to 
> cygwin's tetex package, but I haven't tested it.

Yes, that's right.  I forgot about that.  I didn't know that more than
just findutils and coreutils are affected.  In theory, every tool
should be able to deal with st_nlink == 1.  It's not the right value
for an emtpy dir, which would be 2, so any tool should check what's
actually going on in that dir.


Corinna

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

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Ken Brown]

On 12/12/2008 9:31 AM, Corinna Vinschen wrote:
> On Dec 11 13:14, Ken Brown wrote:
>>
>> I think you forgot to mention the change to st_nlink [1], which will affect 
>> some applications.  For example, the kpathsea search library for texlive 
>> needs to be patched to accommodate the change.  (I've sent the patch to the 
>> tlbuild list in case anyone is interested.)  This might also apply to 
>> cygwin's tetex package, but I haven't tested it.
> 
> Yes, that's right.  I forgot about that.  I didn't know that more than
> just findutils and coreutils are affected.  In theory, every tool
> should be able to deal with st_nlink == 1.  It's not the right value
> for an emtpy dir, which would be 2, so any tool should check what's
> actually going on in that dir.

In the case of kpathsea, the program was deliberately relying on 
st_nlink to speed up searching on systems that it viewed as "unix-like", 
including cygwin.  [It didn't check for subdirectories unless st_nlink > 
2.]  Fortunately, this was documented, and it was easy to make a 
configuration change to tell it to exclude cygwin for this purpose.  I 
don't know how likely it is that other applications will similarly cut 
corners.

Ken

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Corinna Vinschen]

On Dec 12 09:44, Ken Brown wrote:
> On 12/12/2008 9:31 AM, Corinna Vinschen wrote:
>> On Dec 11 13:14, Ken Brown wrote:
>>>
>>> I think you forgot to mention the change to st_nlink [1], which will 
>>> affect some applications.  For example, the kpathsea search library for 
>>> texlive needs to be patched to accommodate the change.  (I've sent the 
>>> patch to the tlbuild list in case anyone is interested.)  This might also 
>>> apply to cygwin's tetex package, but I haven't tested it.
>> Yes, that's right.  I forgot about that.  I didn't know that more than
>> just findutils and coreutils are affected.  In theory, every tool
>> should be able to deal with st_nlink == 1.  It's not the right value
>> for an emtpy dir, which would be 2, so any tool should check what's
>> actually going on in that dir.
>
> In the case of kpathsea, the program was deliberately relying on st_nlink 
> to speed up searching on systems that it viewed as "unix-like", including 
> cygwin.  [It didn't check for subdirectories unless st_nlink > 2.]  
> Fortunately, this was documented, and it was easy to make a configuration 
> change to tell it to exclude cygwin for this purpose.  I don't know how 
> likely it is that other applications will similarly cut corners.

I don't think it's the right way to special case this for Cygwin in
kpathsea.  This isn't exactly a Cygwin issue.  The right thing to do
would be to change the test in a generic fashion from

  if (st_nlink > 2)

to

  if (st_nlink != 2)


Corinna

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

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 12/12/2008 7:58 AM:
> I don't think it's the right way to special case this for Cygwin in
> kpathsea.  This isn't exactly a Cygwin issue.  The right thing to do
> would be to change the test in a generic fashion from
> 
>   if (st_nlink > 2)
> 
> to
> 
>   if (st_nlink != 2)

More generally, it is possible to optimize to spot the number of
subdirectories when st_nlink >= 2.  The point is that the optimization is
invalid if st_nlink < 2, on any file system (not just cygwin).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklCh7EACgkQ84KuGfSFAYBe1gCdFuFbUYxZGKzt+bgGEFBLK2tw
AeIAnROjqNEt4D6j7+sOwLke21iBb8LD
=kzvN
-----END PGP SIGNATURE-----

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

Re: [ANNOUNCEMENT] Public Cygwin 1.7 test starts today

[Ken Brown]

On 12/12/2008 10:48 AM, Eric Blake wrote:
> 
> According to Corinna Vinschen on 12/12/2008 7:58 AM:
>> I don't think it's the right way to special case this for Cygwin in
>> kpathsea.  This isn't exactly a Cygwin issue.  The right thing to do
>> would be to change the test in a generic fashion from
>>
>>   if (st_nlink > 2)
>>
>> to
>>
>>   if (st_nlink != 2)
> 
> More generally, it is possible to optimize to spot the number of
> subdirectories when st_nlink >= 2.  The point is that the optimization is
> invalid if st_nlink < 2, on any file system (not just cygwin).

Thanks.  I've sent a revised patch to the texlive developers 
(http://tug.org/pipermail/tlbuild/2008q4/000460.html).  Cygwin's tetex 
maintainer might need to apply a similar patch.

Ken

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Ken Brown]

On 12/11/2008 2:30 PM, Matt Wozniski wrote:
> On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
>> One other thing I've noticed, which I think is unrelated, is that there is a
>> glitch in directory listing in emacs under cygwin 1.7:  If you try to list a
>> directory with control-x d, very often the directory listing makes it look
>> like the directory is empty when it isn't.  Typing "g" (to ask emacs to
>> redisplay the directory) usually results in a correct listing.
>> [...]
> 
> With no knowledge of cygwin's internals, I'd much sooner guess the
> changes to the pipe code...

I should have just reported the symptom instead of trying to guess the 
cause:  Emacs runs the shell command "ls -al" and thinks there's no 
output.  Here's a second example.  I used emacs's "ediff" function to 
compare two buffers, and it reported (incorrectly) that there were no 
differences.  So it seems that emacs called on the shell to run "diff" 
but didn't get the output.

Ken

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Corinna Vinschen]

On Dec 14 16:49, Ken Brown wrote:
> On 12/11/2008 2:30 PM, Matt Wozniski wrote:
>> On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
>>> One other thing I've noticed, which I think is unrelated, is that there 
>>> is a
>>> glitch in directory listing in emacs under cygwin 1.7:  If you try to 
>>> list a
>>> directory with control-x d, very often the directory listing makes it 
>>> look
>>> like the directory is empty when it isn't.  Typing "g" (to ask emacs to
>>> redisplay the directory) usually results in a correct listing.
>>> [...]
>> With no knowledge of cygwin's internals, I'd much sooner guess the
>> changes to the pipe code...
>
> I should have just reported the symptom instead of trying to guess the 
> cause:  Emacs runs the shell command "ls -al" and thinks there's no output. 
>  Here's a second example.  I used emacs's "ediff" function to compare two 
> buffers, and it reported (incorrectly) that there were no differences.  So 
> it seems that emacs called on the shell to run "diff" but didn't get the 
> output.

Any chance to create a testcase which reproduces this behaviour without
involving emacs?  Emacs is hell of a testcase which I won't even touch
with gloves...


Corinna

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

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Ken Brown]

On 12/15/2008 8:52 AM, Corinna Vinschen wrote:
> On Dec 14 16:49, Ken Brown wrote:
>> On 12/11/2008 2:30 PM, Matt Wozniski wrote:
>>> On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
>>>> One other thing I've noticed, which I think is unrelated, is that there 
>>>> is a
>>>> glitch in directory listing in emacs under cygwin 1.7:  If you try to 
>>>> list a
>>>> directory with control-x d, very often the directory listing makes it 
>>>> look
>>>> like the directory is empty when it isn't.  Typing "g" (to ask emacs to
>>>> redisplay the directory) usually results in a correct listing.
>>>> [...]
>>> With no knowledge of cygwin's internals, I'd much sooner guess the
>>> changes to the pipe code...
>> I should have just reported the symptom instead of trying to guess the 
>> cause:  Emacs runs the shell command "ls -al" and thinks there's no output. 
>>  Here's a second example.  I used emacs's "ediff" function to compare two 
>> buffers, and it reported (incorrectly) that there were no differences.  So 
>> it seems that emacs called on the shell to run "diff" but didn't get the 
>> output.
> 
> Any chance to create a testcase which reproduces this behaviour without
> involving emacs?  Emacs is hell of a testcase which I won't even touch
> with gloves...

Unfortunately, I have virtually no programming experience.  I was hoping 
the emacs maintainer might be able to help.  Or maybe there are some 
programmers out there who are also emacs users and would be willing to 
try to debug this.  There's a file called callproc.c in the emacs 
source, which deals with "synchronous subprocess invocation"; it might 
be a place to start, but that's just a guess.

Ken

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Ken Brown]

On 12/15/2008 10:34 AM, Ken Brown wrote:
> On 12/15/2008 8:52 AM, Corinna Vinschen wrote:
>> On Dec 14 16:49, Ken Brown wrote:
>>> On 12/11/2008 2:30 PM, Matt Wozniski wrote:
>>>> On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
>>>>> One other thing I've noticed, which I think is unrelated, is that 
>>>>> there is a
>>>>> glitch in directory listing in emacs under cygwin 1.7:  If you try 
>>>>> to list a
>>>>> directory with control-x d, very often the directory listing makes 
>>>>> it look
>>>>> like the directory is empty when it isn't.  Typing "g" (to ask 
>>>>> emacs to
>>>>> redisplay the directory) usually results in a correct listing.
>>>>> [...]
>>>> With no knowledge of cygwin's internals, I'd much sooner guess the
>>>> changes to the pipe code...
>>> I should have just reported the symptom instead of trying to guess 
>>> the cause:  Emacs runs the shell command "ls -al" and thinks there's 
>>> no output.  Here's a second example.  I used emacs's "ediff" function 
>>> to compare two buffers, and it reported (incorrectly) that there were 
>>> no differences.  So it seems that emacs called on the shell to run 
>>> "diff" but didn't get the output.
>>
>> Any chance to create a testcase which reproduces this behaviour without
>> involving emacs?  Emacs is hell of a testcase which I won't even touch
>> with gloves...
> 
> Unfortunately, I have virtually no programming experience.  I was hoping 
> the emacs maintainer might be able to help.

Here's one more piece of information, in case it means something to the 
experts.  I had been building emacs with the following patch, which was 
given to me by the person who told me how to build emacs for cygwin:

--- strftime.c.orig     2007-01-14 04:24:37.000000000 +0100
+++ strftime.c  2008-02-04 21:40:01.031250000 +0100
@@ -54,7 +54,7 @@
  # endif
  #endif
  #if HAVE_TZNAME
-#ifndef USE_CRT_DLL
+#if !defined (USE_CRT_DLL) && !defined (CYGWIN)
  extern char *tzname[];
  #endif
  #endif

I just rebuilt emacs under cygwin 1.7 without that patch.  The glitch 
involving directory listings still occurs occasionally, but *much* less 
often.  It happens so much less often that I was about to send a message 
saying the problem was solved, but then it happened again.

Two questions:

1.  For the sake of my education, can someone explain to me what this 
patch is all about and whether it ought to be necessary for cygwin? 
(I'm compiling with gcc-4, if that makes a difference.)

2.  Does the fact that my problem occurs less often without the patch 
provide any clues?

Thanks.

Ken

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Christopher Faylor]

On Mon, Dec 15, 2008 at 02:43:44PM -0500, Ken Brown wrote:
> On 12/15/2008 10:34 AM, Ken Brown wrote:
>> On 12/15/2008 8:52 AM, Corinna Vinschen wrote:
>>> On Dec 14 16:49, Ken Brown wrote:
>>>> On 12/11/2008 2:30 PM, Matt Wozniski wrote:
>>>>> On Thu, Dec 11, 2008 at 1:14 PM, Ken Brown wrote:
>>>>>> One other thing I've noticed, which I think is unrelated, is that 
>>>>>> there is a
>>>>>> glitch in directory listing in emacs under cygwin 1.7:  If you try to 
>>>>>> list a
>>>>>> directory with control-x d, very often the directory listing makes it 
>>>>>> look
>>>>>> like the directory is empty when it isn't.  Typing "g" (to ask emacs 
>>>>>> to
>>>>>> redisplay the directory) usually results in a correct listing.
>>>>>> [...]
>>>>> With no knowledge of cygwin's internals, I'd much sooner guess the
>>>>> changes to the pipe code...
>>>> I should have just reported the symptom instead of trying to guess the 
>>>> cause:  Emacs runs the shell command "ls -al" and thinks there's no 
>>>> output.  Here's a second example.  I used emacs's "ediff" function to 
>>>> compare two buffers, and it reported (incorrectly) that there were no 
>>>> differences.  So it seems that emacs called on the shell to run "diff" 
>>>> but didn't get the output.
>>>
>>> Any chance to create a testcase which reproduces this behaviour without
>>> involving emacs?  Emacs is hell of a testcase which I won't even touch
>>> with gloves...
>> Unfortunately, I have virtually no programming experience.  I was hoping 
>> the emacs maintainer might be able to help.
>
> Here's one more piece of information, in case it means something to the 
> experts.  I had been building emacs with the following patch, which was 
> given to me by the person who told me how to build emacs for cygwin:
>
> --- strftime.c.orig     2007-01-14 04:24:37.000000000 +0100
> +++ strftime.c  2008-02-04 21:40:01.031250000 +0100
> @@ -54,7 +54,7 @@
>  # endif
>  #endif
>  #if HAVE_TZNAME
> -#ifndef USE_CRT_DLL
> +#if !defined (USE_CRT_DLL) && !defined (CYGWIN)
>  extern char *tzname[];
>  #endif
>  #endif
>
> I just rebuilt emacs under cygwin 1.7 without that patch.  The glitch 
> involving directory listings still occurs occasionally, but *much* less 
> often.  It happens so much less often that I was about to send a message 
> saying the problem was solved, but then it happened again.
>
> Two questions:
>
> 1.  For the sake of my education, can someone explain to me what this patch 
> is all about and whether it ought to be necessary for cygwin? (I'm 
> compiling with gcc-4, if that makes a difference.)

Sorry but the patch makes no sense on at least two levels.

1) USE_CRT_DLL should not be set when CYGWIN is defined.

2) declaring tzname should not affect anything timing related.

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

Re: [1.7] Problem - emacs fails to get shell-command output

[Ken Brown]

On 12/15/2008 6:52 PM, Christopher Faylor wrote:
> On Mon, Dec 15, 2008 at 02:43:44PM -0500, Ken Brown wrote:
>> --- strftime.c.orig     2007-01-14 04:24:37.000000000 +0100
>> +++ strftime.c  2008-02-04 21:40:01.031250000 +0100
>> @@ -54,7 +54,7 @@
>>  # endif
>>  #endif
>>  #if HAVE_TZNAME
>> -#ifndef USE_CRT_DLL
>> +#if !defined (USE_CRT_DLL) && !defined (CYGWIN)
>>  extern char *tzname[];
>>  #endif
>>  #endif
>>

> 2) declaring tzname should not affect anything timing related.

OK, thanks.  In the meantime I've learned that the purpose of the patch 
was to prevent a warning about a dll import attribute.  I should have 
checked this before posting.  Sorry for the noise.

Ken

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