[bug #20510] [wishlist] updatedb does not use gettext

Follow-up Comment #1, bug #20510 (project findutils): updatedb.c is almost done. I'm going to add gettext support as well. ___ Reply to this item at: ___

Re: Invalid predicate problem

On Sun, Jul 08, 2007 at 07:09:36AM -0600, Eric Blake wrote: > It's quoted wrong. Each predicate must be a separate argument, not one > run-on argument. You probably meant: Duh. You're right of course. Thanks! Leslie -- Personal homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --k

Invalid predicate problem

I wonder why the following expression: find /home/sky/projects/findutils/sp \ '( -fstype ext3 -o -type d -wholename prune1 \ -o -type d -wholename prune2 -o -type d -wholename prune3)' \ -prune -o -print0 fails with invalid predicate `( -fstype ext3 -o -type d -wholename

updatedb: Spaces in {local,prune,net}paths

AFAICS there's no way to have directory names with spaces in the mentioned paths. Shall we define one? Leslie -- Personal homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpAYrewaMuSX.pgp Description: PGP signature ___

Re: Fwd: This week's NEWS

On Sun, Jun 03, 2007 at 09:25:58AM +0100, James Youngman wrote: > It's a hangover from the days when we used to use basename(). The > basename() function does not allocate memory. The fact that the buffer > returned by base_name() is not freed is not intentional. I'm sure the > same problem affect

Re: Suggestion for updatedb

On Fri, May 11, 2007 at 09:28:45AM +0100, James Youngman wrote: > This change makes a great deal of sense. Unfortunately, there are a > number of difficulties with the idea. None of them are insuperable > perhaps, but here they are: Lots of what you said concerns locate. Is there any serious rea

Re: ARG_MAX

On Thu, Apr 26, 2007 at 10:23:33AM +0100, James Youngman wrote: > I like your idea of separating the strategy (making decisions about > whether to exec now and start again, or add this argument to the > list) from the nuts and bolts of the implementation. Perhaps we couls > separate the buildcmd.c

Re: Things to bear in mind when changing updatedb...

On Sun, Apr 15, 2007 at 01:35:54PM +0100, James Youngman wrote: > It's not that I am asking you to fix the bugs, it's that I hope we can > make the problems irrelevant by improving updatedb's design. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245874 This one seems to be a Debian issue.

Re: Good occasion to drop support for old locatedb format?

On Sun, Apr 15, 2007 at 12:42:01PM +0100, James Youngman wrote: > Anyway, if you think it is helpful to omit that functionality for the > moment in order to complete your SOC project within a reasonable time > frame, that's OK, we can always add it back later after SOC. No, I don't think it's goi

Good occasion to drop support for old locatedb format?

updatedb.sh mentions that support for the old locatedb format will be shortly discontinued. Would the conversion of the script to a C program be a good occasion for dropping this compatibility, or wouldn't there have been enough grace time for users then? Leslie -- NEW homepage: https://viri

Re: updatedb.c: call find via exec()

On Wed, Apr 11, 2007 at 04:47:00PM +0400, Dmitry V. Levin wrote: > On Wed, Apr 11, 2007 at 10:25:23AM +0200, Leslie P. Polzer wrote: > > I gave this some thought and it seems to be the best solution. > > > > Any other ideas? > > Looks like I missed context of this question, sorry. Start at the subj

Re: updatedb helper binaries

On Tue, Apr 10, 2007 at 06:22:02PM +0100, James Youngman wrote: > I think we still need to retain the ability to create a locate > database from a flat file. At the moment we can do this with code and > bigram. I think any replacement would need to keep that ability. Surely, but we can do it witho

updatedb helper binaries

The current updatedb shell script needs the '*code' and 'bigram' binaries to fulfil its duty. As the replacement will be in C, do we still need those binaries? Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpiSNbJZoj8

Re: [PATCH] Draft for xattr support

On Sat, Apr 07, 2007 at 08:37:48PM +0100, James Youngman wrote: > >By the way, I'm currently also looking into the possibility of > >porting findutils to MINIX 3. I miss it badly there! > > If it runs under QEMU or (better) Xen I can support it. Otherwise I > can accept patches, but not guarantee

ChangeLog

Does findutils require developers to update ChangeLog, or is the RCS log enough? -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpGSuNnjeDdL.pgp Description: PGP signature ___ Bug-findu

Re: [PATCH] Draft for xattr support

On Sat, Apr 07, 2007 at 01:15:02PM +0100, James Youngman wrote: > ... that reminds me to remind you: don't forget the tests and > documentation! Not forgotten :) Did you happen to have an idea WRT to the xattr testing problem (reminder: tests will fail if xattr not supported on test file system)?

Re: [PATCH] Draft for xattr support

On Tue, Apr 03, 2007 at 11:33:54PM +0100, James Youngman wrote: > When adding an item to struct predicate, please use a comment to > indicate which predicates it supports. Done. > maynot be available on all platforms, so configure > should check for it. Yeah, that's a TODO for me. > fnmatc

Re: [PATCH] Draft for xattr support

[taking this to bug-findutils] On Wed, Apr 04, 2007 at 10:40:05AM +0100, James Youngman wrote: > I'm not sure what the relative performance cost is of the functions > get_attr() and so forth. I would not be surprised to see that they > were about as fast as access(), perhaps a little slower. So

Re: [PATCH] Error message clarification

On Sat, Mar 31, 2007 at 07:14:24PM +0100, James Youngman wrote: > How about this patch, which gives a more specific error? > [...] Well, even better! :) Mine was just a quick hack to alleviate the matter, but yours surely offers more than that. By the way, I think you introduced some broken thin

[PATCH] Error message clarification

Another quickie. When a predicate is not syntactically correct, the find parser will currently say: "invalid predicate `%s'" which IMO obscures the fact that the predicate NAME may be alright, but the number or format of parameters didn't match. Therefore: "invalid or malformed predicat

Allocating memory in parser.c

This is not of concern to the xattr support, but the question popped up nevertheless: Is there a place to free memory that has been allocated in a parse_* function? Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 pgpOEaU

[PATCH] Draft for xattr support

Hello James, the attached patch includes the guts for extended attributes support in find. Not yet included: * wildcard matching attributes with fnmatch() * success rate estimation * checks in configure.ac for attr headers and libraries * documentation changes Open questi

[PATCH] fix broken import-gnulib.sh

It doesn't work because 'cvsdir' never gets set to something else than "/doesnotexist". Attached patch fixes the problem by making it a global in do_checkout() and moving the assignment behind the calling of that function. ~ L. -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gp

Extended Attributes

Hello, is it true that the current version of findutils does not support extended attributes? Leslie -- gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 http://nic-nac-project.de/~skypher/ pgpsrZHg9Htbr.pgp Description: PGP signature ___ Bug-fi

Re: GNU Summer of Code application

Hello Walter, On Wed, May 03, 2006 at 05:11:44AM -0400, Walter Mundt wrote: > Leslie Polzer (who I presume is reviewing many of the GNU apps since > she doesn't appear in the bug-findutils archives) submitted a question > on the app: To clear things up a bit: I am indeed not inv