Actions
Bug #12328
closedFNMPERIOD makes little sense for find -path
Start date:
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
<ryzokuken> the `find` binary on SmartOS is acting up.
<ryzokuken> `find . -path "*"` won't return anything
This is because of:
1020 /* 1021 * XPG4 find should not treat a leading '.' in a 1022 * filename specially for pattern matching. 1023 * /usr/bin/find will not pattern match a leading 1024 * '.' in a filename, unless '.' is explicitly 1025 * specified. 1026 */ 1027 #ifndef XPG4 1028 fnmflags |= FNM_PERIOD; 1029 #endif
This legacy behaviour is unfortunate for -name / -iname, and was unfortunately carried over
to -path / -ipath. This just doesn't seem meaningful for matching against an entire path and should be ripped out.
Updated by John Levon over 3 years ago
Obviously, GNU find doesn't have this behavior, but I also confirmed that BSD find doesn't either.
Updated by John Levon over 3 years ago
Aside from spot testing and a test boot, I ran the utiltest suite succesfully including the new find tests.
Updated by Electric Monk over 3 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit f3a525d949e26238340eb8c1f6fdcfff91fc7e65
commit f3a525d949e26238340eb8c1f6fdcfff91fc7e65 Author: John Levon <john.levon@joyent.com> Date: 2020-02-25T17:48:41.000Z 12328 FNMPERIOD makes little sense for find -path Reviewed by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi <rm@fingolfin.org>
Actions