Hi, While implementing completion for an alternative to find I found some bugs in the standard completion file for find (Completion/Unix/_find) that I was using as a reference when doing my implementation. These were things that were incorrect on my Arch Linux system using GNU find. They may or may not be correct for other find implementations. 1. Missing handling of -newerXY: From the man page: --- -newerXY reference Succeeds if timestamp X of the file being considered is newer than timestamp Y of the file reference. The letters X and Y can be any of the following letters: a The access time of the file reference B The birth time of the file reference c The inode status change time of reference m The modification time of the file reference t reference is interpreted directly as a time Some combinations are invalid; for example, it is invalid for X to be t. Some combinations are not implemented on all systems; for example B is not supported on all systems. If an invalid or unsupported combination of XY is specified, a fatal error results. Time specifications are interpreted as for the argument to the -d option of GNU date. If you try to use the birth time of a reference file, and the birth time cannot be determined, a fatal error message results. If you specify a test which refers to the birth time of files being examined, this test will fail for any files where the birth time is unknown. --- I suggest the following addition to find implementations that support this option: '*-newer'{a,B,c,m}{a,B,c,m}'[succeeds if timestamp 1 is newer than timestamp 2 of FILE]:reference file:_files' '*-newer'{a,B,c,m}t'[succeeds if timestamp 1 is newer than timestamp]:timestamp:->times' However! I'm not sure if ->times is correct. The code for that state is a bit cryptic to me, and I don't know if -newerXt supports quite the same things as other time parameters. It is also possible that you want to rewrite this to make the help text more specific to each entry. 2. Incorrect handling of -exec, -execdir, -ok etc: These completion entries are on the following form: '*-exec:program: _command_names -e:*\;::program arguments: _normal' However it is not only ; that will terminate arguments to the program in question. + also works. The difference is that ; will only pass a single argument per invocation while + passes as many as will fit on the command line. Thus a more correct line would be: '*-exec:program: _command_names -e:*(\;|+)::program arguments: _normal' Similar changes must also be made for -execdir, -ok and -okdir Best regards, Arvid Norlander
On Wed, Apr 6, 2022 at 8:55 AM Vorpal <zsh@vorpal.se> wrote: > > 1. Missing handling of -newerXY: Ubuntu 20.0x LTS has this option, as does MacOS does, at least as far back as Catalina. Neither one lists this variation in --help output. On MacOS, these can also be "inverted" as -Bnewer, -mnewer, etc., whereas on Ubuntu only the historic -anewer and -cnewer are "invertible". > 2. Incorrect handling of -exec, -execdir, -ok etc: > > However it is not only ; that will terminate arguments to the program in > question. + also works. Yep.
On 2022-04-06 23:11, Bart Schaefer wrote: > On Wed, Apr 6, 2022 at 8:55 AM Vorpal <zsh@vorpal.se> wrote: >> >> 1. Missing handling of -newerXY: > > Ubuntu 20.0x LTS has this option, as does MacOS does, at least as far > back as Catalina. Neither one lists this variation in --help output. > On MacOS, these can also be "inverted" as -Bnewer, -mnewer, etc., > whereas on Ubuntu only the historic -anewer and -cnewer are > "invertible". Not quite the same thing. -newerXY allows you to compare for example the creation time to the access time (not sure *why* that would be useful, but it is possible) or any other such permutation. the -Bnewer/-mnewer etc doesn't seem to support such mixing. As for versions, according to the man page of GNU find (4.9.0) on Arch Linux, in the HISTORY section, -newerXY has been around since version 4.3.3, and "also occurs in BSD". >> 2. Incorrect handling of -exec, -execdir, -ok etc: >> >> However it is not only ; that will terminate arguments to the program in >> question. + also works. > > Yep. 3. Another issue: Missing completion When reading the GNU find man page HISTORY section it seems that a new flag was introduced in 4.9.0, which should probably be supported in the completion: -files0-from file Read the starting points from file instead of getting them on the command line. In contrast to the known limitations of passing starting points via arguments on the command line, namely the limitation of the amount of file names, and the inherent ambiguity of file names clashing with option names, using this option allows to safely pass an arbitrary number of starting points to find. [... this section is quite long in the man page, I suggest looking at for example https://man.archlinux.org/man/find.1 if you don't have it locally and want to read the full thing ...] Something like: '-files0-from[search NUL separated paths from FILE]:file:_path' should do the trick. The feature before that and -newerXY (-D, added in 4.3.1) seems to be supported by zsh completion. I haven't checked if all older features are also supported.
On Wed, Apr 6, 2022, at 5:11 PM, Bart Schaefer wrote: > On Wed, Apr 6, 2022 at 8:55 AM Vorpal <zsh@vorpal.se> wrote: >> >> 1. Missing handling of -newerXY: > > Ubuntu 20.0x LTS has this option, as does MacOS does, at least as far > back as Catalina. At least back to Leopard! > Neither one lists this variation in --help output. lol % find --help find: illegal option -- - find: illegal option -- h find: illegal option -- e find: illegal option -- l find: illegal option -- p usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression] > On MacOS, these can also be "inverted" as -Bnewer, -mnewer, etc., This appears to be the case on Leopard as well. -- vq