On May 13, 2016, at 8:02 AM, Ben Altman <ben...@gmail.com> wrote: > > Doing a ksh --version gives me: version sh (AT&T Research) 93u+ > 2012-08-01 > > I haven't upgraded yet
ksh93u+ is the latest stable version. Everything after that are beta versions which have been in beta for many years, which may be a hint that they’re not quite ready for prime time. > I was compiling under 32-bit Cygwin and if successful would try it on the > 64-bit version. Cygwin 32 and Cygwin 64 are somewhat incompatible. They share a filesystem and can run each others’ programs, but a whole bunch of other stuff will not work correctly between them. If you must have both installed, treat them as wholly independent worlds, except possibly in terms of sharing files. And not necessarily even then, since files produced from 32-bit Cygwin may not be compatible with a consumer linked against 64-bit Cygwin, nor vice versa. The most obvious case is compiler object files, but there are other cases. It’s best if you install only one or the other, not both. That option isn’t always available. Those of us maintaining packages typically need both installed, for example. > The current version I am using will not work with 64-bit Cygwin. We can’t help you if you won’t provide details. I infer from your prior posts that you are a programmer. How do you like “does not work” when you get it in a bug report? Give us the sort of bug report you wish you’d receive from your users. > I am not sure what is involved in packaging ksh with Cygwin https://cygwin.com/setup.html > I was under the impression that if the licensing wasn't GNU it would be a > problem even though it is open source. Not exactly. The license merely has to be *compatible* with the GPL as far as binary distribution goes, since the binaries distributed in the Cygwin package repo are linked to cygwin1.dll, which is GPL’d. But after taking a peek at the AST license, it’s pretty clear it’s incompatible with the GPL. So, new advice: switch to mksh. :) > I renamed my cygwin directory...a complete reinstall...this did not fix the > problem. So that would exonerate Cygwin, then, unless your contention is that a fresh installation somehow causes problems on only your machine, and not on all the others Cygwin is installed on every day. No. The problem must be in the environment external to Cygwin. > typing a simple command like "ls" will take upwards of 20 seconds and all the > other side effects. I'll see about doing the strace with the script though I > will probably have to do it next week though. You can do the strace test with ls. Simpler tests are better. > My script runs VPNClient Ah hah! Many VPNs are…stringent in that they try to force *everything* through the VPN. So, if Cygwin is trying to do AD lookups to map NTFS ACLs to human readable names in ls, and there is no AD server on the other end of the VPN that can answer those questions, you could very easily get that sort of symptom. Solution: test with and without the VPN. For instance, reboot cleanly, bring up the VPN, then say “ls -l”. If that gives the same symptom, you know it’s something like I described above. It is possible the new AD-aware permission handling in Cygwin 1.7.34 is causing a problem for you. If you can’t fix the VPN or the AD setup, you could adjust the /etc/nsswitch.conf file as described here to revert to the old /etc/passwd based permission handling: https://cygwin.com/cygwin-ug-net/ntsec.html In effect, /etc/passwd and /etc/group act as static AD caches that can work while the AD server is unavailable. -- 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
