http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5440 <pre>Ping on this? The issue has bitten me again today, while I was testing the latest Automake development version (soon to become Automake 1.14) on the findutils git repository. Regards, Stefano </pre> Stefano Lattarini 2013-06-19T21:27:38 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5439 <pre>This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond Problems with locate.findutils.1: Unbalanced group in command synopis. You probably forgot to open or close a [ ] or { } group properly. --- locate.findutils.1-unpatched2013-05-24 04:46:40.426655741 -0400 +++ locate.findutils.12013-05-24 04:48:11.186654044 -0400 &lt; at &gt;&lt; at &gt; -3,11 +3,24 &lt; at &gt;&lt; at &gt; locate \- list files in datab</pre> esr< at >thyrsus.com 2013-06-18T05:13:52 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5438 <pre>Additional Item Attachment, bug #39162 (project findutils): File name: findutils39162.patch Size:0 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39162&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> anonymous 2013-06-11T12:28:39 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5437 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39197&gt; Summary: Bad markup in find.1 Project: findutils Submitted by: esr Submitted on: Fri 07 Jun 2013 08:38:36 AM EDT Category: find Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: None Fixed Release: None _______________________________________________________ Details: There's an errant backslash. Fix patch enclosed. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 07 Jun 2013 08:38:36 AM EDT Name: find.1.patch Size: 372B By: esr &lt;http://savannah.gnu.org/bugs/download.php?file_id=28279&gt; _____________________________</pre> Eric S. Raymond 2013-06-07T12:38:37 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5436 <pre>Follow-up Comment #2, bug #39162 (project findutils): Yes, I meant one of the commands that you listed. I don't have a run which shows the problem and I'm not sure whether that can be produced on an x64 box because of the stack layout, but I could imagine a memory violation happening on other architectures. However, you can easily see the issue by adding a print statement inside the for loop from insert_fprintf. This will print not only the -printf argument but also part of envp (which follows on stack). Using the same command line, a change like --- a/find/print.c +++ b/find/print.c &lt; at &gt;&lt; at &gt; -329,6 +329,7 &lt; at &gt;&lt; at &gt; insert_fprintf (struct format_val *vec, for (fmt_editpos = segstart; *fmt_editpos; fmt_editpos++) { + printf("%c", *fmt_editpos); if (fmt_editpos[0] == '\' &amp;&amp; fmt_editpos[1] == 'c') { make_segment (segmentp, segstart, fmt_editpos - segstart, prints %find/find: warning: unrecognized escape `' TERM=xterm-256color ... TERM=xterm-256color should not be there. ___</pre> anonymous 2013-06-05T02:11:58 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5435 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39162&gt; Summary: -printf option reads beyond arguments terminated by \ Project: findutils Submitted by: None Submitted on: Tue 04 Jun 2013 03:23:28 PM UTC Category: find Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Paul Marinescu Originator Email: paul.marinescu&lt; at &gt;imperial.ac.uk Open/Closed: Open Discussion Lock: Any Release: 4.5.9 Fixed Release: None _______________________________________________________ Details: When parsing a -printf argument, insert_fprintf treats a lone \ incorrectly when it's the last character of the argument, reading beyond the terminating NUL, e.g. find . -printf "%f\" This is hard to notice because the final make_segment call does take the terminating NUL into acco</pre> anonymous 2013-06-04T15:23:29 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5434 <pre>Otherwise, even after correctly setting the git configuration entry 'merge.merge-changelog.driver' to "git-merge-changelog %O %A %B" (which is perfectly valid), the 'import-gnulib.sh' script aborts with the following spurious error: ERROR: Merge driver git-merge-changelog is not executable. ERROR: Please fix .git/config or install git-merge-changelog * import-gnulib.sh (check_merge_driver): Adjust to check that the given driver is runnable as a command, rather than that it is executable as a path. Signed-off-by: Stefano Lattarini &lt;stefano.lattarini&lt; at &gt;gmail.com&gt; --- ChangeLog | 13 +++++++++++++ import-gnulib.sh | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index d15ec2f..9a1fbe9 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,16 &lt; at &gt;&lt; at &gt; +2013-06-03 Stefano Lattarini &lt;stefano.lattarini&lt; at &gt;gmail.com&gt; (trivial change) + +Support relative command name for git-merge-changelog program. +Otherwise, even after correctly setting the git configuration entry +'merg</pre> Stefano Lattarini 2013-06-03T15:58:26 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5433 <pre> find . \( -type d -exec test -e {}/.ignore \; -prune \) -o .... will do something like what you want. But, again, it's not efficient, since it performs one fork/exec per subdirectory. A more efficient way might be to build a -prune expression with the output of 'locate .ignore'. But this will only work well if you only use this technique for find expressions where the start points are absolute pathnames. Other options depend a bit on how you identify which directories you put .ignore files in, and whether you can change anything else about them. That is, you could build a list of ignored directories (as a text file) instead of putting .ignore flagfiles in them. Or change the permissions on the directory (i.e. chgrp ignore somedir; chown g= somedir; then run find as with the effective GID set to ignore). James. </pre> James Youngman 2013-06-02T21:11:50 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5432 <pre>Hi, I don't want to let find search directories with a file .ignore (i.e., anything in the directory (including the subdirectories) is ignored). Is there an efficient way to customize find in this way? (I can think of an simple way---recursively call "find" with maxdepth 1 and not go into directories with .ignore. But this is not efficient.) Thanks. </pre> Peng Yu 2013-06-02T14:44:24 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5431 <pre>Update of bug #36060 (project findutils): Status: None =&gt; Need Info Assigned to: None =&gt; jay _______________________________________________________ Follow-up Comment #1: Sorry, but this isn't a useful bug report. The XML files convey almost nothing about the specific nature of the problems you are trying to report. Also, find-4.4.2 is very old. Could you please try again with a recent version of findutils? You can check out the sources with git by following the instructions here: https://savannah.gnu.org/git/?group=findutils _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?36060&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> James Youngman 2013-06-02T13:56:44 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5430 <pre> But if that's what you want to do, why use xargs at all? $ ( set -- $(echo *); count=0; for arg; do echo "Argument ${count} is ${arg}"; (( ++count )); done ) Argument 0 is build-aux Argument 1 is config.cache Argument 2 is config.h Argument 3 is config.log Argument 4 is config.status Argument 5 is doc Argument 6 is find Argument 7 is gl Argument 8 is GNUmakefile Argument 9 is lib Argument 10 is locate Argument 11 is m4 Argument 12 is Makefile Argument 13 is po Argument 14 is stamp-h1 Argument 15 is tests Argument 16 is xargs $ awk 'BEGIN {for (i=1; i&lt;ARGC; ++i) { printf("Argument %d is %s\n", i, ARGV[i]); }; exit(0); }' * Argument 1 is build-aux Argument 2 is config.cache Argument 3 is config.h Argument 4 is config.log Argument 5 is config.status Argument 6 is doc Argument 7 is find Argument 8 is gl Argument 9 is GNUmakefile Argument 10 is lib Argument 11 is locate Argument 12 is m4 Argument 13 is Makefile Argument 14 is po Argument 15 is stamp-h1 Argument 16 is tests Argument 17 is xargs </pre> James Youngman 2013-06-02T13:50:39 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5429 <pre>Update of bug #38963 (project findutils): Status: None =&gt; Fixed Assigned to: None =&gt; jay _______________________________________________________ Follow-up Comment #1: Thanks, I updated import-gnulib.config. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38963&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> James Youngman 2013-06-02T13:36:42 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5428 <pre>Update of bug #38899 (project findutils): Status: None =&gt; Invalid Assigned to: None =&gt; jay Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #2: find reads directories, so on a file system with Unix semantics, it is expected that the access time is updated. If find is modifying the access time of (non-driectory) files, then that is unexpected (for filesystems which are supposed to have Unix semantics, anyway). find doesn't open files, apart from files associated with actions -fprintf, -fprint, and system configuration files such as /etc/fstab and /etc/passed. Hence file access times shouldn't be updated. Since you're running find on Windows XP, you should start by talking to the GnuWin folks about why this is happening I think (this doesn't happen on filesystems with real Unix semantics). </pre> James Youngman 2013-06-02T12:29:43 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5427 <pre> The are many formats the -printf option supports. What's wrong with looking it up in the man page? Have a nice day, Berny </pre> Bernhard Voelker 2013-05-16T07:59:18 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5426 <pre>* lib/buildcmd.c (bc_push_arg): Take prefix length into account to avoid state-&gt;argbuf overflow. * NEWS: Mention this fix. --- It would be a security issue if one could control factors triggering this bug, which include a directory with thousands of files. ChangeLog | 7 +++++++ NEWS | 2 ++ lib/buildcmd.c | 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index e6914ff..7b4f3e0 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,10 &lt; at &gt;&lt; at &gt; +2013-05-15 Dmitry V. Levin &lt;ldv&lt; at &gt;altlinux.org&gt; + +find: fix potential buffer overflow in -execdir and -okdir. +* lib/buildcmd.c (bc_push_arg): Take prefix length into account +to avoid state-&gt;argbuf overflow. +* NEWS: Mention this fix. + 2013-04-22 Paul Eggert &lt;eggert&lt; at &gt;cs.ucla.edu&gt; More removal of support for -perm +MODE. diff --git a/NEWS b/NEWS index 4349a21..010ba6e 100644 --- a/NEWS +++ b/NEWS &lt; at &gt;&lt; at &gt; -30,6 +30,8 &lt; at &gt;&lt; at &gt; The documentation for xargs now warns about parallel processes (xargs Some bugs in 4.5.11 wer</pre> Dmitry V. Levin 2013-05-15T23:48:21 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5425 <pre>Hi, I find that things like '%H' of -printf is very hard to remember. Is there an easy way to remember '%*'? </pre> Peng Yu 2013-05-15T16:09:26 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5424 <pre>URL: &lt;http://savannah.gnu.org/bugs/?38963&gt; Summary: depend on unlinkat gnulib module Project: findutils Submitted by: gagern Submitted on: Sa 11 Mai 2013 10:12:32 CEST Category: find Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Discussion Lock: Any Release: None Fixed Release: None _______________________________________________________ Details: As discussed in https://bugs.gentoo.org/show_bug.cgi?id=469206, building findutils-4.5.11 on OS X will fail due to lack of an unlinkat function. The find/pred.c file requires that function unconditionally. Previous releases apparently shipped that file due to some gnulib-internal dependencies which seem to have changed since then. The clean solution</pre> Martin von Gagern 2013-05-11T08:12:33 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5423 <pre>Follow-up Comment #1, bug #38899 (project findutils): I'am talking about the GnuWin Version of find. Probably sourceforge rather than here is the proper place to report the bug. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38899&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> anonymous 2013-05-06T06:45:42 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5422 <pre>URL: &lt;http://savannah.gnu.org/bugs/?38899&gt; Summary: Find by Last Access Time Actually Modifies the Last Access Time by Itself Project: findutils Submitted by: None Submitted on: Sun 05 May 2013 06:48:07 PM UTC Category: find Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: alec lee Originator Email: alecleekya&lt; at &gt;hotmail.com Open/Closed: Open Discussion Lock: Any Release: 4.2.20 Fixed Release: None _______________________________________________________ Details: find "C:/bin" ( -amin -15 ) -print tested with version 4.2.20 Test done in windows XP where last access time update was enabled (attention NTFS last access time will only be updated if the last access time is &gt; around 1hr ago). So advance the clock by 1 hr for ev</pre> anonymous 2013-05-05T18:48:09 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5421 <pre>Follow-up Comment #12, bug #38474 (project findutils): Sure, but POSIX says that find should treat the existing file mode as 0 here. For example, POSIX says that "find /tmp -perm +rw" finds all files under /tmp that are read-write to everyone and that have no other permissions. Admittedly "+rw" means the same thing as "=rw" here, and "=rw" is clearer; but the point is that there's good precedent for saying that 'find -perm' should mimic chmod's syntax, even when the syntax is obscure. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38474&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Paul Eggert 2013-04-24T08:03:30 http://permalink.gmane.org/gmane.comp.gnu.findutils.bugs/5420 <pre>Update of bug #38474 (project findutils): Status: Fixed =&gt; None _______________________________________________________ Follow-up Comment #11: I've applied Paul's updated patch. However, I think I agree with Eric on the interpretation of the mode argument. I propose not to reinstante -perm +MODE with different semantics in the future. The fact that this went wrong in the first place underlines the fact that more regression test cases are needed for -perm. I don't find the argument from compatibility with chmod very convincing since the mode argument to chmod is understood to describe a modification to the mode of an existing file. In the case of -perm, there is no existing file mode. Hence a description of how the mode should be interpreted that makes perfect sense for chmod could still be confusing for find -perm. This puts me in the uncomfortable position of wondering if mode_change is really the best basis for find -perm; I'm not sure </pre> James Youngman 2013-04-24T07:13:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.findutils.bugs