Re: Another BLODA with Cylance PROTECT? Can't rebase
On Tue, 23 May 2017, Brian Inglis wrote: On 2017-05-23 21:34, Tim McDaniel wrote: Back in ml/cygwin/2017-04/msg00238.html, Wed, 19 Apr 2017 14:25:26 -0400, "Another BLODA with Cylance PROTECT? Can't rebase", I noted that I couldn't install current cygwin, and asked for help on how to proceed. Someone at work did find the two interfering systems. * BeyondTrust BLODA product name is BeyondTrust PowerBroker Endpoint, Server, or both? I am told "BeyondTrust PowerBroker for Windows", installed on a laptop. * Cylance antivirus/antimalware was triggering on certain programs like dash Both had to be dealt with. -- 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: Another BLODA with Cylance PROTECT? Can't rebase
Back in ml/cygwin/2017-04/msg00238.html, Wed, 19 Apr 2017 14:25:26 -0400, "Another BLODA with Cylance PROTECT? Can't rebase", I noted that I couldn't install current cygwin, and asked for help on how to proceed. Someone at work did find the two interfering systems. * BeyondTrust * Cylance antivirus/antimalware was triggering on certain programs like dash Both had to be dealt with. -- 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: Another BLODA with Cylance PROTECT? Can't rebase
On Fri, 21 Apr 2017, Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: On Apr 19 14:25, Timothy McDaniel wrote: $ ./0p_000_autorebase.dash creating empty /var/cache/rebase/rebase_pkg 0 [main] dash 12952 fork: child 12912 - died waiting for dll loading, errno 11 /bin/rebaselst: 98: /bin/rebaselst: Cannot fork $ ./base-files-mketc.sh 0 [main] sh 13628 fork: child 10276 - died waiting for dll loading, errno 11 ./base-files-mketc.sh: fork: retry: Resource temporarily unavailable ... That's pretty bad, considering that ash only links against the Cygwin DLL itself. Running /bin/rebaseall by hand, the old way, had no output and no effect. No effect? How do you know? My apologies. I later ran with the verbose option, letting it choose an address, and later choosing a few myself. There was output saying that it was rebasing each package. Instead of "no effect", I should have written that the exact same error message came up when I tried to run anything slightly complicated. (Simple commands work, but harmless-looking things like "time" and many pipes fail.) If you're sure Cylance PROTECT is the culprit, I'm not. It did not throw up any messages or log any events about blocking anything. It's just that most BLODA appears to be antivirus systems, and it's the only substantial change that I know of in my work systems. (We're still on the same version of Windows.) I have a little more information. A co-worker told me that he uses "Babun", http://babun.github.io/. It's Cygwin, but with a larger number of installed and configured packages and a moderately more convenient control system. I installed it and it works fine ... but immeidately on installation, it's an old Cygwin. (By defualt, each day it auto-updates to the current Cygwin.) Jun 23 2015 libcygwin.a For example, Perl there is 5.14.4, but the current Cygwin Perl is 5.24.1. pcre is 8.36, versus current 8.40.3. But, like I said, it works. If I update to the latest, though, it fails in exactly the same way as a regular Cygwin installation. So all I can say is that it seems that there was some change to libcygwin.a some time in the last 2 years to which my system is allergic for some reason, which is hardly any help. But I don't know how to proceed further, except by letting this 2015 installation sit and never ever update it. Or install a virtual machine with disk sharing and try to do my occasional UNIXy work with it. Someone from the local support team has asked why I was asking about Cygwin, and why I'm interested in "Running OSes on top of OSes". So I may have to go the VM route. -- 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
Windows clipboard and Emacs yank, kill-region, and kill-ring-save
I have updated my packages to the latest versions. I have long had installed - emacs - emacs-X11 - emacs-el - xemacs-emacs-common - X11 In Emacs, ^Y is the default keystroke for the basic yank, to paste the contents of the most recently element of the kill ring (the text most recently cut or copied in Emacs). Until some time in the past few weeks, I am 80% sure that ^Y would grab out of the Windows clipboard -- that is, I could copy in Windows using ^C or Ctrl-Ins, and then use ^Y in Emacs to paste it. But I think that sometime in the last few weeks, perhaps with the end-of-July update of Emacs in Cygwin, it stopped working. Now, ^Y only pastes what was killed (or copied) in Emacs. Similarly, if I kill or copy text in Emacs, it's not put into the Window clipboard. Any Emacs users out there? Am I misremembering the old behavior? At home I use Linux, and there the X clipboard and Emacs clipboard usually work together (modulo X having more than one). If I'm not, did something change, and can I do some setting to obviate it in Emacs? -- 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: Windows clipboard and Emacs yank, kill-region, and kill-ring-save
On Wed, 8 Aug 2012, Ken Brown kbr...@cornell.edu wrote:
There have been some changes in how emacs handles selections,
starting with emacs-24.1. Look at the NEWS file ('C-h n') and
search for selection changes. It describes the changes and tells
you how to restore the old behavior.
Yes! The important one for me is
(setq x-select-enable-primary t)
Thank you very much for the quick and informative answer!
--
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
Interesting gotcha: http + vim-common + maybe Symantec Endpoint Protection
I had something interesting happen to me and wanted to mention it, though perhaps it's in the FAQ and I've just not noticed it. Short form: if downloading a file freezes or fails, switching your setup server from http: to ftp: (or perhaps vice versa) may help. The symptom was that, for a few months, I was unable to download the latest version of vim-common -- it would hang, either partway thru or at the start. The mirror was http://mirrors.xmission.com/..., so Downloading... vim-common-7.3.447-1.tar.bz2 from http://mirrors.xmission.com/... 0 % (0k/1k) 0.0 kB/s Download Incomplete. Try again? Before, I thought that maybe just xmission was hosed. I tried another host: same result. I got tired of it and just uninstalled vim and vim-common just so I didn't have to re-deselect them on each update. Today, I wondered whether it was a file permission problem, so I renamed http%3a%2f%2fmirrors.xmission.com%2fcygwin%2f/release -- same problem. I then suddenly thought to try the ftp: version of the same mirror, as I had been using the http: version. Success! My system has, as its antivirus, Symantec Endpoint Protection. I checked the logs and found nothing. However, I might not be looking in the right place, or for all I know, maybe there is scanning further up like on the $ORKPLACE Internet gateway and thus I can't possibly see it or control it. The FAQ suggests turning off anti-virus (2.8 My computer hangs when I run Cygwin Setup!), but that is NOT permitted (or even possible) for a user at $ORKPLACE. -- 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: Latest cygwin.bat - need one
On Mon, 12 Dec 2011, Mike Brown wrote: Doing some more digging I found the following posting (via google): Does changing 'bash' to '/bin/bash' make a difference? Answering my own question: yes. There was a change in execvp()'s behaviour to no longer look up an executable in the current working directory, wasn't there? I can't find it in the ChangeLog though. You've got to be kidding. Why was the looking into CWD removed? PATH specifies the list of directories to search for executables. So if execvp() ever used . unconditionally regardless of PATH, then it violated one of the most long-standing UNIXy rules. It can also be a massive security hole. On a multi-user system, I can put a script named ls in /tmp, or other likely directory for others to cd to, to - copy /bin/bash to some location - set the setuid bit and setgid on this copy - run /bin/ls (Bonus points: somehow filter out this nasty ls script if they are looking at /tmp. This is hard.) Anyone foolish enough to put . near the start of their PATH and who did cd /tmp ls would thereby get their account hacked, and changing their password would do no good. I removed . from my PATH in the 1980s for just this reason. At least if . is after standard system directories like /bin /usr/bin, it mitigates the problem to a large extent: it catches only typos and attempts to run programs that you don't have installed. I wonder if there are any common typos to try for. If execvp() ever looked in . unconditionally, there would be no way to ever completely close this security hole. -- 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: Cygwin slow on x64 systems?
Tim McDaniel: BLODA is the Big List Of Dodgy Apps, apparently from http://cygwin.com/faq/faq.using.html#faq.using.bloda 44. What applications have been found to interfere with Cygwin? In case anyone cares about the details of my datum, and in case anyone ever searches for the exact system in the archives: It lists Norton/McAfee/Symantec antivirus or antispyware. In my case, the exact installable is called Symantec Endpoint Protection. Integrated antivirus, antispyware, firewall, and intrusion prevention as well as device control and application control and Powerful central management of security, so it's antivirus and antispyware and more. Before uninstalling Symantec Endpoint Protection (note: no Superfetch, and Program Compatibility Assistant disabled in gpedit policy edit, but the PCA Service running): $ time echo hi | read x real0m1.928s user0m0.031s sys 0m0.031s After uninstalling Symantec Endpoint Protection (no changes to Superfetch or PCA Service): $ time echo hi | read x real0m0.093s user0m0.000s sys 0m0.061s Unfortunately, now I'm required to reinstall. -- 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: Cygwin slow on x64 systems?
On Thu, 8 Dec 2011, Marco Moreno wrote: On Thu, Dec 8, 2011 at 11:46 AM, Tim McDaniel wrote: (You quoted my e-mail address there, which may get you dinged by the admins, but I'm cool with my e-mail addy going out -- I put it in my sig and all.) After uninstalling Symantec Endpoint Protection (no changes to Superfetch or PCA Service): $ time echo hi | read x real 0m0.093s user 0m0.000s sys 0m0.061s Unfortunately, now I'm required to reinstall. Any chance they will allow you to add a User defined exception (in Centralized Exceptions) to exclude your cygwin folder? That works for me. After reinstalling: $ time echo hi | read x real0m0.094s user0m0.015s sys 0m0.046s WHOHOO! Now the X server won't start ... -- 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: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Tue, 6 Dec 2011, Lars Bj_rndal wrote: What doew Iirc mean? http://www.acronymfinder.com/ is often useful, but in this case, it produces a lot of useless crud. http://www.urbandictionary.com/define.php?term=iirc is often of more use. If I Recall Correctly. -- 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: Rsync Mirrors Have Disappeared from Cygwin Mirrors Page
On Tue, 6 Dec 2011, L Anderson wrote: Hey! Some rsync mirrors are back on the list--now you see them, now you don't, now you do---just how does all this work? They do it with mirrors. (I'll be here all week, try the veal.) -- 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: Cygwin slow on x64 systems?
On Sat, 3 Dec 2011, Buchbinder, Barry wrote: Tim McDaniel sent the following at Thursday, December 01, 2011 10:59 AM BLODA is the Big List Of Dodgy Apps, apparently from http://cygwin.com/faq/faq.using.html#faq.using.bloda 44. What applications have been found to interfere with Cygwin? Unless someone has another suggestion, maybe I just have to assume I'm SOL. If you use bash completion, try not using it. I Googled for that and found the explanation, that bash completion isn't for ALL completion like I had assumed from the name, but instead programmable context-sensitive completion. Removing it did indeed massively speed up filename completion, which I use all the time. Many thanks. Also, check your PATH. If you set it as a user windows environmental variable, windows may be pre-pending a long for everyone PATH. See http://cygwin.com/faq/faq-nochunks.html#faq.using.path. See also http://cygwin.com/faq/faq-nochunks.html#faq.using.slow. Thank you very much for the pointers. Unfortunately, I have not modified the /etc/profile version of PATH, so it is $ echo $PATH /usr/local/bin:/usr/bin:/Windows/system32:/Windows:/Windows/System32/Wbem:/Windows/System32/WindowsPowerShell/v1.0:/Program Files/Perforce # A form for easier readability: $ echo $PATH | tr ':' '\n' /usr/local/bin /usr/bin /Windows/system32 /Windows /Windows/System32/Wbem /Windows/System32/WindowsPowerShell/v1.0 /Program Files/Perforce And I see slowness even when everything is a bash builtin (except perhaps for whatever is handling | -- I suppose it's forking bash itself): $ time echo hi | read x real0m1.928s user0m0.031s sys 0m0.031s -- 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: Cygwin slow on x64 systems?
On Mon, 5 Dec 2011, marco atzeri wrote: On 12/5/2011 5:20 PM, Tim McDaniel wrote: On Sat, 3 Dec 2011, Buchbinder, Barry wrote: And I see slowness even when everything is a bash builtin (except perhaps for whatever is handling | -- I suppose it's forking bash itself): $ time echo hi | read x real 0m1.928s user 0m0.031s sys 0m0.031s on my W7/x64, a not too fast Corei5 notebook ... The first long time is likely to program loading and Antivirus time delay For me, it's consistently 1.9 seconds for that trivial pipe, even if I run it several times in quick succession. I'm asking the support team about reinstalling Symantec (I have seen a glitch with it), and maybe if I get very very lucky I can talk them into another antivirus solution. -- 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: Cygwin slow on x64 systems?
I wrote: $ 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 Someone replied directly to me, to say that Cygwin should not be that slow on 64-bit installations. He asked whether I have anti-virus installed, and whether I have looked at the BLODA list. BLODA is the Big List Of Dodgy Apps, apparently from http://cygwin.com/faq/faq.using.html#faq.using.bloda 44. What applications have been found to interfere with Cygwin? From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation Unfortunately, Norton/McAfee/Symantec antivirus or antispyware is the second item listed. This is a work machine. IT installed Symantec Endpoint Protection on it and locked down absolutely every setting whatsoever (except for how long to keep local logs). I really doubt that they'd unlock anything for me, especially because I'm brand new and we don't do very much on Windows. Unless someone has another suggestion, maybe I just have to assume I'm SOL. -- 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
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\vim
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
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 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' 12 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
updatedb: man page inaccuracies, not usable out of the box
I downloaded setup.exe and installed Cygwin yesterday and today.
It's cygwin 1.7.9-1 running on Windows 7 64-bit. Just like most of
the times I've installed cygwin over the past decade, updatedb doesn't
work out of the box.
I see three inaccuracies in the man page:
--prunepaths='path1 path2...'
Directories to not put in the database, which
would otherwise be. Remove any trailing slashes
from the path names, otherwise updatedb won't
recognise the paths you want to omit (because it
uses them as regular expression patterns). The
environment variable PRUNEPATHS also sets this
value. Default is /tmp /usr/tmp /var/tmp /afs.
The default is actually /tmp /usr/tmp /var/tmp /afs /amd /sfs /proc,
as set via
: ${PRUNEPATHS=/tmp /usr/tmp /var/tmp /afs /amd /sfs /proc}
--prunefs='path...'
File systems to not put in the database, which
would otherwise be. Note that files are pruned
when a file system is reached; any file system
mounted under an undesired file system will be
ignored. The environment variable PRUNEFS also
sets this value. Default is nfs NFS proc.
The value is not actually a list of path..., but rather filesystem
types.
And the default is actually
nfs NFS proc afs smbfs autofs iso9660 ncpfs coda devpts ftpfs
devfs mfs sysfs shfs
as set by
: ${PRUNEFS=nfs NFS proc afs smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs
sysfs shfs}
This new job was just like at the last three jobs: the version of
updatedb just out of the box does not appear to finish, and since I
don't change jobs that often, I've forgotten the exact problem, so
each time it takes me upwards of an hour to realize that it's
happening again and debug it. At each job, they recommend that I NET
USE some drives onto my machine, and they have huge directories
and/or are slow to insanely slow, so it would take hours or days to
complete and would hammer the often slow network. (And when I try to
add things to --prunepaths or --prunefs, I often copy the incomplete
defaults out of the man page and start picking up things that I don't
want, like /proc/registry/..., which seems to be taking forEVER, so
please fix the man pages.)
Going by the default PRUNEFS list, I would say that the general spirit
of updatedb is not to index networked drives. I therefore ask that
updatedb, by default under Cygwin, not go into networked mapped
drives either.
find /mnt/z -maxdepth 0 -printf '%p %F\n'
suggests that my mapped drives are file system type netapp.
So I suggest that netapp be appended to the default PRUNEFS, or else
mount -p or something be used to determine the current cygdrive
prefix and put it in PRUNEPATHS.
This would probably involve patching what comes from upstream, but the
usability problem hits me bad enough, and perhaps hits others, that I
think it would be reasonable to do it.
--
Tim McDaniel, t...@panix.com
Cygwin Configuration Diagnostics
Current System Time: Tue Nov 29 11:22:14 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 = '\\BEL-DC1'
CommonProgramW6432 = 'C:\Program Files\Common Files
RE: Shell script - is this expected behaviour?
Nellis, Kenneth wrote: From: Eric Blake Never feed 'read' unterminated input. Always end your text files with a newline. When I can't control the contents of the input file, I pipe it through a filter program I wrote that adds a final newline where the last character of a stream is not a newline. 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. -- 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: Illegal character ^M
On Tue, 29 Nov 2011, frenco wrote: I have a variable that is a float value. When I print it with the echo command i get: 0.495959 ... I think it's because my variable have the ^M character (not printed with the echo command) You might try echo [$the_variable_name] The quoting is significant. If it does have a carriage return like you think, then it will probably display like ].495959 That is, the ^M will probably make it go back to the start of the line, and characters after it (here, ]) will overwrite what it output before. But when I try to make an operation on that value with the bc command (I am not sure how to write the bc command). echo $mean *1000 |bc ... How can i eliminate this error? echo $mean *1000 | tr -d '\r' | bc seems to work. tr translates characters, -d says that instead of translating it should just delete the name characters, and '\r' (note: single quote ', not double quote ) is the ^M character. -- 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: Searching manpages for option codes, e.g. --all
On Tue, 29 Nov 2011, carolus wrote: After opening man ls, trying to search for --all leads to Pattern not found (press RETURN). My experiment agrees with that. Do you know why that happens -- what is it doing so /--all doesn't work? Inquiring on comp.unix.shell, I was told that for this kind of search to work properly in linux , one must set PAGER=less. However, that does not seem to work in Cygwin, at least using the old default terminal. Is there a workaround? Whether in an older default terminal or the new one, I've never had a problem with PAGER=/usr/bin/less export PAGER I do them as separate statements because older Bourne shells do not allow the combined form export PAGER=/usr/bin/less But bash does. Further, on my system with little customization, the default man pager is less anyway, so (for example) man ls invokes less anyway. -- 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
IFS not fixing carriage returns
I have tried Googling for info on this, but there are a lot of false hits ... I want to run bash scripts on a Cygwin-running system. The problem is that (so far as I know) I cannot control the format of the scripts -- Rational Build Forge writes each line of the script with a trailing carriage return and then invokes the script with the environment that it wants to put out there. Although it's not documented in man bash on the latest Cygwin, I did find set -o igncr and it seems to work well. But I'm just curious about why my first attempt didn't work. This is a test script with CR-LF lines that I ran on my own box. #! /bin/bash -- set -x # echo $IFS | od -t x1 -a # IFS=$IFS$'\r' # echo $IFS | od -t x1 -a # # set -o igncr 2/dev/null || true # echo Hello, world! pwd ls -l | head exit 0 The trailing #s are to prevent problems with carriage returns before I can do something about them. But the output is $ ./128.bash + echo ' ' + od -t x1 -a 000 20 09 0a 0a sp ht nl nl 004 + IFS=' ' + echo ' ' + od -t x1 -a 000 20 09 0a 0d 0a sp ht nl cr nl 005 + $'\r' ./128.bash: line 8: $'\r': command not found ' echo 'Hello, world! Hello, world! + $'pwd\r' ./128.bash: line 10: $'pwd\r': command not found + ls -l + $'head\r' ./128.bash: line 11: $'head\r': command not found + exit $'0\r' : numeric argument required0 The od calls are intended to show that the carriage returns are getting in there, but the following error messages are showing that IFS apparently has no effect, despite the man page saying IFS The Internal Field Separator that is used for word splitting after expansion and to split lines into words with the read builtin command. The default value is ``spacetabnewline''. Anyone have any ideas on why IFS doesn't work to deal with carriage returns? (Note that adding carriage return to IFS is still an inferior notion to set -o igncr. IFSing would effectively put a space at the end of each line, so I expect that line arg1 arg2 arg3 \ arg4 arg5 would not work. I would also exspect here-documents like some pipe EOF line1 line2 EOF would need their carriage returns stripped. In contrast, set -o igncr strips carriage returns even in these contexts, so they work as-is. I'm asking about IFS merely because I'm curious.) -- 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: Filesystem Filename touch fail [ was: PLEASE TEST YOUR FS ]
On Wed, 7 Apr 2010, Morgan Gangwere wrote:
On 4/7/2010 4:07 PM, Charles Wilson wrote:
One is a simple shared NTFS drive, I think (volinfo-1.txt). The
other is a weird distributed filesystem of some kind
(volinfo-2.txt).
Both are NTFS unless one is not.
$ touch foo.
touch: cannot touch `foo.': No such file or directory
$ touch foo
touch: cannot touch ` foo ': No such file or directory
Both of those are invalid under NTFS FS specifications:
Filenames may contain any character other than NULL (0x) but
may not contain a space (ASCII 0x20, ' ') or period ('.')
Where did you get that sentence?! Googling found nothing but your
e-mail message. That can't possibly be true for NTFS. NTFS takes
spaces in directories (C:\Program Files\) and filenames
(...\Budget 2009.doc) perfectly well. On a Windows XP system, I just
created a file named C:\download\MySQL\foo bar.baz.txt just fine:
created in Explorer, edited in Notepad, typed in CMD.
Windows in kernel-space defines this restriction (as defined by Wikipedia):
Microsoft Windows: Windows kernel forbids the use of
characters in range 1-31 (i.e., 0x01-0x1F) and characters * :
? \ / |. ...These restrictions only apply to Windows - Linux, for
example, allows use of * : ? \ / | even in NTFS.
Though / cannot be used in _filenames_ in Linux -- it's always a
directory delimiter.
Since 'touch foo.' would result in doing an fileopen(foo.) this
would be considered bad by Windows AND Linux ( I mounted an NTFS
Partition and tried 'touch foo.' and was denied it)
In Linux using a Linux filesystem, it doesn't care in the slightest
about periods. In Windows in CMD and Explorer, an attempt to rename
C:\download\MySQL\foo bar baz to
C:\download\MySQL\foo bar baz. simply caused the trailing . to be
ignored.
--
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: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1
About release number testing, Jeremy Bopp wrote: The most accurate way to check for functionality is to specifically test for it, a la autoconf. Even better, when possible, is to just try it and catch errors. -- 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: installer improvements
On Tue, 6 Apr 2010, Christopher Faylor wrote: That's a little harsh. We'll gladly look at patches which improve setup.exe but it's not likely that we'll be interested in making interface changes just because someone makes assertive statements about the UI. Hrm. Can I nevertheless put in a comment? Yesterday, as I mentioned on this list, I was fooling around with packages qt3 and qt3-doc. In setup.exe, at one point, I clicked on qt3 until it was Skip. I then clicked on qt3-doc's New value repeatedly to reach Uninstall, but on the first click (Reinstall, I think), setup.exe put qt3 back to being installed. The only reason I noticed is because there's only one row between them. If the dependency were off in lib*, for example, I would have been thwarted. So two thoughts come to my mind. (1) Why do the docs depend on the package? While it's unlikely, it's possible that someone wants the documentation to be handy on their own machine (convenient access, for example) when the real package is installed on another. For a similar example, I tend to do BAT file work on a production machine, but my browser and bookmarked help links are on my desktop. (2) I was annoyed that it silently included a package, and more, that it silently undid an action. I'm not entirely sure of what the best fix would be. Maybe if, when clicking Next, it would pop up a dialog box listing unmet dependencies and ask whether they should be included? -- 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: 1.7 setup.exe overwrites softlink for home
Corinna Vinschen wrote: Peter Wohlers wrote: Since upgrading to 1.7, I keep seeing weird problems with deletion of my homedir symlink. Before running setup: pwohl...@h1n1 ~ $ ll / [...] lrwxrwxrwx 1 Domain Users 18 2010-04-04 14:31 home - /cygdrive/d/Users/ [...] After running setup: [...] Setup seems to have deleted the softlink for /home Well... yes. That's probably a bit unfortunate. The current mechanism always creates a couple of directories if they don't already exist: ... /home ... If the directory couldn't be created because a non-directory file uses the same name, it deletes that file and tries to create the directory again. It's not perfect, but at least we know that the directories exist, afterwards. We could add a mode which drops the aggressive creation strategy, but I only see that *could* make sense for home. Um, so I suppose it's doing a test for symlinks specifically. Why not just test that /home is a directory via stat(), and if so, leave it alone? Perhaps it doesn't have stat() available and it would be extra work to cobble it together in that environment? -- 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
MySQL client, prompt, redux
From Google searches and some experience, it appears that it's a long-standing situation that, if you run the mysql.exe client program under mintty or rxvt from Cygwin, then mysql figures that it's not on an interactive terminal and therefore does not prompt. Is there yet any workaround other than simply using cmd.exe instead? (In mintty, BTW, cmd /c mysql ... doesn't prompt, presumably for the same reason that mysql alone doesn't prompt.) -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1
On Mon, 5 Apr 2010, Christopher Faylor wrote: On Mon, Apr 05, 2010 at 05:42:05PM +1000, Rurik Christiansen wrote: * How do I know what the current release is ? (e.g. is there something like /etc/redhat-release or whatever ? The docs mention /var/log/setup ... but is not clear at all) ... Otherwise, as Dave Korn suggests, you can *read the website*. I suppose that /etc/redhat-release is not as well-known a concept as he or I had thought. As I understand it, it's a file that's maintained by the Redhat installation software to show, in an easy human-readable way, what is currently installed on the running system. It is only updated by new installs run on the machine. I think that some other distributions put something in /etc/motd. -- 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: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1
On Mon, 5 Apr 2010, Christopher Faylor wrote: On Mon, Apr 05, 2010 at 10:32:53AM -0500, Tim McDaniel wrote: On Mon, 5 Apr 2010, Christopher Faylor wrote: On Mon, Apr 05, 2010 at 05:42:05PM +1000, Rurik Christiansen wrote: * How do I know what the current release is ? (e.g. is there something like /etc/redhat-release or whatever ? The docs mention /var/log/setup ... but is not clear at all) ... Otherwise, as Dave Korn suggests, you can *read the website*. I suppose that /etc/redhat-release is not as well-known a concept as he or I had thought. You're assuming too much. Given that several people replied with information about the version available on the Web (though often also mentioning information on local versions), I think not. The Cygwin distribution doesn't come from Red Hat so calling something /etc/redhat-release wouldn't make much sense. Which is why the original question had e.g., something like, and whatever, and I wrote concept. Thank you for the information on multiple version numbers with Cygwin, and how a single identifier would not make much sense. -- 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
qt3 silently fails to install?
Most recent setup.exe, all my installed packages up-to-date as of now. For at least the past week, when I tried to do any update using setup.exe, the Partial view showed Current New Bin? Src? ... Package 3.3.8b-11 [X] [ ] qt3: C++ GUI application framework (sources) If I left it in this to-be-installed state and continued, installing it and any other updates since the last run, there would be no apparent error and everything else would update, but the next run of setup.exe would show the same qt3 line again. When I changed it to Skip, I got Warning! Unmet Dependencies Found ... Package: qt3 Required by: qt3-doc For qt3-doc, it said Current New Bin? Src? ... Package 3.3.8b-11 Keep n/a [ ] qt3-doc: C++ GUI application framework (documentation) More or less just to see what would happen, I asked to remove qt3-doc, and it did. Then it no longer presented a line in setup.exe for either qt3 or qt3-doc. I then re-ran setup.exe, marked both qt3-doc and qt3 for install, and completed the install. Now the same symptoms have returned: each run of setup.exe again shows the same qt3 line in the Partial view, even if I installed it in the last run. I don't know of anything that I have installed that uses qt3* -- at least, I suppose that setup.exe would have complained if any Cygwin package needed it, and surely it's unlikely that anything outside Cygwin would need it. So I may just remove both and leave them uninstalled. Still, I thought I should report this oddity. (While I'm here: out of curiosity, why does qt3's description say (sources) when the Bin? box is checked?) -- 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: qt3 silently fails to install?
On Mon, 5 Apr 2010, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 05/04/2010 21:03, Tim McDaniel wrote: I don't know of anything that I have installed that uses qt3* -- at least, I suppose that setup.exe would have complained if any Cygwin package needed it, and surely it's unlikely that anything outside Cygwin would need it. So I may just remove both and leave them uninstalled. Still, I thought I should report this oddity. (While I'm here: out of curiosity, why does qt3's description say (sources) when the Bin? box is checked?) The whole thing is a known glitch that arises with dummy empty meta-packages (qt3 is one, gcc4 another) that are used to pull in a group of packages as a whole through their dependencies. It can be ignored; it does nothing and has no effect, so just leave it there and you'll be fine. It's not even actually installing anything repeatedly. Thank you for the information. Since nothing appears to depend on qt3 on my system, I will probably uninstall qt3 and qt3-doc just to clear out the annoying message. -- 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
Cannot stop cygcheck -c
I'm running the latest setup.exe, cygwin libraries, and installed packages. I ran cygcheck -c (thanks to the list member who pointed it out). After a screen or two, I wanted to stop the output to scroll back. It doesn't seem to respond to control-C or control-Z. Does this happen to anyone else? -- 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: UTF-8 versus utf8
On Sat, 3 Apr 2010, Andy Koppe andy.ko...@gmail.com wrote: Tim McDaniel: Why does http://cygwin.com/cygwin-ug-net/setup-locale.html talk all about a charset of UTF-8, then For a list of locales supported by your Windows machine, use the new locale -a command, which shows utf8 (which matches my XP machine)? ... So why doesn't locale -a report the canonical name? Btw, what did you mean by utf8 (which matches my XP machine) That page points to http://cygwin.com/cygwin-ug-net/using-utils.html#locale, which gives sample output of locale -a that has only utf8. I was trying to express that locale -a run under Cygwin on my XP machine agrees with thtat in outputting utf8. Danihel Lindecolina -- 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
UTF-8 versus utf8
Why does http://cygwin.com/cygwin-ug-net/setup-locale.html talk all about a charset of UTF-8, then For a list of locales supported by your Windows machine, use the new locale -a command, which shows utf8 (which matches my XP machine)? I know little about charsets, so I find it confusing nad disheartening to see any difference. -- 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: UTF-8 versus utf8
On Fri, 2 Apr 2010, Eric Blake ebl...@redhat.com wrote: On 04/02/2010 04:27 PM, Tim McDaniel wrote: Why does http://cygwin.com/cygwin-ug-net/setup-locale.html talk all about a charset of UTF-8, then For a list of locales supported by your Windows machine, use the new locale -a command, which shows utf8 (which matches my XP machine)? UTF-8 is the canonical name of the charset, but utf8 is an acceptable synonym in most contexts, and is much easier to type. So, when it comes to specifying your charset, the suffix .utf8 is used to request the UTF-8 charset. So why doesn't locale -a report the canonical name? -- 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
rxvt and mintty fail with SHELL=c:\bin\bash.exe
I've used rxvt for many years, because I don't want to set up an X server and I was able to do everything I want with it. Since the last update, if I clicked on my shortcut to rxvt, or ran it from cmd.exe, it flashed open a window and then immediately closed it. But I could start c:\bin\bash with or without -l from cmd.exe. I went to the mailing lists and saw the recent problem reports about rxvt, modified cygwin.bat for rxvt - window does not stay up in 1.7.2 (but I was already using a full path) and that rxvt does not and will never understand Unicode. So I decided to try mintty. But IT also flashed up its window and immediately closed it. Bless the mintty developers who included the -l, --log FILE option. $ cat mintty.log exec: c:\bin\bash.exe: No such file or directory$ c:\home\tmcdanielset | c:\bin\grep bash SHELL=c:\bin\bash.exe SHELL is set in My Computer's system environment variables. I don't know why I set it in Windows syntax years ago. I might guess that I wanted to keep open the possibility of using %SHELL% in cmd.exe and $SHELL in bash. I changed SHELL to /bin/bash, and now both rxvt and mintty start up fine. I see that Cygwin is deprecating more strongly the use of Windows-syntax filenames in Cygwin. But Cygwin also deprecated a root of c:\ and, frankly, I disagreed with that too. This change broke a system that had been doing what I wanted. If Cygwin will generally accept Window-style paths in shells and such, I think that it should continue to accept them in SHELL too. -- 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
I'd like to have an unreadable file
I'd like to test a script by giving it an unreadable file as an argument. I usually log in as a user, but one that's in the Administrators group. I made the file (a text file containing just hello) owned by user Administrator with absolutely no permissions for anyone else. In Windows Explorer, when running as Administrator, it says that mymachine\tmcdaniel has no permission on the file at all -- I can't even view permissions as tmcdaniel. In cmd, I get c:\home\tmcdanieltype noperm Access is denied. c:\home\tmcdanielCACLS noperm c:\home\tmcdaniel\noperm Access is denied. though I can see some information in other ways: c:\home\tmcdanielattrib noperm A C:\home\tmcdaniel\noperm c:\home\tmcdanieldir noperm ... 04/30/2009 02:47 PM 6 noperm 1 File(s) 6 bytes But Cygwin lets me see it just fine. $ cd $ cat noperm hello and I can see the contents in vi also. So - how do I manipulate a file so that only the owner user can do anything with it, even in Cygwin, even if that owner user is in the Administrators group? - how is it that Cygwin gives more permission than Windows? I am using the latest Cygwin, just updated a few hours ago. Please let me know if you need more information. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Normalized directory name
I have access to a Windows 2003 system. Cygwin is running case-insensitive, so while the directory name is E:\CM\BuildUtil, I can type cd /cm/buildutil and get there (E:\CM is mounted on /cm). And if I do that particular cd, then pwd, /bin/pwd, and echo $PWD all say /cm/buildutil. For tidiness, if nothing else, I'd like to get the normalized form, in much the same way how, in CMD, I can do E:\cd cm\buildutil and have the prompt become E:\CM\BuildUtil Emacs figures it out too. I Googled for the answer a while back, and I think the answer was no way, but I was wondering whether the answer was correct, or whether someone has come up with a program or script to do better. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: I'd like to have an unreadable file
On Thu, 30 Apr 2009, Larry Hall wrote: It's a known fact that Cygwin allows users that are members of the Adminstrators group access to any file, regardless of its permissions. Thank you for the quick reply. (Though I find it scary that Cygwin can escalate privileges so very much.) I guess the workaround would be to simply test the script by running as a user who is not in the Administrators group. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Normalized directory name
On Thu, 30 Apr 2009, Eric Blake wrote: But beware that with cygwin 1.7, you can have directories which are case sensitive, in which case the glob may return multiple files. A few questions out of curiosity, since I've not read up on Cygwin 1.7: What does Cygwin 1.7 do in that case with mkdir FROG cd frog ? I assume there'd be an error, as on UNIXy systems. I assume there'd be the same error for mkdir FROG mkdir fRog cd frog In a completely case-sensitive directory, I would expect that the problem of normalizing a directory or file name would be a no-op, just like on UNIXy systems: if you enter the name exactly, it knows the exact spelling without any other work; if you don't enter it exactly, there's an error, and thus no need to normalize the invalid name. Is there a way for a script to tell whether it's running under Cygwin 1.7, and whether the directory is case-sensitive? -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Did anyone download the Windows 7 beta?
Dave Corn wrote: A lot of complaints have been addressed at how UAC is so intrusive, users just end up turning it off completely. By chance, I recently ran across this Kevin and Kell cartoon (work-safe), titled Allow: http://www.kevinandkell.com/2008/kk0324.html -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Corrupt *.lst.gz
setup.exe kept crashing when trying to update libncurses-devel. Worse, Event Viewer usually said that it was a different fault address each time. After much fixing of file ownerships, searching of mailing list archives, use of Process Monitor, saving PM's output to disk to search for something suspicious, ... I see 6:14:28.7559654 PM,setup.exe,3708,QueryOpen,C:\etc\preremove\libncurses-devel.sh,NAME NOT FOUND, 6:14:28.7564790 PM,setup.exe,3708,QueryOpen,C:\etc\preremove\libncurses-devel.bat,NAME NOT FOUND, 6:14:28.7582832 PM,setup.exe,3708,CreateFile,C:\etc\setup\libncurses-devel.lst.gz,SUCCESS,Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/ a, OpenResult: Opened 6:14:28.7585620 PM,setup.exe,3708,ReadFile,C:\etc\setup\libncurses-devel.lst.gz,SUCCESS,Offset: 0, Length: 10 6:14:28.7588064 PM,setup.exe,3708,ReadFile,C:\etc\setup\libncurses-devel.lst.gz,SUCCESS,Offset: 0, Length: 10 6:14:28.7588728 PM,setup.exe,3708,ReadFile,C:\etc\setup\libncurses-devel.lst.gz,END OF FILE,Offset: 10, Length: 15,872 -- 6:14:28.7589127 PM,setup.exe,3708,ReadFile,C:\etc\setup\libncurses-devel.lst.gz,END OF FILE,Offset: 10, Length: 16,384 6:14:28.7591254 PM,setup.exe,3708,RegOpenKey,HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug,SUCCESS, 6:14:28.7592010 PM,setup.exe,3708,RegQueryValue,HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto,SUCCESS, Type: REG_SZ, Length: 4, Data: 1 6:14:28.7592239 PM,setup.exe,3708,RegQueryValue,HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger,SUCCES S,Type: REG_SZ, Length: 52, Data: drwtsn32 -p %ld -e %ld -g 6:14:28.7592484 PM,setup.exe,3708,RegCloseKey,HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug,SUCCESS, 6:14:28.7599208 PM,setup.exe,3708,QueryOpen,C:\WINDOWS\system32\faultrep.dll,SUCCESS,CreationTime: 7/4/2007 4:32:29 PM, LastAccessTime: 3/13/2009 6:13:56 PM, LastWriteTime: 2/17/2007 9:02:50 AM, ChangeTime: 7/6/2007 7:38:48 PM, AllocationSize: 90,112, EndOfFile: 86,528, FileAttributes: A 6:14:28.7605289 PM,setup.exe,3708,CreateFile,C:\WINDOWS\system32\faultrep.dll,SUCCESS,Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, Al locationSize: n/a, OpenResult: Opened 6:14:28.7606932 PM,setup.exe,3708,QueryStandardInformationFile,C:\WINDOWS\system32\faultrep.dll,SUCCESS,AllocationSize: 90,112, EndOfFile: 86,528, NumberOfLinks: 1, DeletePending: False, Directory: False which seemed to indicate that it was trying to read C:\etc\setup\libncurses-devel.lst.gz when it died. Searching further, I read the suggestion to just delete a suspected corrupt *.lst.gz file and retry setup.exe. I did. It installed a lot of man pages and ran to completion without error. Searching further, I see a number of instances of this happening. May I please lobby for someone to make the reading of *.lst.gz files more bombproof? If there's a reason why that's not possible, can the process at least append to setup.log or setup.log.full just before processing each *.lst.gz file? Or, maybe better: if it's acceptable to just delete the *.lst.gz file, why not just get rid of them? (I'm reminded of the Far Side cartoon with the mom-rat noticing that the box of cereal is right next to the box of rat poison: Hey, what do we have this stuff for anyways?) Or, if all else fails, add text to FAQ question 2.12 (or point me at where it's documented)? Yours in frustration after several hours of diagnosing this with unfamiliar tools, after weeks of being unable to upgrade the package, -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Upgrade woes (file in use)
On Tue, 10 Mar 2009, Nuzhna Pomoshch y...@i remembered! wrote: During a recent upgrade of about a dozen packages, I saw the Cygwin setup window progress normally (deleting package xyz...), and then up popped a window that said: In-use files detected Unable to extract /etc/postinstall/bash.sh -- the file is in use. Please stop all Cygwin processes and select 'Retry,' or select 'Continue' to go on anyway (you will need to reboot). I didn't have any Cygwin processes running There can be processes running that you can't see easily. I use Process Explorer, from http://www.sysinternals.com/, which now redirects to http://technet.microsoft.com/en-us/sysinternals/default.aspx. Perhaps the default Task Manager works OK for this purpose. Anyway, on my current system, even if I have closed all Bash windows and Emacs windows and and and, it is still running ssh-agent.exe. Also, in XP Control Panel - Administrative Tools - Services, it shows services CYGWIN sshd CYGWIN syslog-ng When upgrading, I make a point of killing ssh-agent.exe via Process Explorer, and then stopping the two services via Control Panel. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: umount/mount issues
On Mon, 2 Mar 2009, Corinna Vinschen wrote: On Mar 1 20:40, Karl M wrote: This came from an fstab of (I know...I have done the evil / prefix for years and am hooked.) Sigh. Why are you guys insisting on using this prefix. Is that a rhetorical question, or would you like people's answers? -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, grip chandramohan.usec...@gmail.com wrote:
2. Output from od- tx1 -a test.c
-BEGIN---
000 23 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e
# i n c l u d e sps t d i o .
020 68 3e 0a 0a 69 6e 74 20 6d 61 69 6e 28 29 0a 20
h nl nl i n t sp m a i n ( ) nl sp
040 7b 0a 70 72 69 6e 74 66 28 a8 54 65 73 74 20 74
{ nl p r i n t f ( ( T e s t sp t
060 68 69 73 a8 29 3b 0a 72 65 74 75 72 6e 28 30 29
h i s ( ) ; nl r e t u r n ( 0 )
100 3b 0a 20 7d 0a
; nl sp } nl
105
-END---
THank you for providing that. I've deleted spaces so that the text
representations line up under the hex representations (why od doesn't
do that I don't know; nor do I know how to make od do that).
They really ARE umlauts in Latin-1, hex a8 shown above. Why any other
program displays them as double quotes is beyond me: od apparently
strips the high bit to display them (0xa8 becomes 0x28, which is ();
DOS codepage 437 would show an inverted question mark.
Anyway, go into your editor, delete the quotation marks that are
around the string, and retype them with the key that's probably next
to Enter on your keyboard. Then re-do od as above to make sure that
they show up as , hex code 22, instead of a8 or anything else.
--
Tim McDaniel, t...@panix.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, Eric Blake e...@byu.net wrote: grip Chandramohan.USecure at gmail.com writes: 1. From the command prompt from windows, I tried this - od -tx1 ENTER - ENTER (Note: I have to type double quotes twice always and I get two double quotes. I use backspace to remove one every time. A single double quotes produces no output on the screen) That seems fishy. You are probably better off getting to the root of why isn't working the first time around. Perhaps a faulty .inputrc setting is at play? Or maybe a strange stty setting? Escape character in your terminal program, even? Though that seems unlikely to me: the terminal programs I've used of late look for ~ as the first character on a line only, and the double quotes are not at the start of a line. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc compile problem: error: stray \168 in program
On Tue, 24 Feb 2009, Tim McDaniel t...@panix.com wrote: On Tue, 24 Feb 2009, grip ....@x.xxx wrote: and so forth. I just realized I've been forgetting this list's custom of ripping out e-mail addresses, so I've sent out a bunch of unobfuscated ones lately. My apologies. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file name too long
On Tue, 24 Feb 2009, Paul Cantalupo hey, I remembers to expunge this! wrote: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. I have a vague memory that the limit includes the current directory path. Anyone else know whether that's true or not? What's the current directory name when running that? If you add the length of the current directory name, plus one for the / separator, plus the length of the path above, is it more than 254? Is there a workaround to this problem other than installing Linux? When the problem can be helped with a shorter directory name, I use the subst Windows command to map the directory to a drive letter. That shortens the directory name from whatever to 2. For example, M: is one letter that I leave unused, and /mnt is my value instead of /cygdrive. So, as an untested example from Windows Server 2003: /mnt/c/WINDOWS/system32/subst M: 'c:\long\path name\goes here' pushd /mnt/m [do my work here] popd /mnt/c/WINDOWS/system32/subst M: /d# unmap the drive letter -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc compile problem: error: stray \168 in program
On Mon, 23 Feb 2009, Dave Korn dave.korn.cyg...@googlemail.com wrote: Nor do I, but let's see what's in that file: can you show us the output you get from running od -tx1 test.c on your testcase please, and tell us exactly what editor you used. I personally prefer od -tx1 -a test.c: it should add ASCII versions of each character, to make it faster to find particular positions. Also, type od -tx1 at a command line without any filename following it, type a quote mark, then press enter, then Ctrl+D, and show us what that says. Being ultra-precise: type od -tx1 at a command line, and then press enter. That will start the octal dump program. The quote mark (meaning ) and enter is the one line of input. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fstream - problem with reading/writing to file
On Thu, 19 Feb 2009, Pavel Kudrna pavel.kud...@mff.cuni.cz wrote: I have found problem with read and write to file using fstream. The following example opens existing file for read+write, separately writes Hello and world! and in between it tries to read one character from the file. The problem is that without call to seekg() or tellg() the read fails and without seekp() or tellp() the second write of world! to the file fails too. The same program works on linux with gcc 3.2.2. I'm pretty sure that at least the C standard for stdio said that, between a read and a write (and the reverse), it was necessary to do a seek on the file. But I don't have a citation for that, and I don't know much about C++ I/O to know what rules exist there. I only mention this in case it might prompt someone else who knows where to look. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: subshell redirection (/dev/fd/x)
On Tue, 17 Feb 2009, Brian Ford brian.f...@flightsafety.com wrote: $ uname -a CYGWIN_NT-5.1 PC1163-8460A-XP 1.7.0(0.193/5/3) 2009-02-09 22:27 i686 Cygwin Just curious if the following is known behavior? $ echo a | tee (wc) a tee: /dev/fd/63: Bad file descriptor $ 0 0 0 The bash term is Process Substitution. I had the dim impression that there was a Windows misfeature that prevented (...) from working. Anyway, thanks for reminding me about what I got onto the list to complain about. I think that, out of the box, (...) doesn't work under Cygwin. We had to do ln -s /proc/self/fd /dev/fd (We got there after we deleted all of Cygwin's directories and reinstalled. Apparently we'd set up that symlink before: (...) worked before the reinstall, but didn't work afterwards until we did the symlink above.) The bash manual says, by the way, Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] New documentation available
On Fri, 13 Feb 2009, Corinna Vinschen corinna-cyg...@cygwin.com wrote: - The User's Guide. It should be fairly complete now. http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html - The API reference. ... http://cygwin.com/1.7/cygwin-api/cygwin-api.html - The new FAQ. ... http://cygwin.com/1.7/faq/faq.html Many thanks. Will there be a release-notes document giving some user-visible changes from 1.5 to 1.7? I think you listed them, plus notes on internal restructuring, in the first 1.7 announcement on this list. Is there anything to know about upgrading from 1.5 to 1.7? Denyel de Lincoln -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CygWine 1.0 Beta -- an new cygwin package manager
On Thu, 12 Feb 2009, Mark J. Reed wrote: On Thu, Feb 12, 2009 at 12:37 PM, Warren Young wrote: Brant Young wrote: I have launched a opensource project -- CygWine ( a cygwin package management utility, project homepage: http://cygwine.googlecode.com ) My initial thought on seeing the name is that it was a port of Wine to Cygwin, which would be tres silly. I had that exact same thought. M3 T00, AOL, or whatever other means by which the whippersnappers express agreement now-a-days. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RFE?: CygWinDir in ENV? (was Re: How does one find where Cygwin was installed from Windows?)
On Tue, 10 Feb 2009, Linda Walsh cyg...@tlinx.org wrote: Then anything else in Cygwin that uses paths -- including setup's cygwin.bat could use %CygWinDir% Not that there's being a vote taken or anything, but I would like to support that notion. I have several trampoline scripts, a bat file doing nothing but invoking a corresponding bash shell script or Perl program. I have to hard-code a location for the bash / perl interpreter, but those locations change from user to user (some people install under c:\, some under the standard location). I would like to have the scripts work for any system. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RFE?: CygWinDir in ENV? (was Re: How does one find where Cygwin was installed from Windows?)
On Tue, 10 Feb 2009, Larry Hall (Cygwin) wrote: Tim McDaniel wrote: I have several trampoline scripts, a bat file doing nothing but invoking a corresponding bash shell script or Perl program. I have to hard-code a location for the bash / perl interpreter, but those locations change from user to user (some people install under c:\, some under the standard location). I would like to have the scripts work for any system. This can be done now, That appears to contradict what you wrote yesterday: ] If you need to do this generically for any batch file, then yes, you ] have to rely on external data and heuristics. Going to the registry ] to see if it will help or searching the file system are two ] alternatives but there is no one key or one spot that will ] unequivocally give you the installation path. Looking at the mount ] paths in the registry will work for 1.5 but is flawed for 1.7. ] Looking in the file-system may work depending on what you look for ] and where you start looking. You did mention ] HKLM/Software/Cygwin/setup, the rootdir value. But you noted that that is in version 1.7. (When mentioning it, by the way, you might also mention REG.exe, a program to do registry access, and the options for FOR that allow running a program and getting the results in a variable in CMD.exe. I hadn't heard of REG until I went searching just now.) -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RFE?: CygWinDir in ENV? (was Re: How does one find where Cygwin was installed from Windows?)
On Tue, 10 Feb 2009, Larry Hall wrote: Tim McDaniel wrote: I have several trampoline scripts, a bat file doing nothing but invoking a corresponding bash shell script or Perl program. I have to hard-code a location for the bash / perl interpreter, but those locations change from user to user (some people install under c:\, some under the standard location). I would like to have the scripts work for any system. ... (When mentioning it, by the way, you might also mention REG.exe, a program to do registry access, and the options for FOR that allow running a program and getting the results in a variable in CMD.exe. I hadn't heard of REG until I went searching just now.) Sounds similar to Cygwin's 'regtool'. Definitely would be helpful if you're trying to batch script something like this. Well, not in *this* special case, because like this is trying to find the Cygwin installation in the first place; if it knew where regtool was, it would already know where Cygwin was installed ... But thanks for the pointer to regtool -- I'll make a note of it for other uses. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: read file with windows filenames
On Thu, 29 Jan 2009, Matthias Meyer wrote: while IFS= read -r cLine do echo $cLine attrib +H $cLine done restoreFiles.tmp rm -f restoreFiles.tmp will stop the while loop after the first call of attrib: + echo 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500 + attrib +S 'C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Microsoft\Credentials\S-1-5-21-1606980848-1532298954-1801674531-500' + IFS= + read -r cLine + test 0 -gt 0 + rm -f restoreFiles.tmp Did anyone know what happens there? Given that the debug output has attrib +S but the code at top has attrib +H, and that the debug output has test 0 -gt 0 that the code doesn't have just before the loop exit, it is probably necessary for you to publish the actual code that's failing, even if it has details that you're 100% certain are irrelevant and unimportant. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setting Integer Variables in Bash
On Thu, 29 Jan 2009, whitewall thewhitew...@live.co.uk wrote: The text below is from a text file. If I type the commands line-by-line in the bash then the commands work as expected. If I save the commands in a text file and call the script I get the error message: ': not a valid identifier2: declare: 'Red ': not a valid identifier3: declare: 'Green Two error messages. #! /cygdrive/c/cygwin/bin/bash declare -i Red declare -i Green Red=10 Green=$Red+1 echo $Green exit 0 You have a carriage return at the end of each line. bash does NOT consider carriage return to be whitespace, dammit, so it is considered normal characters. So it things, for example, that you're declaring a variable named Red\r, a four-character name, and it just doesn't allow carriage return in the variable name. The key to recognizing the situation is to see ': not a valid identifier2: declare: 'Red and recognize that there's a carriage return in the middle of the message. The opening ' is just before Red. Its matching closing ' is shown as the start of the line -- because carriage return causes the output display to return to the start of line. So - by default, created files in UNIX file format, not native Windows. - strip out the carriage returns from your existing script -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setting Integer Variables in Bash
On Thu, 29 Jan 2009, Mark J. Reed wrote: On Thu, Jan 29, 2009 at 5:54 PM, whitewall wrote: #! /cygdrive/c/cygwin/bin/bash declare -i Red declare -i Green Red=10 Green=$Red+1 Since you've declared both Green and Red as integer, you should just do Green=Red+1, without the dollar sign. Doing Green=$Red+1 first takes Red's value, which is stored as an integer, expands it back into its decimal string representation, and then reparses it to yield its integer value. There IS one subtle difference. If you're running with set -x, Green=$Red+1 will echo + Green=10+1 But Green=Red+1 will echo + Green=Red+1 (assuming that you've not changed PS4, IFS, c c). You can decide which set -x output you like. I found that I preferred the substituted forms, the ones with $this and $that. -- Tim McDaniel, t...@panix.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl.exe: fatal error on Vista
On Wed, 13 Aug 2008, hce [EMAIL PROTECTED] wrote: On 8/13/08, Reini Urban [EMAIL PROTECTED] wrote: I would try rebase with -v (verbose) and also tie it to a log file. $ rebaseall -v | tie rebaseall.log There is no tie command Reini must have meant the tee command. It's intended to be a T-joint, metaphorically: it copies all its input to the filename argument and also to its standard output. It's most commonly used to saving output into a log file while also monitoring it as it is generated, as intended here. -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Funny behavior with echo command in bash_login
On Mon, 11 Aug 2008, B'Joe [EMAIL PROTECTED] wrote: This is my bash_login: echo Portable Cygwin v1.0.0.0 alpha echo **NOTE** echo Cygwin making modification in HKCU registry echo To completely clean Cygwin Portable echo installation run clean.bat in root directory echo and this is what I get while login: Portable Cygwin v1.0.0.0 alpha **NOTE** Cygwin making modification in HKCU registry To completely clean Cygwin Portable installation run clean.bat in root directory Data Mail max_mem.c mbox msmtp.log procmail.log tmp Look at the last line, bash seen interpreted my echo command in last line as ls command, that not suppose to be. It *is* supposed to be. Unlike cmd on Windows, metacharacters like * and ? and [...] are interpreted by bash. *...* is equivalent to *, and * matches all the files in the current directory. In general, quote your arguments. Single-quote unless you want to do variable interpolation ($abc), in which case double-quote. echo 'Portable Cygwin v1.0.0.0 alpha' echo '**NOTE**' echo 'Cygwin making modification in HKCU registry' echo 'To completely clean Cygwin Portable' echo 'installation run clean.bat in root directory' echo '' -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, 8 Aug 2008, Luke Kendall wrote: On 4 Aug, Gary R. Van Sickle wrote: explorer /e,$XPATH disown %- Don't try this variant, though, since it doesn't work: explorer /e,$XPATH disown %- What happens if you try that innocuous-looking variant is that Cygwin (or bash?) normalises the path /e,... to a windows path first, producing \e,... I'm an utter fanatic about quoting to make sure that what I have in variables isn't munged. So I'm dismayed to learn that quoting can *cause* munging and that something munges values in new and exciting ways. Is there any documentation on who rewrites arguments, under what conditions, and how they're altered? -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, 8 Aug 2008, Lev Bishop [EMAIL PROTECTED] wrote:
On Fri, Aug 8, 2008 at 12:28, Christopher Faylor wrote:
Is there any documentation on who rewrites arguments, under what
conditions, and how they're altered?
I missed this when it was first mentioned.
I've skipped parts of this thread, so my reply here may well be
repeating something recently said.
Cygwin doesn't munge command line arguments. Why would it assume
that /e,something was a windows path? That makes no sense.
Nobody is munging anything.
What's going on here is as simple as the difference:
bash-3.2$ cmd /c echo a b c
a b c
bash-3.2$ cmd /c echo a b c
a b c
There's really no more to it than that.
Actually, bash *does* munge arguments passed to Windows commands,
but by surrounding them with double quotes when invoking the commands,
not by translating paths. To wit:
Except that on 4 Aug, Gary R. Van Sickle wrote:
# Easy Explorer here command with tree control on the left
x()
{
if [ ${1} = ];
then
# No parameter given, open Explorer in the current directory.
XPATH=.;
else
# Open the given path.
XPATH=$(cygpath -w ${1});
fi
explorer /e,$XPATH disown %-
}
and Luke replied
Don't try this variant, though, since it doesn't work:
explorer /e,$XPATH disown %-
What happens if you try that innocuous-looking variant is that
Cygwin (or bash?) normalises the path /e,... to a windows path
first, producing \e,...
I used this function, to control the quoting and to avoid stomping on
/usr/bin/X11/x:
# Source this file only.
xx()
{
WHICH=explorer
# WHICH=local/test/032.bat
# WHICH=cmd /c $WHICH
if [[ $2 = ]];
then
# No parameter given, open Explorer in the current directory.
XPATH=.;
else
# Open the given path.
XPATH=$(cygpath -w $2);
fi
if [[ $1 = quote ]]; then
(set -x; $WHICH /e,$XPATH) disown %-
else
(set -x; $WHICH /e,$XPATH) disown %-
fi
}
Luke is halfway correct: quoting $XPATH can make it fail, but
apparently not for the reason he thinks. If xx is called as
xx noquote '/Program Files'
(that is, avoiding quoting of $XPATH), it works, but
xx quote '/Program Files'
results in a Windows Explorer error window saying
The path '/e,C:\Program Files' does not exist or is not a
directory.
Mucking about in a cmd window shows that
explorer /e,C:\Program Files
gives the correct result while
explorer /e,C:\Program Files
gives the same Windows Explorer error window as above.
And explorer insists on ,, not a space. That all totally sucks.
(I was curious:
explorer '/e,C:\Program Files'
gives the error box but saying that 'C:\Program Files' doesn't exist.)
Doing a simple test:
#! /bin/bash
XPATH='C:\Program Files'
if [[ $1 = quote ]]; then
(set -x; local/test/032.bat /e,$XPATH) disown %-
else
(set -x; local/test/032.bat /e,$XPATH) disown %-
fi
where 032.bat is
@echo off
echo in bat
for %%f in (%*) do echo arg %%f
I find that, with /e,$XPATH, bash just passes it down as separate
arguments,
arg /e
arg C:\Program
arg Files
but with /e,$XPATH, bash actually passes a real double-quoted
string:
arg /e,C:\Program Files
which explorer.exe refuses to accept because it's idiotic
as aforesaid.
explorer /e,C:\Program Files
would work too, but I don't see how to get bash to generate it.
That's most unpleasant. I don't suppose there's any way to control
Cygwin's bash in re where to put double quotes around arguments being
passed to a Windows command (since getting Microsoft to make
explorer.exe be sane is hopeless)? Except by not using characters
that bash thinks need quoting.
I found two workarounds that have safe quoting of $XPATH:
XPATH=$(cygpath -s -w $2); # produce the Windows short name
...
cmd /c explorer /e,$XPATH
(that's the not using characters that need quoting path) or
XPATH=$(cygpath -w $2);
...
cmd /c explorer /e,$XPATH
Again, my apologies if this has all been covered recently -- I was too
lazy to check the list archives as I should have.
--
Tim McDaniel, [EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Bizarre Cygwin/Explorer/paths problem half-solved
On Fri, 8 Aug 2008, Christopher Faylor [EMAIL PROTECTED] wrote: On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote: That's most unpleasant. I don't suppose there's any way to control Cygwin's bash in re where to put double quotes around arguments being passed to a Windows command (since getting Microsoft to make explorer.exe be sane is hopeless)? Except by not using characters that bash thinks need quoting. I'd be very surprised if bash was doing anything different for Windows than it does for linux. cygwin1.dll does do some quoting of arguments to non-cygwin programs if it thinks it is required. Well, *something* had to be adding the double-quotes. It's execve() and such adding them, then? But, no, we're not going to implement a complicated scheme to turn that off for random programs. -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: environment variables derived from TMPDIR
On Tue, 5 Aug 2008, Kurt Franke [EMAIL PROTECTED] wrote: Ralf Fassel ralfixx at gmx.de writes: In a SHELL script I prepare a temp file to pass to some non-cygwin program: # TMPDIR is set to c:/temp outside of cygwin # which translates to /cygdrive/c/temp inside cygwin # prepare input TMPFILE=$TMPDIR/foo.$$ cat $TMPFILE \EOF some stuff EOF # call program: error: no such file /cygdrive/c/temp/foo.1234 # filename should be c:/temp/foo.1234 external_program $TMPFILE Now TMPFILE is passed to the external program using POSIX path notation which it does not understand. If possible I'd like to avoid using 'cygpath' in the script since it should run on different platforms. you may check if the cygpath usage is valid before do it: is_CYGWIN=`uname | grep CYGWIN | wc -l` if [ $is_CYGWIN -gt 0 ] then TMPDIR=`cygpath -w $TMPDIR` fi # continue with your code here My notion is in the vicinity of duck typing and EAFP (Easier to Ask Forgiveness than Permission). The best way to see whether cygpath can do what you want is to call cygpath to do what you want # I use /bin/cygpath so that I don't have to depend on PATH being # set correctly. if new_TMPDIR=`/bin/cygpath -w $TMPDIR 2/dev/null`; then TMPDIR=$new_TMPDIR fi unset new_TMPDIR # I like to explicitly kill dead variables much like it's common advice that, when you want to know whether a file is readable at the start of using it in your program, you should simply try to open it for reading and catch the error or exception if it's not. -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash shell interface broken after install on Vista
On Sun, 3 Aug 2008, Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, Aug 03, 2008 at 02:36:49PM -0500, [EMAIL PROTECTED] wrote: Since you just installed Cygwin and didn't configure it much, have you considered just uninstalling and reinstalling from a new mirror? The mirror checking software runs four times a day to weed out bad mirrors. It's very unlikely that a new installation would have problems that were due to a mirror. The original problem report mentioned it hanging during the download or install, I forget which. I wondered whether it might have been some odd networking problem with that particular mirror. (I've had odd networking problems in the past, even in Linux.) It's also an obvious fix technique, if it works, but he later said it didn't. -- Tim McDaniel, [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
