[bug #45656] mention git on project page https://www.gnu.org/software/findutils/

[James Youngman]

Follow-up Comment #4, bug #45656 (project findutils):

The update to https://www.gnu.org/software/findutils/ is live now.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #45656] mention git on project page https://www.gnu.org/software/findutils/

[James Youngman]

Update of bug #45656 (project findutils):

  Status:   Need Info => Fixed  
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I just made the following change to https://www.gnu.org/software/findutils/ :

--- findutils.html  29 Aug 2019 21:03:12 -  1.21
+++ findutils.html  1 Sep 2019 21:38:01 -   1.22
@@ -125,6 +125,15 @@
 
href="https://ftp.gnu.org/gnu/gnu-keyring.gpg";>https://ftp.gnu.org/gnu/gnu-keyring.gpg.
 
 
+Accessing findutils source code with git
+
+
+  Official releases can be downloaded as source archives as described
+  above, but the findutils source code is also available via
+  https://git-scm.com";>git.   See the Savannah web page
+  https://savannah.gnu.org/git/?group=findutils";>findutils -
+  Git Repositories for details.
+
 
 How to Get Help
 
@@ -299,7 +308,7 @@
 
 Updated:
 
-$Date: 2019/08/29 21:03:12 $
+$Date: 2019/09/01 21:38:01 $
 
 
 


The change will go live the next time the web repository is exported to the
web site.  I'm not sure how often that happens, I'd expect minuted to hours.

I also applied the attached patch to the README file.  That won't be useful to
anybody much until the next source release though (if people can see that
content already it's because they already know how to use git to access the
findutils code).



(file #47430)
___

Additional Item Attachment:

File name: 0001-doc-Add-instructions-on-how-to-access-source-via-git.patch
Size:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #45656] mention git on project page https://www.gnu.org/software/findutils/

[Karl-P. Richter]

Follow-up Comment #2, bug #45656 (project findutils):

I assume I meant to mention the git repository URL in the downloads section as
an alternative to tarball downloads. The description is very unclear, sorry.
This link avoid searching for the git repository URL and makes the site more
intuitive (otherwise it's only usable with a search engine).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52137] unexpected behaviour when combining -I and -n

[James Youngman]

Update of bug #52137 (project findutils):

  Status:None => In Progress
 Assigned to:None => berny  

___

Follow-up Comment #11:

Bernhard, I notice that the shell-based test infrastructure is in place.   Are
these patches ready to be applied?   If you're no longer working on this
please change the "Assigned to" and "Status" fields back to "None".  Thanks.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52129] find lacks "-older" option symmetric to "-newer"

[James Youngman]

Update of bug #52129 (project findutils):

  Status:None => Need Info  

___

Follow-up Comment #1:

Any other supporters of such a feature request?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #51345] find shows different results despite using same command

[James Youngman]

Update of bug #51345 (project findutils):

 Assigned to: jay => None   
   Fixed Release:None => 4.6.0  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #49147] Tab character replaced by question mark ("?") when locate outputs to tty

[James Youngman]

Update of bug #49147 (project findutils):

 Open/Closed:  Closed => Open   


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #38092] Optionally support distributed memory machines using MPI

[James Youngman]

Update of bug #38092 (project findutils):

  Status:None => Postponed  
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #16:

I'm going to close this for now, since we didn't get a patch.  In any case if
such a patch existed, it's not clear how the maintainers would maintain the
relevant functionality or how many of findutils' developers would benefit.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #45656] mention git on project page https://www.gnu.org/software/findutils/

[James Youngman]

Update of bug #45656 (project findutils):

  Status:None => Need Info  

___

Follow-up Comment #1:

What's the change you're proposing?   Why?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #35254] Compress sort's temporary files

[James Youngman]

Update of bug #35254 (project findutils):

  Status:None => Need Info  
 Assigned to:None => jay

___

Follow-up Comment #2:

I'd like to get an idea how many users would benefit from such a change.  Is
it more than one?  

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Running out of disk space in updatedb?

[James Youngman]

https://savannah.gnu.org/bugs/index.php?35254 proposes compressing the
temporary files generated by "sort" dyring updatedb.

Has anyone on the list experienced an out-of-disk-space problem when
running updatedb in a situation where compression would have wholly
resolved the problem?   If there is 0 space left, compression won't
help.  If the disk is being slowly filled, compression only buys a
short time.  Anybody had a similar problem in a situation where
compression would provide a permanent benefit?

Thanks,
James.

[bug #51345] find shows different results despite using same command

[James Youngman]

Update of bug #51345 (project findutils):

  Status:None => Fixed  
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #13:

The problem is fixed in (or before) findutils 4.6.0.   Hence we can close this
bug.   For what it is worth, the version of findutils in Debian Buster is
slightly newer than that.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #35253] printf format documentation (basename/dirname)

[James Youngman]

Update of bug #35253 (project findutils):

  Status:None => Fixed  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #35253] printf format documentation (basename/dirname)

[James Youngman]

Follow-up Comment #1, bug #35253 (project findutils):

I'm about to push the attached patch to clarify the descriptions.

(file #47418)
___

Additional Item Attachment:

File name: 0001-find-Clarify-description-of-f-and-h.patch Size:4 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #49147] Tab character replaced by question mark ("?") when locate outputs to tty

[Yuval S]

Follow-up Comment #3, bug #49147 (project findutils):

 
> Well that's a design option which we don't take.  We quote them, for several
reasons, including user security.  IOW the tool is operating as intended
here.

Can you elaborate, on the security benefits of not outputting tabs to the
terminal? Especially as this is easily circumvented using `cat` I don't see
the benefit. I would be happy to learn here.

Anyway, I do suggest adding this to the documentation.

I would also be glad with an answer of "good idea, why don't you implement
it?", but I don't understand this answer.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #34083] [feature request] analog of -I REPLACE-STR without -l 1 restriction

[James Youngman]

Update of bug #34083 (project findutils):

  Status:None => Wont Fix   
 Assigned to:None => jay
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54730] Add additional valuable example of find -quit

[James Youngman]

Update of bug #54730 (project findutils):

  Status: In Progress => Fixed  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54730] Add additional valuable example of find -quit

[James Youngman]

Follow-up Comment #10, bug #54730 (project findutils):

I'm about to apply the attached patch which adds some examples similar to the
ones we discussed.

(file #47417)
___

Additional Item Attachment:

File name: 0001-Fix-Savannah-bug-54730-additional-examples-for-quit.patch
Size:4 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #48135] samefile-p-brokenlink.exp fails on Hurd and BSD

[Andreas Metzler]

Follow-up Comment #2, bug #48135 (project findutils):


[comment #1 comment #1:]
> I applied your patch, making a tweak to the wording and adding an update to
the NEWS file.  The result is
https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=c31ef289899fb06777cdf97fd8e2bf8b22fa49cc

Thank you.

> Do you think it would be worthwhile to use -P with ln as a matter of
course?

Sorry, I have no idea about the implications.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54730] Add additional valuable example of find -quit

[James Youngman]

Update of bug #54730 (project findutils):

  Status:None => In Progress
 Assigned to:None => jay


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54730] Add additional valuable example of find -quit

[James Youngman]

Follow-up Comment #9, bug #54730 (project findutils):

My second example in #5 is incorrect since -exec ... {} + is not guaranteed to
have launched a child process before the -quit is processed.   See also the
wording in the EXIT STATUS section of the manual page:

When some error occurs, find may stop immediately, without completing all the
actions specified.  For example, some starting points may not have been
examined or some pending program invocations for -exec ... {} + or -execdir
... {} + may not have been performed.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #42087] make error while cros compiling for arm with static flag enabled

[James Youngman]

Follow-up Comment #3, bug #42087 (project findutils):

Correction: s/many releases/some releases/.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #44570] Wrong find -type f -not -name "*txt" result for files with weird names

[James Youngman]

Update of bug #44570 (project findutils):

  Status:None => Working as Intended
 Assigned to:None => ericb  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #42087] make error while cros compiling for arm with static flag enabled

[James Youngman]

Update of bug #42087 (project findutils):

  Status:None => Need Info  
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

There have been many releases since this bug was reported (most recently
4.7.0).   If you can reproduce this problem with 4.7.0, please re-open this
bug.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #45930] -ignore_readdir_race ineffective in find 4.5.11 and 4.5.14

[James Youngman]

Update of bug #45930 (project findutils):

 Assigned to:None => berny  

___

Follow-up Comment #5:

Trying the reproducer in #4 with Findutils 4.7.0, I see no problems.   
Bernhard, did you fix this already?   If the problem is partially-fixed, is it
fixed enough that we can close the bug?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #32976] find has no option to ignore case of starting directories

[Linda A. Walsh]

Follow-up Comment #5, bug #32976 (project findutils):

[comment #1 comment #1:]
> If I understand what you're asking for, this is what -iname does.
> 
> /tmp$ touch x
> /tmp$ find x -iname X
> x
> 
> If this isn't what you are interested in, could you be more specific?
> 
I was asking for a case ignore option for the starting path.

I'm aware of -iname to look for names, ignoring case, but how do you put in
the start directory?

find  args

what is needed is a find DIR -istart which would find DIR whether it is named
'dir', 'DIR' or whatever.  like -maxdepth, -istart would have to be one of the
first args.

In a similar way bash can match a path regardless of case if it is part of a
regex and you hve the ignore case turned on.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #32447] Wishlist: fadvise()

[James Youngman]

Update of bug #32447 (project findutils):

  Status:None => Wont Fix   
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #6:

No response from Alan (the original reporter of the bug).  Hence, closing. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #24561] find -ok should not redirect stdin

[James Youngman]

Follow-up Comment #7, bug #24561 (project findutils):

I would suggest that -okdir should follow -ok unless there turn out to be some
very user-surprising consequences.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52890] `find --name` ignores files with non-printable character in the filename

[James Youngman]

Update of bug #52890 (project findutils):

  Status:None => Working as Intended
 Assigned to:None => ericb  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #53075] FR: command line switch to make -ls print file names as-is

[James Youngman]

Update of bug #53075 (project findutils):

  Status:None => Working as Intended
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I believe that piping the output through "cat" is a sufficient workaround. 
Please re-open the bug if you disagree.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54745] -mount needs to be slightly different from -xdev

[James Youngman]

Follow-up Comment #2, bug #54745 (project findutils):

Eric, would you like to work on this?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54745] -mount needs to be slightly different from -xdev

[James Youngman]

Follow-up Comment #1, bug #54745 (project findutils):

The announcement email for the recent 4.7.0 release states:

* Upcoming changes

For consistency with planned changes to POSIX, the semantics of 'find -mount'
may be different from that of 'find -xdev' in future releases.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #32977] updatedb has no option to ignore case on filenames

[James Youngman]

Update of bug #32977 (project findutils):

  Status:None => Wont Fix   
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

By design, updatedb now uses the C locale (see the NEWS file for findutils
4.7.0, and also https://savannah.gnu.org/bugs/?46846).  This avoids problems
with path names whose components are encoded in incompatible locales.   

This makes it infeasible to ignore case, since the implementation would need
to identify the character encoding of each component in the current path name,
and this information is not recorded by the operating system.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

[James Youngman]

Update of bug #37093 (project findutils):

Severity:  3 - Normal => 4 - Important  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

[James Youngman]

Update of bug #37093 (project findutils):

  Status:None => Need Info  

___

Follow-up Comment #5:

Findutils 4.7.0 was recently released also.   Are you still able to reproduce
the problem with it?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

[James Youngman]

Update of bug #49466 (project findutils):

  Status: Invalid => Platform Issue 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #48135] samefile-p-brokenlink.exp fails on Hurd and BSD

[James Youngman]

Update of bug #48135 (project findutils):

  Status:None => Fixed  

___

Follow-up Comment #1:

I applied your patch, making a tweak to the wording and adding an update to
the NEWS file.  The result is
https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=c31ef289899fb06777cdf97fd8e2bf8b22fa49cc

Do you think it would be worthwhile to use -P with ln as a matter of course?


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #48135] samefile-p-brokenlink.exp fails on Hurd and BSD

[James Youngman]

Update of bug #48135 (project findutils):

 Assigned to:None => jay


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #48169] find makes unnecessary syscalls

[James Youngman]

Update of bug #48169 (project findutils):

  Status:None => Postponed  
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

We have quite a few open bugs and in the absence of a (reported) measurable
performance difference, I'm going to close this bug.

I'm not saying the bug report is incorrect, just that in the absence of a
measurable perfoemance impact it doesn't seem worthwhile to work on this bug
(and in so doing, neglect others).

Please re-open this bug or create a new one if there is, in fact, a measurable
performance difference.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #42501] Add -E option for FreeBSD/Mac OSX compatibility

[James Youngman]

Update of bug #42501 (project findutils):

  Status:None => Need Info  

___

Follow-up Comment #3:

I'm happy to implement this option as long as we can nail down which regex
dialect -E should select.   Is there any chance you could provide more detail
on your answer to question 1, perhaps by performing some experiments?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #46846] failure due to filename encoding and locale on OSX

[James Youngman]

Update of bug #46846 (project findutils):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => 4.7.0  

___

Follow-up Comment #3:

This should be fixed in findutils 4.7.0.   From the NEWS file:

The updatedb script now operates in the C locale only.  This means
that character encoding issues are now not likely to cause sort to
fail.  It also honours the TMPDIR environment variable if that was
set, and no longer sorts file names case-insensitively.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #48298] Find performance problem on simple conditions/large directories

[James Youngman]

Update of bug #48298 (project findutils):

  Status:None => Need Info  
 Assigned to:None => jay

___

Follow-up Comment #1:

Findutils 4.7.0 was recently released and includes a newer version of the fts
code.  Could you check whether this problem also exists in 4.7.0 please?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #49147] Tab character replaced by question mark ("?") when locate outputs to tty

[James Youngman]

Update of bug #49147 (project findutils):

  Status:None => Invalid
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

> Output piped via `cat` should be identical to direct terminal output.

Well that's a design option which we don't take.  We quote them, for several
reasons, including user security.  IOW the tool is operating as intended
here.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

[James Youngman]

Update of bug #49466 (project findutils):

  Status:None => Invalid
 Assigned to:None => jay


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #50606] Garbage printed with "no such file or directory"

[James Youngman]

Update of bug #50606 (project findutils):

  Status:None => Invalid
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

[James Youngman]

Update of bug #54591 (project findutils):

  Status:None => Fixed  
 Assigned to:None => berny  
   Fixed Release:None => 4.7.0  

___

Follow-up Comment #6:

Findutils 4.7.0, which Bernhard released recently, includes an update to
gnulib.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56831] FAIL: tests/find/printf_inode

[James Youngman]

Update of bug #56831 (project findutils):

  Status:None => Need Info  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56823] -regextype egrep compatibility issue, requires full string match as opposed to egrep

[James Youngman]

Update of bug #56823 (project findutils):

Severity:  3 - Normal => 2 - Minor  
  Status:None => Invalid
 Assigned to:None => jay

___

Follow-up Comment #1:

Well if we look at the "Finding Files" manual we see that -regex is described
like this:

@deffn Test -regex expr
@deffnx Test -iregex expr
True if the entire file name matches regular expression @var{expr}.
This is a match on the whole path, not a search.  For example, to
[...]

Similarly, in the manual page:

-regex pattern
  File name matches regular expression pattern.  This is a match on the whole
path, not a search.  For example, to
[...]

The description of the -regextype option specifically states that it affects
only the regular expression syntax understood:

@deffn Option -regextype name
This option controls the variety of regular expression syntax
understood by the @samp{-regex} and @samp{-iregex} tests.  

The manpage is worded somewhat similarly:

-regextype type

  Changes  the  regular  expression  syntax  understood by -regex and -iregex
tests which occur later on the command line.  To see which regular expression
types are known, use -regextype help.  The Texinfo documentation (see SEE
ALSO) explains the meaning of and differences between the various types of
regular expression.


It's difficult then to see how such a confusion can arise.
If there is a specific change to the documentation that you think would avoid
confusion, I'd be happy to consider a patch you'd like to send.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/