RE: Editors set x-bit (sometimes)
From: Achim Gratz > I said "-exec +", although I concur it was too easy to miss. Indeed, I overlooked the "+" and was unfamiliar with that option to find. Glad I asked. Learned something today. Thanx for the clarification. ☺ --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Editors set x-bit (sometimes)
Nellis, Kenneth writes:
> Really? I always thought the opposite. With -exec, doesn't
> find invoke the command for each single found object? While xargs
> allows a single command to operate on a whole slew of objects.
I said "-exec +", although I concur it was too easy to miss.
> For example:
> find ... -exec pgm {} \;
Try replacing the "\;" with "+", depending on whether pgm can deal with
multiple arguments.
> executes pgm separately for each found object while
> find ... | xargs pgm
> invokes pgm only once for as many files as will fit on the
> command line, which is quite a few.
Which is what
find ... -exec pgm {} +
will do, without piping the data to xarg and without you having to
remember that you really, really wanted to say
find … -print0 | xargs -0 pgm
unless you already know that there are no spaces or funny characters
anywhere in your filenames.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
--
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: Editors set x-bit (sometimes)
Greetings, Nellis, Kenneth!
>> From: Achim Gratz
>> .. the latter is slightly less efficient and you have to
>> do -print0/-0, but I tend to get it right more easily then the -exec
>> stuff.
> Really? I always thought the opposite. With -exec, doesn't
> find invoke the command for each single found object?
Depends, how do you set the find, and what the net effect you wan to achieve.
> While xargs allows a single command to operate on a whole slew of objects.
Which boils down to executing command every time for each argument.
> For example:
> find ... -exec pgm {} \;
> executes pgm separately for each found object
What about
find ... -exec pgm '{}' +
?
> while
> find ... | xargs pgm
> invokes pgm only once for as many files as will fit on the
> command line, which is quite a few.
> If I'm wrong about this, please share.
It really depends on what you are doing with find.
find . -iname *.php -execdir grep -qP '(?<=function )funcname' '{}' \; -print
is one thing, but
find . -date +7 -exec mv -t /dir '{}' +
is completely another.
> Or, perhaps we are talking about commands that only take
> a single object. In that case, you would need to say
> xargs -n1
> in which case, I agree, it is less efficient.
--
With best regards,
Andrey Repin
Wednesday, December 14, 2016 20:13: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: Editors set x-bit (sometimes)
> From: Achim Gratz
> .. the latter is slightly less efficient and you have to
> do -print0/-0, but I tend to get it right more easily then the -exec
> stuff.
Really? I always thought the opposite. With -exec, doesn't
find invoke the command for each single found object? While xargs
allows a single command to operate on a whole slew of objects.
For example:
find ... -exec pgm {} \;
executes pgm separately for each found object while
find ... | xargs pgm
invokes pgm only once for as many files as will fit on the
command line, which is quite a few.
If I'm wrong about this, please share.
Or, perhaps we are talking about commands that only take
a single object. In that case, you would need to say
xargs -n1
in which case, I agree, it is less efficient.
--Ken Nellis
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Editors set x-bit (sometimes)
I find I can reproduce the OP's observations, and the most recent advice doesn't fix it (although it changes the symptoms): >From mintty/bash: 639> cd /tmp 641> ls -ld . drwxrwxr-x+ 1 ht None 0 Dec 13 19:55 ./ 640> getfacl . # file: . # owner: ht # group: None user::rwx group::rwx other:r-x default:user::rwx default:group::r-x default:other:r-x 642> touch x3 643> ls -l x3 -rw-r--r-- 1 ht None 0 Dec 13 19:59 x3 Switch to CMD (not elevated): C:\Users\ht>cd ..\..\C64\tmp C:\C64\tmp>echo > x2 C:\C64\tmp> Back to mintty/bash: 644> ls -l x2 -rwxr-xr-x 1 ht None 13 Dec 13 20:00 x2* OK, try the advice 645> setfacl -bk . 649> getfacl . # file: . # owner: ht # group: None user::rwx group::rwx other:r-x 646> echo > y3 647> ls -l y3 -rw-r--r-- 1 ht None 1 Dec 13 20:01 y3 Over to CMD: C:\Users\ht>cd ..\..\C64\tmp C:\C64\tmp>echo > y2 C:\C64\tmp> And back to mintty/bash: 648> ls -l y2 -rwxrwx---+ 1 ht None 13 Dec 13 20:02 y2* 650> ls -ld . drwxrwxr-x 1 ht None 0 Dec 13 20:02 ./ 652> setfacl -bk y2 653> ls -l y2 -rwx-- 1 ht None 13 Dec 13 20:02 y2* Windows 10 Professional N Ver 10.0 Build 10586 3229k 2016/08/31 C:\C64\bin\cygwin1.dll Cygwin DLL version info: DLL version: 2.6.0 ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- 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: Editors set x-bit (sometimes)
Brian Inglis writes: > Remove DACLs Default ACLs also on directories using: > setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \ > /???/**/ /???/**/* /sbin/ /sbin/* > - that takes a while to run, and you may get a few anonymous > setfacl: Permission denied > messages - paths in the messages would have been nice here! > > Be careful *NOT* to hit Windows directories including your Windows > home directory, or any other Windows directories, native symlinks, > native hardlinks, junctions, or file types such as Windows .lnk, > .URL, etc. where Windows may rely on the DACLs, ACLs, and attributes > for proper handling. Which is why you shouldn't use the above, but have find produce a list of the files to be changed and when you are sure it doesn't contain any stray things process them either via the -exec + option in find or piping into xargs (the latter is slightly less efficient and you have to do -print0/-0, but I tend to get it right more easily then the -exec stuff. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: Editors set x-bit (sometimes)
On 2016-12-13 08:20, Ronald Otto Valentin Fischer wrote: >On 2016-12-13 10:57, Ken Brown wrote: >> Does this help? >> https://cygwin.com/faq/faq.html#faq.using.same-with-permissions > While interesting, it seems to describe a different phenomenon. > Actually, when I create files by Cygwin tools only (touch, nano, > ), the access rights are always correct. Indeed, even after > removing the extended ACL entries - as was suggested in the FAQ -, > the problem still appears. > However, I have a new finding: When I create a file from a CMD.EXE > command line, by i.e. > echo xx > abc.rb > the access rights *do* have the x-bits set! This is reproducible, > but only when the file which was created, is below my Cygwin tree! > I agree that this smells a lot like an extended ACL issue, but as > I said, setacl -b provided no help. Remove DACLs Default ACLs also on directories using: setfacl -bk ~/.[!.]* ~/.[!.]*/**/ ~/.[!.]*/**/* \ /???/**/ /???/**/* /sbin/ /sbin/* - that takes a while to run, and you may get a few anonymous setfacl: Permission denied messages - paths in the messages would have been nice here! Be careful *NOT* to hit Windows directories including your Windows home directory, or any other Windows directories, native symlinks, native hardlinks, junctions, or file types such as Windows .lnk, .URL, etc. where Windows may rely on the DACLs, ACLs, and attributes for proper handling. I don't know that removing them would cause problems, but I don't trust Windows to DTRT if it doesn't see what it expects, or DTRT in future if changes are made and the expected settings are not still in place. -- -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: Editors set x-bit (sometimes)
> Does this help? > > https://cygwin.com/faq/faq.html#faq.using.same-with-permissions While interesting, it seems to describe a different phenomenon. Actually, when I create files by Cygwin tools only (touch, nano, ), the access rights are always correct. Indeed, even after removing the extended ACL entries - as was suggested in the FAQ -, the problem still appears. However, I have a new finding: When I create a file from a CMD.EXE command line, by i.e. echo xx > abc.rb the access rights *do* have the x-bits set! This is reproducible, but only when the file which was created, is below my Cygwin tree! I agree that this smells a lot like an extended ACL issue, but as I said, setacl -b provided no help. Ronald -- Ronald Fischer http://www.fusshuhn.de/ -- 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: Editors set x-bit (sometimes)
On 12/13/2016 5:39 AM, Ronald Fischer wrote: Does anybody have an explanation for the following strange phenomenon? When I create Ruby files (*.rb) with an, the files end up with the x-bit set with some editors, while this does not happen with some other editors. This is annoying, because when I use git to put the file in a repository, and the repository is later read on Linux, the incorrect x-bit is applied there too. The text editors where this happens, do so consistently, as long as the file is below my Ruby HOME directory. It does not happen, if I store the file outside my $HOME, say in c:\tmp. Since a few editors do not show this behaviour, one might blame the way the editor creates the file. However, these text editors were not written with a Cygwin environment in mind, and Windows doesn't have the concept of an "executable bit", and it happens only if I create files below my Cygwin Home, so I think this happens when Cygwin tries to "infer" the x-bit from some other file properties. Does this help? https://cygwin.com/faq/faq.html#faq.using.same-with-permissions 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
