Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001031 [1003.1(2013)/Issue7+TC1] Shell and Utilities Editorial Enhancement Request 2016-03-07 03:21 2020-04-14 15:19
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name DannyNiu/NJF
Organization
User Reference
Section The 'find' utility.
Page Number 2761-2770
Line Number 90443-90860
Interp Status ---
Final Accepted Text Note: 0003559
Summary 0001031: Add -iname (case-insensitive name search) to the find utility.
Description As said in the title, I think we should add the '-iname' option to the 'find' utility. From what I know, both GNU and BSD find have this option, but I'm not sure about the SVR4 family.
Desired Action after line 90502, add paragraph:

<dl>
<dt> -iname pattern
<dd> Same as -name, except that the match shall be case-insensitive based on current locale.
</dl>
Tags issue8
Attached Files

- Relationships
related to 0001553Applied 1003.1(2016/18)/Issue7+TC2 find has two references to -n option that should be about -name 

-  Notes
(0003090)
stephane (reporter)
2016-03-07 12:09

If we're going to add -iname, we might as well add -ipath at the same time.

According to the doc, GNU find deprecates -ipath in favour of (the confusing to me) -iwholename though but it looks like a documentation bug (resolution to https://savannah.gnu.org/bugs/?func=detailitem&item_id=26092 [^] incomplete).

GNU find did use to deprecate -ipath, but it was reverted following POSIX adoption of -path.

-ilname, -iname, -ipath, -iregex were all added at the same time to GNU find in 3.8 in 1993.

(-lname and -ilname would also be useful additions btw (and all other options common to BSD and GNU).
(0003091)
schwarze (reporter)
2016-03-07 12:53

Re: 0003090

I respectfully disagree. Please do not add -ipath. It is not universal in BSD, at least OpenBSD doesn't have it. Solaris 11 doesn't have it either. If even GNU deprecated it, that doesn't speak in its favour.

The -lname, -ilname, and -iregex primaries are not universally supported either and don't seem all that useful. Neither OpenBSD nor Solaris 11 have them.

There is value in keeping the user interface of a utility concise: It makes it easier to learn and use. The find(1) utility already suffers from user interface bloat. Please don't make it worse by adding yet more primaries in an inflationary way.

If it is true that -iname is universally supported, not much harm is done by mentioning it in the standard: It cannot be deleted any more once people started using it. But honestly, if it weren't there and if it were proposed for addition, i would probably object because it doesn't seem useful enough to justify enlarging the user interface.
(0003559)
geoffclare (manager)
2017-02-16 16:33

(2016 edition page and line numbers)

On page 107 before line 2926 (XBD chapter 4 General Concepts), insert a new section:
4.1 Case Insensitive Comparisons

When a standard utility or function that uses regular expressions or pattern matching specifies that matching shall be case insensitive, then if a string would match the regular expression or pattern when doing a case-sensitive match, the same string with any of its characters replaced with their case counterparts, as defined by the toupper and tolower character mappings (see [xref to XBD 7.3.1]), shall also match when doing a case-insensitive match.

This definition of case-insensitive processing is intended to allow matching of multi-character collating elements as well as characters, as each character in the string is matched using both its cases. For example, in a locale with a "Ch" multi-character collating element (see [xref to XBD 7.3.2 bullet 1]), the bracket expression <tt>"[[.Ch.]]"</tt> (see [xref to XBD 9.3.5 bullet 4]) matches the strings <tt>"ch"</tt>, <tt>"Ch"</tt>, <tt>"cH"</tt>, and <tt>"CH"</tt> when matching without regard to case.
and renumber the following sections.

On page 182 line 6030 (XBD 9.2) change:
When a standard utility or function that uses regular expressions specifies that pattern matching shall be performed without regard to the case (uppercase or lowercase) of either data or patterns, then when each character in the string is matched against the pattern, not only the character, but also its case counterpart (if any), shall be matched. This definition of case-insensitive processing is intended to allow matching of multi-character collating elements as well as characters, as each character in the string is matched using both its cases. For example, in a locale where "Ch" is a multi-character collating element and where a matching list expression matches such elements, the RE "<tt>[[.Ch.]]</tt>" when matched against the string "<tt>char</tt>" is in reality matched against "<tt>ch</tt>", "<tt>Ch</tt>", "<tt>cH</tt>", and "<tt>CH</tt>".
to:
Some standard utilities and functions support case-insensitive regular expression matching. When this type of matching is in effect, the matching process shall be modified as described in [xref to XBD 4.1].

On page 2797 after line 91930 (XCU section find operands) add a new item:
-iname pattern
The -iname primary shall be equivalent to -name, except that the match shall be case insensitive. See [xref to XBD 4.1].

On page 2800 line 92074 (XCU section find (LC_COLLATE)), change:
used in the pattern matching notation for the -n option
to:
used in the pattern matching notation for the -name, -iname and -path primaries

On page 2800 line 92079 (XCU section find (LC_CTYPE)), change:
within the pattern matching notation used for the -n option
to:
within the pattern matching notation used for the -name, -iname and -path primaries

On page 2843 line 93633 (XCU section grep), change:
Perform pattern matching in searches without regard to case;
to:
Perform pattern matching in a case-insensitive manner;

On page 3005 line 99882 (XCU more), change:
Perform pattern matching in searches without regard to case;
to:
Perform pattern matching in a case-insensitive manner;

Cross-volume changes to XBD ...

On page 254 after line 8520 (XBD section <fnmatch.h>), add the following new items:
FNM_CASEFOLD string and pattern are compared in a case-insensitive manner. See [xref to XBD 4.1].

FNM_IGNORECASE Equivalent to FNM_CASEFOLD.

On page 323 line 10972 (XBD section <regex.h>), change:
Ignore case in match
to:
Perform pattern matching in a case-insensitive manner

Cross-volume changes to XSH ...
    
On page 890 after line 30073 (XSH section fnmatch()), add a new paragraph:
If FNM_CASEFOLD or FNM_IGNORECASE is set, string and pattern shall be compared in a case-insensitive manner. See [xref to XBD 4.1].

On page 1802 line 58345 (XSH section regcomp()), change:
Ignore case in match (see [xref to XBD Chapter 9])
to:
Perform matching in a case-insensitive manner (see [xref to XBD 9.2])

Cross-volume changes to XRAT ...

On page 3511 line 118810 (XRAT A.4), insert a new section:
A.4.1 Case Insensitive Comparisons

Case-insensitive matching is defined in this standard in terms of a simple algorithm whereby, for each character in the string to be matched, if the character is uppercase then the lowercase equivalent (if any) is also checked for a match, and if the character is lowercase then the uppercase equivalent (if any) is also checked for a match. It is described this way to make the expected behavior easier to understand; however, implementations may internally use more sophisticated algorithms to improve efficiency, provided that the result is the same as the simple algorithm would produce.

and renumber the following A.4.x sections.

- Issue History
Date Modified Username Field Change
2016-03-07 03:21 dannyniu New Issue
2016-03-07 03:21 dannyniu Name => DannyNiu/NJF
2016-03-07 03:21 dannyniu Section => The 'find' utility.
2016-03-07 03:21 dannyniu Page Number => 2761-2770
2016-03-07 03:21 dannyniu Line Number => 90443-90860
2016-03-07 12:09 stephane Note Added: 0003090
2016-03-07 12:53 schwarze Note Added: 0003091
2017-02-16 16:33 geoffclare Note Added: 0003559
2017-02-16 16:34 geoffclare Interp Status => ---
2017-02-16 16:34 geoffclare Final Accepted Text => Note: 0003559
2017-02-16 16:34 geoffclare Status New => Resolved
2017-02-16 16:34 geoffclare Resolution Open => Accepted As Marked
2017-02-16 16:34 geoffclare Tag Attached: issue8
2020-04-14 15:19 geoffclare Status Resolved => Applied
2022-01-17 10:00 geoffclare Relationship added related to 0001553


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker