Re: Capturing a Cygwin instance from another PC (CORRECTION)
*** CORRECTION On 2023-11-22 9:53 am, Jose Isaias Cabrera via Cygwin wrote: I have a new Win11 PC, and I wanted to capture the same Cygwin setup that I have in another Win10 PC. I copied the C:\cygwin64 folder from the Win10 pc to the Win11 pc, then I downloaded a fresh setup-x86_64.exe from cygwin.com to the win11 PC. I ran it and chose "Install from Local Directory" and only one shortcut for "Cygwin64 Terminal" was created on the desktop. No Cygwin nor Cygwin-X folders were created on the Start menu. The original cygwin from the Win10 PC had X installed also. Any idea how to get this done automatically? I know I can go and create folders manually, etc., but it kind of a pain. Any help would be greatly appreciated. Thanks. josé Unfortunately you can't "just copy it" because Cygwin sets up file permissions and creates symlinks in very particular ways. Even using WinRAR in Admin mode with all the capturing things turned on won't give you an exact copy. To create a snapshot of a Cygwin installation you have to do it within Cygwin itself and then unpack it in another Cygwin environment. The best option is this: 1. On the source: tar -vczf /cygwin64.tgz /etc /sbin /usr /var 2. Install only the *** Base category *** on the new machine using setup.exe 3. Unpack on the new machine: cd /; tar -vxzf /cygwin64.tgz If you just want to duplicate the package selection this trick is all you need. 1. Get the current list: cygcheck -cd |perl -ane '$\=","; print $F[0]' 2. Ignore the "Cygwin,Package" at the front. 3. Copy all that and put it as the command line argument to setup.exe -P You can see setup options with setup.exe -h. HTH, thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Capturing a Cygwin instance from another PC
On 2023-11-22 9:53 am, Jose Isaias Cabrera via Cygwin wrote: I have a new Win11 PC, and I wanted to capture the same Cygwin setup that I have in another Win10 PC. I copied the C:\cygwin64 folder from the Win10 pc to the Win11 pc, then I downloaded a fresh setup-x86_64.exe from cygwin.com to the win11 PC. I ran it and chose "Install from Local Directory" and only one shortcut for "Cygwin64 Terminal" was created on the desktop. No Cygwin nor Cygwin-X folders were created on the Start menu. The original cygwin from the Win10 PC had X installed also. Any idea how to get this done automatically? I know I can go and create folders manually, etc., but it kind of a pain. Any help would be greatly appreciated. Thanks. josé Unfortunately you can't "just copy it" because Cygwin sets up file permissions and creates symlinks in very particular ways. Even using WinRAR in Admin mode with all the capturing things turned on won't give you an exact copy. To create a snapshot of a Cygwin installation you have to do it within Cygwin itself and then unpack it in another Cygwin environment. The best option is this: 1. On the source: tar -vczf /cygwin64.tgz /etc /sbin /usr /var 2. Install only base-cygwin on the new machine using setup.exe 3. Unpack on the new machine: cd /; tar -vxzf /cygwin64.tgz If you just want to duplicate the package selection this trick is all you need. 1. Get the current list: cygcheck -cd |perl -ane '$\=","; print $F[0]' 2. Ignore the "Cygwin,Package" at the front. 3. Copy all that and put it as the command line argument to setup.exe -P You can see setup options with setup.exe -h. HTH, thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Run a Cygwin process with "higher" scheduler priority
On 2023-10-14 7:39 am, Cedric Blancher via Cygwin wrote: I know about nice and renice, but I don't see whether it is working or not. Is there anything in /proc which can tell me the current *Windows* scheduler priority level? Or a command line tool? Ced Iarn's TaskInfo will show you the real Windows priority (and let you change it and even suspend processes) along with a boatload of other highly useful stats. That will let you validate anything Cygwin claims it did. https://www.iarsn.com/taskinfo.html It's old but it still works and I run it continuously. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod g+s ineffective
On 6/29/2022 9:18 AM, Norton Allen wrote: On one machine I have, chmod g+s fails to set the sticky bit. The >>> command does not return any error, but ls -l continues to show the bit not set. $ mkdir foo $ chgrp flight foo $ chmod g+ws foo $ ls -ld foo drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo Hi. The permission bits are implemented as normal Window's DACLs (Discretionary Access List). +s is implemented magically with the NULL SID. You can view it from Explorer or with icacls. Try checking the return code (echo $?) from chmod. Also try changing perms from Explorer. You might not be able to set the NULL SID for some reason. It works for me: $ ls -ld z drwxrwsr-x+ 1 wagnerc Users 0 Nov 24 2020 z $ getfacl z # file: z # owner: wagnerc # group: Users # flags: -s- user::rwx group::r-x group:Administrators:rwx group:Users:rwx mask::rwx other::r-x default:user::rwx default:user:wagnerc:rwx default:group::r-x default:group:Administrators:rwx default:group:Users:rwx default:mask::rwx default:other::r-x $ icacls z z NULL SID:(DENY)(Rc,S,WD,REA,WEA,X,DC) APPLEJACK\wagnerc:(F) BUILTIN\Users:(RX) BUILTIN\Administrators:(RX,W,DC) BUILTIN\Users:(RX,W,DC) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,WD,REA,WEA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) APPLEJACK\wagnerc:(OI)(CI)(IO)(RX,W,DC) BUILTIN\Users:(OI)(CI)(IO)(RX) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) BUILTIN\Users:(OI)(CI)(IO)(RX,W,DC) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ uname -a CYGWIN_NT-6.1 applejack 3.1.0(0.340/5/3) 2019-11-19 13:58 x86_64 Cygwin Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Could rm remove files and folders with colon in their name?
On 2021-11-10 3:39 pm, Corinna Vinschen via Cygwin wrote: To the contrary. The problem is the ambiguity that "X:/foo" might be either the absolute POSIX path $CWD/X:/foo, or the absolute DOS path "X:\foo". I have a patch which fixes your case, but not much else. The problem is that we historically allow DOS paths as input at all. That was a bad decision from the start, but you can't easily change 25 years of history... To contribute my 2 cents, native support for DOS paths is invaluable for me. Changeing that would break a lot of Windows/POSIX integration. The simple fix for all weird/ambiguous names is to qualify it with `./...`. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: wildcards don't work in directory with files with odd characters
On 2020-05-19 6:49 am, Andrey Repin wrote: Then take a look at this thread: https://cygwin.com/pipermail/cygwin/2020-March/thread.html#174 You'll need correctly configured LANG and CYGWIN's glob option. That info should definately be in the FAQ. Although I would still consider this behavior a bug. C:\cygwin64\tmp\wild>dir 05/18/2020 09:46 PM 0 foo 05/18/2020 09:55 PM 0 Highlander-S03E21-Finalé_Part_I-22.mkv C:\cygwin64\tmp\wild>set LANG= C:\cygwin64\tmp\wild>ls * ls: cannot access '*': No such file or directory C:\cygwin64\tmp\wild>set LANG=en_US C:\cygwin64\tmp\wild>ls * foo Highlander-S03E21-Finalé_Part_I-22.mkv C:\cygwin64\tmp\wild>set LANG=x C:\cygwin64\tmp\wild>ls * ls: cannot access '*': No such file or directory C:\cygwin64\tmp\wild>set LANG=en C:\cygwin64\tmp\wild>ls * foo C:\cygwin64\tmp\wild>set LANG=de C:\cygwin64\tmp\wild>ls * foo C:\cygwin64\tmp\wild>set LANG=en_US C:\cygwin64\tmp\wild>ls * foo Highlander-S03E21-Finalé_Part_I-22.mkv Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: wildcards don't work in directory with files with odd characters
On 2020-05-18 8:40 am, jeff wrote: I have a directory that has some files with odd files. I can do a 'ls', successfully. However if I do a 'ls *'' I get: ls: cannot access '*': No such file or directory Here is ls output: 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv' 'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv' I can confirm this. I've seen weirdo behavior before with Cygwin commands having to interpret wild cards internally. It's probably related to some wonky unicode optimization or incomplete wildcard implementation. This falls under the category of "don't do that". :) Mintty: $ uname -a; cygcheck -c coreutils CYGWIN_NT-6.1 applejack 3.1.0(0.340/5/3) 2019-11-19 13:58 x86_64 Cygwin Cygwin Package Information Package VersionStatus coreutils8.26-2 OK wagnerc@applejack /tmp/wild $ touch 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'; dir * -rw-rw-r--+ 1 0 May 18 21:46 foo -rw-rw-r--+ 1 0 May 18 21:55 Highlander-S03E21-Finalé_Part_I-22.mkv CMD: C:\cygwin64\tmp\wild>dir Volume in drive C is INTELWINNT Volume Serial Number is 642B-E7BA Directory of C:\cygwin64\tmp\wild 05/18/2020 09:46 PM . 05/18/2020 09:46 PM .. 05/18/2020 09:46 PM 0 foo 05/18/2020 09:55 PM 0 Highlander-S03E21-Finalé_Part_I-22.mkv 2 File(s) 0 bytes 2 Dir(s) 35,887,038,464 bytes free C:\cygwin64\tmp\wild>ls 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv' foo C:\cygwin64\tmp\wild>ls * ls: cannot access '*': No such file or directory C:\cygwin64\tmp\wild>ls f* foo C:\cygwin64\tmp\wild>ls H* ls: cannot access 'H*': No such file or directory Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Groups command failing me in Windows 10
On 2020-05-12 3:45 pm, David wrote: The groups command in the cmd window on Windows 10 shows None as my first group. When I use the dir command to create a file, the security display shows no error. When I use the touch command to create a file, I get "The permissions on ... are incorrectly ordered [NULL if first] Hi David. The first thing to realize is that POSIX permissions and Windows ACLs are almost impossible to reconcile. Best to pick one and ignore the other. https://cygwin.com/cygwin-ug-net/ntsec.html has additional information. To set your group you should do it in /etc/passwd. If you don't have one, do: mkpasswd > /etc/passwd Then edit the file and change the 4th field on the line with your username to the group Id for Users. david:*:123456:197153: -> david:*:123456:545: Then restart ALL Cygwin processes and id should show Users as your primary group. Any files created by a Windows process however will still put None as the group. Hope that helps. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Default mingw _WIN32_WINNT
On 2020-05-11 12:53 pm, Yaakov Selkowitz wrote: I would just like to chime in that it would be a crying shame if Cygwin were to ever drop support for Windows 7. There are many people, myself one, who are dead set against Windows 10. "Ever"?!? You do realize that, ESU aside, Windows 7 is out of support and therefore should be assumed to be vulnerable? I suspect that something one day will make it untenable but Windows 7 is no less secure or more vulnerable than it was a year ago. All software should always be assumed to be always vulnerable. Is 10 secure on patching day but then vulnerable until the next patch day? The number of vulns in any software is fixed on the day it ships and it's whittled down as patches come out. 7 has had a heck of a lot of security fixes. It's new software that increases security holes. I have to use 10 at work and it is a ghastly operating system. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Default mingw _WIN32_WINNT
On 2020-05-05 5:05 am, Rainer Emrich wrote: Hi Corinna, Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: Therefore it might be a good idea to bump the default for these Cygwin-related headers to at least 0x0600. Setting them to 0x0602 sounds like a good idea, but as long as we didn't drop Vista or W7 support it might be premature. Btw., checking Cygwin sources for Vista and W7-specific code, it turned out that actually very few lines of code handle Vista or W7-specific workarounds. The advantage of removing the code is pretty minor, so I didn't push the changes. While it's a bad idea to keep Vista and W7 running (at least attached to the internet), we can support them a while longer. I would expect support for Windows 7 as long as the Micsrosoft ESU program is active. I would just like to chime in that it would be a crying shame if Cygwin were to ever drop support for Windows 7. There are many people, myself one, who are dead set against Windows 10. Thanks. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Mailing list issues
Hi folks, I'm having some issues with getting mail from this list. The first one is that I'm getting a decent number of messages diverted into spam holding over protocol violations. For example this one has two reply-to headers. Reply-To: cygwin@cygwin.com Authentication-Results: sourceware.org; auth=none From: Brian Inglis Subject: [ANNOUNCEMENT] [New] cpuid 20200211 Reply-To: Cygwin Announcements To: cygwin@cygwin.com Message-Id: Date: Sun, 23 Feb 2020 22:56:31 -0700 X-Spampanel-Evidence: Bad header count. The second issue is causing some of the list mail to not be filtered. I started getting messages like this a couple days ago. The list-id header is this List-Id: Cygwin mailing list instead of List-Id: like 99% of the mail. Is this an error or the new normal? Thanks. "--Problem reports: http://cygwin.com/problems.htmlFAQ: http://cygwin.com/faq/Documentation: http://cygwin.com/docs.htmlUnsubscribe info: http://cygwin.com/ml/#unsubscribe-simple";
Re: about downloading Cygwin using linux
The first thing to consider is that Windows XP is no longer supported by the main Cygwin code base. https://cygwin.com/cygwin-ug-net/setup-net.html If you really need to install on XP, you'll have to find a snapshot of the last repository that supported it. That would be anything prior to Cygwin 2.6. http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html Download the appropriate Setup program and follow the instructions. I have no idea if this still works. In any case, you can run Setup on another machine with internet connectivity in download only mode, then copy that downloaded directory tree to the offline machine and run Setup there. If that's not possible, you can just wget -r the appropriate package directories and copy them to the other machine. HTH. Thanks. -- 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: bug with grep 3.0.2 in cygwin 3.0.7
On 2019-08-28 3:16 am, ak...@free.fr wrote: Hi, I encounter some problem with grep option -E on cygwin 3.0.7 echo "a^b" | grep "a^b" #answer a^b ie it's OK but echo "a^b" | grep -E "a^b" #answer nothing " for me it's KO I have to backslash ^ to be OK like : grep -E 'a\^b' Is-it a bug ? I don't know if all versions of cygwin and grep are concerned. Hi Akiki. As others mentioned, it has to do with how regular expressions operate. However the best solution for you in this situation is to not use regular expressions. To search for fixed strings, use fgrep or grep -F. That avoids all issues with meta characters and covers the vast majority of cases when we use grep anyway. To use full power regular expressions read perlre and use grep -P. Thanks. -- 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: find command seems to lock files
On 2019-08-19 8:33 am, Morten Kjærulff wrote:
find //$server/d$/dir/subdir*/subsubdir -name 'thefile' -printf '%A+\n'
Problem is that it seems this command locks thefile, as the application
sometimes can't delete it.
Unfortunately, yes. On Windows, a "full stat" requires that the file be
opened.
This is why Perl has the ${^WIN32_SLOPPY_STAT} flag variable.
https://metacpan.org/pod/distribution/perl/pod/perlvar.pod#${^WIN32_SLOPPY_STAT}
${^WIN32_SLOPPY_STAT}
If this variable is set to a true value, then stat() on Windows will
not try to open the file. This means that the link count cannot be
determined and file attributes may be out of date if additional
hardlinks to the file exist. On the other hand, not opening the file is
considerably faster, especially for files on network drives.
-Chris
--
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: Perl Illegal Instruction
Apologies for the necropost but the solution deserves to be documented. I suspected that it could be a rebasing issue and sure enough having Setup do a rebase fixed the problem. Rebasing should probably be the first thing to do whenever you get some weird execution error from a Cygwin program. Thanks. On 2019-07-16 1:37 am, Achim Gratz wrote: Chris Wagner writes: Of course it's up to date... I'll let that stand, although I've seen sufficiently many Win7 systems lately to be wary of any such statement. That is not BLODA. That's the standard list of libraries. I changed nothing; it worked yesterday; today it didn't. Every other Cygwin executable I've tried works without problem. I even tried reextracting the files from perl_base. So again, something changed and you have no idea what. If you rule out a hardware error (memory most likely if it always strikes at the same place) and you didn't actively made changes (not limited to Cygwin), then the culprit must by definition be some change that occured elsewhere in the system. If it was some automatic update there might be a restore point pertaining to those changes and certainly something in the event logs. $ uname -a CYGWIN_NT-6.1 applejack 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin A current Cygwin... $ cygcheck -c perl perl_base Cygwin Package Information Package VersionStatus perl 5.22.4-1 OK perl_base5.22.4-1 OK combined with an outdated Perl (Cygwin is at 5.26.3 now). What are you trying to achieve? Please fully update Cygwin after checking your system. Also, you might want to clean up your PATH a bit. I'm not going to recompile all my modules and rework the new lib paths until I have a really good reason to. As they say, "you break it, you get to keep the broken pieces". Trying to lock down part(s) of Cygwin is a losing proposition unless you are building everything yourself, at which point building a bunch of Perl modules after an update ceases to be an issue anyway. I'ld be happy to run any other diagnostic command anyone can think of. Well, as I said, try to start with some halfway sane PATH perhaps? In other words, something like env PATH=/bin perl --version for starters. Regards, Achim. -- 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: Perl Illegal Instruction
On 2019-07-15 3:46 pm, Achim Gratz wrote: Chris Wagner writes: For some reason this afternoon, after having worked fine, my Perl stopped working. There was no error message. It just silently died with status 0 no less. Windows 7 SP1. Terribly out of date and no longer safe to use on a networked system. Of course it's up to date... So I turn to strace and it states Illegal Instruction. Any ideas? BLODA or worse, assuming that _you_ didn't change anything recently. That is not BLODA. That's the standard list of libraries. I changed nothing; it worked yesterday; today it didn't. Every other Cygwin executable I've tried works without problem. I even tried reextracting the files from perl_base. $ uname -a CYGWIN_NT-6.1 applejack 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin A current Cygwin... $ cygcheck -c perl perl_base Cygwin Package Information Package VersionStatus perl 5.22.4-1 OK perl_base5.22.4-1 OK combined with an outdated Perl (Cygwin is at 5.26.3 now). What are you trying to achieve? Please fully update Cygwin after checking your system. Also, you might want to clean up your PATH a bit. I'm not going to recompile all my modules and rework the new lib paths until I have a really good reason to. I'ld be happy to run any other diagnostic command anyone can think of. Thanks. -- 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
Perl Illegal Instruction
Hi folks. For some reason this afternoon, after having worked fine, my Perl stopped working. There was no error message. It just silently died with status 0 no less. Windows 7 SP1. $ /usr/bin/perl.exe -v $ echo $? 0 So I turn to strace and it states Illegal Instruction. Any ideas? Thanks. $ strace -n -m all /usr/bin/perl.exe -v --- Process 26136 created --- Process 26136 loaded C:\Windows\System32\ntdll.dll at 7733 --- Process 26136 loaded C:\Windows\System32\kernel32.dll at 7711 --- Process 26136 loaded C:\Windows\System32\KernelBase.dll at 07fefd08 --- Process 26136 loaded C:\cygwin64\bin\cygperl5_22.dll at 0003f8e4 --- Process 26136 loaded C:\cygwin64\bin\cygcrypt-0.dll at 0003ffa9 --- Process 26136 loaded C:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 26136 loaded C:\cygwin64\bin\cygssp-0.dll at 0003f88d 0 0 [main] perl (26136) ** 103 103 [main] perl (26136) Program name: C:\cygwin64\bin\perl.exe (windows pid 26136) 48 151 [main] perl (26136) OS version: Windows NT-6.1 41 192 [main] perl (26136) ** --- Process 26136 loaded C:\Windows\System32\advapi32.dll at 07fefd8e --- Process 26136 loaded C:\Windows\System32\msvcrt.dll at 07fefdc8 --- Process 26136 loaded C:\Windows\System32\sechost.dll at 07feff5d --- Process 26136 loaded C:\Windows\System32\rpcrt4.dll at 07fefd71 --- Process 26136 loaded C:\Windows\System32\cryptbase.dll at 07fefcd2 49125104 [main] perl (26136) sigprocmask: 0 = sigprocmask (0, 0x0, 0x18030AD30) 9906094 [main] perl (26136) open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x84, *m 6 1046198 [main] perl (26136) user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 1026300 [main] perl (26136) open_shared: name S-1-5-21-3582216975-893534028-59465-1002.1, n 1, shared 0x18002 (wanted 0x18002), h 0x80, *m 6 856385 [main] perl (26136) user_info::create: opening user shared for 'S-1-5-21-3582216975-893534028-59465-1002' at 0x18002 686453 [main] perl (26136) user_info::create: user shared version AB1FCCE8 1036556 [main] perl (26136) fhandler_pipe::create: name \\.\pipe\cygwin-e022582115c10879-26136-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 1006656 [main] perl (26136) fhandler_pipe::create: pipe read handle 0x98 466702 [main] perl (26136) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-e022582115c10879-26136-sigwait 646766 [main] perl (26136) fhandler_pipe::create: pipe write handle 0x9C 486814 [main] perl (26136) dll_crt0_0: finished dll_crt0_0 initialization --- Process 26136, exception c01d at 0003f88d18d3 --- Process 26136 exited with status 0xc01d Illegal instruction $ uname -a CYGWIN_NT-6.1 applejack 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin $ cygcheck -c perl perl_base Cygwin Package Information Package VersionStatus perl 5.22.4-1 OK perl_base5.22.4-1 OK $ cygcheck -v /usr/bin/perl.exe C:\cygwin64\bin\perl.exe - os=4.0 img=0.0 sys=5.2 "perl.exe" v0.0 ts=2017-07-15 19:17 C:\cygwin64\bin\cygperl5_22.dll - os=4.0 img=0.0 sys=5.2 "cygperl5_22.dll" v0.0 ts=2017-07-15 19:12 C:\cygwin64\bin\cygcrypt-0.dll - os=4.0 img=0.0 sys=5.2 "cygcrypt-0.dll" v0.0 ts=2017-09-03 08:18 C:\cygwin64\bin\cygwin1.dll - os=4.0 img=0.0 sys=5.2 "cygwin1.dll" v0.0 ts=2019-04-30 19:08 C:\Windows\system32\KERNEL32.dll - os=6.1 img=6.1 sys=6.1 "KERNEL32.dll" v0.0 ts=2019-06-12 15:36 Warning: C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-RtlSupport-L1-1-0.dll" v0.0 ts=2019-06-12 14:55 C:\Windows\system32\ntdll.dll - os=6.1 img=6.1 sys=6.1 "ntdll.dll" v0.0 ts=2019-06-12 14:59 C:\Windows\system32\KERNELBASE.dll - os=6.1 img=6.1 sys=6.1 "KERNELBASE.dll" v0.0 ts=2019-06-12 15:35 C:\Windows\system32\ntdll.dll (already done) Warning: C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-ProcessThreads-L1-1-0.dll" v0.0 ts=2019-06-12 14:55 Warning: C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-
Re: Windowless Perl
On 2019-06-10 3:24 pm, Achim Gratz wrote: Chris Wagner writes: Perl maintainers, I was wondering why the Cygwin Perl distribution does not contain a windowless Perl executable, wperl.exe. Because nobody needs it? Directly executing the standard perl.exe from Windows causes a command console to pop up. I've had it before in other distros but it would be super handy to execute completely headless Perl scripts with Cygwin access. That's what "run" is for, actually. Well I would have a good use for it. I didn't know about run, thanks for the tip. However when I use it to launch something from the Start Menu Run command, it still pops open a terminal window of some kind for a fraction of a second. I'm on Windows 7. Thanks. -- 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
Windowless Perl
Perl maintainers, I was wondering why the Cygwin Perl distribution does not contain a windowless Perl executable, wperl.exe. Directly executing the standard perl.exe from Windows causes a command console to pop up. I've had it before in other distros but it would be super handy to execute completely headless Perl scripts with Cygwin access. Anyone know how I could build it or how to get it added to the distro? Or make it its own package? Thanks. -- 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: Dragging from explorer to cygwin terminal is not putting the path into the terminal
It won't work if the terminal window was started in administrator mode. Something to do with Windows's security isolation. On 2019-06-06 12:26 am, Academy OfFetishes wrote: Hello, I tried to google for this but couldn't find anyone with the same problem. I'm using mintty 3.0.1 and cygwin 3.0.7(0.338/5/3). On my previous computer, if I dragged a file from my explorer to the cygwin terminal, the cygwin terminal used to be populated with the full path to that file. Now when I do this, the cygwin terminal isn't affected. -- 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: Trying to create default ACL entries to match file ACL entries
Hi Linda, / is just a mount to something like C:\Cygwin64 so there is no problem in changing it. You should delete all the target thing's permissions first to guarantee starting from a clean slate. $ setfacl -kb z2/ && getfacl z1/ |setfacl -f - z2/ This works for me with the latest packages. HTH, Chris -- 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: cygrunsrv --install --user : avoid having to enter the user's password
Hi Irfan,
I'm assuming that there is some reason you don't want to use the
password option:
-w, --passwdOptional password for user. Only needed
if a user is given. If a user has an empty
password, enter `-w '. If a user is given
but
no password, cygrunsrv will ask for a
password
interactively.
The password prompt can be scripted with Perl. (Assuming you *have* the
password)
use IO::Pty::Easy;
$io = IO::Pty::Easy->new;
@cmd = qw{cygrunsrv -I name -t manual -p /c/foo.exe -u name};
$io->spawn(@cmd);
printf "read: %s\n", $io->read;
printf "write: %s\n", $io->write("foo\n");
printf "read: %s\n", $io->read;
printf "write: %s\n", $io->write("foo\n");
printf "read: %s\n", $io->read;
$io->close;
Hope that helps.
-Chris
On 2019-05-19 11:49 pm, Irfan Adilovic wrote:
Hi,
(All actions here assume an elevated mintty terminal)
I have the need to automate the installation of autossh as a windows
service (=> several dozen autossh services) and when installing as a
local user, the password prompt is an issue.
Is there a way to add windows services with cygrunsrv from an elevated
mintty bash shell to run as a local user, somehow without requiring
that local user's password each time the service is installed?
--
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: ezmlm warning
Maintainers, I have been getting numerous bounce warnings and spam holds on mail sent to me by the list. The spam holds are due to protocol violations. This ezmlm warning is because of: 550 Messages should have one or no Sender headers, not 2. If the list software could be made more compliant or I could be informed about some loosened setting on my spam panel. Thanks. On 2019-05-06 2:22 pm, cygwin-h...@cygwin.com wrote: Hi! This is the ezmlm program. I'm managing the cygwin@cygwin.com mailing list. Messages to you from the cygwin mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the cygwin mailing list, without further notice. I've kept a list of which messages from the cygwin mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: To receive a subject and author list for the last 100 or so messages, send an empty message to: Here are the message numbers: 216505 216503 216515 216521 216525 216526 216529 216533 216540 216556 216557 216558 216559 216560 216561 216563 216564 216562 216571 216574 216575 216583 216579 216585 216586 216580 216587 216588 216590 216582 216584 216591 216589 216581 216594 216595 216598 216599 216601 216602 216600 216603 216604 216614 216623 216616 216615 216618 216619 216620 216621 216622 --- Enclosed is a copy of the bounce message I received. Return-Path: <> Received: (qmail 67289 invoked for bounce); 24 Apr 2019 18:35:31 - Date: 24 Apr 2019 18:35:31 - From: mailer-dae...@sourceware.org To: cygwin-return-2165...@cygwin.com Subject: failure notice Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : User and password not set, continuing without authentication. 69.64.57.52 failed after I sent the message. Remote host said: 550 Messages should have one or no Sender headers, not 2. -- 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: Are my emails being filtered out?
I too have had ongoing issues getting Cygwin mail. My spam package regularly filters out emails for "protocol" violations which I then have to notice and release. Some were for having multiple Reply-To headers. I even got a notice from the list stating that email to me had been bouncing. So I think that the mailing list software could use some maintenance. Thanks. On 2019-04-17 11:30 am, Brian Inglis wrote: On 2019-04-17 02:06, LRN wrote: I've been sending emails to this list for a couple of weeks now, and no one replies. Do these messages come through at all? I know for a fact that the messages do end up in the ML archives, so they reach at least *some* places. In case this message is being read by anyone: i'm looking either for Yaakov Selkowitz, or for anyone who maintains the glib Cygwin package. Please help, i only have a few months. -- 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: base-files revisited
Personally I wouldn't want to see yet another .directory in home. Endless fractionation of config is one of the things about unix that irks me. This is not to say that there aren't perfectly valid use cases for YACF (yet another config file). Perhaps this would be best served by a new shell configurator package. Or possibly some other already existing shell manager. If someone had a use for a non standard shell config, he could install and run shell-configurator which would walk him through all of the various possibilities for shell initialization. Whether to use foo.d, special files to include, color, etc. It could also save these settings to its own init file that could be applied to new users for organizational use or just to backup your own settings. Thanks. On 2019-04-06 10:08 am, John Morrison wrote: Hi, I've been asked at work to get the standard base-files extended with specifics for the company I work for and wondered if this would be a good time to revisit how the .bashrc file in particular is put together. What I was considering would be introducing a ~/.bashrc.d/ folder and splitting the existing ~/.bashrc file into its component parts; * alias.bashrc * completion.bashrc * functions.bashrc * history.bashrc * shell.bashrc * umask.bashrc and changing .bashrc to source all the *.bashrc files. This would allow easier extension of the bashrc with, in my case, company specific options (proxies, common aliases etc). I was also thinking of taking some more of the sample from https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the colours and some more of the aliases and adding them into the existing sets. Thoughts? I think Achim Gratz took over the base-files from me. Achim, are you still around? Open for a discussion? Kind regards John. -- 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: cygpath -u converts quoted UNC paths to local
On 2019-04-03 12:20 pm, Andrey Repin wrote: Greetings, All! This can be considered "working by design", but it really imposes some serious restrictions on interoperability with Cygwin, that I think can be avoided. ... After some further testing, this seems to be affecting IP-based UNC paths only. The essence is this: $ dir "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" 26.10.2018 18:16 431 online.sh $ cygpath -u \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" /192.168.1.5/wwwroot/ccenter/bin/online.sh $ cygpath -u \\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ cygpath -u "\\HOSTING64.DARKDRAGON.LAN\wwwroot\ccenter\bin\online.sh" //HOSTING64.DARKDRAGON.LAN/wwwroot/ccenter/bin/online.sh $ Using echo is a good way of checking just what the shell is handing to your program. But I totally agree that this is a major interoperability annoyance. I'm using Bash 4.4.12(3): $ echo \\192.168.1.5\wwwroot\ccenter\bin\online.sh \192.168.1.5wwwrootccenterbinonline.sh $ echo "\\192.168.1.5\wwwroot\ccenter\bin\online.sh" \192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo '\\192.168.1.5\wwwroot\ccenter\bin\online.sh' \\192.168.1.5\wwwroot\ccenter\bin\online.sh $ echo \\foo\wwwroot\ccenter\bin\online.sh \foowwwrootccenterbinonline.sh $ echo "\\foo\wwwroot\ccenter\bin\online.sh" \foo\wwwroot\ccenter\bin\online.sh $ echo '\\foo\wwwroot\ccenter\bin\online.sh' \\foo\wwwroot\ccenter\bin\online.sh read -r is an alternate way of getting text into a command line that might otherwise turn into quoting hell. $ read -r; cygpath -u $REPLY \\192.168.1.5\wwwroot\ccenter\bin\online.sh //192.168.1.5/wwwroot/ccenter/bin/online.sh -- 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: Compile perl Win32::OLE module
On 2019-03-29 9:43 pm, Massimo Balestra wrote: Thank you Chris for answering. But the problem is not during the test, but during the compilation itself (make). Yes, I know I could use ActiveState, but I don't want to have two perl installed on my pc. For me it is more important to have cygwin and if OLE does not work it is less important. But I would like to have it work, also because it should work. Thank you again Massimo No problem, let us know when you get it working. -- 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: Compile perl Win32::OLE module
On 2019-03-29 3:56 pm, Massimo Balestra wrote:
Hi,
I am trying to compile the module Win32::OLE but it fails.
I searched on Google and I did not find any good suggestion.
Can anyone help me?
This is what I get:
(This is from cpan but it is the same if I compile manually
downlaoding the tar package)
Hi Massimo. The following changes should let it compile. The tests
working depends on the peculiarities of your Windows version and Excel
version. I would, though, highly recommend using ActiveState Perl along
with their prebuilt module for any OLE work.
--- OLE.xs.bak 2019-03-29 16:29:52.225925700 -0400
+++ OLE.xs 2019-03-29 16:35:28.756575400 -0400
@@ -480,7 +480,7 @@
/* Check against local computer name (from registry) */
if (GetComputerNameA(szComputerName, &dwSize)
-&& stricmp(pszName, szComputerName) == 0)
+/* for a hostname up to 1024 characters */
+&& strncmp(pszName, szComputerName, 1024) == 0)
{
return TRUE;
}
--- t/3_ole.t.bak 2019-03-29 17:53:21.284781500 -0400
+++ t/3_ole.t 2019-03-29 17:39:18.345496000 -0400
@@ -86,6 +86,7 @@
# 1. Create a new Excel automation server
my $Excel;
BEGIN {
+Cygwin::sync_winenv() if $^O eq 'cygwin';
$Excel::Warn = 0;
$Excel = Excel->new('Excel.Application', \&Quit);
$Excel::Warn = 2;
@@ -186,7 +187,7 @@
# 10. Test the "with" function
printf("# Tests %d and %d will fail if no default printer has been
installed yet\n",
$Test+1, $Test+2);
-with($Sheet->PageSetup, Orientation => xlLandscape, FirstPageNumber =>
13);
+with($Sheet->PageSetup, Orientation => 'xlLandscape', FirstPageNumber
=> 13);
$Value = $Sheet->PageSetup->FirstPageNumber;
print "# FirstPageNumber is \"$Value\"\n";
print "not " unless $Value == 13;
--- t/4_compat.t.bak2013-11-28 14:21:41.0 -0500
+++ t/4_compat.t2019-03-29 16:41:19.797676000 -0400
@@ -22,6 +22,7 @@
my $Test = 0;
# 1. Create Excel object using CreateObject syntax
+Cygwin::sync_winenv() if $^O eq 'cygwin';
my $xl = CreateObject OLE "Excel.Application";
unless (defined $xl) {
print "1..0 # skip Excel.Application not installed\n";
--
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
Dependancy Hell (was Re: [ANNOUNCEMENT] Updated: mintty 2.9.9)
On 2019-03-28 7:36 am, Steven Penny wrote: On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote: Mintty can be used to run any command-line application directly (like top, your editor, ...), a shell is not needed. That may be true, the by default Mintty is configure to load Bash. So it is disingenuous so simply say that it does not require a shell, unless you want to change the default to load "top" as you said. I think that part of the issue is that there is no clear definition of a dependancy. I encounter questionable dependancies all the time from Cygwin Setup. If I try to install the wrong thing, there is a whole ecosystem of packages that come with it that I don't want. I just don't install that thing I wanted and live without it or get it another way. Likewise there are dependancies that are merely advisory and the package works just fine without it. I think that a package should only be listed as a dependancy if the upstream package will not even run without it. Things like library packages. Even if it provides core functionality, if the main package will run, it's not a dependancy. Dependancy hell is one of the few things I don't like about Cygwin. Thanks. -- 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: cat.exe failing silently with exit status 3
Thanks for the responses. The uname output was already in my attachment. I executed cat as /usr/bin/cat.exe. Cygcheck cat is also in my original attachment. I attached the cygcheck -svr. The other Cygwin installations referenced are from my debugging and are not active. The missing Perl files are erroneous because I'm still on 5.22.4. The only "new" file is usr/share/doc/groff/examples/mom/elvis_syntax.new. $ stat /usr/bin/cat.exe File: /usr/bin/cat.exe Size: 34323 Blocks: 36 IO Block: 65536 regular file Device: 642be7bah/1680598970d Inode: 3659174697303481 Links: 1 Access: (0755/-rwxr-xr-x) Uid: (197610/ wagnerc) Gid: (197121/ None) Access: 2019-03-26 19:19:34.495208400 -0400 Modify: 2017-02-03 14:40:48.0 -0500 Change: 2019-03-26 19:19:34.495208400 -0400 Birth: 2019-03-26 19:19:34.495208400 -0400 $ file /usr/bin/cat.exe /usr/bin/cat.exe: PE32+ executable (console) x86-64, for MS Windows I have one postinstall error that is due to cat not working. 2019/03/26 19:19:46 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/crypto-policies.sh" Couldn't read current profile 2019/03/26 19:19:46 abnormal exit: exit code=1 Here is a comparison of cygcheck cat and tac. $ cygcheck -v cat Found: C:\cygwin64\bin\cat.exe Found: C:\cygwin64\bin\cat.exe C:\cygwin64\bin\cat.exe - os=4.0 img=0.0 sys=5.2 C:\cygwin64\bin\cygwin1.dll - os=4.0 img=0.0 sys=5.2 "cygwin1.dll" v0.0 ts=2019-03-16 10:50 C:\Windows\system32\KERNEL32.dll - os=6.1 img=6.1 sys=6.1 "KERNEL32.dll" v0.0 ts=2019-01-09 02:36 Warning: C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-RtlSupport-L1-1-0.dll" v0.0 ts=2019-01-09 01:55 C:\Windows\system32\ntdll.dll - os=6.1 img=6.1 sys=6.1 "ntdll.dll" v0.0 ts=2019-01-09 01:58 C:\Windows\system32\KERNELBASE.dll - os=6.1 img=6.1 sys=6.1 "KERNELBASE.dll" v0.0 ts=2019-01-09 02:34 C:\Windows\system32\ntdll.dll (already done) Warning: C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-ProcessThreads-L1-1-0.dll" v0.0 ts=2019-01-09 01:55 Warning: C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-Heap-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 Warning: C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-Memory-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 Warning: C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-Handle-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 Warning: C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-Synch-L1-1-0.dll" v0.0 ts=2019-01-09 01:55 Warning: C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-File-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-IO-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-ThreadPool-L1-1-0.dll" v0.0 ts=2019-01-09 01:55 Warning: C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-LibraryLoader-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 Warning: C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll hides C:\Program Files\TortoiseSVN\bin\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-Core-NamedPipe-L1-1-0.dll" v0.0 ts=2019-01-09 01:54 C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll - os=6.1 img=6.1 sys=6.1 "API-MS-Win-
cat.exe failing silently with exit status 3
Hi all. A few days ago I noticed that cat.exe was failing without printing any output or errors and exiting with status 3. I tried rebooting, updating my Cygwin, even a fresh install of Base only. I removed all recently installed Windows software and nothing changed. What's truly strange is that it seems to be only cat that is broken. Hilariously tac works fine. I can even emulate cat with "tac foo |tac". Whatever changed, Cygwin, coreutils, or Windows, I can't narrow it down. I'm on Windows 7 SP1 and my Cygwin is up to date (3.0.4-1). Coreutils is 8.26-2. I launched cat with strace and it always ends with: --- Process 3928, exception c005 at --- Process 3928 thread 10476 exited with status 0xc001 --- Process 3928 exited with status 0xc001 The output is vastly truncated compared to what tac shows. The thread dies immediately instead of loading the environment, etc. I attached the strace output of cat and tac along with the sysinfo and cygcheck output. I hope this is just something simple overlooked in the latest version of cat. Thanks in advance. uname -a >cat_straces.txt CYGWIN_NT-6.1 applejack 3.0.4(0.338/5/3) 2019-03-16 09:50 x86_64 Cygwin strace /usr/bin/cat.exe new_benchmarks.pl >>cat_straces.txt 2>&1 --- Process 3928 created --- Process 3928 loaded C:\Windows\System32\ntdll.dll at 77ae --- Process 3928 loaded C:\Windows\System32\verifier.dll at 07fef183 --- Process 3928 loaded C:\Windows\System32\vrfcore.dll at 07fef69b --- Process 3928 loaded C:\Windows\System32\vfbasics.dll at 07fef694 --- Process 3928 loaded C:\Windows\System32\kernel32.dll at 779c --- Process 3928 loaded C:\Program Files\AVAST\x64\aswhooka.dll at 07fef59b --- Process 3928 loaded C:\Windows\System32\KernelBase.dll at 07fefd97 --- Process 3928 loaded C:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 3928 loaded C:\cygwin64\bin\cygintl-8.dll at 0003fa95 --- Process 3928 loaded C:\cygwin64\bin\cygiconv-2.dll at 0003fe34 0 0 [main] cat (3928) ** 116 116 [main] cat (3928) Program name: C:\cygwin64\bin\cat.exe (windows pid 3928) 36 152 [main] cat (3928) OS version: Windows NT-6.1 24 176 [main] cat (3928) ** --- Process 3928 loaded C:\Windows\System32\advapi32.dll at 07fefec7 --- Process 3928 loaded C:\Windows\System32\msvcrt.dll at 07fefebd --- Process 3928 loaded C:\Windows\System32\sechost.dll at 07feff33 --- Process 3928 loaded C:\Windows\System32\rpcrt4.dll at 07fefed5 --- Process 3928 loaded C:\Windows\System32\cryptbase.dll at 07fefd4d 10497 10673 [main] cat (3928) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180309D30) 1074 11747 [main] cat (3928) open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x208, *m 6 65 11812 [main] cat (3928) user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 332 12144 [main] cat (3928) open_shared: name S-1-5-21-3582216975-893534028-59465-1002.1, n 1, shared 0x18002 (wanted 0x18002), h 0x218, *m 6 28 12172 [main] cat (3928) user_info::create: opening user shared for 'S-1-5-21-3582216975-893534028-59465-1002' at 0x18002 26 12198 [main] cat (3928) user_info::create: user shared version AB1FCCE8 190 12388 [main] cat (3928) fhandler_pipe::create: name \\.\pipe\cygwin-e022582115c10879-3928-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 170 12558 [main] cat (3928) fhandler_pipe::create: pipe read handle 0x240 24 12582 [main] cat (3928) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-e022582115c10879-3928-sigwait 167 12749 [main] cat (3928) fhandler_pipe::create: pipe write handle 0x248 66 12815 [main] cat (3928) dll_crt0_0: finished dll_crt0_0 initialization Cygwin WARNING: Couldn't compute FAST_CWD pointer. This typically occurs if you're using an older Cygwin version on a newer Windows. Please update to the latest available Cygwin version from https://cygwin.com/. If the problem persists, please see https://cygwin.com/problems.html --- Process 3928 thread 10476 created --- Process 3928, exception c005 at --- Process 3928 thread 10476 exited with status 0xc001 --- Process 3928 exited with status 0xc001 strace /usr/bin/tac.exe new_benchmarks.pl >>cat_straces.txt 2>&1 --- Process 3724 created --- Process 3724 loaded C:\Windows\System32\ntdll.dll at 77ae --- Process 3724 loaded C:\Windows\System32\kernel32.dll at 779c --- Process 3724 loaded C:\Program Files\AVAST\x64\aswhooka.dll at 07fef59b --- Process 3724 loaded C:\Windows\System32\KernelBase.dll at 07fefd97 --- Process 3724 loaded C:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 3724 loaded C:\cygwin64\bin
