[ANNOUNCEMENT] Updated: MATE Desktop 1.10.2
The following packages (and their respective subpackages) have been updated in the Cygwin distribution: * atril-1.10.2-1 * caja-1.10.3-1 * caja-extensions-1.10.0-1 * caja-python-1.10.0-1 * engrampa-1.10.1-1 * eom-1.10.3-1 * galculator-2.1.4-1 * libmatekbd-1.10.0-1 * libmatemixer-1.10.0-1 * libmateweather-1.10.0-1 * marco-1.10.2-1 * mate-applets-1.10.3-1 * mate-backgrounds-1.10.0-1 * mate-common-1.10.0-1 * mate-control-center-1.10.1-1 * mate-desktop-1.10.2-1 * mate-icon-theme-1.10.1-1 * mate-media-1.10.0-1 * mate-menus-1.10.0-1 * mate-notification-daemon-1.10.1-1 * mate-panel-1.10.1-1 * mate-session-manager-1.10.2-1 * mate-settings-daemon-1.10.2-1 * mate-system-monitor-1.10.1-1 * mate-terminal-1.10.1-1 * mate-themes-1.10.4-1 * mate-themes-extras-3.14.6-1 * mate-utils-1.10.3-1 * mozo-1.10.1-1 * pluma-1.10.2-1 This is an update to the latest upstream stable release: http://mate-desktop.org/blog/2015-06-11-mate-1-10-released/ -- Yaakov -- 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 potentially corrupting permissions?
Greg Freemyer wrote: On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh wrote: Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). $ ./lsacl.sh . [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] . But maybe this is interesting. I just created 2 folders in C:\ . I did it at the C:\ level because I can't imagine I ever modified the ACLs on C:\. Anyway, one directory was created via "mkdir" in cygwin. The other via the file explorer. Look at how different the ACLs are: $ mkdir /cygdrive/c/Test-dir-created-in-cygwin $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/ [u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x] /cygdrive/c/Test-dir-created-in-cygwin/ $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/ [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] /cygdrive/c/Test-dir-created-in-file-explorer/ What's that about? Again I'm not expert at ACLs, but the ACLs on the directory created via File Explorer look really strange to me. - That looks like the 'Creator User & Creator Group Policies at work, which try to let you create a dir in root, but give limited access to that dir -- but doesn't allow just any Creator to have full access... I think you are seeing a trickle down effect from the creator owner policy and the creator group policy banning full access -- because if you look at the security tab in explorer I'll be those are pretty restricted... This is a local file system? NTFS? Yes, C: drive. It's my local system drive on both computers and NTFS on both machines. Do you have process hacker? Maybe the writing process has a different integrity label or such. Look at the acl in the Explorer 'security tab' You find some extra rules for 'creators' that are supposed to allow them to do things inside the dir but not to the dir or some such. No, but let me know if you still want me to pursue that. For now I'm thinking the ACLs on folders created via File Explorer are somehow getting screwed up. 'screwed-up' is relative -- i.e. in this case, likely what explorer is designed to do, (screw you), *str8-face*... In the home directory you want to deal with this in (I wouldn't suggest changing drives from root folder (I do such things and constantly end up with 'shot-in-foot' type problems that I get to have 'fun' fixing! ;->) But get rid of the creator rules so they won't propagate have to do it from windows those because those entities aren't posix. -- 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 potentially corrupting permissions?
Andrey Repin wrote: Obscurity has no relation to security. Oh, and these both are disabled on my systems. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... There's no such rules as "rename default accounts". It makes no sense and bears no reason. --- Security best practices : See "https://technet.microsoft.com/en-us/library/cc747353%28v=ws.10%29.aspx"; and "https://technet.microsoft.com/en-us/library/jj852273.aspx"; -- 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 potentially corrupting permissions?
On Thu, Sep 24, 2015 at 9:46 PM, Andrey Repin wrote: > Obscurity has no relation to security Tell any Army in the world about that theory. They should save their money wasted on camouflage, stealth technology, etc. But, I did not knowingly add the "root" group. Greg -- 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 potentially corrupting permissions?
On Thu, Sep 24, 2015 at 3:22 PM, Ken Brown wrote: > > > The problem could be caused by the default ACL on whatever directory you're > working in. You might consider running 'setfacl -b' and/or 'setfacl -k' on > that directory. (Run 'setfacl --help' for more information.) I just posted this, but it looks like directories created in cygwin have reasonable ACLs, but directories created via "File Explorer" are bizarre. Where bizzare is defined as: $ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/ # file: /cygdrive/c/Test-dir-created-in-file-explorer/ # owner: GAF # group: None user::--- group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- Here's getfacl for C:\ $ getfacl /cygdrive/c # file: /cygdrive/c # owner: TrustedInstaller # group: TrustedInstaller user::--- group::--- group:root:rwx group:Authenticated Users:--- group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- Is that what others have? fyi: I just realized I installed "System Mechanic" around the time I started seeing problems. It is installed on both of the machines having issues. I wonder if it adulterated my ACLs in an attempt to make my machine safer? Thanks Greg -- 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 potentially corrupting permissions?
On Thu, Sep 24, 2015 at 2:37 PM, Andrey Repin wrote: > Greetings, Greg Freemyer! > >> We seem to travel the same mailing lists. This is my first time to cygwin's. > >> I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to >> make a copy. > >> The copy is permission denied for reading. Basic ls -l shows no >> difference (as expected) > >> $ ls -l lsacl.sh it >> rwx---+ 1 gaf None 1630 Sep 24 12:05 it >> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh > > Notice the "+" at the end of basic POSIX access bits. > And use getfacl (or native icacl(s)) to view real permissions. I'm using Linda' script that does that, but here's the raw getfacl output for 2 folders created in C:\Note they have very different ACLs. Why? $ getfacl /cygdrive/c/Test-dir-created-in-cygwin/ # file: /cygdrive/c/Test-dir-created-in-cygwin/ # owner: GAF # group: None user::rwx group::r-x group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:r-x $ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/ # file: /cygdrive/c/Test-dir-created-in-file-explorer/ # owner: GAF # group: None user::--- group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- That last one with the directory created via file explorer has truly bizarre (to me) ACLs. Normal? If not, how do I fix it. Note I have 2 different Win 7 boxes showing this same behavior. > >> But your script does show a difference: > >> $ ./lsacl.sh lsacl.sh it >> [u::---,g::---,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh >> [u::---,g::r-x,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > >> My user id is "gaf". > >> fyi: I thought I knew how to read an ACL, but the above makes little >> sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". > > Your system seems to be mangled. There should be no "root" user. hmm. I think that is a "root" group, not a "root" user. I seriously doubt I created a root as a group. Are you sure that isn't standard with cygwin? note: I love using cygwin, but I'm not very knowledgeable about user and group management in cygwin. On the other hand, I'm pretty good at it in Linux. (I'm a 30+ year UNIX/Linux user) > Also, please avoid top posting as per list rules. If I did, I will try to avoid it in the future. This e-mail is interspersed. I assume that is desired. Greg -- 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 potentially corrupting permissions?
On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> >> Totally logical, but not accurate. ) > > --- > What does it say if you do an 'lsacl' on "." (the parent directory). $ ./lsacl.sh . [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] . But maybe this is interesting. I just created 2 folders in C:\ . I did it at the C:\ level because I can't imagine I ever modified the ACLs on C:\. Anyway, one directory was created via "mkdir" in cygwin. The other via the file explorer. Look at how different the ACLs are: $ mkdir /cygdrive/c/Test-dir-created-in-cygwin $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/ [u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x] /cygdrive/c/Test-dir-created-in-cygwin/ $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/ [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] /cygdrive/c/Test-dir-created-in-file-explorer/ What's that about? Again I'm not expert at ACLs, but the ACLs on the directory created via File Explorer look really strange to me. > This is a local file system? NTFS? Yes, C: drive. It's my local system drive on both computers and NTFS on both machines. > Do you have process hacker? Maybe the writing process has a different > integrity label or such. No, but let me know if you still want me to pursue that. For now I'm thinking the ACLs on folders created via File Explorer are somehow getting screwed up. Thanks Greg > Process hacker lets you see what the integrity labels are on files, > but to see what they are on files you'd have to d/l another util. > (chml/regil > >> >> - cygwin is not properly maintaining the permissions when it manipulates a >> file > > > May not be able to ... Windows trumps cygwin. > MS-regularly screws w/windows, .. it's like switching to a new > init system every month... ok.. maybe not quite that bad... > >> >> Either way, I would really like a solution that doesn't involve a >> manual chmod for every file I create via the normal Windows interface >> and which I want to work with it in cygwin. > > === > I can understand that -- that's sorta why I haven't upgraded > my cygwin lately -- She spent alot of time solving a problem that didn't > really appear on my system, so changing the whole security system -- well > I already know that cygwin doesn't respect existing standards or sources. > (overwrite windows mount points created -- and is shipping a login that > zeros your environment -- even when passed switch to not do so -- > effectively > wipes your windows session -- forcing users to copy sessions from static > files to get around the problem. > -- 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 potentially corrupting permissions?
Greetings, Linda Walsh! > Andrey Repin wrote: >> Your system seems to be mangled. There should be no "root" user. >> >> Also, please avoid top posting as per list rules. > > You are missing one? Don't tell me, you have > Administrator instead? No, I have my own account, that's quite enough. > Maybe that's why you see Greg's messages as top-posted, where > as I saw him as interleaving his response w/what I said? ;-) > If you have Win7-Pro or above, you can rename Admin > and Guest accounts -- You can rename them in NT4, too. Just sayin'. > which is recommended for security reasons. Obscurity has no relation to security. Oh, and these both are disabled on my systems. > If you read windows 'rules', you'd know that... (so many rules > to read...really hard for someone to keep up)... There's no such rules as "rename default accounts". It makes no sense and bears no reason. -- With best regards, Andrey Repin Friday, September 25, 2015 04:43:28 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: workflow idiom to compare zip/tgz with folder subtree
Greetings, Paul! > I noticed that fossil & cvs are part of cygwin. I will have to bite > the bullet & try a few baby steps at some point. If anything, I would NOT recommend CVS to anyone making their first steps into VCS world. Subversion is way more consistent, better thought out and have about the same usability characteristics where they are comparable. (And don't forget the marvelous svnbook.org ...) The unly reason I was using CVS up until a month ago for some of my projects is because I was lazy and did not convert them to Subversion ten years ago. -- With best regards, Andrey Repin Friday, September 25, 2015 04:36:25 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: workflow idiom to compare zip/tgz with folder subtree
Eliot Moss wrote: > There are also various backup tools based on rsync and compression. > One of these is called duplicity, and it supports encryption as > well. But I suspect there are a number of these and that you can > find one that matches your task ... Andrey Repin wrote: > It seems he need comparison over reservation. I don't know of any > backup tools that offer differential view against backup content. > Not that I know many backup tools, though... Warren Young suggested: fossil Thank you all. I've perused and pondered. There is a key constraint that I neglected to mention. I am shuttling incremental work back and forth between two locations using disc. At one of the sites, the only possible tools are M$ Office and a snapshot of Cygwin. The full copy of the working hierarchy exists at the two sites (almost identical). The more restrictive site is the authoritative home of the historical snapshots, though I may have mini-snapshots at the alternative site. The comparison of the working file hierarchy with snapshots lets me vet what needs to be shuttle back and forth; the majority of the differences will not be relevant as the hierarcy exists at both sites. I use the same archival scheme for local snapshots and for shuttling work between sites, though the content is not the same (I won't take an entire local snapshot with me on disc most of the time). Most of the files are not software, though parallels can be drawn: Long SQL scripts, Matlab scripts, images, data files, VBA, Matlab files, text files, LaTeX files, image files, and M$ Office files (Access, Excel, Word, Powerpoint, PST). This is not a development environment, it is an analysis environment (with code hackery to that end). However, the evolution of files and version control requirements probably overlap (I can only guess as I've never worked in a regulated code development environment, relying instead on my own adhoc snapshots & incrementals). One differences from the days when I wrote "real" (compiled) code is that I'm not just archiving source code; some of the files are images, databases, etc., and take up a lot of space. I end up creating incrementals a lot more, or simply leaving the big files out of the snapshot routine (relying on very old snapshots). My analysis strategy is strongly influenced by this; I try to avoid computational approaches that rely on intermediately generated data that need to be archvied. As much as possible, everything should be quickly generatable from raw client input data files. Been able to get away with that so far, with a great deal of effort. I rely alot on bash hackery, even though I'm no graybeard. "find", "diff -qr", and "xargs" are indispensible, and using vim window splitting, it is very efficient to browse the diff output and warp to discrepant text files, and even delve into zip files to open its content, and then use vimdiff to cruise the discrepancies. The synergy between vim & bash are (to me) like magic, scripting up copies and such and piping them to bash. For the most part, however, you need to unpack the snapshot (or rebuild it from incrementals). Andrey is right, the main thing causing me to put the question out there is the desire to avoid this. I noticed that fossil & cvs are part of cygwin. I will have to bite the bullet & try a few baby steps at some point. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: bash-4.3.42-4
A new release of bash, 4.3.42-4, has been uploaded and will soon reach a mirror near you. It is currently marked experimental pending test results from others that have reported problems on text mounts: https://cygwin.com/ml/cygwin/2015-03/msg00496.html https://cygwin.com/ml/cygwin/2015-06/msg00087.html But assuming it passes those tests, it will be promoted to current, leaving 4.3.42-3 as the previous version. NEWS: = This is a minor build that fixes an upstream typo that broke bash behavior when reading scripts from a text mount, regardless of whether you used the igncr option. Thanks to Jeff Downs for helping isolate the problem. This build of bash is immune to the ShellShock vulnerabilities (although unpatched bash 4.3 is vulnerable, the official upstream patches solve the issue). By now, you should no longer be running a vulnerable bash, but to double check you can run the following test to make sure you are not subject to arbitrary remote code execution due to ShellShock: $ env 'bad=() { echo vulnerable; }' bash -c bad If it prints "bash: bad: command not found", your version of bash is safe and not subject to remote exploits. If it prints "vulnerable", you need to upgrade now. There are a few things you should be aware of before using this version: 1. When using binary mounts, cygwin programs try to emulate Linux. Bash on Linux does not understand \r\n line endings, but interprets the \r literally, which leads to syntax errors or odd variable assignments. Therefore, you will get the same behavior on Cygwin binary mounts by default. 2. d2u is your friend. You can use it to convert any problematic script into binary line endings. 3. Cygwin text mounts automatically work with either line ending style, because the \r is stripped before bash reads the file. If you absolutely must use files with \r\n line endings, consider mounting the directory where those files live as a text mount. However, text mounts are not as well tested or supported on the cygwin mailing list, so you may encounter other problems with other cygwin tools in those directories. 4. This version of bash has a cygwin-specific set option, named "igncr", to force bash to ignore \r, independently of cygwin's mount style. As of bash-3.2.3-5, it controls regular scripts, command substitution, and sourced files. I hope to convince the upstream bash maintainer to accept this patch into a future bash release even on Linux, rather than keeping it a cygwin-specific patch, but only time will tell. There are several ways to activate this option: 4a. For a single affected script, add this line just after the she-bang: (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed 4b. For a single script, invoke bash explicitly with the option, as in 'bash -o igncr ./myscript' rather than the simpler './myscript'. 4c. To affect all scripts, export the environment variable BASH_ENV, pointing to a file that sets the shell option as desired. Bash will source this file on startup for every script. 4d. Added in the bash-3.2-2 release: export the environment variable SHELLOPTS with igncr included in it. It is read-only from within bash, but you can set it before invoking bash; once in bash, it auto-tracks the current state of 'set -o igncr'. If exported, then all bash child processes inherit the same option settings; with the exception added in 3.2.9-11 that certain interactive options are not inherited in non-interactive use. 4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make sense to support the option through both set and shopt, and SHELLOPTS proved to be more powerful. 5. You can also experiment with the IFS variable for controlling how bash will treat \r during variable expansion. 6. There are varying levels of speed at which bash operates. The fastest is on a binary mount with igncr disabled (the default behavior). Next would be text mounts with igncr disabled and no \r in the underlying file. Next would be binary mounts with igncr enabled. And the slowest that bash will operate is on text mounts with igncr enabled. 7. As additional cygwin extensions, this version of bash includes: 7a. EXECIGNORE - a colon-separated list of glob patterns to ignore when completing on executables. EXECIGNORE=*.dll is common. 7b. completion_strip_exe - using 'shopt -s completion_strip_exe' makes completion strip .exe suffixes 8. This version of bash is immune to ShellShock (CVE-2014-6271 and friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than 'foo=' environment variables. However, doing this has exposed weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub their environment to exclude what is not a valid name for them. 9. If you don't like how bash behaves, then propose a patch, rather than proposing idle ideas. This turn of events has already been talked to death on the mailing lists by people with many ideas, but few patches. Thanks to Dan Colascione for providing the EXECIGNORE
Re: [ANNOUNCEMENT] Updated: bash-4.3.39-2
On 06/04/2015 03:51 AM, Mikhail Usenko wrote: > Eric Blake (cygwin) <...> wrote: >> 4.3.39-2 > > Hello, Eric. > It has the same issue as in the previous version: > eating one \r from the odd numbered chains of the \r. > Please try the (currently-experimental) 4.3.42-4, which should fix the issues observed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash-4.3.33-1 fails to execute shell script with CR+LF EOL in text-mounted directory
On 03/26/2015 09:37 AM, sm...@cygwin.akamoz.jp wrote: > Dear Cygwin developers: > > It seems that bash-4.3.33(1) handles CR+LF end-of-line in > the shell-script incorrectly, all of the following conditions are met: > > a. the shell-script file is on TEXT-MOUNTED directory, > b. end-of-line style of the file is CR+LF, and > c. the command in the file includes & (exec-background), >$( ), or `` (command substitutions) > > It works: > d. it is on the binary-mounted directory, and with igncr shell-option, > e. end-of-line style is LF, or > f. condition c is not met. It seems that &&, | and || work fine, >although I didn't try all of the metachacters and control-constructs. > Please try the (currently-experimental) 4.3.42-4, which should fix the issues observed. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Solved Re: Bash / cygwin process spawning (?) performance very slow
> turns out that Comodo Firewall (Free version) loads a DLL in each process > that is the cause of the delay. > Although I only use the Firewall, and do not use any "AntiVirus" features, > still it causes delay during startup of a process. > > However, after disabling it -- which did speed up process spawning in Bash -- > I encountered the other problem I already had much more often. > For now I consider the issue of slow spawning to be solved > (although it would have been nice if there was an easier way to diagnose it, > maybe with tracing?) After some more experimenting, and reading on Comodo issues in combination with Chrome, I found the following solution: Add the cygwin installation folder to Comodo's 'Detect Shellcode Injections Exclusions' setting. This will lead to an immediate drop in 'spawn' times to more acceptable levels. Somehow 'Detect Shellcode Injections' is active, even when HIPS is disabled. Paul -- 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
Advices on compiling a C, C++, python and fortran code...
Hi, I have found different emails related to compiling while linking libraries in a Cygwin environment. These mails are quite old (usually from year 2000 to 2003) and explain how linking either libpthread.a or libdl.a with the program being compiled. Manipulations indicated mention the need to create symbolic links to link to either cygwin1.dll or libcygwin, or to use specific compilation flags. Please, could someone tell me if such manipulations are still required to be able to compile Code_Aster in latest cygwin environment (I am using 2.2.1)? Most notably, this code is written Fortran90 + C + C++. Its compilation is managed by a quite complex python script that has been written to work on Linux workstations (Debian, Ubuntu...). The python script checks before compilation that the following libraries are found in the system: - libpthread.so or libpthread.a - libdl.so or libdl.a - libutil.so or libutil.a - libm.so or libm.a I confirm that the python script correctly found in the cygwin lib directory the following ones: libpthread.a libdl.a libutil.a libm.a Please, do I have with current cygwin version to use specific flags or to create specific symlink to make sure the code get correctly linked against these libraries? Also, once the executable will be obtained, and if I want to copy it on another Windws machine without Cygwin environment, do I have to make sure to copy as well cygwin1.dll library? If so, in which directory can I put it? I thank you in advance for your help. Best regards, Pierre -- 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: startx not working
On 24/09/2015 22:19, Tim Higgins wrote: I can get an x window when I enter startx -d but it does not seem to display the x programs that I am running on my UNIX server. http://x.cygwin.com/docs/ug/using-remote-apps.html "Note: You must provide the -listen tcp option to startx or startxwin so that the X server will listen for TCP/IP connections. (See this FAQ for more details). " -- 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: startx not working
Please leave the mailing list in copy On 24/09/2015 21:48, Tim Higgins wrote: Yes I get a different error Just trying to get X working on my desktop as I need its functionality for some Unix jobs that require X. Tim Higgins As openGL crashed and the suggestion on the screenshot is "-nowgl" can you try startxwin -- -multiwindow +iglx -nowgl it should disable the hardware acceleration. http://x.cygwin.com/docs/ug/using-glx.html Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: startx not working
On 24/09/2015 20:56, Tim Higgins wrote: When I run startx I get the following error. higginst@HigginsT-LT-W7 ~ $ startx same here, but have you tried startxwin ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). This is a local file system? NTFS? Do you have process hacker? Maybe the writing process has a different integrity label or such. Process hacker lets you see what the integrity labels are on files, but to see what they are on files you'd have to d/l another util. (chml/regil - cygwin is not properly maintaining the permissions when it manipulates a file May not be able to ... Windows trumps cygwin. MS-regularly screws w/windows, .. it's like switching to a new init system every month... ok.. maybe not quite that bad... Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. === I can understand that -- that's sorta why I haven't upgraded my cygwin lately -- She spent alot of time solving a problem that didn't really appear on my system, so changing the whole security system -- well I already know that cygwin doesn't respect existing standards or sources. (overwrite windows mount points created -- and is shipping a login that zeros your environment -- even when passed switch to not do so -- effectively wipes your windows session -- forcing users to copy sessions from static files to get around the problem. -- 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 potentially corrupting permissions?
Andrey Repin wrote: Your system seems to be mangled. There should be no "root" user. Also, please avoid top posting as per list rules. You are missing one? Don't tell me, you have Administrator instead? Maybe that's why you see Greg's messages as top-posted, where as I saw him as interleaving his response w/what I said? ;-) If you have Win7-Pro or above, you can rename Admin and Guest accounts -- which is recommended for security reasons. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... *cheers* -l -- 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 potentially corrupting permissions?
On 9/24/2015 2:52 PM, Greg Freemyer wrote: On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh wrote: Greg Freemyer wrote: Linda, I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it --- Well user 'gaf' (that's you, from the file perms has no access). So up front, you are denied before anything happens. Totally logical, but not accurate. ) I am the owner of both "it" and "lsacl.sh." For both the user permissions are "---" (why I don't know. I created lsacl.sh by a simple drag and drop out of firefox.) I can cat out "lsacl.sh", but not "it". I know "chmod +rw it" gives me access to the file. The problem is Windows is creating files with permissions like lsacl.sh routinely on my system. Then when I do anything to them in cygwin, the permissions are modified to block my access. I first noticed this because I was exporting CSV files from excel, then editing them with vi from cygwin. On the first edit, all was good. After that, I no longer had permission to access the file. So, either: - Windows 7 (on 2 different machines) has started using default permissions that are bad on their face - cygwin is not properly maintaining the permissions when it manipulates a file Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. The problem could be caused by the default ACL on whatever directory you're working in. You might consider running 'setfacl -b' and/or 'setfacl -k' on that directory. (Run 'setfacl --help' for more information.) Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash / cygwin process spawning (?) performance very slow
> If you use http://www.dependencywalker.com/ on bash.exe with view/full > paths enabled, does the Comodo Firewall dll stand out or is it just > another .dll loaded from windows\system32? > > Regards, > Lee I use Process Explorer to view in-process .dlls: C:\WINDOWS\system32\guard32.dll Regards, Paul -- 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 potentially corrupting permissions?
On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> Linda, > > >> I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to >> make a copy. >> >> The copy is permission denied for reading. Basic ls -l shows no >> difference (as expected) >> >> $ ls -l lsacl.sh it >> rwx---+ 1 gaf None 1630 Sep 24 12:05 it >> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh >> >> But your script does show a difference: >> >> $ ./lsacl.sh lsacl.sh it >> [u::---,g::---,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh >> [u::---,g::r-x,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > > --- > Well user 'gaf' (that's you, from the file perms has no access). > > So up front, you are denied before anything happens. Totally logical, but not accurate. ) I am the owner of both "it" and "lsacl.sh." For both the user permissions are "---" (why I don't know. I created lsacl.sh by a simple drag and drop out of firefox.) I can cat out "lsacl.sh", but not "it". I know "chmod +rw it" gives me access to the file. The problem is Windows is creating files with permissions like lsacl.sh routinely on my system. Then when I do anything to them in cygwin, the permissions are modified to block my access. I first noticed this because I was exporting CSV files from excel, then editing them with vi from cygwin. On the first edit, all was good. After that, I no longer had permission to access the file. So, either: - Windows 7 (on 2 different machines) has started using default permissions that are bad on their face - cygwin is not properly maintaining the permissions when it manipulates a file Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. Greg > lsacl is the embedded acl (the '+') at the end of the file perms > > u::--- = user seen by 'ls -l' has no access, g::--- = group seen by 'ls -l > has no access > g:root:rwx = group root has read/write/execute access > g:Authenticated Users:rwx == group consisting of Authenticated Users... > (after you login or provide credentials). > m:rwx m = a maximum allowed privs 'mask' for user/groups other > than owner, but since all bits are turned on, it has no limiting > effect > o:--- = other has no access > > So the main take-away is that since your 'user' has no access, pretty much > everything else is ignored. > > From the mode-bits+acl, amost anyone in the groups: > root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you) > should have access... > > you might try 1) chmod u+rwx file ... > then look at both mode+acl... if you have no access > and acl still says u::---, then nuke the acl or modify it with "setfacl" > (setfacl --help)... > >> >> We seem to travel the same mailing lists. This is my first time to >> cygwin's. >> > > Yeah... I wondered about that -- my Tbird tried to change my > reply addr to suse(at)tlinx based on you being the 1st address I typed > in... ;-) -- 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 potentially corrupting permissions?
Greetings, Greg Freemyer! > We seem to travel the same mailing lists. This is my first time to cygwin's. > I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to > make a copy. > The copy is permission denied for reading. Basic ls -l shows no > difference (as expected) > $ ls -l lsacl.sh it > rwx---+ 1 gaf None 1630 Sep 24 12:05 it > rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh Notice the "+" at the end of basic POSIX access bits. And use getfacl (or native icacl(s)) to view real permissions. > But your script does show a difference: > $ ./lsacl.sh lsacl.sh it > [u::---,g::---,g:root:rwx,g:Authenticated > Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh > [u::---,g::r-x,g:root:rwx,g:Authenticated > Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > My user id is "gaf". > fyi: I thought I knew how to read an ACL, but the above makes little > sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". Your system seems to be mangled. There should be no "root" user. Also, please avoid top posting as per list rules. -- With best regards, Andrey Repin Thursday, September 24, 2015 21:35:24 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash / cygwin process spawning (?) performance very slow
On 24/09/2015 19:46, Lee wrote: On 9/24/15, litter wrote: On 24/09/2015 11:57, litter wrote: Obviously something is. The FAQ entry does not mention performance, but real failures. How to further diagnose this? I took the plunge and spent almost a full day trying to find the cause. ... snip ... turns out that Comodo Firewall (Free version) loads a DLL in each process that is the cause of the delay. ... snip ... (although it would have been nice if there was an easier way to diagnose it, maybe with tracing?) Tracing may report it as at process load is reporting the loaded dll's --- Process 7380 loaded C:\Windows\System32\ntdll.dll at 7736 --- Process 7380 loaded C:\Windows\System32\kernel32.dll at 7724 --- Process 7380 loaded C:\Windows\System32\KernelBase.dll at 07FEFDB2 --- Process 7380 loaded C:\Windows\System32\sysfer.dll at 74B4 --- Process 7380 loaded E:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 7380 loaded E:\cygwin64\bin\cygiconv-2.dll at 0003C270 --- Process 7380 loaded E:\cygwin64\bin\cygintl-8.dll at 0003BEC9 --- Process 7380 loaded E:\cygwin64\bin\cygncursesw-10.dll at 0003BD88 --- Process 7380 loaded E:\cygwin64\bin\cygreadline7.dll at 0003B5FD --- Process 7380 loaded C:\Windows\System32\user32.dll at 76C6 --- Process 7380 loaded C:\Windows\System32\gdi32.dll at 07FEFEBE --- Process 7380 loaded C:\Windows\System32\lpk.dll at 07FEFF3C --- Process 7380 loaded C:\Windows\System32\usp10.dll at 07FEFF50 --- Process 7380 loaded C:\Windows\System32\msvcrt.dll at 07FEFF5D If you use http://www.dependencywalker.com/ on bash.exe with view/full paths enabled, does the Comodo Firewall dll stand out or is it just another .dll loaded from windows\system32? unlikely to appear as it is not a dependency but an injected dll Regards, Lee -- 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: Issues encountered with new Cygwin version
Greetings, Linda Walsh! >>> > > > > I believe the target of the symlink should be "protocol" (i.e. >>> How would that affect 'services'? >> >> Sorry, you lost me. 'services' has 8 characters in the file name and so is >> its symlink target; That shouldn't be an issue. Of the 4 symlinks under >> /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' >> exceeds the 8 character limit and hence the actual target file in >> Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the >> *target* file not the symlinks themselves, which are fine. > --- > Oops.. my bad -- don't know why I substituted services. However, > weren't those files there for unix-subsystem support? Not sure: > From this: > https://books.google.com/books?id=6hlNFc7drzEC&pg=PA39&lpg=PA39&dq=reason+for+drivers/etc/protocol+on+windows&source=bl&hl=en&sa=X&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false#v=snippet&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false > (page 39) -- it says those files were specific to NT systems beginning with > NT4.0, which used NTFS. I don't know if NT supported having the > windows/system32 > directory on FAT][32]... It did. Read the help article about "convert" tool for more info. > NT4 would have been the version before Windows 2000 Aye. -- With best regards, Andrey Repin Thursday, September 24, 2015 21:32:08 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How do I make my Emacs font match my xterm font?
I ended up downloading xlsfonts, and after a little trial-and-error, this appears to be the matching font: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 So I have a new Emacs font, which for some reason seems smaller than before, but it's certainly usable. -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: How do I make my Emacs font match my xterm font?
On Thu, Sep 24, 2015 at 11:50 AM, Ken Brown wrote: > I'm not positive, but I think you might need to install xorg-x11-fonts-Type1. Thanks, Ken. I tried, but it did not fix the problem. -- Jim Reisert AD1C, , http://www.ad1c.us -- 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 potentially corrupting permissions?
Greg Freemyer wrote: Linda, I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it --- Well user 'gaf' (that's you, from the file perms has no access). So up front, you are denied before anything happens. lsacl is the embedded acl (the '+') at the end of the file perms u::--- = user seen by 'ls -l' has no access, g::--- = group seen by 'ls -l has no access g:root:rwx = group root has read/write/execute access g:Authenticated Users:rwx == group consisting of Authenticated Users... (after you login or provide credentials). m:rwx m = a maximum allowed privs 'mask' for user/groups other than owner, but since all bits are turned on, it has no limiting effect o:--- = other has no access So the main take-away is that since your 'user' has no access, pretty much everything else is ignored. From the mode-bits+acl, amost anyone in the groups: root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you) should have access... you might try 1) chmod u+rwx file ... then look at both mode+acl... if you have no access and acl still says u::---, then nuke the acl or modify it with "setfacl" (setfacl --help)... We seem to travel the same mailing lists. This is my first time to cygwin's. Yeah... I wondered about that -- my Tbird tried to change my reply addr to suse(at)tlinx based on you being the 1st address I typed in... ;-) -- 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: How do I make my Emacs font match my xterm font?
On 9/24/2015 1:16 PM, Jim Reisert AD1C wrote: After the recent fonts reorganization, the font I (used to ) specify for Emacs in my ~/.Xresources file no longer works: Font `-adobe-courier-medium-r-*-*-*-96-*-*-*-*-iso8859-1' is not defined I'm not positive, but I think you might need to install xorg-x11-fonts-Type1. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash / cygwin process spawning (?) performance very slow
On 9/24/15, litter wrote: >> On 24/09/2015 11:57, litter wrote: >>> Obviously something is. The FAQ entry does not mention performance, but >>> real failures. >>> How to further diagnose this? > > I took the plunge and spent almost a full day trying to find the cause. ... snip ... > turns out that Comodo Firewall (Free version) loads a DLL in each process > that is the cause of the delay. ... snip ... > (although it would have been nice if there was an easier way to diagnose it, > maybe with tracing?) If you use http://www.dependencywalker.com/ on bash.exe with view/full paths enabled, does the Comodo Firewall dll stand out or is it just another .dll loaded from windows\system32? Regards, Lee -- 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: Bash / cygwin process spawning (?) performance very slow
On 24/09/2015 18:24, lit...@null.net wrote: >> On 24/09/2015 11:57, lit...@null.net wrote: >>> Obviously something is. The FAQ entry does not mention performance, but >>> real failures. >>> How to further diagnose this? > > I took the plunge and spent almost a full day trying to find the cause. > > 1. Booting into Safe Mode gave a huge performance boost > 2. By eliminating all services and programs in Normal Mode, one-by-one, I > found the offender: > > turns out that Comodo Firewall (Free version) loads a DLL in each process > that is the cause of the delay. > Although I only use the Firewall, and do not use any "AntiVirus" features, > still it causes delay during startup of a process. > > However, after disabling it -- which did speed up process spawning in Bash -- > I encountered the other problem I already had much more often. > For now I consider the issue of slow spawning to be solved > (although it would have been nice if there was an easier way to diagnose it, > maybe with tracing?) Comodo firewall pro is listed in https://cygwin.com/faq/faq.html#faq.using.bloda. Looks as if the free version should be listed too. -- 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-4.2-3 : attention maintainer
Marco Atzeri writes: > the bug is in the > /etc/postinstall/base-files-mketc.sh > of base-files-4.2-3 > > > FILES="hosts protocols services networks" > OSNAME="$(/usr/bin/uname -s)" > WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc" > > [cut] > > for mketc in ${FILES} > do > if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ] > then > /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}" > fi > done > > > As on my systems the bug is not present, > it can be a relative recent introduction. I've introduced this bug inadvertently when releasing base-files-4.1. I'll fix it towards the weekend. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: Bash / cygwin process spawning (?) performance very slow
> Maybe: > > strace bash -c 'time cat some-file | while read i;do echo > $i;/bin/true;done' > > Haven't tested it. > > Simplify the command: > > for((i=0;i<150;i++));do /bin/true;done > > to rule out a pipe-problem. Thanks for the tips! Used a variant on the for loop to simplify the problem. Regards, Paul -- 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: Bash / cygwin process spawning (?) performance very slow
> On 24/09/2015 11:57, lit...@null.net wrote: >> Obviously something is. The FAQ entry does not mention performance, but real >> failures. >> How to further diagnose this? I took the plunge and spent almost a full day trying to find the cause. 1. Booting into Safe Mode gave a huge performance boost 2. By eliminating all services and programs in Normal Mode, one-by-one, I found the offender: turns out that Comodo Firewall (Free version) loads a DLL in each process that is the cause of the delay. Although I only use the Firewall, and do not use any "AntiVirus" features, still it causes delay during startup of a process. However, after disabling it -- which did speed up process spawning in Bash -- I encountered the other problem I already had much more often. For now I consider the issue of slow spawning to be solved (although it would have been nice if there was an easier way to diagnose it, maybe with tracing?) Regards, Paul -- 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
How do I make my Emacs font match my xterm font?
After the recent fonts reorganization, the font I (used to ) specify for Emacs in my ~/.Xresources file no longer works: Font `-adobe-courier-medium-r-*-*-*-96-*-*-*-*-iso8859-1' is not defined Emacs will work if I comment out the font, albeit with a different font and character size. My xterm font seems unchanged. Ideally, what I would like is for my Emacs font to exactly match my xterm font. How can I go about doing this? Thanks - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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] bash' read builtin command behaves differently on '\r' (4.3.33)
On 05/14/2015 01:32 PM, Mikhail Usenko wrote: > > Cygwin version: 2.0.2-1 > > [linux]$ bash --version > GNU bash, version 4.3.33(1)-release (i686-redhat-linux-gnu) > [cygwin]$ bash --version > GNU bash, version 4.3.33(1)-release (x86_64-unknown-cygwin) > > Testcase: > [linux]$ echo -ne "\r\n" | { read t; echo "$t"; } | od -A n -t x1 > 0d 0a > [cygwin]$ echo -ne "\r\n" | { read t; echo "$t"; } | od -A n -t x1 > 0a > > But then, the pipe itself is OK: > [cygwin]$ echo -e "\r" | od -A n -t x1 > 0d 0a Jeff Downs helped me investigate off-list, and I think he found the culprit (a typo in input.c that requested O_TEXT when it meant B_TEXT, when mapping from open() flags to bash's internal B_* flags). I'm building a new bash build right now, and will shortly be posting it for testing. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Issues encountered with new Cygwin version
Walter L. wrote: > > > > I believe the target of the symlink should be "protocol" (i.e. How would that affect 'services'? Sorry, you lost me. 'services' has 8 characters in the file name and so is its symlink target; That shouldn't be an issue. Of the 4 symlinks under /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' exceeds the 8 character limit and hence the actual target file in Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the *target* file not the symlinks themselves, which are fine. --- Oops.. my bad -- don't know why I substituted services. However, weren't those files there for unix-subsystem support? Not sure: From this: https://books.google.com/books?id=6hlNFc7drzEC&pg=PA39&lpg=PA39&dq=reason+for+drivers/etc/protocol+on+windows&source=bl&hl=en&sa=X&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false#v=snippet&q=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows&f=false (page 39) -- it says those files were specific to NT systems beginning with NT4.0, which used NTFS. I don't know if NT supported having the windows/system32 directory on FAT][32]... NT4 would have been the version before Windows 2000 -- 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 potentially corrupting permissions?
Linda, We seem to travel the same mailing lists. This is my first time to cygwin's. I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it My user id is "gaf". fyi: I thought I knew how to read an ACL, but the above makes little sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". Greg -- Greg Freemyer www.IntelligentAvatar.net On Wed, Sep 23, 2015 at 10:58 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> All, >> >> I've noticed on 2 different machines that if I copy (cp) a file I can >> read with cygwin, I don't have permission to read the copy. > > --- > What does the acl say? > > (Attached a script, lsacl, that I use -- it works > with linux or cygwin and allows wildcards). > > > #!/bin/bash > > ## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp law $ > # Version 2 -- try to work with getfacl on cygwin > # > > > shopt -s expand_aliases > alias int=declare\ -i sub=function string=declare > > gfacl=$(type -P getfacl) > > if ! type -f cygwin 2>/dev/null ; then > _un_=$(type -P uname) > if [[ $_un_ ]] ; then _os_=$($_un_ -o); > elif[[ -e /proc/sys/kernel ]]; then _os_=Linux; > else_os_=Cygwin; > fi > if [[ $_os_ =~ Cygwin ]]; then function cygwin () { > return 0; } > elsefunction cygwin () { return 1; } > fi > unset _un_ _os_ > export -f cygwin > fi > > if cygwin 2>/dev/null ;then > [[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n"; > exit 1; } > sub gfacl () { "$gfacl" "$@"; } > else > ## linux version has broken semantics requiring "-p" > sub gfacl () { "$gfacl" -p "$@" ; } > fi > > export -f gfacl > > > sub facl2str { > string fn=${1:?"Need pathname"} > string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//; > s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/' > string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",") > facl=${facl%,} > string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n" > ",") > dacl=${dacl%,} > printf "[%s/%s]\n" "$facl" "$dacl" > } > > > > int acllen=0 maxfnln=0 > #for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done > > sub acl_str () { > if cygwin ;then > perm=$(facl2str "$fn") > else > qfn=$(printf "%q " "$fn") > out="$(chacl -l "$fn")" > perm="${out#$qfn}" > fi > printf "%s\n" "$perm" > } > > > for fn in "$@"; do > int max=40 > perm=$(acl_str "$fn") > int len=${#perm} > if ((len>_acl_len_)); then acllen=len; fi > if ((acllen>max)); then acllen=max; fi > printf "%-${acllen}s %s\n" "$perm" "$fn" > done > -- 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: workflow idiom to compare zip/tgz with folder subtree
On Sep 22, 2015, at 7:06 PM, Paul wrote: > > Andrey Repin writes: >> Git, Subversion... basically any sane VCS out there. > > I've managed to avoid version control all these years > because I wanted the convenience of bash file management and changing > things on a whim as I see fit. The only file management task that VCSes force you to do through the VCS is file moves/renames and deletions, and that’s only because a VCS can’t work out how to manage the files you told it to manage if there isn’t a file where you told it to expect one. All changes to the file *content* can — and normally *are* — done outside the VCS. Normally you check your changes into the VCS shortly after you make them and are happy with the changes, but it’s quite possible to put off check-ins for weeks or months. I don’t do that at work on source code repositories, but I have one repo at home that backs up changes to things like ~/bin which sometimes lags way behind “current” like that. That’s where the VCS’s diff command comes in handy. It answers the question, “What did I change in this file 4 weeks ago?” If you were using zip as the archiving format because you want a single file you can move between systems, I recommend that you look at Fossil, rather than the more popular VCSes: http://fossil-scm.org/ Fossil’s repository is a single well-strucured, compressed file, which makes it easy to back up, move to other machines, etc. (It’s a SQLite database file, if that means anything to you.) If you actually need ZIP files (or tarballs) for some reason, there is a Fossil command to get a particular point in history as an archive. One of those points in history is called “tip”, meaning the state of the whole repository as of the most recent checkin, which means it’s a single command to get a zip file of all files at the tip of the Fossil repository. Subversion is a bit simpler to use than Fossil, but its default storage format is a big pile o’ files, which means you pretty much need to do repository management through the svnadmin tool. Git is even worse than svn in that the pile o’ files is in the same tree as the working file set, instead of a separate tree. Git is also more complicated than Fossil: http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki > And for lack of time to learn yet another system. You should be able to get started with any sane VCS in maybe half an hour. Learning all the ins-and-outs will take time, but there’s power in mastering the details. In terms of complexity, Subversion < Fossil < Git. The only reason for someone with simple needs to go with Git is that you need the interoperability it provides, since it’s becoming the lingua franca of the developer world. There’s something to be said for going with the standard, even if it’s a PITA in some ways. But I’m not telling a Windows user something they don’t already know with that, am I? :) -- 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
base-files-4.2-3 : attention maintainer
On 23/09/2015 01:04, Walter L. wrote: Hi, I've just performed a fresh install of the latest (2.2.1) Cygwin on 64-bit Windows 7 and noticed 2 issues with the new version that I'd like to verify whether or not they are bugs: 1) The symlink to protocol file seems incorrect [user@hostname /etc]$ ls -l | grep protocol lrwxrwxrwx 1 user Domain Users 50 Sep 22 17:03 protocols -> /cygdrive/c/Windows/System32/drivers/etc/protocols [user@hostname /etc]$ ls -l /cygdrive/c/Windows/System32/drivers/etc | grep protocol -rwxrwx---+ 1 SYSTEM SYSTEM 1358 Jun 10 2009 protocol I believe the target of the symlink should be "protocol" (i.e. singular) Corinna, the bug is in the /etc/postinstall/base-files-mketc.sh of base-files-4.2-3 FILES="hosts protocols services networks" OSNAME="$(/usr/bin/uname -s)" WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc" [cut] for mketc in ${FILES} do if [ ! -e "/etc/${mketc}" -a ! -L "/etc/${mketc}" ] then /usr/bin/ln -s -v "${WINETC}/${mketc}" "/etc/${mketc}" fi done As on my systems the bug is not present, it can be a relative recent introduction. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues encountered with new Cygwin version
> > > > I believe the target of the symlink should be "protocol" (i.e. > > > > singular) > > > > > > Err. That is. How did no one found it earlier? > > --- > > Because it is plural on unix/linux? MS seems to have misspelt it? > > I believe it's "misspelt" due to the 8 character limit for legacy file > names, --- How would that affect 'services'? Sorry, you lost me. 'services' has 8 characters in the file name and so is its symlink target; That shouldn't be an issue. Of the 4 symlinks under /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' exceeds the 8 character limit and hence the actual target file in Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the *target* file not the symlinks themselves, which are fine. ~WL -- 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: Issues encountered with new Cygwin version
Greetings, Linda Walsh! >>> > > I believe the target of the symlink should be "protocol" (i.e. >>> > > singular) >>> > >>> > Err. That is. How did no one found it earlier? >>> --- >>> Because it is plural on unix/linux? MS seems to have misspelt it? >> >> I believe it's "misspelt" due to the 8 character limit for legacy file >> names, > --- > How would that affect 'services'? It doesn't. -- With best regards, Andrey Repin Thursday, September 24, 2015 13:29:32 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash / cygwin process spawning (?) performance very slow
On 24/09/2015 11:57, lit...@null.net wrote: Obviously something is. The FAQ entry does not mention performance, but real failures. How to further diagnose this? together with the cygcheck output that I already mentioned I suggest 1) to look on /proc/self/maps or /proc//maps to looks for strange DLL loaded 2) try to use strace. However usually strace impact the timing and the problem can never arise. Best regards, Paul -- 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 bash for loops : repeated errors : [main] bash 1972 fork: child -1 - CreateProcessW failed for errno 9 bash: fork: Bad file descriptor
On 24/09/2015 11:51, lit...@null.net wrote: .> On 23/09/2015 17:03, lit...@null.net wrote: It seems a race problem, due to the repetitive fork of grep for every line of some-file So why does it fail? Seems like a bug to me! Regards, Paul As does not fail on my computer, I suspect is a race between your AV and cygwin and sometimes cygwin wins. Regards Marco. Good for you. I don't have AV SW as I mentioned. And even so, that still makes it a bug. Your system timing performance as so poor that something is likely interfering. Don't assume that is a cygwin bug. Anyhow, a suspicion is speculative. I thought this mailing list was meant to report issues, and I think this is an issue. Yes, this is the right place. How can I further diagnose this? Is there a known way to further determine what's causing this? start with > Problem reports: http://cygwin.com/problems.html "Run cygcheck -s -v -r > cygcheck.out and include that file as an attachment in your report. Please do not compress or otherwise encode the output. Just attach it as a straight text file so that it can be easily viewed. " so we can look at your system configuration. Regards, Paul Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash / cygwin process spawning (?) performance very slow
> On 23/09/2015 17:17, lit...@null.net wrote: for a file of 167 lines. Process Explorer showed a CPU load of 20% on bash.exe, which was almost completely Kernel time. Is such high Kernel load normal? >>> >>> may be. forks are time consuming and your command is spending all the >>> time in fork >> >> So why is it spending all its time in fork? That is the question. > > https://cygwin.com/faq.html#faq.api.fork That doesn't answer my question on Kernel load. Why is it fast on your machine, and slow on mine? How can I find the culprit? >> >>> In addition, I suspect your Antivirus is further slowing down the things. >> >> I don't run an Antivirus program > > than some thing else is crashing your performance > https://cygwin.com/faq/faq.html#faq.using.bloda Obviously something is. The FAQ entry does not mention performance, but real failures. How to further diagnose this? Best regards, Paul -- 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 bash for loops : repeated errors : [main] bash 1972 fork: child -1 - CreateProcessW failed for errno 9 bash: fork: Bad file descriptor
.> On 23/09/2015 17:03, lit...@null.net wrote: >>> It seems a race problem, due to the repetitive fork of grep >>> for every line of some-file >> >> So why does it fail? Seems like a bug to me! >> >> Regards, >> Paul > > As does not fail on my computer, I suspect is a race between your AV and > cygwin and sometimes cygwin wins. > > > Regards > Marco. Good for you. I don't have AV SW as I mentioned. And even so, that still makes it a bug. Anyhow, a suspicion is speculative. I thought this mailing list was meant to report issues, and I think this is an issue. How can I further diagnose this? Is there a known way to further determine what's causing this? Regards, Paul -- 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