Re: [bug #63605] Large number of UBSAN failures in test suite

James Youngman writes: > Fixed with the attached patch. > Thank you!

Re: [bug #63605] Large number of UBSAN failures in test suite

Fixed with the attached patch. On Sun, May 19, 2024 at 10:26 PM James Youngman wrote: > Update of bug #63605 (group findutils): > > Status:None => Fixed > > Assigned to:None => jay > > >

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Documentation update for the above change. On Sun, May 19, 2024 at 11:18 AM James Youngman wrote: > This patch addresses the POSIX compliance aspect explained by Geoff > Clare. A test is included. > > > From 9fed05088f5bfe5d7d7b5e92ae301517e84760f8 Mon Sep 17 00:00:00 2001 From: James

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

This patch addresses the POSIX compliance aspect explained by Geoff Clare. A test is included. From b560e3f911c1eb0095a2c07a461bc28f7335fbd1 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sun, 19 May 2024 11:05:38 +0100 Subject: [PATCH] [xargs] POSIX requires SIGUSR1/2 to be fatal if not

Re: [bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Fixed in git with the attached patch. On Thu, Jul 20, 2023 at 8:46 AM anonymous wrote: > URL: > > > Summary: Unexpected behaviour of xargs when multiple > children > exit with 255 in parallel >Group: findutils >

Re: MinGW support

> This repo is a fork of jamesyoungman/findutils:master but that is a > (frequently very out of date) mirror of the real findutils git repository, > which is on Savannah, not github (see > https://savannah.gnu.org/git/?group=findutils for details). > > If you'd like to discuss next steps, the

Re: [bug #65283] Misleading statement, I believe

Fixed with this patch. On Fri, May 17, 2024 at 9:49 AM James Youngman wrote: > Update of bug #65283 (group findutils): > > Severity: 3 - Normal => 2 - Minor > > Status:None => Fixed > > Assigned to:

Re: [bug #65297] -regexp incompatible statements concerning default

Fixed with this patch. On Fri, May 17, 2024 at 9:31 AM James Youngman wrote: > Update of bug #65297 (group findutils): > > Status:None => Fixed > > > ___ > > Follow-up Comment #2: > > Fixed in git. > >

Re: MinGW support

On Thu, May 9, 2024 at 11:46 AM Cyril Arnould wrote: > Hi! I was wondering if there's a possibilty for GNU findutils to > officially start supporting MinGW-w64. To set your expectations, this email isn't going to answer that question. > It has been ported before as > part of both the

Re: [bug #65305] @var{name} should be @var{NAME}

I pushed the attached simple patch to fix this. From e549900aa62dde81c65af5ede950a7918a0facb5 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Fri, 17 May 2024 08:42:07 +0100 Subject: [PATCH] [doc] Use @var{name}, not NAME or @var{NAME} in "Hard Links". To: findutils-patc...@gnu.org The

Re: [PATCH 0/2] gnulib related patches

Looks good. I'm a fan of ght gnulib-tool rewrite.

Re: Rust findutils

On Wed, May 15, 2024 at 6:53 PM James Youngman wrote: > > [I changed the subject line because this is quite a tangent from the original > thread] > > On Wed, May 15, 2024 at 7:50 PM Nikolaos Chatzikonstantinou > wrote: >> >> >> How about GNU does a call to arms for an alternative Rust >>

Re: Rust findutils

I wrote: > The advantage of using gnulib for things like fts is that findutils is not the only consumer, and we're very likely to notice issues with it even in weird corner cases. I should explain that this advantage is strong enough that, following a multi-year period of parallel running, we

Re: Ensuring that all the fields of struct predicate are initialized

On Tue, May 14, 2024 at 5:16 PM James Youngman wrote: > One of the worries in the back of my mind with findutils has always been > about whether all the fields in `struct predicate` actually get initialised > correctly by the parser functions. > > I should explain that recently I've been using

Re: Ensuring that all the fields of struct predicate are initialized

of utility functions around predicates which already exist: get_new_pred_chk_op, get_new_pred_noarg, insert_primary_withpred, insert_primary, collect_arg_nonconst, ... I would see some potential to make the code better readable. Compared to other find(1) implementations, the GNU code is really complex. Re.

Re: Ensuring that all the fields of struct predicate are initialized

On 5/14/24 2:15 PM, James Youngman wrote: > I should explain that recently I've been using other languages which make > it possible to ensure at compile time that things are correctly initialised > and consistently used, and to be direct about it, I miss these things in C. Newer GCC versions have

Re: Some tidy-ups

On 5/14/24 10:06 AM, James Youngman wrote: See attached patches. If no objections, I will submit these soon. all 3 look good to me, thanks! Have a nice day, Berny

Re: Some tidy-ups

On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > > > On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > >> See attached patches. If no objections, I will submit these soon. >> >> >> From 76215fb45f29a035ddeb64ede8eb8078f02f5e75 Mon Sep 17 00:00:00 2001 From: James Youngman Date:

Re: Some tidy-ups

On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > See attached patches. If no objections, I will submit these soon. > > > From ab0137eff33dcb09b1d108d99e3549fb1e5d38a6 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Mon, 13 May 2024 21:37:05 +0100 Subject: [PATCH 2/3] Rename

Re: Enhancement request for 'locate'

On 4/22/24 23:18, James Youngman wrote: locate-ls() { locate -0 "$@" | xargs -0 ls -ld } I'd suggest using -r there also, so that if no files are found, the user doesn't get a surprising listing of just "." (with its mod-time and so forth). $ xargs --help | grep empty -r,

Re: Enhancement request for 'locate'

> > > > locate-ls() { >locate -0 "$@" | xargs -0 ls -ld > } > > I'd suggest using -r there also, so that if no files are found, the user doesn't get a surprising listing of just "." (with its mod-time and so forth).

Re: Enhancement request for 'locate'

Hi Seamus, On 2/13/24 22:02, Seamus de Mora wrote: Hello, I have a request for the 'locate' program: thanks. I would like to see an option added that would add the modification time/date to the results (files found by locate). This would be similar (even identical) to the output of 'ls -l

Re: [bug #65386] unknown predicate error when using '-1M' as lt 1

You need a space after -size. On Thu 29 Feb 2024, 03:59 anonymous, wrote: > URL: > > > Summary: unknown predicate error when using '-1M' as lt 1 >Group: findutils >Submitter: None >

Re: Null pointer dereference

On 2/9/24 19:13, John Seth Thielemann wrote: > Building with a gcc nolibc / musl / linux setup found a null pointer dereference in the pred_and handling. > > Take care, > J. Seth Thielemann Thanks for the patch, but ... > diff -Naur

Re: Reg.. find command not working as expected in Ubuntu...

On Mon, Dec 04, 2023 at 07:37:10AM +1100, raf wrote: > On Sat, Dec 02, 2023 at 03:44:19PM +, Mannem Anil kumar > wrote: > > > Dear Concern, > > As i was exploring Linux related commands, i have executed the > > following command in terminal. Where that file is not existed and > > find

Re: Reg.. find command not working as expected in Ubuntu...

On Sat, Dec 02, 2023 at 03:44:19PM +, Mannem Anil kumar wrote: > Dear Concern, > As i was exploring Linux related commands, i > have executed the following command in terminal. Where that file is not > existed and find command not says that file is not

Re: Reg.. find command not working as expected in Ubuntu...

I can't reproduce this claimed problem with findutils 4.9.0: horizon:~$ find foo find: ‘foo’: No such file or directory horizon:~$ echo $? 1 horizon:~$

Re: Reg.. find command not working as expected in Ubuntu...

On 2023-12-02 Mannem Anil kumar wrote: > Dear Concern, > As i was exploring Linux related commands, i > have executed the following command in terminal. Where that file is not > existed and find command not says that file is not found. >

Re: [PATCH 2/2] find.1: highlight the find(1) tool in more places.

On 10/14/23 20:39, Bernhard Voelker wrote: +.find find Drats! A lint check complains about this syntax error, and prohibits a successful build. Fixed with the attached and pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=c79e5f7973848 Have a nice day, BernyFrom

Re: Guaranteed order among starting points?

On Tue, Nov 7, 2023 at 6:04 PM Bernhard Voelker wrote: > > On 11/7/23 07:10, Ronan Pigott wrote: > > $ find one/ two/ -name file > > one/file > > two/file > > > > I want to know if there exists directories one/ and two/ and a matching > > file in > > each directory, is the above

Re: Guaranteed order among starting points?

Hey Bernhard, Thanks for the response. > The man page of GNU find(1) is quite clear about the order (right at the top > of the page): > https://git.savannah.gnu.org/cgit/findutils.git/tree/find/find.1?id=9a6b5821#n13 > > GNU find searches the directory tree rooted at each given starting-point

Re: Guaranteed order among starting points?

On 11/7/23 07:10, Ronan Pigott wrote: Hey find users, I have a question about the behavior of GNU find. Consider the following invocation of find $ find one/ two/ -name file one/file two/file I want to know if there exists directories one/ and two/ and a matching file in each

Re: Excluding future-dated files in 'find' on Cygwin

On 2023-10-20 Backwoods BC wrote: > On Fri, Oct 13, 2023 at 7:55 AM Andreas Metzler wrote: > > On 2023-10-13 Backwoods BC wrote: > > [...] [...] > TFM says: > -atime n > File was last accessed less than, more than or exactly n*24 hours ago. > When find figures out how many 24-hour periods ago

Re: Minor documentation issue: escaping {}

Bash promises to leave incorrectly-formed brace expressions unchanged, and this is why {} on input yields {} on find's command-line. {} is incorrectly formed since it doesn't contain a sequence expression or a comma. But is the same guarantee provided by other shells that also perform brace

Re: Minor documentation issue: escaping {}

On 10/7/23 00:11, Keith Thompson wrote: As of the latest version of findutils (commit e6e2d10a, Mon 2023-10-02), the man and info documentation both incorrectly state that {} needs to be escaped. In the info documentation, section 3.3.1: It replaces the string '{}' by the current file name

Re: Excluding future-dated files in 'find' on Cygwin

On 2023-10-13 Backwoods BC wrote: [...] > find ./ -mtime +0 -mtime -1 > but this found nothing. When I changed it to: > find ./ -mtime 0 -mtime -1 > it worked as desired and found all files less than a day old and not > future-dated. > Can someone tell me, please, if this is a bug or the

Re: Request for long option support for find -type

On 9/29/23 04:00, A C wrote: I would like to request that the find command supports long options for the -type argument, such as "--type=directory" or "-type directory". This would make the command more readable and self-explanatory, especially when writing bash scripts that use find. Thanks

Re: [PATCH] xargs.1: some remarks and editing fixes in the man page

On 6/29/23 00:13, Bernhard Voelker wrote: Hello Bjarni, On 6/20/23 20:13, Bjarni Ingi Gislason wrote: > [...] many thanks for the fixes - this is highly appreciated. I like them all. Pushed at:

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

Sometimes the thing you need to do isn't a precise fit for the tools (in this case, find) you have, and the Bourne shell is not quite powerful enough to directly express the algorithm you have in mind, so it can be better to fall back on a scripting language, perhaps something like this:

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

On 9/15/23 17:24, Peng Yu wrote: On 2023-09-12 Peng Yu wrote: How to find directories that only contain a certain type of files (e.g., .txt)? This is too inefficient. It will call sh too many times. To be efficient, I will have to call find to just get the path of all files and process the

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

On Tue, Sep 12, 2023 at 6:13 PM raf wrote: > > On Tue, Sep 12, 2023 at 06:39:32PM +0200, Andreas Metzler > wrote: > > > On 2023-09-12 Peng Yu wrote: > > > Hi, > > > > > How to find directories that only contain a certain type of files (e.g., > > > .txt)? > > > > > One idea that I have is to

Re: clarification regarding the evaluation of global options

On 9/13/23 08:45, crs...@libero.it wrote: Tavian Barnes wrote: -depth is always true, but "true and something else" is the same as "something else" so it still has to check -name a.txt. Very correct. It is more than obvious that my question/interpretation was wrong. Probably because my

Re: clarification regarding the evaluation of global options

Tavian Barnes wrote: On Tue, Sep 12, 2023 at 10:15 AM wrote: Let's assume the following current folder: . | + a.txt | + b.txt | + c.txt in which we issue the following command $ find . -depth -name a.txt -o -name b.txt We get the following result: ./a.txt ./b.txt

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

On Tue, Sep 12, 2023 at 06:39:32PM +0200, Andreas Metzler wrote: > On 2023-09-12 Peng Yu wrote: > > Hi, > > > How to find directories that only contain a certain type of files (e.g., > > .txt)? > > > One idea that I have is to just search for all files' paths. Then use > > a post-processing

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

On 2023-09-12 Peng Yu wrote: > Hi, > How to find directories that only contain a certain type of files (e.g., > .txt)? > One idea that I have is to just search for all files' paths. Then use > a post-processing script to analyze which directories only contain > files of a certain type (e.g.,

Re: clarification regarding the evaluation of global options

On Tue, Sep 12, 2023 at 10:15 AM wrote: > > Let's assume the following current folder: > > . > | > + a.txt > | > + b.txt > | > + c.txt > > in which we issue the following command > > $ find . -depth -name a.txt -o -name b.txt > > We get the following result: > > ./a.txt > ./b.txt > >

Re: [bug #64605] Add support for extended attributes

Thanks for the mention Raf, unfortunately I'm not much of a developer so addressing the concerns with my patch was a bit out of my league. I'm happy to assist if anyone wants to try and get it rebased/updated. cheers On Tue, 29 Aug 2023 at 12:38, raf wrote: > Follow-up Comment #1, bug #64605

Re: [bug #58197] "find" fails to optimize "-path /usr/foo -o -path /usr/bar" to "-regex '/usr/\(foo\|bar\)'"

> On 19 Jul 2023, at 11:52 PM, Spencer Baugh wrote: > > Follow-up Comment #3, bug #58197 (project findutils): > > One use case is GNU Emacs which heavily uses find, for example in M-x rgrep. > Emacs often constructs find commands which look like this by default: > > find -H . \( -path

Re: [PATCH] xargs.1: some remarks and editing fixes in the man page

e it doesn't use the .B \-i -option. The second invocation of +option. +The second invocation of .B xargs -does have such a limit, but we have ensured that it never encounters -a line which is longer than it can handle. This is not an ideal -solution. Instead, the +does have such a limit, +but we

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On 2023-06-02 raf wrote: > On Thu, Jun 01, 2023 at 07:14:55PM +0200, Andreas Metzler > wrote: [...] > > file reads from $(datadir)/misc and libmagic-mgc ships > > /usr/lib/file/magic.mgc which is symlinked to /usr/share/misc/magic.mgc. > > > > cu Andreas > > Thanks. On Debian the symlink is

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On Thu, Jun 01, 2023 at 07:14:55PM +0200, Andreas Metzler wrote: > On 2023-06-01 raf wrote: > [...] > > but both locations are empty. /usr/share/misc/magic is > > a symlink to /usr/share/file/magic which is empty. I > > wonder how it works. > [...] > > file reads from $(datadir)/misc and

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On 2023-06-01 raf wrote: [...] > but both locations are empty. /usr/share/misc/magic is > a symlink to /usr/share/file/magic which is empty. I > wonder how it works. [...] file reads from $(datadir)/misc and libmagic-mgc ships /usr/lib/file/magic.mgc which is symlinked to

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On Wed, May 31, 2023 at 11:19:27PM +0200, Bernhard Voelker wrote: > On 5/27/23 01:39, raf wrote: > > I could be wrong, but I don't think a -mime predicate adds much value. Since > > mimetypes are determined by file name extension anyway, [...] > > I don't think (proper) tools determine the

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On 5/27/23 01:39, raf wrote: I could be wrong, but I don't think a -mime predicate adds much value. Since mimetypes are determined by file name extension anyway, [...] I don't think (proper) tools determine the mime type of a file by its extension. Instead, they (should) always look at the

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

exec $TOOL '{}' ';' - bulk execution: $ find ... -exec $TOOL '{}' + - if $TOOL understands Zero-separated input (e.g. like grep): $ find ... -print0 | $TOOL -z - else $ find ... -print0 | xargs -r0 $TOOL Re. file(1): unfortunately, this tool - although it has a --files-from option - does not

Re: Allow users to find "--" argument documentation

On 4/21/23 01:20, Dan Jacobson wrote: If we read (info "(coreutils) cat invocation") we also get told about (info "(coreutils) Common options") But if we read e.g., (info "(find) Invoking xargs") we never know about (info "(coreutils) Common options") even though they also apply. So unlike cat,

Re: findutils INFO lacks bug reporting mention

On 4/22/23 08:54, Dan Jacobson wrote: OK, but remember to link "bugs, reporting" in https://www.gnu.org/software/findutils/manual/html_node/find_html/Primary-Index.html Done with the attached && pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=277de38d4bc97e Thanks & have

Re: info find does not describe -name option

On 4/14/23 15:42, uzibalqa wrote: I see what you mean - the entry point for `info find` is a bit unlucky, because it directly goes to section "Invoking find". Maybe `info '(find)' 'Finding Files'` would be a better start. I have to think about it. Thank you for thinking about some organising

Re: findutils INFO lacks bug reporting mention

OK, but remember to link "bugs, reporting" in https://www.gnu.org/software/findutils/manual/html_node/find_html/Primary-Index.html just like on https://www.gnu.org/software/coreutils/manual/html_node/Concept-index.html#Concept-index_cp_letter-B Thanks. > "JY" == James Youngman writes: JY>

Re: findutils INFO lacks bug reporting mention

It's in the introduction. On Fri, Apr 21, 2023 at 12:32 AM Dan Jacobson wrote: > > No where in (info "(find) Top") is where to report bugs mentioned. > Please do like (info "(coreutils) Introduction") where they remember to > mention where to report bugs. Yes, it is mentioned on the findutils

Re: info find does not describe -name option

--- Original Message --- On Friday, April 14th, 2023 at 7:46 PM, Bernhard Voelker wrote: > On 4/14/23 00:02, uzibalqa wrote: > > > --- Original Message --- > > On Friday, April 14th, 2023 at 9:24 AM, Bernhard Voelker > > m...@bernhard-voelker.de wrote: > > > > > I see

Re: prunefs/paths on AIX

Good afternoon, > Is the locatedb so huge, or are there some pseudo paths like /sys or > (undetected?) recursive mounts involved? Apologies, prunepaths does work, some numbers below. This system has about 3 million files on it: locatedb = 73MB sort files at peak = ~600MB If I exclude a

Re: info find does not describe -name option

On 4/14/23 00:02, uzibalqa wrote: --- Original Message --- On Friday, April 14th, 2023 at 9:24 AM, Bernhard Voelker wrote: I see -name well documented in section "2.3.1 Base Name Patterns": It is good as you say, but I get something different when I do "info find" in terminal.

Re: info find does not describe -name option

--- Original Message --- On Friday, April 14th, 2023 at 9:24 AM, Bernhard Voelker wrote: > On 4/12/23 22:10, uzibalqa wrote: > > > Have been looking at > > > > info find > > > > for find (GNU findutils) 4.7.0-git > > > > Although info describes -name option in "8.1.2 Warning

Re: info find does not describe -name option

On 4/12/23 22:10, uzibalqa wrote: Have been looking at info find for find (GNU findutils) 4.7.0-git Although info describes -name option in "8.1.2 Warning Messages", this is not the standard way of listing command options. I would be grateful if info for find could list find options in the

Re: prunefs/paths on AIX

On Wed, Apr 12, 2023 at 2:22 PM AIXperts Consultancy ltd. wrote: > > > Good morning, > > We have a problem with running updatedb on AIX filling up either /var or > /tmp. This seems to come from sort generating temporary files, but it > does not appear to be a problem on Linux. The updatedb

Re: prunefs/paths on AIX

On 4/12/23 09:59, AIXperts Consultancy ltd. wrote: Good morning, We have a problem with running updatedb on AIX filling up either /var or /tmp. This seems to come from sort generating temporary files, but it does not appear to be a problem on Linux. I have scrutinised sort but cannot explain

Re: An interesting thing: about the naming of xargs

Applied, thanks.

Re: An interesting thing: about the naming of xargs

On 3/18/23 11:02, James Youngman wrote: Some minor improvements. I like it. Minor nit: > Subject: [PATCH] [doc] describe history of find, xargs and locate. ___^ git seems to swallow square brackets at the beginning of the "Subject:" line during `apply-mail`, so the

Re: An interesting thing: about the naming of xargs

Some minor improvements. From 21f22dabccaa715d388cdcd3625fea5616741e42 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sat, 18 Mar 2023 10:01:19 + Subject: [PATCH 2/2] [doc] provide an introduction to the History section. To: findutils-patc...@gnu.org --- doc/find.texi | 12 +++-

Re: An interesting thing: about the naming of xargs

On Thu, Mar 16, 2023 at 6:12 PM James Youngman wrote: > > Interesting question. I just asked Herb Gellis, the inventor of > xargs. No answer yet. The answer turns out to be "eXecute command with ARGumentS". The first letter is "x" because there was no other command beginning with "x" at the

Re: An interesting thing: about the naming of xargs

On Thu, Mar 16, 2023 at 06:12:51PM +, James Youngman wrote: > Interesting question. I just asked Herb Gellis, the inventor of > xargs. No answer yet. "x" is often used in abbreviations and initialisms of words that start with "ex". it's quite possible that it wasn't even a conscious

Re: An interesting thing: about the naming of xargs

Interesting question. I just asked Herb Gellis, the inventor of xargs. No answer yet.

Re: An interesting thing: about the naming of xargs

On 3/14/23 05:01, Nature wrote: Hi: Learned from Wikipedia : xargs (short for "extended arguments") is a command on Unix and most Unix-like operating systems. Why isn't it called exargs, but xargs. Would love to know what was considered at the time. It saves one char of typing -

Re: An interesting thing: about the naming of xargs

> > On 14 Mar 2023, at 5:11 PM, Nature wrote: > > Hi: >Learned from Wikipedia : xargs (short for "extended arguments") is a > command on Unix and most Unix-like operating systems. > >Why isn't it called exargs, but xargs. Would love to know what was > considered at the time.

Re: [gnu.org #1912852] Typo

On 2/12/23 02:48, bill-auger via RT wrote: your comment got through to webmaster - thanks for attending to it - ive a follow suggest "all its input" is improper grammar - that should be "all of its input" also, i would either quote or hyphenate "the end of file string"; because that phrase

Re: [gnu.org #1912852] Typo

Hi *, I'm not sure how RT works, but it seems that I can't reply to forwarded messages, and the communication is somehow "broken". I hope this reply to webmasters-comment makes it go the right way ... On 2/9/23 10:47, Therese Godefroy via RT wrote: Hello Findutils maintainers, If you don't

Re: [gnu.org #1912852] Typo in the findutils manual

Hello Thérèse, first of all, I have to admit that I don't have access to RT. I wrote the sysadmins to clarify. I hope you'll find this reply on the regular Findutils mailing list. On 1/23/23 20:02, Therese Godefroy via RT wrote: Hello Bernhard, Here is the sentence the OP is referring to:

Re: Report 2 UBSan bugs found by an automatic tool

Hi Sam, On 1/6/23 05:37, Sam James wrote: (Replying to https://www.mail-archive.com/bug-findutils@gnu.org/msg06369.html) Given that the CBO is responsible for so many failures both in the test suite and at runtime with UBSAN, would it be possible to go ahead and drop it? (See

Re: Report 2 UBSan bugs found by an automatic tool

(Replying to https://www.mail-archive.com/bug-findutils@gnu.org/msg06369.html) Given that the CBO is responsible for so many failures both in the test suite and at runtime with UBSAN, would it be possible to go ahead and drop it? (See https://savannah.gnu.org/bugs/?63605). Best, sam

Re: find: invalid argument `-inum' to `-inum'

On 1/4/23 20:43, Andreas Schwab wrote: On Jan 04 2023, Bernhard Voelker wrote: + 'find -inum' (without the mandatory argument) now outputs a correct error + diagnostic. Previously it output: "find: invalid argument `-gid' to `-gid'". s/gid/inum/g oops, thanks. There was another typo:

Re: find: invalid argument `-inum' to `-inum'

On Jan 04 2023, Bernhard Voelker wrote: > + 'find -inum' (without the mandatory argument) now outputs a correct error > + diagnostic. Previously it output: "find: invalid argument `-gid' to > `-gid'". s/gid/inum/g -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Wed, Nov 23, 2022 at 07:07:14PM +1100, raf wrote: > On Tue, Nov 22, 2022 at 11:12:00PM +0100, Bernhard Voelker > wrote: > > > Hi raf, > > Hi Berny, > > > thanks for the patch. > > Besides busy day job times here, I was actually waiting for the FSF legal > > to add your entry into the

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Tue, Nov 22, 2022 at 11:12:00PM +0100, Bernhard Voelker wrote: > Hi raf, Hi Berny, > thanks for the patch. > Besides busy day job times here, I was actually waiting for the FSF legal > to add your entry into the 'copyright.list' file on the GNU fencepost server. > It's not yet in place

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

Hi raf, thanks for the patch. Besides busy day job times here, I was actually waiting for the FSF legal to add your entry into the 'copyright.list' file on the GNU fencepost server. It's not yet in place though, so no need to hurry. On 11/18/22 23:48, raf wrote: * find/find.1 - Fix -prune SCM

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Sat, Nov 19, 2022 at 09:48:27AM +1100, raf wrote: > Hi, > > Here's the second attempt. I've made it clear that the only "fix" > is to the example directories and output, not to the command itself. > I've restored the three-exec version of the command in both find.1 and > find.texi, so that

Re: Redundant @deffnx and typo in manual

On 11/16/22 01:55, Antonio Diaz Diaz wrote: Bernhard Voelker wrote: Good to push (with the first 2 in your name)? Of course. Thanks again. Thanks! Pushed. Have a nice day, Berny

Re: Redundant @deffnx and typo in manual

Hi Bernhard, Thank you for the quick fix! Bernhard Voelker wrote: Good to push (with the first 2 in your name)? Of course. Thanks again. Best regards, Antonio.

Re: Redundant @deffnx and typo in manual

Hi Antonio, On 11/15/22 19:55, Antonio Diaz Diaz wrote: > Hello. > > I have found a couple minor bugs in the manuals of findutils 4.9.0. > > Line 389 of find.texi seems to be redundant: > > 388 @deffn Option -files0-from file > 389 @deffnx Option -files0-from file Good catch! See

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

On Wed, Oct 26, 2022 at 03:20:09PM +0200, Bernhard Voelker wrote: > On 10/26/22 11:33, James Youngman wrote: > > The style "test X -o Y" is obsolescent in POSIX (citation: > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html > >

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

On 10/26/22 11:33, James Youngman wrote: The style "test X -o Y" is obsolescent in POSIX (citation: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html ). The POSIX standard recommends the use instead of

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

The style "test X -o Y" is obsolescent in POSIX (citation: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html). The POSIX standard recommends the use instead of test X || test Y. Which is, in effect, what we are doing in the existing code. Supposing efficiency is an

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

On Wed, Oct 26, 2022 at 12:35:34AM +0200, Bernhard Voelker wrote: > First of all: thanks for the patch. > A concrete code change is always a good basis for discussion. :-) > > On 10/23/22 01:54, raf wrote: > > Subject: [PATCH] find: doc: Fix -prune SCM example and really make it > > efficient

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

First of all: thanks for the patch. A concrete code change is always a good basis for discussion. :-) On 10/23/22 01:54, raf wrote: > Subject: [PATCH] find: doc: Fix -prune SCM example and really make it efficient IMO we shouldn't call this a "fix", because there was nothing wrong with the

Re: strange non-existing directories printed with arabic letters

Hi Chris, On 10/15/22 02:53, Christoph Anton Mitterer wrote: Hey. With findutils 4.9.0 the following happened. I have some directory tree with maps from dives sites looking like: $ tree -d … ├── Tauchplätze │   ├── Bearbeitet │   ├── Safari2012 - Südtour Beschriftet x│   └── صور لنشات …

Re: find: print trailing slash for directories

Hi! > Could somebody please advise, if there is some easy way to patch this > myself? DISCLAIMER: - For the reasons mentioned here before I don't consider this a good idea but as long as you promise not to tell anyone that it was me you provided the patch ;-) - I tried it with Debian 11 - It

Re: find: print trailing slash for directories

> On 2022-08-07 12:49, Bernhard Voelker wrote: On 8/6/22 09:20, Fourhundred Thecat wrote:> how difficult would it be to patch find, to print trailing slash for > find \( -type d -printf '%p/\n' \) -or \( -print \) thank you, but this solution is quite tedious to type, especially when already

Re: find: print trailing slash for directories

On 8/6/22 09:20, Fourhundred Thecat wrote:> how difficult would it be to patch find, to print trailing slash for > directories? > > This seems like a very useful feature, without interfering with > compatibility or specifications. > [...] > I am wondering if some simple patch would be possible to

Re: find: print trailing slash for directories

On 2022-08-06 Fourhundred Thecat <400the...@gmx.ch> wrote: > Hello, > how difficult would it be to patch find, to print trailing slash for > directories? [...] No patching required. ametzler@argenau:/tmp/findtest$ find \( -type d -printf '%p/\n' \) -or \( -print \) ./ ./symlink1 ./file1

Re: Passing directories and files

On 5/25/22 20:53, goncholden wrote: > Although if I know the filename, I would not need to call the find command, > and just pass the filename to HEAD, TAIL, or AWK. correct ;-)

  1   2   3   4   5   6   7   8   9   10   >