* New Cygwin 1.7.0-18 in release-2
@ 2008-07-17 15:53 Corinna Vinschen
2008-07-18 0:18 ` Eric Blake
` (5 more replies)
0 siblings, 6 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-17 15:53 UTC (permalink / raw)
To: cygwin-apps; +Cc: Brian Dessent
Hi,
again I would like to encourage the Cygwin maintainers, to try the new
Cygwin 1.7.0 release and to look for problems in their packages which
might be a result of the fairly massive changes in Cygwin 1.7. I
attached a list of the changes below. The latest changes are:
- Changes in mkpasswd/mkgroup and in seteuid() should result in more
correct user tokens in AD domains. Try the LSA module.
- Case-sensitivity on NTFS and NFS and mount option "posix=[0|1]".
- Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount
option "acl"/"noacl".
Download a 1.7 distro using http://cygwin.com/setup-1.7.exe
Cygwin 1.7 and 1.5 can run in parallel sessions on the same machine, but
the installation in parallel needs some manual intervention. Setup.exe
is not yet using the new registry location and will happily install into
your 1.5 installation dir...
Brian, any timeframe for a new setup for 1.7?
I made new documentation available, which just isn't yet finished. Have
a look into http://cygwin.com/1.7/cygwin-ug-net.html. The missing
pieces are changes to the utilities, half of the "NT Security" chapter
is still old, and some bits of information on NFS access. A new FAQ is
also not available yet. However, the docs already explain how to use
the new /etc/fstab and /etc/fstab.d/${USER} files, the available
mount options, how to tweak the system to get case-sensitivity, etc.
Please test and please create new packages for 1.7 as far as necessary.
I really think we should prepare to push out an official 1.7 release in
2008.
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 in a few weeks time. The setting of $LANG or
$LC_CTYPE will be used instead.
- The CYGWIN environment variable options "ntsec" and "smbntsec" have
been replaced by the per-mount option "acl"/"noacl".
- The CYGWIN environment variable option "check_case" has been removed.
- 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.
- 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.
- 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.
- 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.
- Restrict send/sendto/sendmsg to send never more than 64K to circumvent
internal buffer problem in WinSock. (May need rework)
- 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.
- Reworked pipe handling for better speed and better support for signal
processing.
- Improved fifo handling.
- 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
- Drop CYGWIN=ntea fake.
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.
- 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.
- 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
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
@ 2008-07-18 0:18 ` Eric Blake
2008-07-18 7:33 ` Corinna Vinschen
2008-07-18 16:37 ` Marco Atzeri
` (4 subsequent siblings)
5 siblings, 1 reply; 69+ messages in thread
From: Eric Blake @ 2008-07-18 0:18 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Corinna Vinschen on 7/17/2008 9:55 AM:
| Hi,
|
| again I would like to encourage the Cygwin maintainers, to try the new
| Cygwin 1.7.0 release and to look for problems in their packages which
| might be a result of the fairly massive changes in Cygwin 1.7. I
| attached a list of the changes below. The latest changes are:
|
| - Changes in mkpasswd/mkgroup and in seteuid() should result in more
| correct user tokens in AD domains. Try the LSA module.
| - Case-sensitivity on NTFS and NFS and mount option "posix=[0|1]".
| - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount
| option "acl"/"noacl".
Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
to the new cygwin1.dll today, I'm now suffering from an inability to
modify files on a shared drive on my work machine. I can create empty
files and remove existing files just fine, but get access denied on any
attempt to change contents. The -1 for owner and group looks fishy as well.
$ touch /cygdrive/u/file
$ echo hi > /cygdrive/u/file
bash: /cygdrive/u/file: Permission denied
$ ls -lF /cygdrive/u/file
- -rwxrw-r-- 1 ???????? ???????? 0 Jul 17 18:08 /cygdrive/u/file*
$ rm /cygdrive/u/file
$ echo hi > /cygdrive/u/file
bash: /cygdrive/u/file: Permission denied
$ ls -lF /cygdrive/u/file
- -rwxrw-r-- 1 ???????? ???????? 0 Jul 17 18:08 /cygdrive/u/file*
$ ls -niF /cygdrive/u/file
7573255750942747 -rwxrw-r-- 1 4294967295 4294967295 0 Jul 17 18:08
/cygdrive/u/file*
$ od -tx1
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session\
Manager/kernel/obcaseinsensitive
0000000 00 00 00 00
0000004
$ mount
C:\cygwin-2\bin on /usr/bin type ntfs (binmode,system)
C:\cygwin-2\lib on /usr/lib type ntfs (binmode,system)
C:\cygwin\home on /home type ntfs (binmode,system)
C:\cygwin-2 on / type ntfs (binmode,system)
c: on /cygdrive/c type ntfs (binmode,posix=0,noumount,user)
u: on /cygdrive/u type smbfs (binmode,posix=0,noumount,user)
$ volinfo /cygdrive/u
Device Type : 7
Characteristics : 10
Volume Name : <eblake>
Serial Number : 316278793
Max Filenamelength : 255
Filesystemname : <NTFS>
Flags : b
~ FILE_CASE_SENSITIVE_SEARCH : TRUE
~ FILE_CASE_PRESERVED_NAMES : TRUE
~ FILE_UNICODE_ON_DISK : FALSE
~ FILE_PERSISTENT_ACLS : TRUE
~ FILE_FILE_COMPRESSION : FALSE
~ FILE_VOLUME_QUOTAS : FALSE
~ FILE_SUPPORTS_SPARSE_FILES : FALSE
~ FILE_SUPPORTS_REPARSE_POINTS: FALSE
~ FILE_SUPPORTS_REMOTE_STORAGE: FALSE
~ FILE_VOLUME_IS_COMPRESSED : FALSE
~ FILE_SUPPORTS_OBJECT_IDS : FALSE
~ FILE_SUPPORTS_ENCRYPTION : FALSE
~ FILE_NAMED_STREAMS : FALSE
~ FILE_READ_ONLY_VOLUME : FALSE
~ FILE_SEQUENTIAL_WRITE_ONCE : FALSE
~ FILE_SUPPORTS_TRANSACTIONS : FALSE
Need an strace?
- --
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
iEYEARECAAYFAkh/4TwACgkQ84KuGfSFAYBMbQCgoOcoxxLn2BfjBotyh92EOf6t
C1YAoLsSga/e6271Tfe1Aal4XyHh3C3i
=jDOI
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 0:18 ` Eric Blake
@ 2008-07-18 7:33 ` Corinna Vinschen
2008-07-18 7:53 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 7:33 UTC (permalink / raw)
To: cygwin-apps
On Jul 17 18:18, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Corinna Vinschen on 7/17/2008 9:55 AM:
> | Hi,
> |
> | again I would like to encourage the Cygwin maintainers, to try the new
> | Cygwin 1.7.0 release and to look for problems in their packages which
> | might be a result of the fairly massive changes in Cygwin 1.7. I
> | attached a list of the changes below. The latest changes are:
> |
> | - Changes in mkpasswd/mkgroup and in seteuid() should result in more
> | correct user tokens in AD domains. Try the LSA module.
> | - Case-sensitivity on NTFS and NFS and mount option "posix=[0|1]".
> | - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount
> | option "acl"/"noacl".
>
> Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> to the new cygwin1.dll today, I'm now suffering from an inability to
> modify files on a shared drive on my work machine. I can create empty
> files and remove existing files just fine, but get access denied on any
> attempt to change contents. The -1 for owner and group looks fishy as
> well.
Drive U is apparently a Samba drive. Is that in a Windows domain?
If not, try the noacl mount option. It's equivalent to what was
CYGWIN=nosmbntsec before.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 7:33 ` Corinna Vinschen
@ 2008-07-18 7:53 ` Corinna Vinschen
2008-07-18 8:08 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 7:53 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 09:34, Corinna Vinschen wrote:
> On Jul 17 18:18, Eric Blake wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > According to Corinna Vinschen on 7/17/2008 9:55 AM:
> > | Hi,
> > |
> > | again I would like to encourage the Cygwin maintainers, to try the new
> > | Cygwin 1.7.0 release and to look for problems in their packages which
> > | might be a result of the fairly massive changes in Cygwin 1.7. I
> > | attached a list of the changes below. The latest changes are:
> > |
> > | - Changes in mkpasswd/mkgroup and in seteuid() should result in more
> > | correct user tokens in AD domains. Try the LSA module.
> > | - Case-sensitivity on NTFS and NFS and mount option "posix=[0|1]".
> > | - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount
> > | option "acl"/"noacl".
> >
> > Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> > to the new cygwin1.dll today, I'm now suffering from an inability to
> > modify files on a shared drive on my work machine. I can create empty
> > files and remove existing files just fine, but get access denied on any
> > attempt to change contents. The -1 for owner and group looks fishy as
> > well.
>
> Drive U is apparently a Samba drive. Is that in a Windows domain?
> If not, try the noacl mount option. It's equivalent to what was
> CYGWIN=nosmbntsec before.
Hmm, I can reproduce it and now that I see it myself I can see how
this is a problem with cygdrive mounts.
I assume the best way to handle this would be to set Samba drives to
noacl by default, right?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 7:53 ` Corinna Vinschen
@ 2008-07-18 8:08 ` Corinna Vinschen
2008-07-18 12:07 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 8:08 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 09:54, Corinna Vinschen wrote:
> On Jul 18 09:34, Corinna Vinschen wrote:
> > On Jul 17 18:18, Eric Blake wrote:
> > > Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> > > to the new cygwin1.dll today, I'm now suffering from an inability to
> > > modify files on a shared drive on my work machine. I can create empty
> > > files and remove existing files just fine, but get access denied on any
> > > attempt to change contents. The -1 for owner and group looks fishy as
> > > well.
> >
> > Drive U is apparently a Samba drive. Is that in a Windows domain?
> > If not, try the noacl mount option. It's equivalent to what was
> > CYGWIN=nosmbntsec before.
>
> Hmm, I can reproduce it and now that I see it myself I can see how
> this is a problem with cygdrive mounts.
>
> I assume the best way to handle this would be to set Samba drives to
> noacl by default, right?
OTOH, I can't choose different mount options for different per cygdrive
mounted drives. All cydrives share the same options. How should we
solve that? I hope that doesn't mean we still need the global
(no)smbntsec option...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 8:08 ` Corinna Vinschen
@ 2008-07-18 12:07 ` Corinna Vinschen
2008-07-22 21:19 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 12:07 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 10:09, Corinna Vinschen wrote:
> On Jul 18 09:54, Corinna Vinschen wrote:
> > On Jul 18 09:34, Corinna Vinschen wrote:
> > > On Jul 17 18:18, Eric Blake wrote:
> > > > Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> > > > to the new cygwin1.dll today, I'm now suffering from an inability to
> > > > modify files on a shared drive on my work machine. I can create empty
> > > > files and remove existing files just fine, but get access denied on any
> > > > attempt to change contents. The -1 for owner and group looks fishy as
> > > > well.
> > >
> > > Drive U is apparently a Samba drive. Is that in a Windows domain?
> > > If not, try the noacl mount option. It's equivalent to what was
> > > CYGWIN=nosmbntsec before.
> >
> > Hmm, I can reproduce it and now that I see it myself I can see how
> > this is a problem with cygdrive mounts.
> >
> > I assume the best way to handle this would be to set Samba drives to
> > noacl by default, right?
>
> OTOH, I can't choose different mount options for different per cygdrive
> mounted drives. All cydrives share the same options. How should we
> solve that? I hope that doesn't mean we still need the global
> (no)smbntsec option...
For a start, I don't think we have to go back to smbntsec.
The real problem is exactly what I describe in the comment in
fhandler_base::open(). Apparently, creating the file and sending the
security descriptor to the server is a two step approach. So Samba
creates the file first, and then, afterwards, Windows sends the request
to change the security descriptor of the file. Now Samba can't map
SID->uid and returns STATUS_ACCESS_DENIED. But there seems to be no
knowledge that the two actions are actually one system call in Windows.
So Samba doesn't remove the file, but still, NtCreateFile failed.
Bummer.
I have a local workaround which I'll apply in a minute.
However, I never really understood why the mapping from the Windows
SID to the UNIX user fails, even though the user has been successfully
authenticated before. I have written a clueless mail to the samba
developers list. Maybe they can enlighten me.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
2008-07-18 0:18 ` Eric Blake
@ 2008-07-18 16:37 ` Marco Atzeri
2008-07-18 17:08 ` Corinna Vinschen
2008-07-18 19:29 ` Bill Hoffman
` (3 subsequent siblings)
5 siblings, 1 reply; 69+ messages in thread
From: Marco Atzeri @ 2008-07-18 16:37 UTC (permalink / raw)
To: cygwin-apps
--- Corinna Vinschen ha scritto:
> Hi,
>
Hi Corinna,
>
> Download a 1.7 distro using
> http://cygwin.com/setup-1.7.exe
>
Is it still unable to handle empty tarball ?
Bye
Marco
Posta, news, sport, oroscopo: tutto in una sola pagina.
Crea l'home page che piace a te!
www.yahoo.it/latuapagina
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 16:37 ` Marco Atzeri
@ 2008-07-18 17:08 ` Corinna Vinschen
2008-07-18 17:56 ` Christopher Faylor
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 17:08 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 18:36, Marco Atzeri wrote:
> --- Corinna Vinschen ha scritto:
> > Download a 1.7 distro using
> > http://cygwin.com/setup-1.7.exe
>
> Is it still unable to handle empty tarball ?
... of a certain type, yes, unfortunately. Fortunately it doesn't
stop the whole setup process, it just prints an error message and
asks for user input.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 17:08 ` Corinna Vinschen
@ 2008-07-18 17:56 ` Christopher Faylor
2008-07-18 18:18 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Christopher Faylor @ 2008-07-18 17:56 UTC (permalink / raw)
To: cygwin-apps
On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna Vinschen wrote:
>On Jul 18 18:36, Marco Atzeri wrote:
>> --- Corinna Vinschen ha scritto:
>> > Download a 1.7 distro using
>> > http://cygwin.com/setup-1.7.exe
>>
>> Is it still unable to handle empty tarball ?
>
>... of a certain type, yes, unfortunately. Fortunately it doesn't
>stop the whole setup process, it just prints an error message and
>asks for user input.
Actually I don't think it can handle any type of empty tarball can it?
I created them with "tar -T /dev/null -cjf foo.tar.bz2" but I think
setup.exe still complains about those type of tar files.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 17:56 ` Christopher Faylor
@ 2008-07-18 18:18 ` Corinna Vinschen
2008-07-18 23:59 ` Brian Dessent
2008-07-19 10:15 ` Marco Atzeri
0 siblings, 2 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-18 18:18 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 13:56, Christopher Faylor wrote:
> On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna Vinschen wrote:
> >On Jul 18 18:36, Marco Atzeri wrote:
> >> Is it still unable to handle empty tarball ?
> >
> >... of a certain type, yes, unfortunately. Fortunately it doesn't
> >stop the whole setup process, it just prints an error message and
> >asks for user input.
>
> Actually I don't think it can handle any type of empty tarball can it?
I don't know. I thought it handles one type and complains about the
other. I didn't actually test it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
2008-07-18 0:18 ` Eric Blake
2008-07-18 16:37 ` Marco Atzeri
@ 2008-07-18 19:29 ` Bill Hoffman
2008-07-19 12:24 ` Corinna Vinschen
2008-07-19 14:16 ` Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2) Corinna Vinschen
` (2 subsequent siblings)
5 siblings, 1 reply; 69+ messages in thread
From: Bill Hoffman @ 2008-07-18 19:29 UTC (permalink / raw)
To: cygwin-apps
Corinna Vinschen wrote:
> Download a 1.7 distro using http://cygwin.com/setup-1.7.exe
>
> Cygwin 1.7 and 1.5 can run in parallel sessions on the same machine, but
> the installation in parallel needs some manual intervention. Setup.exe
> is not yet using the new registry location and will happily install into
> your 1.5 installation dir...
>
Are there any instructions on exactly how to do this? I tried to
install both of them on my machine. I told setup-1.7 to install into a
separate directory, however, all of the other registry stuff that keeps
track of what is installed seems to be used as well. So, it installed
some stuff, but not everything. The resulting install could not run
programs because of missing dll's.
Thanks.
-Bill
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 18:18 ` Corinna Vinschen
@ 2008-07-18 23:59 ` Brian Dessent
2008-07-19 10:15 ` Marco Atzeri
1 sibling, 0 replies; 69+ messages in thread
From: Brian Dessent @ 2008-07-18 23:59 UTC (permalink / raw)
To: cygwin-apps
Corinna Vinschen wrote:
> > Actually I don't think it can handle any type of empty tarball can it?
>
> I don't know. I thought it handles one type and complains about the
> other. I didn't actually test it.
It can handle the type created by "bzip2 </dev/null" but not the "tar -T
/dev/null" type. I haven't had time to fix that yet, and I apologize
for letting setup remain in this state for so long. However, aside from
having to dismiss a popup it should be inconsequential -- the resulting
installation is not affected.
Brian
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 18:18 ` Corinna Vinschen
2008-07-18 23:59 ` Brian Dessent
@ 2008-07-19 10:15 ` Marco Atzeri
1 sibling, 0 replies; 69+ messages in thread
From: Marco Atzeri @ 2008-07-19 10:15 UTC (permalink / raw)
To: cygwin-apps
--- Corinna Vinschen ha scritto:
> On Jul 18 13:56, Christopher Faylor wrote:
> > On Fri, Jul 18, 2008 at 07:10:10PM +0200, Corinna
> Vinschen wrote:
> > >On Jul 18 18:36, Marco Atzeri wrote:
> > >> Is it still unable to handle empty tarball ?
> > >
> > >... of a certain type, yes, unfortunately.
> Fortunately it doesn't
> > >stop the whole setup process, it just prints an
> error message and
> > >asks for user input.
> >
> > Actually I don't think it can handle any type of
> empty tarball can it?
>
> I don't know. I thought it handles one type and
> complains about the
> other. I didn't actually test it.
>
for me complained on:
gcc-3.4.4-3.tar.bz2 for reading: Invalid or
unsupported tar format
tetex-3.0.0-3.tar.bz2 for reading: Invalid or
unsupported tar format
end it is a bit boring on a long installation
to wait for click to continue
:-)
>
> Corinna
>
Marco
Posta, news, sport, oroscopo: tutto in una sola pagina.
Crea l'home page che piace a te!
www.yahoo.it/latuapagina
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 19:29 ` Bill Hoffman
@ 2008-07-19 12:24 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-19 12:24 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 15:28, Bill Hoffman wrote:
> Corinna Vinschen wrote:
>
>> Download a 1.7 distro using http://cygwin.com/setup-1.7.exe
>> Cygwin 1.7 and 1.5 can run in parallel sessions on the same machine, but
>> the installation in parallel needs some manual intervention. Setup.exe
>> is not yet using the new registry location and will happily install into
>> your 1.5 installation dir...
> Are there any instructions on exactly how to do this? I tried to install
> both of them on my machine. I told setup-1.7 to install into a separate
> directory, however, all of the other registry stuff that keeps track of
> what is installed seems to be used as well. So, it installed some stuff,
> but not everything. The resulting install could not run programs because
> of missing dll's.
You have to rename the "Cygnus Solutions" registry key and also rename the
Cygwin 1.5 dir to something other than C:/cygwin. Then install 1.7 into,
say, C:/cygwin-1.7. Then rename the "Cygnus Solutions" registry key to,
for instance, "Cygnus Solutions 1.7" (it's not used in 1.7 anyway) and
rename the old 1.5 key back to "Cygnus Solutions".
We would really need a new setup.exe.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
` (2 preceding siblings ...)
2008-07-18 19:29 ` Bill Hoffman
@ 2008-07-19 14:16 ` Corinna Vinschen
2008-07-22 17:42 ` Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)) Corinna Vinschen
2008-07-21 23:42 ` New Cygwin 1.7.0-18 in release-2 Yaakov (Cygwin Ports)
2008-07-31 6:57 ` Yaakov (Cygwin Ports)
5 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-19 14:16 UTC (permalink / raw)
To: cygwin-apps
On Jul 17 17:55, Corinna Vinschen wrote:
> Hi,
>
> again I would like to encourage the Cygwin maintainers, to try the new
> Cygwin 1.7.0 release and to look for problems in their packages which
> might be a result of the fairly massive changes in Cygwin 1.7. I
> attached a list of the changes below. The latest changes are:
>
> - Changes in mkpasswd/mkgroup and in seteuid() should result in more
> correct user tokens in AD domains. Try the LSA module.
> - Case-sensitivity on NTFS and NFS and mount option "posix=[0|1]".
> - Remove CYGWIN=ntsec and CYGWIN=smbntsec options in favor of a mount
> option "acl"/"noacl".
I just uploaded 1.7.0-19. I made the following changes
- Workaround for the problem Eric reported, a "permission denied" when
creating files on a Samba shares mounted with "acl" option (default,
replacement for CYGWIN=ntsec option, see comment in default /etc/fstab
file).
- Removed the CYGWIN=binmode option. We're now always using binmode
for pipes and stuff.
- ls // now lists all SMB servers in all accessible domains and workgroups,
instead of just the servers in the machine's member domain or workgroup.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
` (3 preceding siblings ...)
2008-07-19 14:16 ` Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2) Corinna Vinschen
@ 2008-07-21 23:42 ` Yaakov (Cygwin Ports)
2008-07-22 9:32 ` Corinna Vinschen
2008-07-31 6:57 ` Yaakov (Cygwin Ports)
5 siblings, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-21 23:42 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| again I would like to encourage the Cygwin maintainers, to try the new
| Cygwin 1.7.0 release and to look for problems in their packages which
| might be a result of the fairly massive changes in Cygwin 1.7. I
| attached a list of the changes below. The latest changes are:
I've considered making the switch, as the new features in 1.7 (namely
IPv6 and wchar functions) would make porting *much* easier. It might
also provide the chance to finally close the gap between Ports and the
distro, and generally improve our packaging scheme at the same time.
OTOH I don't have only myself to think about; with all my packages, I
doubt that I'll be able to support 1.5 any more after I switch.
It would help if I could get some clarification on:
*) When 1.7 goes gold (and I don't mean binutils!), is the recommended
upgrade path going to be in the same (Windows) tree, or to start fresh
in a new directory?
*) Is gcc-4.3 in the near future for 1.7? Will gcc define
_GLIBCXX_USE_WCHAR_T? Will it provide shared libgcc, libstdc++, etc?
*) Is there a roadmap of what needs to be done for 1.7? I know you
don't want to provide a date, but some focus and perspective would be
helpful.
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiFHuIACgkQpiWmPGlmQSOYMACfUJJNNcUFVxtD+PYv4SSpaVIh
kJUAnRF44vDumN4ScJX/sjcgly9lO/9M
=xoP5
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-21 23:42 ` New Cygwin 1.7.0-18 in release-2 Yaakov (Cygwin Ports)
@ 2008-07-22 9:32 ` Corinna Vinschen
2008-07-23 17:26 ` Yaakov (Cygwin Ports)
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-22 9:32 UTC (permalink / raw)
To: cygwin-apps
On Jul 21 18:42, Yaakov (Cygwin Ports) wrote:
> I've considered making the switch, as the new features in 1.7 (namely
> IPv6 and wchar functions) would make porting *much* easier. It might
> also provide the chance to finally close the gap between Ports and the
> distro, and generally improve our packaging scheme at the same time.
>
> OTOH I don't have only myself to think about; with all my packages, I
> doubt that I'll be able to support 1.5 any more after I switch.
Not even pure security updates?
> It would help if I could get some clarification on:
>
> *) When 1.7 goes gold (and I don't mean binutils!), is the recommended
> upgrade path going to be in the same (Windows) tree, or to start fresh
> in a new directory?
When 1.7 goes gold, the idea is to install over an 1.5 install. Or not.
It's the choice of the user. Installing over 1.5 is supported by the
base-cygwin package, which is supposed to convert the registry mount
points to /etc/fstab mount points. OTOH, a 1.7 install can coexist with
a 1.5 install on the same machine.
> *) Is gcc-4.3 in the near future for 1.7? Will gcc define
> _GLIBCXX_USE_WCHAR_T? Will it provide shared libgcc, libstdc++, etc?
That's one for Dave to answer.
> *) Is there a roadmap of what needs to be done for 1.7? I know you
> don't want to provide a date, but some focus and perspective would be
> helpful.
There's no roadmap. What's missing for a release is
- A new setup.exe
- The Cygwin utils are not quite up to speed
- Documentation changes
- Support by the package maintainers
- Testing
All of the above items could need a helping hand. If 1.7 isn't too
buggy, I plan to release 1.7 still in 2008. When that actually happens
doesn't depend on me. Cygwin 1.7 development has gone on for two years
and it comes with a lot of changes. Not all of them allow a 100% smooth
transition.
Eventually this release depends on the support it gets from all of you.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))
2008-07-19 14:16 ` Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2) Corinna Vinschen
@ 2008-07-22 17:42 ` Corinna Vinschen
2008-07-25 8:10 ` Corinna Vinschen
2008-07-28 14:52 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) John Morrison
0 siblings, 2 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-22 17:42 UTC (permalink / raw)
To: cygwin-apps; +Cc: John Morrison
I just uploaded 1.7.0-20. It contains the following important changes:
- Fix for the problem with native Win32 apps described in this thread:
http://cygwin.com/ml/cygwin/2008-07/msg00457.html
- Reworked mkpasswd and mkgroup tools including the documentation.
The usage changed and you have some additional options to create
unique usernames especially for multi-domain environments.
You can now call mkpasswd and mkgroup without any -l or -d parameter
and both tools choose by themselves what information to print, depending
on the machine being a domain member machine or not.
This should result in a matching change to the base-passwd package for
1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
without any parameter.
Could you please change that for us, John?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-18 12:07 ` Corinna Vinschen
@ 2008-07-22 21:19 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-22 21:19 UTC (permalink / raw)
To: cygwin-apps
On Jul 18 14:09, Corinna Vinschen wrote:
> > > > On Jul 17 18:18, Eric Blake wrote:
> > > > > Somewhere between setting obcaseinsensitive to 0 yesterday and upgrading
> > > > > to the new cygwin1.dll today, I'm now suffering from an inability to
> > > > > modify files on a shared drive on my work machine. I can create empty
> > > > > files and remove existing files just fine, but get access denied on any
> > > > > attempt to change contents. The -1 for owner and group looks fishy as
> > > > > well.
> [...]
> The real problem is exactly what I describe in the comment in
> fhandler_base::open(). Apparently, creating the file and sending the
> security descriptor to the server is a two step approach. So Samba
> creates the file first, and then, afterwards, Windows sends the request
> to change the security descriptor of the file. Now Samba can't map
> SID->uid and returns STATUS_ACCESS_DENIED. But there seems to be no
> knowledge that the two actions are actually one system call in Windows.
> So Samba doesn't remove the file, but still, NtCreateFile failed.
> Bummer.
>
> I have a local workaround which I'll apply in a minute.
>
> However, I never really understood why the mapping from the Windows
> SID to the UNIX user fails, even though the user has been successfully
> authenticated before. I have written a clueless mail to the samba
> developers list. Maybe they can enlighten me.
They don't so far. However, as a side note, with "acl" on, you currently
don't see user/group info in `ls -l', if your machines are not in fully
Windows domain integrated. With the latest incarnation of
mkpasswd and mkgroup (from CVS, not fully functional in 1.7.0-20), you can
now ask your Samba machine for their passwd and group information:
$ mkpasswd -L samba-machine >> /etc/passwd
$ mkgroup -L samba-machine >> /etc/group
At least this works for me. Unfortunately Samba doesn't enumerate the
UNIX user and group information from its own /etc/passwd and /etc/group
files. For instance the user "root" is S-1-22-1-0, the group "root" is
S-1-22-2-0. That's what you see in the Windows Explorer Security tab
as "Unix User\root" and "Unix Group\root". Apparently these are never
enumerated, only returned in calls to LookupAccountSid and
LookupAccountName.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-22 9:32 ` Corinna Vinschen
@ 2008-07-23 17:26 ` Yaakov (Cygwin Ports)
2008-07-23 18:00 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-23 17:26 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| When 1.7 goes gold, the idea is to install over an 1.5 install. Or not.
| It's the choice of the user. Installing over 1.5 is supported by the
| base-cygwin package, which is supposed to convert the registry mount
| points to /etc/fstab mount points. OTOH, a 1.7 install can coexist with
| a 1.5 install on the same machine.
The advantage of "starting fresh" with 1.7 would allow us to dump a lot
of obsolete packages from the distro (both old versions of libs, and
empty packages created for the purpose of smooth upgrades), and make
some more changes leading up to 1.7 without creating more. It would
mean some things would have to be rebuilt (e.g. diff requires libintl2),
but IMHO everything should anyways be rebuilt for 1.7.
OTOH I'm not sure what the user reaction would be. I suppose one
compromise would be to require users to "rm -fr /etc/setup" before
upgrading to 1.7.
| There's no roadmap. What's missing for a release is
|
| - A new setup.exe
|
| - The Cygwin utils are not quite up to speed
|
| - Documentation changes
|
| - Support by the package maintainers
|
| - Testing
|
| All of the above items could need a helping hand. If 1.7 isn't too
| buggy, I plan to release 1.7 still in 2008. When that actually happens
| doesn't depend on me. Cygwin 1.7 development has gone on for two years
| and it comes with a lot of changes. Not all of them allow a 100% smooth
| transition.
| Eventually this release depends on the support it gets from all of you.
I for one would like to "catch up" the distro to what I've made
available in Ports.
Could someone point me again to the current directions to install 1.7 in
parallel to 1.5 on the same machine?
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiHaZgACgkQpiWmPGlmQSO7jQCfXURX9AXZ5UaioPocdpte0W8o
KokAniwdo2yASqmyM8JO+BMa5hIST7Jt
=DgWy
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-23 17:26 ` Yaakov (Cygwin Ports)
@ 2008-07-23 18:00 ` Corinna Vinschen
2008-07-23 20:44 ` John Morrison
2008-07-24 3:45 ` Yaakov (Cygwin Ports)
0 siblings, 2 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-23 18:00 UTC (permalink / raw)
To: cygwin-apps
On Jul 23 12:25, Yaakov (Cygwin Ports) wrote:
> Corinna Vinschen wrote:
> | When 1.7 goes gold, the idea is to install over an 1.5 install. Or not.
> | It's the choice of the user.
>
> The advantage of "starting fresh" with 1.7 would allow us to dump a lot
> of obsolete packages from the distro [...]
> but IMHO everything should anyways be rebuilt for 1.7.
I'd be happy if even the most important packages have been rebuilt for
1.7. So far the reactions from the package maintainers were somewhat
reticent.
> OTOH I'm not sure what the user reaction would be. I suppose one
> compromise would be to require users to "rm -fr /etc/setup" before
> upgrading to 1.7.
I'm still rather trying to smooth out the upgrade path so that there
are as little as possible manual changes left to the user. It will
be bumpy nevertheless...
> | There's no roadmap. What's missing for a release is
> |
> | - A new setup.exe
> |
> | - The Cygwin utils are not quite up to speed
> |
> | - Documentation changes
> |
> | - Support by the package maintainers
> |
> | - Testing
> |
> | All of the above items could need a helping hand. If 1.7 isn't too
> | buggy, I plan to release 1.7 still in 2008. When that actually happens
> | doesn't depend on me. Cygwin 1.7 development has gone on for two years
> | and it comes with a lot of changes. Not all of them allow a 100% smooth
> | transition.
> | Eventually this release depends on the support it gets from all of you.
>
> I for one would like to "catch up" the distro to what I've made
> available in Ports.
Cool.
> Could someone point me again to the current directions to install 1.7 in
> parallel to 1.5 on the same machine?
The problem so far is the "Cygnus Solutions" registry key and the
default name of the cygwin dir, C:\cygwin. When you try to install
1.7, both shouldn't exist. So what I did is this:
- Rename C:\cygwin to C:\cygwin-1.5. Change this everywhere in the
registry.
- My HKCU "Cygnus Solutions" mount table is empty anyway, so it doesn't
matter. Rename HKLM "Cygnus Solutions" to "Cygnus Solutions 1.5".
- Install Cygwin 1.7 with setup-1.7.exe into C:\cygwin.
- Rename HKLM "Cygnus Solutions" to "Cygnus Solutions 1.7"
- Rename HKLM "Cygnus Solutions 1.5" back to "Cygnus Solutions".
Since 1.7 doesn't use the above registry key, it doesn't matter for
running 1.7. Just when calling setup-1.7 for an update, the registry
key rename orgy starts again.
We *really* need a new setup for 1.7 which doesn't access the "Cygnus
Solutions" registry key anymore.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-23 18:00 ` Corinna Vinschen
@ 2008-07-23 20:44 ` John Morrison
2008-07-24 9:08 ` Corinna Vinschen
2008-07-25 10:07 ` Andrew Schulman
2008-07-24 3:45 ` Yaakov (Cygwin Ports)
1 sibling, 2 replies; 69+ messages in thread
From: John Morrison @ 2008-07-23 20:44 UTC (permalink / raw)
To: cygwin-apps
On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote:
> On Jul 23 12:25, Yaakov (Cygwin Ports) wrote:
>> Corinna Vinschen wrote:
>> | When 1.7 goes gold, the idea is to install over an 1.5 install. Or
>> not.
>> | It's the choice of the user.
>>
>> The advantage of "starting fresh" with 1.7 would allow us to dump a lot
>> of obsolete packages from the distro [...]
>> but IMHO everything should anyways be rebuilt for 1.7.
>
> I'd be happy if even the most important packages have been rebuilt for
> 1.7. So far the reactions from the package maintainers were somewhat
> reticent.
I think that'll probably alter once there's a setup for 1.7. Speaking
personally I *need* my installation of cygwin and couldn't stand to be
without it. (I will get 'round to patching the base packages, but I
was/did hand these over to Igor; is he still around?)
X under 1.7 is a requirement for me. Just wish I had the skills to get
the latest version working.
>> OTOH I'm not sure what the user reaction would be. I suppose one
>> compromise would be to require users to "rm -fr /etc/setup" before
>> upgrading to 1.7.
Once X works, that works for me :)
> I'm still rather trying to smooth out the upgrade path so that there
> are as little as possible manual changes left to the user. It will
> be bumpy nevertheless...
>
>> | There's no roadmap. What's missing for a release is
>> |
>> | - A new setup.exe
>> |
>> | - The Cygwin utils are not quite up to speed
>> |
>> | - Documentation changes
>> |
>> | - Support by the package maintainers
>> |
>> | - Testing
>> |
>> | All of the above items could need a helping hand. If 1.7 isn't too
>> | buggy, I plan to release 1.7 still in 2008. When that actually
>> happens
>> | doesn't depend on me. Cygwin 1.7 development has gone on for two
>> years
>> | and it comes with a lot of changes. Not all of them allow a 100%
>> smooth
>> | transition.
>> | Eventually this release depends on the support it gets from all of
>> you.
>>
>> I for one would like to "catch up" the distro to what I've made
>> available in Ports.
>
> Cool.
Definately.
>> Could someone point me again to the current directions to install 1.7 in
>> parallel to 1.5 on the same machine?
>
> The problem so far is the "Cygnus Solutions" registry key and the
> default name of the cygwin dir, C:\cygwin. When you try to install
> 1.7, both shouldn't exist. So what I did is this:
>
> - Rename C:\cygwin to C:\cygwin-1.5. Change this everywhere in the
> registry.
>
> - My HKCU "Cygnus Solutions" mount table is empty anyway, so it doesn't
> matter. Rename HKLM "Cygnus Solutions" to "Cygnus Solutions 1.5".
>
> - Install Cygwin 1.7 with setup-1.7.exe into C:\cygwin.
>
> - Rename HKLM "Cygnus Solutions" to "Cygnus Solutions 1.7"
>
> - Rename HKLM "Cygnus Solutions 1.5" back to "Cygnus Solutions".
>
> Since 1.7 doesn't use the above registry key, it doesn't matter for
> running 1.7. Just when calling setup-1.7 for an update, the registry
> key rename orgy starts again.
>
> We *really* need a new setup for 1.7 which doesn't access the "Cygnus
> Solutions" registry key anymore.
Agreed :(
J.
(attempting to find some time!)
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-23 18:00 ` Corinna Vinschen
2008-07-23 20:44 ` John Morrison
@ 2008-07-24 3:45 ` Yaakov (Cygwin Ports)
2008-07-24 9:24 ` Corinna Vinschen
1 sibling, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-24 3:45 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| I'd be happy if even the most important packages have been rebuilt for
| 1.7. So far the reactions from the package maintainers were somewhat
| reticent.
I know I've been holding back because of the apparent difficulties in
transitioning between versions (even one way, not to mention
back-and-forth), and until recently the uncertainty as to the timeframe
for 1.7. I am at the point that I am ready to consider switching, however.
| I'm still rather trying to smooth out the upgrade path so that there
| are as little as possible manual changes left to the user. It will
| be bumpy nevertheless...
IOW you want to leave upgrading in the same root a possibility. Is it
really worth it?
| The problem so far is the "Cygnus Solutions" registry key and the
| default name of the cygwin dir, C:\cygwin. When you try to install
| 1.7, both shouldn't exist. So what I did is this:
I understand the registry key is due to setup. But what's the problem
with C:\cygwin?
| We *really* need a new setup for 1.7 which doesn't access the "Cygnus
| Solutions" registry key anymore.
Agreed, **ASAP**.
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiH+q0ACgkQpiWmPGlmQSPHKQCg4CVTKqvlFcMoMedsx3DdO2W7
ErUAoN1WMf9kucpPgh/IBGhf/5PFtvLM
=77Hl
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-23 20:44 ` John Morrison
@ 2008-07-24 9:08 ` Corinna Vinschen
2008-07-24 9:18 ` John Morrison
2008-07-25 10:07 ` Andrew Schulman
1 sibling, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-24 9:08 UTC (permalink / raw)
To: cygwin-apps
On Jul 23 21:44, John Morrison wrote:
> On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote:
> > I'd be happy if even the most important packages have been rebuilt for
> > 1.7. So far the reactions from the package maintainers were somewhat
> > reticent.
>
> I think that'll probably alter once there's a setup for 1.7. Speaking
> personally I *need* my installation of cygwin and couldn't stand to be
> without it. (I will get 'round to patching the base packages, but I
> was/did hand these over to Igor; is he still around?)
Igor is still around, yes. I didn't know (or forgot again) you handed
over maintainership of the base packages. Igor?
> X under 1.7 is a requirement for me. Just wish I had the skills to get
> the latest version working.
>
> >> OTOH I'm not sure what the user reaction would be. I suppose one
> >> compromise would be to require users to "rm -fr /etc/setup" before
> >> upgrading to 1.7.
>
> Once X works, that works for me :)
Why is X so important for testing and building packages? I mean,
the console window and rxvt exist, right? Personally I'm doing a lot
in my Linux X console, connecting to my Windows machines via rdesktop
and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in
different directories, there should be no problem running 1.7 based
rxvt/xterm in a 1.5 X server.
> > We *really* need a new setup for 1.7 which doesn't access the "Cygnus
> > Solutions" registry key anymore.
>
> Agreed :(
>
> J.
>
> (attempting to find some time!)
Please with sugar?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-24 9:08 ` Corinna Vinschen
@ 2008-07-24 9:18 ` John Morrison
2008-07-24 9:26 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: John Morrison @ 2008-07-24 9:18 UTC (permalink / raw)
To: cygwin-apps
On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote:
> On Jul 23 21:44, John Morrison wrote:
>> On Wed, July 23, 2008 7:00 pm, Corinna Vinschen wrote:
>> > I'd be happy if even the most important packages have been rebuilt for
>> > 1.7. So far the reactions from the package maintainers were somewhat
>> > reticent.
>>
>> I think that'll probably alter once there's a setup for 1.7. Speaking
>> personally I *need* my installation of cygwin and couldn't stand to be
>> without it. (I will get 'round to patching the base packages, but I
>> was/did hand these over to Igor; is he still around?)
>
> Igor is still around, yes. I didn't know (or forgot again) you handed
> over maintainership of the base packages. Igor?
>
>> X under 1.7 is a requirement for me. Just wish I had the skills to get
>> the latest version working.
>>
>> >> OTOH I'm not sure what the user reaction would be. I suppose one
>> >> compromise would be to require users to "rm -fr /etc/setup" before
>> >> upgrading to 1.7.
>>
>> Once X works, that works for me :)
>
> Why is X so important for testing and building packages?
testing and building no, but I suspect that for most maintainers (at least
those with only one or two packages) the package is a 'thank you' back to
cygwin for the environment so the stability of the environment is very
important. I know that's why I started with the base- packages, 'cause I
wanted to improve the 'out of the box' experience.
> I mean,
> the console window and rxvt exist, right? Personally I'm doing a lot
> in my Linux X console, connecting to my Windows machines via rdesktop
> and ssh in an xterm. Btw., since 1.5 and 1.7 can co-exist running in
> different directories, there should be no problem running 1.7 based
> rxvt/xterm in a 1.5 X server.
I didn't know that.
>> (attempting to find some time!)
>
> Please with sugar?
I only have windows at work now and all my time is 'allocated' to
projects... trying! If I don't get it done before the weekend I'll get a
virtual machine running. Promise.
J.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-24 3:45 ` Yaakov (Cygwin Ports)
@ 2008-07-24 9:24 ` Corinna Vinschen
2008-07-24 16:18 ` Yaakov (Cygwin Ports)
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-24 9:24 UTC (permalink / raw)
To: cygwin-apps
On Jul 23 22:44, Yaakov (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> | I'd be happy if even the most important packages have been rebuilt for
> | 1.7. So far the reactions from the package maintainers were somewhat
> | reticent.
>
> I know I've been holding back because of the apparent difficulties in
> transitioning between versions (even one way, not to mention
> back-and-forth), and until recently the uncertainty as to the timeframe
> for 1.7. I am at the point that I am ready to consider switching, however.
I'm building OpenSSH as 1.5 and 1.7 version in different build dirs.
I had no transitioning problems. Maybe that's because the build system
is rather simple or something. Admittedly, except for openssh, openssl
and syslog-ng and a local BETA vim7.2a I didn't bother to create more
1.7 packages so far. I was mainly interested in IPv6.
> | I'm still rather trying to smooth out the upgrade path so that there
> | are as little as possible manual changes left to the user. It will
> | be bumpy nevertheless...
>
> IOW you want to leave upgrading in the same root a possibility. Is it
> really worth it?
Honestly, I don't know. Maybe it isn't. But so far I'm still thinking
that a parallel 1.7 install should only be a temporary solution for
developers and maintainers. It's not something I would like to drag
on for years. That's why an upgrade path has some merits for me.
> | The problem so far is the "Cygnus Solutions" registry key and the
> | default name of the cygwin dir, C:\cygwin. When you try to install
> | 1.7, both shouldn't exist. So what I did is this:
>
> I understand the registry key is due to setup. But what's the problem
> with C:\cygwin?
So far setup looks if c:\cygwin exists and if so, uses the install
database in c:\cygwin\etc\setup accidentelly, even if you choose to
install another installation to, say, D:\cygwin-2.
> | We *really* need a new setup for 1.7 which doesn't access the "Cygnus
> | Solutions" registry key anymore.
>
> Agreed, **ASAP**.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-24 9:18 ` John Morrison
@ 2008-07-24 9:26 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-24 9:26 UTC (permalink / raw)
To: cygwin-apps
On Jul 24 10:17, John Morrison wrote:
> On Thu, July 24, 2008 10:08 am, Corinna Vinschen wrote:
> > Please with sugar?
>
> I only have windows at work now and all my time is 'allocated' to
> projects... trying! If I don't get it done before the weekend I'll get a
> virtual machine running. Promise.
Thanks! Btw., all my Windows machines are virtual machines. Even my
domain controller is running in a VM :)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-24 9:24 ` Corinna Vinschen
@ 2008-07-24 16:18 ` Yaakov (Cygwin Ports)
2008-07-24 17:46 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-24 16:18 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| Honestly, I don't know. Maybe it isn't. But so far I'm still thinking
| that a parallel 1.7 install should only be a temporary solution for
| developers and maintainers. It's not something I would like to drag
| on for years. That's why an upgrade path has some merits for me.
I definitely agree that we don't want to support 1.5 anymore after 1.7
is stable.
| So far setup looks if c:\cygwin exists and if so, uses the install
| database in c:\cygwin\etc\setup accidentelly, even if you choose to
| install another installation to, say, D:\cygwin-2.
Would it suffice to rename /etc/setup/installed.db?
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiIqxoACgkQpiWmPGlmQSPs+wCfbBHf8/82nFnMi0495IxmgZYH
9yYAoOIsocD8gruP4uyKhWWgCiDIPj7X
=DRzP
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-24 16:18 ` Yaakov (Cygwin Ports)
@ 2008-07-24 17:46 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-24 17:46 UTC (permalink / raw)
To: cygwin-apps
On Jul 24 11:17, Yaakov (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> | Honestly, I don't know. Maybe it isn't. But so far I'm still thinking
> | that a parallel 1.7 install should only be a temporary solution for
> | developers and maintainers. It's not something I would like to drag
> | on for years. That's why an upgrade path has some merits for me.
>
> I definitely agree that we don't want to support 1.5 anymore after 1.7
> is stable.
>
> | So far setup looks if c:\cygwin exists and if so, uses the install
> | database in c:\cygwin\etc\setup accidentelly, even if you choose to
> | install another installation to, say, D:\cygwin-2.
>
> Would it suffice to rename /etc/setup/installed.db?
I don't know, sorry.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))
2008-07-22 17:42 ` Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)) Corinna Vinschen
@ 2008-07-25 8:10 ` Corinna Vinschen
2008-07-25 11:00 ` 1.7.0-21 broken Corinna Vinschen
2008-07-28 14:52 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) John Morrison
1 sibling, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-25 8:10 UTC (permalink / raw)
To: cygwin-apps; +Cc: John Morrison
I just uploaded 1.7.0-21. It contains the following important changes:
- Fix for the fix for the problem with native Win32 apps described in this
thread: http://cygwin.com/ml/cygwin/2008-07/msg00457.html
My first solution didn't work for applications started from a remote
share path (//server/share/bin/foo).
- Reworked mkpasswd and mkgroup tools a bit more. I added a -U option
which allows to enumerate the standard UNIX accounts from a Samba
server. I also added a way to define per-server uid/gid offsets
(-D domain,offset). This allows to define the offsets in a
reproducible way for later calls to mkpasswd/mkgroup. I also added a
-b option to drop enumerating the builtin groups. This is handy when
appending group information from another server to your already
existing /etc/group file and you don't want to have to remove
duplicate builtin groups manually.
I updated the mkpasswd and mkgroup documentation under
http://cygwin.com/1.7/cygwin-ug-net.html accordingly.
- It turned out that on reading the user fstab file, the username used
to construct the fstab filename was actually the Windows username, not
the Cygwin username. I changed the startup code so that the Cygwin
username is read from /etc/passwd before trying to read the user's
fstab file.
This also allows to define different user fstab files for users with
the same name but from different domains. Assume you have created
the mkpasswd file so that the usernames are fully qualified (real
life example):
$ mkpasswd -L coffee -D vinschen -u corinna
COFFEE\corinna:unused:11003:10513:U-COFFEE\corinna,S-1-5-21-790525478-115176313-839522115-1003:/home/corinna:/bin/bash
VINSCHEN\corinna:unused:21001:21125:U-VINSCHEN\corinna,S-1-5-21-9231407823-6179817828-4384181110-1001:/home/corinna:/bin/bash
The /etc/profile.d/user-fstab.sh script from the latest base-cygwin
package 0.7-1 will now actually create a different fstab file for
both users on first logon:
/etc/fstab.d/COFFEE/corinna
/etc/fstab.d/VINSCHEN/corinna
Yes, if the username contains / or \ as separator char, it will create
the matching subdirs. If you defined another separator char like in
-S+, it will of course just create plain files:
/etc/fstab.d/COFFEE+corinna
/etc/fstab.d/VINSCHEN+corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-23 20:44 ` John Morrison
2008-07-24 9:08 ` Corinna Vinschen
@ 2008-07-25 10:07 ` Andrew Schulman
1 sibling, 0 replies; 69+ messages in thread
From: Andrew Schulman @ 2008-07-25 10:07 UTC (permalink / raw)
To: cygwin-apps
> > I'd be happy if even the most important packages have been rebuilt for
> > 1.7. So far the reactions from the package maintainers were somewhat
> > reticent.
>
> I think that'll probably alter once there's a setup for 1.7.
Ditto here. Waiting for setup for 1.7, then I'll rebuild all of my packages.
^ permalink raw reply [flat|nested] 69+ messages in thread
* 1.7.0-21 broken
2008-07-25 8:10 ` Corinna Vinschen
@ 2008-07-25 11:00 ` Corinna Vinschen
2008-07-25 18:08 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-25 11:00 UTC (permalink / raw)
To: cygwin-apps; +Cc: John Morrison
On Jul 25 10:10, Corinna Vinschen wrote:
> I just uploaded 1.7.0-21.
Please ignore this for now. There's a serious problem with this
release. I'm investigating...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: 1.7.0-21 broken
2008-07-25 11:00 ` 1.7.0-21 broken Corinna Vinschen
@ 2008-07-25 18:08 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-25 18:08 UTC (permalink / raw)
To: cygwin-apps; +Cc: John Morrison
On Jul 25 13:00, Corinna Vinschen wrote:
> On Jul 25 10:10, Corinna Vinschen wrote:
> > I just uploaded 1.7.0-21.
>
> Please ignore this for now. There's a serious problem with this
> release. I'm investigating...
I uploaded 1.7.0-22 which hopefully fixes this issue.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
2008-07-22 17:42 ` Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)) Corinna Vinschen
2008-07-25 8:10 ` Corinna Vinschen
@ 2008-07-28 14:52 ` John Morrison
2008-07-28 15:27 ` Corinna Vinschen
1 sibling, 1 reply; 69+ messages in thread
From: John Morrison @ 2008-07-28 14:52 UTC (permalink / raw)
To: cygwin-apps
On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
> You can now call mkpasswd and mkgroup without any -l or -d parameter
> and both tools choose by themselves what information to print, depending
> on the machine being a domain member machine or not.
>
> This should result in a matching change to the base-passwd package for
> 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
> without any parameter.
>
> Could you please change that for us, John?
Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
parameters when calling mkpasswd and mkgroup. I've left the rest of the
script the same; that's OK?
Do we still want the base-files profile to have the message wrt group
names of mkpassword/mkgroup/mkgroup_l_d?
Are there any other changes wanted? For example, I think a comment about
MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
to alter anything. Corinna; you use the tcsh shell don't you (I seem to
recall)? Are there any profile defaults we should put in for it?
I've added a few licenses; AFL (1.1, 1.2, 2.0, 2.1), Apache (1.0, 1.1,
2.0), Artistic (1, 2), BSD, GPL (2.0, 3.0), LGPL (2.0, 3.0), MIT, PHP (3).
Are there any others folks would like?
Is there anything more base-[files|password] could do for users?
My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
installed vim I suppose; vi?)
/etc/bash.bashrc has the following in both Debian and Ubuntu (not a
suprise I suppose);
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
would it work in cygwin? Also;
# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
else
return 127
fi
}
fi
could we do something similar? (Although, I wouldn't want to bring python
into base if I could help it) /usr/lib/command-no-found is a python
script as well.
Should we have a /etc/motd? (not that I know what should calls/displays
it in the cygwin env; /etc/profile?)
I'll package and upload tomorrow evening if nobody has any improvements.
J.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
2008-07-28 14:52 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) John Morrison
@ 2008-07-28 15:27 ` Corinna Vinschen
2008-07-28 16:34 ` base-[files|password] for 1.7 John Morrison
` (3 more replies)
0 siblings, 4 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-28 15:27 UTC (permalink / raw)
To: cygwin-apps
On Jul 28 15:51, John Morrison wrote:
> On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
> > You can now call mkpasswd and mkgroup without any -l or -d parameter
> > and both tools choose by themselves what information to print, depending
> > on the machine being a domain member machine or not.
> >
> > This should result in a matching change to the base-passwd package for
> > 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
> > without any parameter.
> >
> > Could you please change that for us, John?
>
> Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
> parameters when calling mkpasswd and mkgroup. I've left the rest of the
> script the same; that's OK?
Yep, that's ok.
> Do we still want the base-files profile to have the message wrt group
> names of mkpassword/mkgroup/mkgroup_l_d?
Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and
mkgroup will probably reduce printing this message a lot, if not
entirely.
> Are there any other changes wanted? For example, I think a comment about
> MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
> to alter anything.
Is that MAKE_MODE thingy supported at all in latest make? If so,
isn't MAKE_MODE=unix default anyway?
> Corinna; you use the tcsh shell don't you (I seem to
> recall)? Are there any profile defaults we should put in for it?
Yes, I'm using tcsh, but your scripts don't have to care for them
since everything's already done in csh.login and csh.cshrc. Including
setting MAKE_MODE=unix :)
> My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
> installed vim I suppose; vi?)
I think setting EDITOR should be a user choice, but I'm not strongly
opposing the idea, especially given that I'm vim user anyway ;).
> /etc/bash.bashrc has the following in both Debian and Ubuntu (not a
> suprise I suppose);
>
> # check the window size after each command and, if necessary,
> # update the values of LINES and COLUMNS.
> shopt -s checkwinsize
>
> would it work in cygwin? Also;
Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric?
> # if the command-not-found package is installed, use it
> if [ -x /usr/lib/command-not-found ]; then
> function command_not_found_handle {
> # check because c-n-f could've been removed in the meantime
> if [ -x /usr/lib/command-not-found ]; then
> /usr/bin/python /usr/lib/command-not-found -- $1
> return $?
> else
> return 127
> fi
> }
> fi
Not for me.
> Should we have a /etc/motd? (not that I know what should calls/displays
> it in the cygwin env; /etc/profile?)
We get a default /etc/motd when the inetutils package has been installed.
> I'll package and upload tomorrow evening if nobody has any improvements.
Cool, I'm looking forward,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-28 15:27 ` Corinna Vinschen
@ 2008-07-28 16:34 ` John Morrison
2008-07-29 9:32 ` Corinna Vinschen
2008-07-28 18:56 ` Pierre A. Humblet
` (2 subsequent siblings)
3 siblings, 1 reply; 69+ messages in thread
From: John Morrison @ 2008-07-28 16:34 UTC (permalink / raw)
To: cygwin-apps
On Mon, July 28, 2008 4:27 pm, Corinna Vinschen wrote:
> On Jul 28 15:51, John Morrison wrote:
>> On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
> Yep, that's ok.
Good :)
>> Do we still want the base-files profile to have the message wrt group
>> names of mkpassword/mkgroup/mkgroup_l_d?
>
> Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and
> mkgroup will probably reduce printing this message a lot, if not
> entirely.
Doesn't hurt, but might speed up startup by a second or so... prob not
worth removing.
>> Are there any other changes wanted? For example, I think a comment
>> about
>> MAKE_MODE=Unix came up on the lists a few months ago... Now's a good
>> time
>> to alter anything.
>
> Is that MAKE_MODE thingy supported at all in latest make? If so,
> isn't MAKE_MODE=unix default anyway?
absolutely no idea.
>> Corinna; you use the tcsh shell don't you (I seem to
>> recall)? Are there any profile defaults we should put in for it?
>
> Yes, I'm using tcsh, but your scripts don't have to care for them
> since everything's already done in csh.login and csh.cshrc. Including
> setting MAKE_MODE=unix :)
Ok. So the tcsh script includes csh.cshrc? Should the bash package
include the bash.bashrc?
>> My Debian /etc/profile sets EDITOR=vim useful? (not if you've not
>> installed vim I suppose; vi?)
>
> I think setting EDITOR should be a user choice, but I'm not strongly
> opposing the idea, especially given that I'm vim user anyway ;).
Me too, but the user can always override this in their ~ files.
>> /etc/bash.bashrc has the following in both Debian and Ubuntu (not a
>> suprise I suppose);
>>
>> # check the window size after each command and, if necessary,
>> # update the values of LINES and COLUMNS.
>> shopt -s checkwinsize
>>
>> would it work in cygwin? Also;
>
> Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric?
>
>> # if the command-not-found package is installed, use it
>> if [ -x /usr/lib/command-not-found ]; then
>> function command_not_found_handle {
>> # check because c-n-f could've been removed in the
>> meantime
>> if [ -x /usr/lib/command-not-found ]; then
>> /usr/bin/python /usr/lib/command-not-found -- $1
>> return $?
>> else
>> return 127
>> fi
>> }
>> fi
>
> Not for me.
Ah, but I bet you've got just about everything installed anyway! You also
know where/how to find this informtion. We could knockup a script which
calls http://cygwin.com/cgi-bin2/package-grep.cgi?grep=<command>, cleans
up the html and writes it out? It's more for the person who doesn't know
what package to install. It'd be even easier if there was a plain text
version of the output then it'd just be curl :) Is the source for the
package-grep.cgi available?
>> Should we have a /etc/motd? (not that I know what should calls/displays
>> it in the cygwin env; /etc/profile?)
>
> We get a default /etc/motd when the inetutils package has been installed.
Okie, I've only installed base on my vm.
>> I'll package and upload tomorrow evening if nobody has any improvements.
>
> Cool, I'm looking forward,
Np, sorry it's take so long :(
J.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-28 15:27 ` Corinna Vinschen
2008-07-28 16:34 ` base-[files|password] for 1.7 John Morrison
@ 2008-07-28 18:56 ` Pierre A. Humblet
2008-07-29 9:45 ` Corinna Vinschen
2008-07-28 19:00 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) Christopher Faylor
2008-07-29 11:37 ` Eric Blake
3 siblings, 1 reply; 69+ messages in thread
From: Pierre A. Humblet @ 2008-07-28 18:56 UTC (permalink / raw)
To: cygwin-apps
----- Original Message -----
From: "Corinna Vinschen" <>
To: <cygwin-apps@cygwin.com>
Sent: Monday, July 28, 2008 11:27 AM
Subject: Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19
(was Re: New Cygwin 1.7.0-18 in release-2)))
| On Jul 28 15:51, John Morrison wrote:
| > On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
| > > You can now call mkpasswd and mkgroup without any -l or -d parameter
| > > and both tools choose by themselves what information to print, depending
| > > on the machine being a domain member machine or not.
| > >
| > > This should result in a matching change to the base-passwd package for
| > > 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
| > > without any parameter.
| > >
| > > Could you please change that for us, John?
| >
| > Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
| > parameters when calling mkpasswd and mkgroup. I've left the rest of the
| > script the same; that's OK?
|
| Yep, that's ok.
|
| > Do we still want the base-files profile to have the message wrt group
| > names of mkpassword/mkgroup/mkgroup_l_d?
|
| Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and
| mkgroup will probably reduce printing this message a lot, if not
| entirely.
Looks like without argument the new mk{passwd/group} will dump the entire
passwd/group from the domain server. Some companies have tens of thousands
of names and that's why they weren't called with -l -d by default but with -l -c
The -c switch would only create an entry for the current user or the current primary group
WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
using only local info but mkgroup could not find the group name, so it was
calling it "mkgroup-l-d" .
The new mkgroup also has a -c option, which gets the current primary group name.
That's great, but does it contact the server? If so, how does it behave when a domain
user installs cygwin while not connected to the domain server? That case generated
complaints in the past.
I also noticed that the new mkpasswd -c does not put a guess about the full user name
in the comment field
old -c:
p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
new -c
p-humblet:unused:11068:11031: U-W... <== no p-humblet
{old,new} -d
p-humblet:unused:11068:11031:Pierre Humblet,U-W...
Pierre
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
2008-07-28 15:27 ` Corinna Vinschen
2008-07-28 16:34 ` base-[files|password] for 1.7 John Morrison
2008-07-28 18:56 ` Pierre A. Humblet
@ 2008-07-28 19:00 ` Christopher Faylor
2008-07-29 11:37 ` Eric Blake
3 siblings, 0 replies; 69+ messages in thread
From: Christopher Faylor @ 2008-07-28 19:00 UTC (permalink / raw)
To: cygwin-apps
On Mon, Jul 28, 2008 at 05:27:50PM +0200, Corinna Vinschen wrote:
>On Jul 28 15:51, John Morrison wrote:
>> On Tue, July 22, 2008 6:42 pm, Corinna Vinschen wrote:
>> > You can now call mkpasswd and mkgroup without any -l or -d parameter
>> > and both tools choose by themselves what information to print, depending
>> > on the machine being a domain member machine or not.
>> >
>> > This should result in a matching change to the base-passwd package for
>> > 1.7. The /etc/postinstall/passwd-grp.sh script should call both tools
>> > without any parameter.
>> >
>> > Could you please change that for us, John?
>>
>> Ok, changed base-password/etc/postinstall/passwd-grp.sh to remove the
>> parameters when calling mkpasswd and mkgroup. I've left the rest of the
>> script the same; that's OK?
>
>Yep, that's ok.
>
>> Do we still want the base-files profile to have the message wrt group
>> names of mkpassword/mkgroup/mkgroup_l_d?
>
>Hmm, well, it doesn't hurt a lot, right? Using the new mkpasswd and
>mkgroup will probably reduce printing this message a lot, if not
>entirely.
>
>> Are there any other changes wanted? For example, I think a comment about
>> MAKE_MODE=Unix came up on the lists a few months ago... Now's a good time
>> to alter anything.
>
>Is that MAKE_MODE thingy supported at all in latest make? If so,
>isn't MAKE_MODE=unix default anyway?
MAKE_MODE hasn't been supported in make since 2006.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-28 16:34 ` base-[files|password] for 1.7 John Morrison
@ 2008-07-29 9:32 ` Corinna Vinschen
2008-07-29 11:50 ` Eric Blake
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-29 9:32 UTC (permalink / raw)
To: cygwin-apps
On Jul 28 17:33, John Morrison wrote:
> On Mon, July 28, 2008 4:27 pm, Corinna Vinschen wrote:
> > On Jul 28 15:51, John Morrison wrote:
> >> Corinna; you use the tcsh shell don't you (I seem to
> >> recall)? Are there any profile defaults we should put in for it?
> >
> > Yes, I'm using tcsh, but your scripts don't have to care for them
> > since everything's already done in csh.login and csh.cshrc. Including
> > setting MAKE_MODE=unix :)
>
> Ok. So the tcsh script includes csh.cshrc? Should the bash package
> include the bash.bashrc?
I don't think so. Eric?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-28 18:56 ` Pierre A. Humblet
@ 2008-07-29 9:45 ` Corinna Vinschen
2008-07-29 14:35 ` Pierre A. Humblet
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-29 9:45 UTC (permalink / raw)
To: cygwin-apps
On Jul 28 14:55, Pierre A. Humblet wrote:
> Looks like without argument the new mk{passwd/group} will dump the entire
> passwd/group from the domain server. Some companies have tens of thousands
> of names and that's why they weren't called with -l -d by default but with -l -c
>
> The -c switch would only create an entry for the current user or the current primary group
> WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
> using only local info but mkgroup could not find the group name, so it was
> calling it "mkgroup-l-d" .
I thought it's a good idea to have the domain by default. It's a bit
strange that a machine is running in a domain but as soon as another
user logs in, the passwd and possibly group information for this user
is missing.
Even if we drop back to using mkpasswd -l -c, I don't think it makes
sense to run mkgroup in a domain environment without fetching all
domain groups.
> The new mkgroup also has a -c option, which gets the current primary
> group name. That's great, but does it contact the server? If so, how
No. The -c options only open the user token and fetch the name
information from a call to LookupAccountName(NULL, ...). Since the
user information for the current user is cached on the local machine,
there's no server access.
> does it behave when a domain user installs cygwin while not connected
> to the domain server? That case generated complaints in the past.
Not for -c, but in the default case it will take some time until it
times out and won't print the domain groups. Since that's only an
actual issue at installation time, where's the problem?
> I also noticed that the new mkpasswd -c does not put a guess about the full user name
> in the comment field
> old -c:
> p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
> new -c
> p-humblet:unused:11068:11031: U-W... <== no p-humblet
> {old,new} -d
> p-humblet:unused:11068:11031:Pierre Humblet,U-W...
Why do you need that? I was contemplating the idea to drop this
entirely. I even contemplated the idea to remove the U-domain\user
entry from pw_gecos, plus the extra functionality in the
extract_nt_dom_user function in sec_auth.cc. I rearranged it to use
the SID from the passwd entry and to call LookupAccountSid first.
In theory there's no good reason to use that U-domain\user entry at all.
Extracting this information from the SID only makes much more sense,
IMHO.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
2008-07-28 15:27 ` Corinna Vinschen
` (2 preceding siblings ...)
2008-07-28 19:00 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) Christopher Faylor
@ 2008-07-29 11:37 ` Eric Blake
2008-07-29 11:56 ` John Morrison
3 siblings, 1 reply; 69+ messages in thread
From: Eric Blake @ 2008-07-29 11:37 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Corinna Vinschen on 7/28/2008 9:27 AM:
|> # check the window size after each command and, if necessary,
|> # update the values of LINES and COLUMNS.
|> shopt -s checkwinsize
|>
|> would it work in cygwin? Also;
|
| Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric?
Hmm. Right now, bash _does_ set LINES and COLUMNS (as shell variables,
you have to export them for children to see), but only after the first
SIGWINCH, or if you have 'shopt -s checkwinsize', after the first
non-builtin-command (ie. if checkwinsize is set, bash does not check
window size after builtins - how weird is that?). At any rate, I already
have a cygwin-specific patch for the upstream bug that lib/sh/winsize.c
forgot to include <termios.h>. And blindly setting checkwinsize seems
like it would slow things down: since SIGWINCH works (I tested in both cmd
and urxvt), there is no need to slow down bash to check window size after
every single command, when only window size changes are necessary.
checkwinsize is primarily for those platforms that lack SIGWINCH.
At any rate, you've given me an idea. Add this to /etc/profile, and
$LINES and $COLUMNS will be automatically populated for all users,
regardless of whether they use 'shopt -s checkwinsize':
kill -s WINCH $$
- --
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
iEYEARECAAYFAkiPAOsACgkQ84KuGfSFAYB4+wCgnKRhiE1P6r/mKrOeR0BabG2n
LjsAnR6CQyVTjw6huQBbHXU8qn4GvNyX
=yxl6
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 9:32 ` Corinna Vinschen
@ 2008-07-29 11:50 ` Eric Blake
0 siblings, 0 replies; 69+ messages in thread
From: Eric Blake @ 2008-07-29 11:50 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Corinna Vinschen on 7/29/2008 3:33 AM:
|> Ok. So the tcsh script includes csh.cshrc? Should the bash package
|> include the bash.bashrc?
|
| I don't think so. Eric?
Right now, cygwin's /etc/bash.bashrc is a no-op. I'm not sure what users
would like to see in a bash-specific startup file. Also, upstream bash
does not automatically source /etc/bash.bashrc (or, as I've seen on some
Linux systems, /etc/bashrc); that would take a bash patch or an explicit
source command from within /etc/profile. I don't mind taking ownership of
bash.bashrc, if you'd like me to do so, but what should I put in it? It
seems easier to me to leave it as part of base-files, since it already
requires coordination with /etc/profile.
- --
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
iEYEARECAAYFAkiPBAkACgkQ84KuGfSFAYDuawCfQlroINtRLBB7xsceCX+YvJOb
T78AoLv617JMXLDx47QhAPaO9cIhbG5G
=+VC6
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)))
2008-07-29 11:37 ` Eric Blake
@ 2008-07-29 11:56 ` John Morrison
2008-07-29 12:01 ` base-[files|password] for 1.7 Eric Blake
0 siblings, 1 reply; 69+ messages in thread
From: John Morrison @ 2008-07-29 11:56 UTC (permalink / raw)
To: cygwin-apps
On Tue, July 29, 2008 12:37 pm, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Corinna Vinschen on 7/28/2008 9:27 AM:
> |> # check the window size after each command and, if necessary,
> |> # update the values of LINES and COLUMNS.
> |> shopt -s checkwinsize
> |>
> |> would it work in cygwin? Also;
> |
> | Looks like bash on Cygwin doesn't set LINES and COLUMNS. Eric?
>
> Hmm. Right now, bash _does_ set LINES and COLUMNS (as shell variables,
> you have to export them for children to see), but only after the first
> SIGWINCH, or if you have 'shopt -s checkwinsize', after the first
> non-builtin-command (ie. if checkwinsize is set, bash does not check
> window size after builtins - how weird is that?). At any rate, I already
> have a cygwin-specific patch for the upstream bug that lib/sh/winsize.c
> forgot to include <termios.h>. And blindly setting checkwinsize seems
> like it would slow things down: since SIGWINCH works (I tested in both cmd
> and urxvt), there is no need to slow down bash to check window size after
> every single command, when only window size changes are necessary.
> checkwinsize is primarily for those platforms that lack SIGWINCH.
>
> At any rate, you've given me an idea. Add this to /etc/profile, and
> $LINES and $COLUMNS will be automatically populated for all users,
> regardless of whether they use 'shopt -s checkwinsize':
>
> kill -s WINCH $$
Hi Eric,
So, let me get this straight, you _don't_ want/need me to add the shopt
but you would like me to add the kill instruction?
J.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 11:56 ` John Morrison
@ 2008-07-29 12:01 ` Eric Blake
2008-07-29 12:28 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Eric Blake @ 2008-07-29 12:01 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to John Morrison on 7/29/2008 5:56 AM:
|> At any rate, you've given me an idea. Add this to /etc/profile, and
|> $LINES and $COLUMNS will be automatically populated for all users,
|> regardless of whether they use 'shopt -s checkwinsize':
|>
|> kill -s WINCH $$
|
| Hi Eric,
|
| So, let me get this straight, you _don't_ want/need me to add the shopt
| but you would like me to add the kill instruction?
Correct, the kill instruction is more efficient than the shopt - there is
no reason to poll for window changes after every command if the interrupt
for window changes works.
- --
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
iEYEARECAAYFAkiPBpcACgkQ84KuGfSFAYDqsQCg1NOdOC6i0nB16GMhSIqzcLWV
MC0AoMLD7TMrxjYn9E5Hwrt4Q3lObWEZ
=S+Vp
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 12:01 ` base-[files|password] for 1.7 Eric Blake
@ 2008-07-29 12:28 ` Corinna Vinschen
2008-07-29 14:31 ` Christopher Faylor
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-29 12:28 UTC (permalink / raw)
To: cygwin-apps
On Jul 29 06:01, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to John Morrison on 7/29/2008 5:56 AM:
> |> At any rate, you've given me an idea. Add this to /etc/profile, and
> |> $LINES and $COLUMNS will be automatically populated for all users,
> |> regardless of whether they use 'shopt -s checkwinsize':
> |>
> |> kill -s WINCH $$
> |
> | Hi Eric,
> |
> | So, let me get this straight, you _don't_ want/need me to add the shopt
> | but you would like me to add the kill instruction?
>
> Correct, the kill instruction is more efficient than the shopt - there is
> no reason to poll for window changes after every command if the interrupt
> for window changes works.
I think it doesn't work for console windows. There's no automatic
message when the console window size changes. There is some code
in Cygwin's console code (fhandler_console::send_winch_maybe), but
it only works when a console event is generated. And then it isn't
called on key events. For testing I added the call to the key event
so that the window size change is at least advertised when the next
key is pressed.
Chris, is there any good reason NOT to call send_winch_maybe on
a key event?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 12:28 ` Corinna Vinschen
@ 2008-07-29 14:31 ` Christopher Faylor
2008-07-29 14:56 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Christopher Faylor @ 2008-07-29 14:31 UTC (permalink / raw)
To: cygwin-apps
On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>On Jul 29 06:01, Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> According to John Morrison on 7/29/2008 5:56 AM:
>> |> At any rate, you've given me an idea. Add this to /etc/profile, and
>> |> $LINES and $COLUMNS will be automatically populated for all users,
>> |> regardless of whether they use 'shopt -s checkwinsize':
>> |>
>> |> kill -s WINCH $$
>> |
>> | Hi Eric,
>> |
>> | So, let me get this straight, you _don't_ want/need me to add the shopt
>> | but you would like me to add the kill instruction?
>>
>> Correct, the kill instruction is more efficient than the shopt - there is
>> no reason to poll for window changes after every command if the interrupt
>> for window changes works.
>
>I think it doesn't work for console windows. There's no automatic
>message when the console window size changes. There is some code
>in Cygwin's console code (fhandler_console::send_winch_maybe), but
>it only works when a console event is generated. And then it isn't
>called on key events. For testing I added the call to the key event
>so that the window size change is at least advertised when the next
>key is pressed.
>
>Chris, is there any good reason NOT to call send_winch_maybe on
>a key event?
It only makes sense when there is a mouse event. It would make more
sense to move the handling of SIGWINCH into the signal handler so that
the above works transparently. I'll look into doing that.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 9:45 ` Corinna Vinschen
@ 2008-07-29 14:35 ` Pierre A. Humblet
2008-07-29 14:53 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Pierre A. Humblet @ 2008-07-29 14:35 UTC (permalink / raw)
To: cygwin-apps
----- Original Message -----
From: "Corinna Vinschen"
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 5:46 AM
Subject: Re: base-[files|password] for 1.7
| On Jul 28 14:55, Pierre A. Humblet wrote:
| > Looks like without argument the new mk{passwd/group} will dump the entire
| > passwd/group from the domain server. Some companies have tens of thousands
| > of names and that's why they weren't called with -l -d by default but with -l -c
| >
| > The -c switch would only create an entry for the current user or the current primary group
| > WITHOUT contacting the domain server. mkpasswd could do a good job for passwd
| > using only local info but mkgroup could not find the group name, so it was
| > calling it "mkgroup-l-d" .
|
| I thought it's a good idea to have the domain by default. It's a bit
| strange that a machine is running in a domain but as soon as another
| user logs in, the passwd and possibly group information for this user
| is missing.
Well yes, I don't recall what the complaints were about.
Perhaps long delays.
But it caused problems to NEW cygwin users installing for the first
time and without visibility or knowledge into what's happening.
| Even if we drop back to using mkpasswd -l -c, I don't think it makes
| sense to run mkgroup in a domain environment without fetching all
| domain groups.
Agreed, but it's done under user control.
| > The new mkgroup also has a -c option, which gets the current primary
| > group name. That's great, but does it contact the server? If so, how
|
| No. The -c options only open the user token and fetch the name
| information from a call to LookupAccountName(NULL, ...). Since the
| user information for the current user is cached on the local machine,
| there's no server access.
Great. I am surprised we didn't do that before if it worked then.
| > does it behave when a domain user installs cygwin while not connected
| > to the domain server? That case generated complaints in the past.
|
| Not for -c, but in the default case it will take some time until it
| times out and won't print the domain groups. Since that's only an
| actual issue at installation time, where's the problem?
Not sure what the old complaints were about...
Do you expect the user and primary group to be put in passwd/group in that case?
| > I also noticed that the new mkpasswd -c does not put a guess about the full user name
| > in the comment field
| > old -c:
| > p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
| > new -c
| > p-humblet:unused:11068:11031: U-W... <== no p-humblet
| > {old,new} -d
| > p-humblet:unused:11068:11031:Pierre Humblet,U-W...
|
| Why do you need that?
No idea why it was done like that in the first place :)
Does it work for domain users in absence of a server?
Pierre
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 14:35 ` Pierre A. Humblet
@ 2008-07-29 14:53 ` Corinna Vinschen
2008-07-29 16:24 ` Pierre A. Humblet
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-29 14:53 UTC (permalink / raw)
To: cygwin-apps
On Jul 29 10:35, Pierre A. Humblet wrote:
> From: "Corinna Vinschen"
> | I thought it's a good idea to have the domain by default. It's a bit
> | strange that a machine is running in a domain but as soon as another
> | user logs in, the passwd and possibly group information for this user
> | is missing.
>
> Well yes, I don't recall what the complaints were about.
> Perhaps long delays.
> But it caused problems to NEW cygwin users installing for the first
> time and without visibility or knowledge into what's happening.
That would have required a decision when to call mkpasswd -d in the
postinstall script. I don't recall that we ever did that.
> | I don't think it makes
> | sense to run mkgroup in a domain environment without fetching all
> | domain groups.
>
> Agreed, but it's done under user control.
Just so that the group file doesn't get too big?
> | Not for -c, but in the default case it will take some time until it
> | times out and won't print the domain groups. Since that's only an
> | actual issue at installation time, where's the problem?
>
> Not sure what the old complaints were about...
> Do you expect the user and primary group to be put in passwd/group in that case?
I'm not sure I understand the question. If we run mkpasswd/mkgroup
without arguments, you get local accounts on a non-domain machine
and domain accounts on a domain member machine. Doesn't that make
the most sense?
> | > I also noticed that the new mkpasswd -c does not put a guess about the full user name
> | > in the comment field
> | > old -c:
> | > p-humblet:unused_by_nt/2000/xp:11068:11031:p-humblet,U-W...
> | > new -c
> | > p-humblet:unused:11068:11031: U-W... <== no p-humblet
> | > {old,new} -d
> | > p-humblet:unused:11068:11031:Pierre Humblet,U-W...
> |
> | Why do you need that?
>
> No idea why it was done like that in the first place :)
> Does it work for domain users in absence of a server?
No. This information is only available from NetUserEnum/NetUserGetInfo
calls and those require DC access.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 14:31 ` Christopher Faylor
@ 2008-07-29 14:56 ` Corinna Vinschen
2008-07-29 16:18 ` John Morrison
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-29 14:56 UTC (permalink / raw)
To: cygwin-apps
On Jul 29 10:31, Christopher Faylor wrote:
> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
> >Chris, is there any good reason NOT to call send_winch_maybe on
> >a key event?
>
> It only makes sense when there is a mouse event.
I don't understand that. Mouse events typically don't happen. I can
use the mouse as much as I want in a console window running vim, vim
never gets the SIGWINCH.
> It would make more
> sense to move the handling of SIGWINCH into the signal handler so that
> the above works transparently. I'll look into doing that.
That would be a nice addition.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 14:56 ` Corinna Vinschen
@ 2008-07-29 16:18 ` John Morrison
2008-07-29 18:00 ` Christopher Faylor
0 siblings, 1 reply; 69+ messages in thread
From: John Morrison @ 2008-07-29 16:18 UTC (permalink / raw)
To: cygwin-apps
On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
> On Jul 29 10:31, Christopher Faylor wrote:
>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>> >Chris, is there any good reason NOT to call send_winch_maybe on
>> >a key event?
>>
>> It only makes sense when there is a mouse event.
>
> I don't understand that. Mouse events typically don't happen. I can
> use the mouse as much as I want in a console window running vim, vim
> never gets the SIGWINCH.
>
>> It would make more
>> sense to move the handling of SIGWINCH into the signal handler so that
>> the above works transparently. I'll look into doing that.
>
> That would be a nice addition.
So I don't need to add anything to /etc/profile?
J.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 14:53 ` Corinna Vinschen
@ 2008-07-29 16:24 ` Pierre A. Humblet
2008-07-29 22:22 ` Pierre A. Humblet
0 siblings, 1 reply; 69+ messages in thread
From: Pierre A. Humblet @ 2008-07-29 16:24 UTC (permalink / raw)
To: cygwin-apps
----- Original Message -----
From: "Corinna Vinschen" <>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 10:54 AM
Subject: Re: base-[files|password] for 1.7
| On Jul 29 10:35, Pierre A. Humblet wrote:
| > From: "Corinna Vinschen"
| > | I thought it's a good idea to have the domain by default. It's a bit
| > | strange that a machine is running in a domain but as soon as another
| > | user logs in, the passwd and possibly group information for this user
| > | is missing.
| >
| > Well yes, I don't recall what the complaints were about.
| > Perhaps long delays.
| > But it caused problems to NEW cygwin users installing for the first
| > time and without visibility or knowledge into what's happening.
|
| That would have required a decision when to call mkpasswd -d in the
| postinstall script. I don't recall that we ever did that.
I don't recall the specifics but it would have been a lot easier to use
-d rather than to create a -c . There must have been a good reason.
| > | I don't think it makes
| > | sense to run mkgroup in a domain environment without fetching all
| > | domain groups.
| >
| > Agreed, but it's done under user control.
|
| Just so that the group file doesn't get too big?
No, so that the user can ctrl-c if it takes forever.
| > | Not for -c, but in the default case it will take some time until it
| > | times out and won't print the domain groups. Since that's only an
| > | actual issue at installation time, where's the problem?
| >
| > Not sure what the old complaints were about...
| > Do you expect the user and primary group to be put in passwd/group in that case?
|
| I'm not sure I understand the question. If we run mkpasswd/mkgroup
| without arguments, you get local accounts on a non-domain machine
| and domain accounts on a domain member machine. Doesn't that make
| the most sense?
It does make the most sense if all goes well and quickly.
But if the server is not connected the passwd/group entries for the domain
user installing cygwin for the first time may not be created.
Pierre
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 16:18 ` John Morrison
@ 2008-07-29 18:00 ` Christopher Faylor
2008-07-30 1:39 ` Christopher Faylor
0 siblings, 1 reply; 69+ messages in thread
From: Christopher Faylor @ 2008-07-29 18:00 UTC (permalink / raw)
To: cygwin-apps
On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>> On Jul 29 10:31, Christopher Faylor wrote:
>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>>> >a key event?
>>>
>>> It only makes sense when there is a mouse event.
>>
>> I don't understand that. Mouse events typically don't happen. I can
>> use the mouse as much as I want in a console window running vim, vim
>> never gets the SIGWINCH.
>>
>>> It would make more
>>> sense to move the handling of SIGWINCH into the signal handler so that
>>> the above works transparently. I'll look into doing that.
>>
>> That would be a nice addition.
>
>So I don't need to add anything to /etc/profile?
Adding the kill -WINCH still makes sense. It will at least get things
working for xterm and rxvt.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 16:24 ` Pierre A. Humblet
@ 2008-07-29 22:22 ` Pierre A. Humblet
2008-07-30 9:14 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Pierre A. Humblet @ 2008-07-29 22:22 UTC (permalink / raw)
To: cygwin-apps
----- Original Message -----
From: "Pierre A. Humblet" <>
To: <cygwin-apps@cygwin.com>
Sent: Tuesday, July 29, 2008 12:24 PM
| ----- Original Message -----
| From: "Corinna Vinschen" <>
| To: <cygwin-apps@cygwin.com>
| Sent: Tuesday, July 29, 2008 10:54 AM
| || On Jul 29 10:35, Pierre A. Humblet wrote:
|| > From: "Corinna Vinschen"
|| > | I thought it's a good idea to have the domain by default. It's a bit
|| > | strange that a machine is running in a domain but as soon as another
|| > | user logs in, the passwd and possibly group information for this user
|| > | is missing.
|| >
|| > Well yes, I don't recall what the complaints were about.
|| > Perhaps long delays.
|| > But it caused problems to NEW cygwin users installing for the first
|| > time and without visibility or knowledge into what's happening.
||
|| That would have required a decision when to call mkpasswd -d in the
|| postinstall script. I don't recall that we ever did that.
|
| I don't recall the specifics but it would have been a lot easier to use
| -d rather than to create a -c . There must have been a good reason.
I searched the list, there are tons of mails about mkpasswd, most from the
turn of the millennium, AFAICS. Here are two interesting ones:
http://www.cygwin.com/ml/cygwin/2001-10/msg01413.html
http://cygwin.com/ml/cygwin/2002-09/msg00663.html
The first one may well have been the trigger to have a -c switch.
The second gives you an example of what can happen, and this is not
acceptable under setup.
Pierre
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 18:00 ` Christopher Faylor
@ 2008-07-30 1:39 ` Christopher Faylor
2008-07-30 9:22 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Christopher Faylor @ 2008-07-30 1:39 UTC (permalink / raw)
To: cygwin-apps
On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
>On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>>> On Jul 29 10:31, Christopher Faylor wrote:
>>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>>>> >a key event?
>>>>
>>>> It only makes sense when there is a mouse event.
>>>
>>> I don't understand that. Mouse events typically don't happen. I can
>>> use the mouse as much as I want in a console window running vim, vim
>>> never gets the SIGWINCH.
>>>
>>>> It would make more
>>>> sense to move the handling of SIGWINCH into the signal handler so that
>>>> the above works transparently. I'll look into doing that.
>>>
>>> That would be a nice addition.
>>
>>So I don't need to add anything to /etc/profile?
>
>Adding the kill -WINCH still makes sense. It will at least get things
>working for xterm and rxvt.
Ok. I'm confused. If I perform a "kill -SIGWINCH <pid>" on a bash
which is opened in a console window, the right number of lines shows up.
They also show up when you change the size of the window.
So it seems like this is working correctly without any Cygwin
modifications.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-29 22:22 ` Pierre A. Humblet
@ 2008-07-30 9:14 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-30 9:14 UTC (permalink / raw)
To: cygwin-apps
On Jul 29 18:21, Pierre A. Humblet wrote:
> From: "Pierre A. Humblet" <>
> | From: "Corinna Vinschen" <>
> || That would have required a decision when to call mkpasswd -d in the
> || postinstall script. I don't recall that we ever did that.
> |
> | I don't recall the specifics but it would have been a lot easier to use
> | -d rather than to create a -c . There must have been a good reason.
>
> I searched the list, there are tons of mails about mkpasswd, most from the
> turn of the millennium, AFAICS. Here are two interesting ones:
> http://www.cygwin.com/ml/cygwin/2001-10/msg01413.html
> http://cygwin.com/ml/cygwin/2002-09/msg00663.html
> The first one may well have been the trigger to have a -c switch.
> The second gives you an example of what can happen, and this is not
> acceptable under setup.
John, scratch it. Back to -l -c. No change to base-passwd. And I
really thought that this change would be helpful. Bleah.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-30 1:39 ` Christopher Faylor
@ 2008-07-30 9:22 ` Corinna Vinschen
2008-07-30 15:20 ` Christopher Faylor
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-30 9:22 UTC (permalink / raw)
To: cygwin-apps
On Jul 29 21:39, Christopher Faylor wrote:
> On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
> >On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
> >>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
> >>> On Jul 29 10:31, Christopher Faylor wrote:
> >>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
> >>>> >Chris, is there any good reason NOT to call send_winch_maybe on
> >>>> >a key event?
> >>>>
> >>>> It only makes sense when there is a mouse event.
> >>>
> >>> I don't understand that. Mouse events typically don't happen. I can
> >>> use the mouse as much as I want in a console window running vim, vim
> >>> never gets the SIGWINCH.
> >>>
> >>>> It would make more
> >>>> sense to move the handling of SIGWINCH into the signal handler so that
> >>>> the above works transparently. I'll look into doing that.
> >>>
> >>> That would be a nice addition.
> >>
> >>So I don't need to add anything to /etc/profile?
> >
> >Adding the kill -WINCH still makes sense. It will at least get things
> >working for xterm and rxvt.
>
> Ok. I'm confused. If I perform a "kill -SIGWINCH <pid>" on a bash
> which is opened in a console window, the right number of lines shows up.
> They also show up when you change the size of the window.
>
> So it seems like this is working correctly without any Cygwin
> modifications.
Doesn't work for me. kill -WINCH $$ creates the LINES and COLUMNS
values, but any later windows resize doesn't change the values. And as
mentioned before it also doesn't work in vim. Adding send_winch_maybe()
to the KEY_EVENT at least changes it at the next keypress. And there's
no such thing as a mouse event, whatever I do with the mouse.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-30 9:22 ` Corinna Vinschen
@ 2008-07-30 15:20 ` Christopher Faylor
2008-07-30 17:39 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Christopher Faylor @ 2008-07-30 15:20 UTC (permalink / raw)
To: cygwin-apps
On Wed, Jul 30, 2008 at 11:23:10AM +0200, Corinna Vinschen wrote:
>On Jul 29 21:39, Christopher Faylor wrote:
>> On Tue, Jul 29, 2008 at 01:59:54PM -0400, Christopher Faylor wrote:
>> >On Tue, Jul 29, 2008 at 05:18:32PM +0100, John Morrison wrote:
>> >>On Tue, July 29, 2008 3:57 pm, Corinna Vinschen wrote:
>> >>> On Jul 29 10:31, Christopher Faylor wrote:
>> >>>> On Tue, Jul 29, 2008 at 02:29:19PM +0200, Corinna Vinschen wrote:
>> >>>> >Chris, is there any good reason NOT to call send_winch_maybe on
>> >>>> >a key event?
>> >>>>
>> >>>> It only makes sense when there is a mouse event.
>> >>>
>> >>> I don't understand that. Mouse events typically don't happen. I can
>> >>> use the mouse as much as I want in a console window running vim, vim
>> >>> never gets the SIGWINCH.
>> >>>
>> >>>> It would make more
>> >>>> sense to move the handling of SIGWINCH into the signal handler so that
>> >>>> the above works transparently. I'll look into doing that.
>> >>>
>> >>> That would be a nice addition.
>> >>
>> >>So I don't need to add anything to /etc/profile?
>> >
>> >Adding the kill -WINCH still makes sense. It will at least get things
>> >working for xterm and rxvt.
>>
>> Ok. I'm confused. If I perform a "kill -SIGWINCH <pid>" on a bash
>> which is opened in a console window, the right number of lines shows up.
>> They also show up when you change the size of the window.
>>
>> So it seems like this is working correctly without any Cygwin
>> modifications.
>
>Doesn't work for me. kill -WINCH $$ creates the LINES and COLUMNS
>values, but any later windows resize doesn't change the values. And as
>mentioned before it also doesn't work in vim. Adding send_winch_maybe()
>to the KEY_EVENT at least changes it at the next keypress. And there's
>no such thing as a mouse event, whatever I do with the mouse.
L:\Documents and Settings\cgf>bash
bash-3.2$ echo $LINES
bash-3.2$ echo $LINES # make window bigger
42
bash-3.2$ echo $LINES # make window even bigger
56
(also checked with a 4NT console)
Putting a "kill -WINCH $$" in my /home/cgf/.profile file causes LINES to
be set initially when I use "bash -login".
In my version of vim the screen size *does* change after every keypress
just like it always did. I checked this with vim when I implemented it.
If this isn't working for you then fixing the symptom by checking on
every keystroke, slowing down the already slow input processing even
further, is not the correct first solution for handling the problem.
Cygwin does this:
SetConsoleMode (get_io_handle (), ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT);
If you are saying that this is broken in Windows or that it isn't being
properly set in Cygwin then that's what needs to be fixed. Maybe
checking the screen size on every keystroke is the way to do it but,
since everything is working as I designed it for me, I am not yet
convinced.
cgf
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: base-[files|password] for 1.7
2008-07-30 15:20 ` Christopher Faylor
@ 2008-07-30 17:39 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-30 17:39 UTC (permalink / raw)
To: cygwin-apps
On Jul 30 11:20, Christopher Faylor wrote:
> On Wed, Jul 30, 2008 at 11:23:10AM +0200, Corinna Vinschen wrote:
> >On Jul 29 21:39, Christopher Faylor wrote:
> >> Ok. I'm confused. If I perform a "kill -SIGWINCH <pid>" on a bash
> >> which is opened in a console window, the right number of lines shows up.
> >> They also show up when you change the size of the window.
> >>
> >> So it seems like this is working correctly without any Cygwin
> >> modifications.
> >
> >Doesn't work for me. kill -WINCH $$ creates the LINES and COLUMNS
> >values, but any later windows resize doesn't change the values. And as
> >mentioned before it also doesn't work in vim. Adding send_winch_maybe()
> >to the KEY_EVENT at least changes it at the next keypress. And there's
> >no such thing as a mouse event, whatever I do with the mouse.
>
> L:\Documents and Settings\cgf>bash
> bash-3.2$ echo $LINES
>
> bash-3.2$ echo $LINES # make window bigger
> 42
> bash-3.2$ echo $LINES # make window even bigger
> 56
>
> (also checked with a 4NT console)
In a standard console window on Windows 2008 (but the OS doesn't matter):
$ echo $LINES
$ echo $LINES # make windows smaller
$ echo $LINES # make windows bigger
$ kill -WINCH $$; echo $LINES
54
$ echo $LINES # make windows smaller
54
> Putting a "kill -WINCH $$" in my /home/cgf/.profile file causes LINES to
> be set initially when I use "bash -login".
>
> In my version of vim the screen size *does* change after every keypress
> just like it always did. I checked this with vim when I implemented it.
It never worked right for me in a console window.
> If this isn't working for you then fixing the symptom by checking on
> every keystroke, slowing down the already slow input processing even
> further, is not the correct first solution for handling the problem.
I didn't claim that. I just mentioned that to point out the difference.
> SetConsoleMode (get_io_handle (), ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT);
I know. I have no idea what could be different between your and my
setup, though.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
` (4 preceding siblings ...)
2008-07-21 23:42 ` New Cygwin 1.7.0-18 in release-2 Yaakov (Cygwin Ports)
@ 2008-07-31 6:57 ` Yaakov (Cygwin Ports)
2008-07-31 7:39 ` Corinna Vinschen
5 siblings, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-31 6:57 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| - 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.
But does/will setup.exe know what to do with a package containing such
filenames?
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiRYjsACgkQpiWmPGlmQSMcnwCg3q2JpXIOpDUhFBF9cs4vOfwN
U88Ani5WrUfBySOpEM76hzNuEqnUdQLo
=/Sml
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 6:57 ` Yaakov (Cygwin Ports)
@ 2008-07-31 7:39 ` Corinna Vinschen
2008-07-31 8:28 ` Yaakov (Cygwin Ports)
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 7:39 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 01:56, Yaakov (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> | - 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.
>
> But does/will setup.exe know what to do with a package containing such
> filenames?
setup is a Win32 application. It won't know about this. Thou shalt
not create packages which rely on case-sensitivity as part of the
net distro.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 7:39 ` Corinna Vinschen
@ 2008-07-31 8:28 ` Yaakov (Cygwin Ports)
2008-07-31 11:44 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-31 8:28 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| setup is a Win32 application. It won't know about this. Thou shalt
| not create packages which rely on case-sensitivity as part of the
| net distro.
That's what I thought. So while managed mounts will no longer be needed
for building, something still needs to be done for the packaging stage.
So far my idea is to adapt cygport's make_managed_mount[1], but remove
the mount/umount commands. I should also add a postinstall check to
make sure illegal filenames aren't being installed without special handling.
[1]
http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/cygport/bin/make_managed_mount
Any other ideas?
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiRd50ACgkQpiWmPGlmQSPb/QCgxaNwHBXFaHGxYx4VsvIpUDqy
mMIAn09jTDYpN3CiTnEoL13Rf4yKOw7n
=Bpi4
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 8:28 ` Yaakov (Cygwin Ports)
@ 2008-07-31 11:44 ` Corinna Vinschen
2008-07-31 13:00 ` Charles Wilson
2008-07-31 15:06 ` Yaakov (Cygwin Ports)
0 siblings, 2 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 11:44 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 03:28, Yaakov (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> | setup is a Win32 application. It won't know about this. Thou shalt
> | not create packages which rely on case-sensitivity as part of the
> | net distro.
>
> That's what I thought. So while managed mounts will no longer be needed
> for building, something still needs to be done for the packaging stage.
>
> So far my idea is to adapt cygport's make_managed_mount[1], but remove
> the mount/umount commands. I should also add a postinstall check to
> make sure illegal filenames aren't being installed without special
> handling.
Illegal? The only illegal chars are slash and backslash, even on
case-insensitive mounts. Does it really occur often that you have two
filenames in the same dir only differing by case?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 11:44 ` Corinna Vinschen
@ 2008-07-31 13:00 ` Charles Wilson
2008-07-31 13:23 ` Corinna Vinschen
2008-07-31 15:06 ` Yaakov (Cygwin Ports)
1 sibling, 1 reply; 69+ messages in thread
From: Charles Wilson @ 2008-07-31 13:00 UTC (permalink / raw)
To: CygWin-Apps
Corinna Vinschen wrote:
> Illegal? The only illegal chars are slash and backslash, even on
> case-insensitive mounts. Does it really occur often that you have two
> filenames in the same dir only differing by case?
I'd imagine aux and prn are still "illegal", right? The numbers are
fewer, these days, but there are still source packages out there that
have 'aux/' subdirectories.
--
Chuck
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 13:00 ` Charles Wilson
@ 2008-07-31 13:23 ` Corinna Vinschen
2008-07-31 13:31 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 13:23 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 08:59, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
>> Illegal? The only illegal chars are slash and backslash, even on
>> case-insensitive mounts. Does it really occur often that you have two
>> filenames in the same dir only differing by case?
>
> I'd imagine aux and prn are still "illegal", right? The numbers are fewer,
> these days, but there are still source packages out there that have 'aux/'
> subdirectories.
No. Aux is fine now. As is nul, prn, com, ...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 13:23 ` Corinna Vinschen
@ 2008-07-31 13:31 ` Corinna Vinschen
2008-07-31 14:10 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 13:31 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 15:23, Corinna Vinschen wrote:
> On Jul 31 08:59, Charles Wilson wrote:
> > Corinna Vinschen wrote:
> >
> >> Illegal? The only illegal chars are slash and backslash, even on
> >> case-insensitive mounts. Does it really occur often that you have two
> >> filenames in the same dir only differing by case?
> >
> > I'd imagine aux and prn are still "illegal", right? The numbers are fewer,
> > these days, but there are still source packages out there that have 'aux/'
> > subdirectories.
>
> No. Aux is fine now. As is nul, prn, com, ...
Btw., the list of changes attached to my original mail starting this
thread http://cygwin.com/ml/cygwin-apps/2008-07/msg00060.html
already mentioned that. This is one result of using NT functions
exclusively for file access.
What still won't work, though is to start an application called, for
instance, "aux.exe". The reason is that the CreateProcess call in
spawn/exec is still a Win32 call which will treat this filename as a
DOS device.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 13:31 ` Corinna Vinschen
@ 2008-07-31 14:10 ` Corinna Vinschen
2008-07-31 20:16 ` Corinna Vinschen
0 siblings, 1 reply; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 14:10 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 15:30, Corinna Vinschen wrote:
> On Jul 31 15:23, Corinna Vinschen wrote:
> > On Jul 31 08:59, Charles Wilson wrote:
> > > Corinna Vinschen wrote:
> > >
> > >> Illegal? The only illegal chars are slash and backslash, even on
> > >> case-insensitive mounts. Does it really occur often that you have two
> > >> filenames in the same dir only differing by case?
> > >
> > > I'd imagine aux and prn are still "illegal", right? The numbers are fewer,
> > > these days, but there are still source packages out there that have 'aux/'
> > > subdirectories.
> >
> > No. Aux is fine now. As is nul, prn, com, ...
>
> Btw., the list of changes attached to my original mail starting this
> thread http://cygwin.com/ml/cygwin-apps/2008-07/msg00060.html
> already mentioned that. This is one result of using NT functions
> exclusively for file access.
>
> What still won't work, though is to start an application called, for
> instance, "aux.exe". The reason is that the CreateProcess call in
> spawn/exec is still a Win32 call which will treat this filename as a
> DOS device.
Hang on, I have a workaround for that problem. It works fine when
using the long path prefix \\?\ in the call to CreateProcessW.
Unfortunately I had to add code to remove the \\?\ prefix for paths
which fit into 260 chars to avoid problems with native Win32 apps so
that's kind of a chicken-egg. Hmm, tricky.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 11:44 ` Corinna Vinschen
2008-07-31 13:00 ` Charles Wilson
@ 2008-07-31 15:06 ` Yaakov (Cygwin Ports)
2008-07-31 15:41 ` Corinna Vinschen
1 sibling, 1 reply; 69+ messages in thread
From: Yaakov (Cygwin Ports) @ 2008-07-31 15:06 UTC (permalink / raw)
To: cygwin-apps
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Corinna Vinschen wrote:
| Illegal? The only illegal chars are slash and backslash, even on
| case-insensitive mounts. Does it really occur often that you have two
| filenames in the same dir only differing by case?
For Cygwin I understand that, but you mean to say that *setup* will be
able to install a file with a "*:<>|? (The : is the most common case,
usually within API docs, for obvious reasons.)
If the only thing I have to worry about not installing is
case-insensitive files in the same directory, I know of three cases
(WindowMaker, gnome-chess, and liblouis) among 1650+ sources.
Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkiR1LUACgkQpiWmPGlmQSPuWgCcCpCPoohY/4qxF++DZezCJZtD
cPQAoI0SEFSv21YpVkguB8cgyfKk8jdD
=pzfn
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 15:06 ` Yaakov (Cygwin Ports)
@ 2008-07-31 15:41 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 15:41 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 10:05, Yaakov (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> | Illegal? The only illegal chars are slash and backslash, even on
> | case-insensitive mounts. Does it really occur often that you have two
> | filenames in the same dir only differing by case?
>
> For Cygwin I understand that, but you mean to say that *setup* will be
> able to install a file with a "*:<>|? (The : is the most common case,
> usually within API docs, for obvious reasons.)
Uh oh, you got me there. It shouldn't be ovberly complicated to tweak
the untar code in setup to do the same special char conversion as
Cygwin does, but, as usual, somebody has to do it. Maybe I'll look
into that myself when I'm back in a couple of days.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: New Cygwin 1.7.0-18 in release-2
2008-07-31 14:10 ` Corinna Vinschen
@ 2008-07-31 20:16 ` Corinna Vinschen
0 siblings, 0 replies; 69+ messages in thread
From: Corinna Vinschen @ 2008-07-31 20:16 UTC (permalink / raw)
To: cygwin-apps
On Jul 31 16:10, Corinna Vinschen wrote:
> On Jul 31 15:30, Corinna Vinschen wrote:
> > What still won't work, though is to start an application called, for
> > instance, "aux.exe". The reason is that the CreateProcess call in
> > spawn/exec is still a Win32 call which will treat this filename as a
> > DOS device.
>
> Hang on, I have a workaround for that problem. It works fine when
> using the long path prefix \\?\ in the call to CreateProcessW.
> Unfortunately I had to add code to remove the \\?\ prefix for paths
> which fit into 260 chars to avoid problems with native Win32 apps so
> that's kind of a chicken-egg. Hmm, tricky.
I uploaded 1.7.0-23 to the release-2 area. It fixes the above problem.
Now you can call an application called aux.exe just fine.
Other changes:
- Instead of restricting send/sendto/sendmsg calls to 64K, send data in
64K chunks under the hood to circumvent problem described in KB 201213.
- Reworked tty code to handle inheritance better.
- Remove some ancient code and better never used APIs.
- Constify utmp/login API.
- Fix for file systems which get confused when using NtQueryDirectoryFile
with FileIdBothDirectoryInformation info class (just UNIXFS right now).
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2008-07-31 20:16 UTC | newest]
Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-17 15:53 New Cygwin 1.7.0-18 in release-2 Corinna Vinschen
2008-07-18 0:18 ` Eric Blake
2008-07-18 7:33 ` Corinna Vinschen
2008-07-18 7:53 ` Corinna Vinschen
2008-07-18 8:08 ` Corinna Vinschen
2008-07-18 12:07 ` Corinna Vinschen
2008-07-22 21:19 ` Corinna Vinschen
2008-07-18 16:37 ` Marco Atzeri
2008-07-18 17:08 ` Corinna Vinschen
2008-07-18 17:56 ` Christopher Faylor
2008-07-18 18:18 ` Corinna Vinschen
2008-07-18 23:59 ` Brian Dessent
2008-07-19 10:15 ` Marco Atzeri
2008-07-18 19:29 ` Bill Hoffman
2008-07-19 12:24 ` Corinna Vinschen
2008-07-19 14:16 ` Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2) Corinna Vinschen
2008-07-22 17:42 ` Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2)) Corinna Vinschen
2008-07-25 8:10 ` Corinna Vinschen
2008-07-25 11:00 ` 1.7.0-21 broken Corinna Vinschen
2008-07-25 18:08 ` Corinna Vinschen
2008-07-28 14:52 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) John Morrison
2008-07-28 15:27 ` Corinna Vinschen
2008-07-28 16:34 ` base-[files|password] for 1.7 John Morrison
2008-07-29 9:32 ` Corinna Vinschen
2008-07-29 11:50 ` Eric Blake
2008-07-28 18:56 ` Pierre A. Humblet
2008-07-29 9:45 ` Corinna Vinschen
2008-07-29 14:35 ` Pierre A. Humblet
2008-07-29 14:53 ` Corinna Vinschen
2008-07-29 16:24 ` Pierre A. Humblet
2008-07-29 22:22 ` Pierre A. Humblet
2008-07-30 9:14 ` Corinna Vinschen
2008-07-28 19:00 ` base-[files|password] for 1.7 (was Re: Cygwin 1.7.0-20 (was Re: Cygwin 1.7.0-19 (was Re: New Cygwin 1.7.0-18 in release-2))) Christopher Faylor
2008-07-29 11:37 ` Eric Blake
2008-07-29 11:56 ` John Morrison
2008-07-29 12:01 ` base-[files|password] for 1.7 Eric Blake
2008-07-29 12:28 ` Corinna Vinschen
2008-07-29 14:31 ` Christopher Faylor
2008-07-29 14:56 ` Corinna Vinschen
2008-07-29 16:18 ` John Morrison
2008-07-29 18:00 ` Christopher Faylor
2008-07-30 1:39 ` Christopher Faylor
2008-07-30 9:22 ` Corinna Vinschen
2008-07-30 15:20 ` Christopher Faylor
2008-07-30 17:39 ` Corinna Vinschen
2008-07-21 23:42 ` New Cygwin 1.7.0-18 in release-2 Yaakov (Cygwin Ports)
2008-07-22 9:32 ` Corinna Vinschen
2008-07-23 17:26 ` Yaakov (Cygwin Ports)
2008-07-23 18:00 ` Corinna Vinschen
2008-07-23 20:44 ` John Morrison
2008-07-24 9:08 ` Corinna Vinschen
2008-07-24 9:18 ` John Morrison
2008-07-24 9:26 ` Corinna Vinschen
2008-07-25 10:07 ` Andrew Schulman
2008-07-24 3:45 ` Yaakov (Cygwin Ports)
2008-07-24 9:24 ` Corinna Vinschen
2008-07-24 16:18 ` Yaakov (Cygwin Ports)
2008-07-24 17:46 ` Corinna Vinschen
2008-07-31 6:57 ` Yaakov (Cygwin Ports)
2008-07-31 7:39 ` Corinna Vinschen
2008-07-31 8:28 ` Yaakov (Cygwin Ports)
2008-07-31 11:44 ` Corinna Vinschen
2008-07-31 13:00 ` Charles Wilson
2008-07-31 13:23 ` Corinna Vinschen
2008-07-31 13:31 ` Corinna Vinschen
2008-07-31 14:10 ` Corinna Vinschen
2008-07-31 20:16 ` Corinna Vinschen
2008-07-31 15:06 ` Yaakov (Cygwin Ports)
2008-07-31 15:41 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).