Re: Passwordless sftp with ssh 5.9 still asks for password
Greetings, Warren Young! >> Accept the default >> key location, C:\Documents and Settings\nhuser\.ssh\id_dsa, > Why would that be the default location, if you are using Cygwin tools? > Shouldn't it be something like c:\cygwin\home\nhuser\.ssh\...? Why? > You can change your HOME to anything you like, but that's not the default > with Cygwin. Are you sure? Last time I checked, $HOME in newly installed Cygwin point to the $USERPROFILE Which is, quite, logical. -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2011, <12:34> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Passwordless sftp with ssh 5.9 still asks for password
On Wed, Nov 30, 2011 at 12:17 AM, Warren Young wrote: > On 11/29/2011 2:49 PM, Andrew Erskine wrote: >> >> ssh-keygen -t dsa > > "-t [keytype]" is a default flag these days, and it defaults to RSA, not > DSA. Unless you know for a fact you need DSA keys for some odd reason, > leave this flag off and accept the default. > > (ssh itself doesn't care what kind of key you use, as long as both ends have > support for the key type you want to use. Since every ssh implementation > I've used since *forever* supports both RSA and DSA, the only way I can see > why you'd want to use DSA is if you had some weird third-party tool that > only understood DSA keys.) > >> Accept the default >> key location, C:\Documents and Settings\nhuser\.ssh\id_dsa, > > Why would that be the default location, if you are using Cygwin tools? > Shouldn't it be something like c:\cygwin\home\nhuser\.ssh\...? You can > change your HOME to anything you like, but that's not the default with > Cygwin. That *is* the default with Cygwin if HOME, or HOMEDRIVE and HOMEPATH, is set in the Windows environment. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Passwordless sftp with ssh 5.9 still asks for password
On Nov 30 12:38, Andrey Repin wrote: > Greetings, Warren Young! > > >> Accept the default > >> key location, C:\Documents and Settings\nhuser\.ssh\id_dsa, > > > Why would that be the default location, if you are using Cygwin tools? > > Shouldn't it be something like c:\cygwin\home\nhuser\.ssh\...? > > Why? > > > You can change your HOME to anything you like, but that's not the default > > with Cygwin. > > Are you sure? > Last time I checked, $HOME in newly installed Cygwin point to the $USERPROFILE > Which is, quite, logical. Just to be clear, that's not done by the Cygwin DLL. When setting HOME, the order is very simple: - If $HOME is already set in the environment, leave it alone. - Otherwise, grab home dir from /etc/passwd. - If /etc/passwd doesn't exist or if the homedir field is empty, set HOME to /home/$USER. If $HOME points to $USERPROFILE, it's because that value is set in /etc/passwd. mkpasswd, for instance, reads the homedir path from the local SAM or AD and uses it, unless the -p option is used. Otherwise, if -p isn't used and the SAM/AD homedir is empty, the fallback is /home/$USER again. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Passwordless sftp with ssh 5.9 still asks for password
Greetings, Corinna Vinschen! >> Last time I checked, $HOME in newly installed Cygwin point to the >> $USERPROFILE >> Which is, quite, logical. > Just to be clear, that's not done by the Cygwin DLL. When setting HOME, > the order is very simple: > - If $HOME is already set in the environment, leave it alone. > - Otherwise, grab home dir from /etc/passwd. > - If /etc/passwd doesn't exist or if the homedir field is empty, > set HOME to /home/$USER. > If $HOME points to $USERPROFILE, it's because that value is set in > /etc/passwd. mkpasswd, for instance, reads the homedir path from the > local SAM or AD and uses it, unless the -p option is used. That explains it, thanks. > Otherwise, if -p isn't used and the SAM/AD homedir is empty, the fallback is > /home/$USER again. -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2011, <18:17> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Searching manpages for option codes, e.g. "--all"
On 11/29/2011 8:29 PM, carolus wrote: Then maybe I just need to update my Cygwin installation, which is about a year old. Yes, that fixes the problem. Thanks, everyone. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin slow on x64 systems?
I'm setting up a laptop running a 64-bit install of Windows 7. It has an Intel i5 chip, which I think is not a slow processor. I renamed .bashrc and such to be out of the way to have as unmodified an environment as I can think of. $ time echo hello hello real0m0.000s user0m0.000s sys 0m0.000s $ cp /dev/null frog $ time cat frog real0m1.259s user0m0.000s sys 0m0.015s # The next line has no effect - x is set in a subshell and thus lost. # It's a contrived example just to show performance of a pipe purely, # without extra delay due to forking programs. $ time echo hello | read x real0m1.929s user0m0.016s sys 0m0.062s I Googled a little, and a few messages suggest that forking new processes has been slow in 64-bit mode for a year or two. Have I done something to screw up performance? Is there anything I can do? Or is this indeed intrinsic to Cygwin, and is there any prospect of fixing this soon? -- Tim McDaniel, t...@panix.com Cygwin Configuration Diagnostics Current System Time: Wed Nov 30 10:30:05 2011 Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\usr\local\bin C:\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files\Perforce Output from C:\bin\id.exe UID: 35511(tmcdaniel)GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'tmcdaniel' PWD = '/home/tmcdaniel' HOME = '/home/tmcdaniel' HOMEPATH = '\Users\tmcdaniel' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\tmcdaniel\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'TMCDANIEL-E6520' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/Users/tmcdaniel/Desktop' USERDOMAIN = 'ATHENAHEALTH' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'tmcdaniel' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\tmcdaniel' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SEN-DC2' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\tmcdaniel\AppData\Local' ProgramData = 'C:\ProgramData' SHLVL = '1' USERDNSDOMAIN = 'CORP.ATHENAHEALTH.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\Windows' PRINTER = '\\ARS-PRINT1\Austin_HPOJ8500A' PROCESSOR_REVISION = '2a07' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' SESSIONNAME = 'Console' COMPUTERNAME = 'TMCDANIEL-E6520' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: a46ac466ed629d62 Path: C: c: hd NTFS122002Mb 25% CP CS UN PA FC d: cd N/AN/A C: / system binary,auto C:\bin /usr/bin system binary,auto C:\lib /usr/lib system binary,auto cygdrive prefix /mnt userbinary,posix=0,auto Found: C:\bin\awk -> C:\bin\gawk.exe Found: C:\bin\bash.exe Found: C:\bin\cat.exe Found: C:\bin\cp.exe Found: C:\bin\cpp.exe -> C:\etc\alternatives\cpp -> C:\bin\cpp-4.exe Not Found: crontab Found: C:\bin\find.exe Found: C:\Windows\system32\find.exe Warning: C:\bin\find.exe hides C:\Windows\system32\find.exe Found: C:\bin\gcc.exe -> C:\etc\alternatives\gcc -> C:\bin\gcc-4.exe Not Found: gdb Found: C:\bin\grep.exe Found: C:\bin\kill.exe Found: C:\bin\ld.exe Found: C:\bin\ls.exe Found: C:\bin\make.exe Found: C:\bin\mv.exe Not Found: patch Found: C:\bin\perl.exe Found: C:\bin\rm.exe Found: C:\bin\sed.exe Found: C:\bin\ssh.exe Found: C:\bin\sh.exe Found: C:\bin\tar.exe Found: C:\bin\test.exe Found: C:\bin\vi -> C:\bin\v
RE: Shell script - is this expected behaviour?
From: Tim McDaniel Subject: RE: Shell script - is this expected behaviour? >I don't have the time to experiment at the moment, but I'm pretty sure >that some of the standard tools append a line terminator if it's not >already on the last line of their input. sed or awk or gawk, maybe? >Anyway, if you can stumble on such a program, it can save you having >to write and maintain and distribute a filter to all your >environments. FWIW, "grep ^" seems to do the trick. --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.9-1 dll::init() still causing STATUS_ACCESS_VIOLATION errors
I updated today to 1.7.9-1 from an earlier install. Now, bash produces a
series of dozens of exception lines like the following:
214713567 [main] bash 5368 exception::handle: Exception: STATUS_ACCESS_VIOLATION
214714267 [main] bash 5368 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
The contents of bash.exe.stackdump are:
Exception: STATUS_ACCESS_VIOLATION at eip=6102048B
eax=00C40308 ebx=6124545C ecx=75110F81 edx=003C51F8 esi= edi=0028F9F4
ebp=61020C00 esp=0028C7C4 program=C:\cygwin\bin\bash.exe, pid 1928, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
End of stack trace
The address 6102048B is associated with line 82 of winsup/cygwin/dll_init.cc,
which is in dll::init():
/* Initialize an individual DLL */
int
dll::init ()
{
int ret = 1;
/* This should be a no-op. Why didn't we just import this variable? */
if (!p.envptr)
p.envptr = &__cygwin_environ;
else
*(p.envptr) = __cygwin_environ; /* This is line 82 */
/* Don't run constructors or the "main" if we've forked. */
if (!in_forkee)
{
/* global contructors */
p.run_ctors ();
/* entry point of dll (use main of per_process with null args...) */
if (p.main)
ret = p.main (0, 0, 0);
}
return ret;
}
The pointer p.envptr is tested before an attempt is made to use it, so it looks
like it is getting garbage. Disassembling the function dll::init shows that
the edx register is being used to hold the address. It's holding 003C51F8,
just short of 240K before the base address of bash.
If I manage to run it down, I'll send a patch.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Emacs in Cygwin: (file-exists-p "c:/")?
I dunno whether anyone here know about Emacs, but I thought I would ask. In a previous setup (Windows XP, 32-bit), I believe that running the Emacs function (file-exists-p "c:/") produced t. Now, with the latest Cygwin, Windows 7, 64-bit, emacs-version "23.3.1", (file-exists-p "c:/") nil (file-exists-p "c:\\") nil I notice it because it broke some code, my .emacs startup file to be precise. It was a quick and easy way to check whether it was running under Windows. I have a workaround, (file-exists-p "/mnt/c") but that only "works" because I "know" that I have changed the drive prefix from /cygdrive to /mnt. Can it be made to work again? Any suggestions on how to tell in Emacs whether I'm running under Windows? -- Tim McDaniel, t...@panix.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Emacs in Cygwin: (file-exists-p "c:/")?
On 11/30/2011 4:08 PM, Tim McDaniel wrote: I dunno whether anyone here know about Emacs, but I thought I would ask. In a previous setup (Windows XP, 32-bit), I believe that running the Emacs function (file-exists-p "c:/") produced t. Now, with the latest Cygwin, Windows 7, 64-bit, emacs-version "23.3.1", (file-exists-p "c:/") nil (file-exists-p "c:\\") nil I notice it because it broke some code, my .emacs startup file to be precise. It was a quick and easy way to check whether it was running under Windows. I have a workaround, (file-exists-p "/mnt/c") but that only "works" because I "know" that I have changed the drive prefix from /cygdrive to /mnt. Can it be made to work again? Any suggestions on how to tell in Emacs whether I'm running under Windows? I'm not sure what you mean by "running under Windows", but I think the variable `system-type' should do whatever you need. For example, I do system-specific customization by putting the following in my .emacs file: (cond ((eq system-type 'cygwin) (load "cygwin-init")) ((eq system-type 'windows-nt) (load "nt-init")) ((eq system-type 'gnu/linux) (load "linux-init"))) Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ash is wrong about [ -w Temp ], so rebaseall fails
Windows 7, 64-bit, up-to-date Cygwin. I got "unable to remap to same address as parent" and did a rebaseall. It failed: $ /bin/rebaseall rebaseall: '/Users/TMCDAN~1/AppData/Local/Temp' is not writable I hand-disabled the condition that produced that and did some testing. I ran these commands in bash: $ [[ -d /Users/TMCDAN~1/AppData/Local/Temp ]] && echo yes || echo no yes $ [[ -w /Users/TMCDAN~1/AppData/Local/Temp ]] && echo yes || echo no yes $ [ -d /Users/TMCDAN~1/AppData/Local/Temp ] && echo yes || echo no yes $ [ -w /Users/TMCDAN~1/AppData/Local/Temp ] && echo yes || echo no yes $ /bin/ash -c ' [ -d /Users/TMCDAN~1/AppData/Local/Temp ] && echo yes || echo no ' yes $ /bin/ash -c ' [ -w /Users/TMCDAN~1/AppData/Local/Temp ] && echo yes || echo no' no $ /bin/ash -c ' [ -d /Users/tmcdaniel/AppData/Local/Temp ] && echo yes || echo no' yes $ /bin/ash -c ' [ -w /Users/tmcdaniel/AppData/Local/Temp ] && echo yes || echo no' no So bash and ash disagree on whether this Temp directory is writable. $ echo long > /Users/tmcdaniel/AppData/Local/Temp/long $ echo short > /Users/TMCDAN~1/AppData/Local/Temp/short $ ash -c 'echo ashlong > /Users/tmcdaniel/AppData/Local/Temp/ashlong' $ ash -c 'echo ashshort > /Users/TMCDAN~1/AppData/Local/Temp/ashshort' $ ls -l /Users/tmcdaniel/AppData/Local/Temp/*short* /Users/tmcdaniel/AppData/Local/Temp/*long* -rw-r--r--+ 1 tmcdaniel Domain Users 8 Nov 30 16:10 /Users/tmcdaniel/AppData/Local/Temp/ashlong -rw-r--r--+ 1 tmcdaniel Domain Users 9 Nov 30 16:11 /Users/tmcdaniel/AppData/Local/Temp/ashshort -rw-r--r--+ 1 tmcdaniel Domain Users 5 Nov 30 16:10 /Users/tmcdaniel/AppData/Local/Temp/long -rw-r--r--+ 1 tmcdaniel Domain Users 6 Nov 30 16:10 /Users/tmcdaniel/AppData/Local/Temp/short So bash is right about it being writable, and ash is wrong. (And /Users/tmcdaniel and /Users/TMCDAN~1 do indeed point to the same directory.) -- Tim McDaniel, t...@panix.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ash is wrong about [ -w Temp ], so rebaseall fails
On 11/30/2011 03:17 PM, Tim McDaniel wrote: > $ /bin/ash -c ' [ -w /Users/tmcdaniel/AppData/Local/Temp ] && echo yes > || echo no' > no > > So bash and ash disagree on whether this Temp directory is writable. Known limitation in dash - it is going off of just st_mode bits instead of using faccessat() and honoring ACLs. My guess is that if you do 'getfacl /Users/tmcdaniel/AppData/Local/Temp' and 'id', you will find that your current uid and gid are not the owner of the directory, but do have an ACL granting write access to the directory anyway. I've been meaning to do a new build of dash (aka ash), and to force the use of faccessat as part of that build; I just haven't had the time to get to it yet. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: ash is wrong about [ -w Temp ], so rebaseall fails
On Wed, 30 Nov 2011, Eric Blake wrote: On 11/30/2011 03:17 PM, Tim McDaniel wrote: $ /bin/ash -c ' [ -w /Users/tmcdaniel/AppData/Local/Temp ] && echo yes || echo no' no So bash and ash disagree on whether this Temp directory is writable. Known limitation in dash - it is going off of just st_mode bits instead of using faccessat() and honoring ACLs. I think that's the case. I've been meaning to do a new build of dash (aka ash), and to force the use of faccessat as part of that build; I just haven't had the time to get to it yet. In the meantime, though, rebaseall as distributed did not work for me. There's a general principle that, if you want to find out whether you can do an operation, you should not check permissions bits, but instead just try to do what you want to do and check for errors -- for this very reason, that your test may not be accurate, and also because if it's so critical an operation, you should be checking for errors anyway when you do it. So I suggest that # Validate temp directory if [ ! -d "$TmpDir" ] then echo "$ProgramName: '$TmpDir' is not a directory" exit 2 fi if [ ! -w "$TmpDir" ] then echo "$ProgramName: '$TmpDir' is not writable" exit 2 fi be removed, and that the check instead be done just before writing it for real: # Create rebase list # This creates an empty file if you have permission to do so, # and outputs an error message if not. if ! > "$TmpFile"; then echo "$ProgramName: cannot write to temporary file in '$TmpDir'" 1>&2 exit 2 fi case $Platform in ... I've tested this proposal briefly and it appears to work, though I can't really try it for real, because I'd have to close this window. Even better might be to check every command that tries to > or >> on TmpFile. -- Tim McDaniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.9-1 dll::init() still causing STATUS_ACCESS_VIOLATION errors
On 11/30/2011 9:33 PM, Jim Schneider wrote:
I updated today to 1.7.9-1 from an earlier install. Now, bash produces a
series of dozens of exception lines like the following:
214713567 [main] bash 5368 exception::handle: Exception: STATUS_ACCESS_VIOLATION
214714267 [main] bash 5368 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
The contents of bash.exe.stackdump are:
Exception: STATUS_ACCESS_VIOLATION at eip=6102048B
eax=00C40308 ebx=6124545C ecx=75110F81 edx=003C51F8 esi= edi=0028F9F4
ebp=61020C00 esp=0028C7C4 program=C:\cygwin\bin\bash.exe, pid 1928, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
End of stack trace
The address 6102048B is associated with line 82 of winsup/cygwin/dll_init.cc,
which is in dll::init():
/* Initialize an individual DLL */
int
dll::init ()
{
int ret = 1;
/* This should be a no-op. Why didn't we just import this variable? */
if (!p.envptr)
p.envptr =&__cygwin_environ;
else
*(p.envptr) = __cygwin_environ;/* This is line 82 */
/* Don't run constructors or the "main" if we've forked. */
if (!in_forkee)
{
/* global contructors */
p.run_ctors ();
/* entry point of dll (use main of per_process with null args...) */
if (p.main)
ret = p.main (0, 0, 0);
}
return ret;
}
The pointer p.envptr is tested before an attempt is made to use it, so it looks
like it is getting garbage. Disassembling the function dll::init shows that
the edx register is being used to hold the address. It's holding 003C51F8,
just short of 240K before the base address of bash.
If I manage to run it down, I'll send a patch.
I suggest to test a latest snapshot to see if the problem as
been already solved, a lot of improvement are already in place for
the future 1.7.10.
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: hdf5-1.8.8-1
Version 1.8.8-1 of libhdf5_7 libhdf5-devel hdf5 for cygwin have been uploaded. Due to API change the library bumped from libhdf5_6 to libhdf5_7. DESCRIPTION HDF5 is a suite/library that makes possible the management of extremely large and complex data collections. HOMEPAGE http://www.hdfgroup.org/HDF5/ CHANGES This is a new upstream release. For the full list of changes: http://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
