07/30/86 Star Convention (general information) Many commands accept starnames to identify the entities to be examined or operated upon. Starnames are names containing wildcard characters which can be used to specify sets of entities. These wildcard characters can also be used as a typing aid to reduce the number of typed characters needed to identify a single file. The star convention defines the wildcard characters and matching criteria. Starnames are constrained by the application. Commands which use starnames to match file or directory names permit the final entryname in a pathname to be a starname. In this case, the starname is also an entryname and is subject to the restrictions on entrynames such as the 32 character limit. Such a command would match the starname against the names of all of the entries in the directory (as determined from the pathname) and select those entries of appropriate type which have at least one matching name. A starname matches links if the command utilizing the star convention operates on the link itself. In general, commands do not work upon the targets of links matching a starname. Similarly, a starname matches every entryname of an entry if it operates on name attributes. Otherwise, an entry is generally selected only once even if it has several names matched by the starname. Rules for Constructing Starnames: 1. A starname is a character string. 2. A starname is made up of components. The components are delimited by beginning and end of the name, and by the period (.) character, which is referred to as a dot. 3. Each question mark (?) character appearing in a starname is treated as a special character. 4. Each asterisk (*) character, which is referred to as a star, appearing in a starname is treated as a special character. 5. Each occurance of two consecutive asterisks (**), called a doublestar, appearing in a starname is treated specially. 6. Each component consisting only of a doublestar, called a doublestar component, is treated specially. 7. Three or more consecutive asterisks (***) are invalid. Interpreting Starnames: A starname is compared to a set of names. Those names which meet the following criteria are considered to match the starname. 1. If the starname contains no special characters (stars or question marks), then the rules for PL/I string comparison are used. 2. Trailing ASCII space characters are not significant. 3. Each nonspecial character matches itself literally. The matching constructs must be in one to one correspondence between the starname and the matched name, in the same order. 4. Each question mark matches exactly one character within a component, so it matches any single character except dot. 5. Each star matches any number of characters within a component, so it matches any number (including zero) of any character except dot. 6. Each doublestar matches any number of characters, including zero. 7. Each doublestar component matches any number of entire components, including zero. Note that the dot or dots delimiting the doublestar component match component boundaries, and if zero components are matched, they match the same boundary. The boundary can be a dot or the beginning or end of the matched name. List of starname examples: The following examples illustrate some common forms for starnames. !?????????????? identifies all 15 character one-component entries beginning with ! (called unique names because such names are generated by the unique_chars_ subroutine, described in the MPM Subroutines, and by the unique active function) in the user's working directory. ad? identifies all three-character one-component entries in the user's working directory that begin with ad. ad?* identifies all one-component entries in the user's working directory that begin with ad and have three or more characters. * identifies all one-component entries in the user's working directory. *_data identifies all one-component entries whose first component ends with _data preceded by any number of other characters (including none). *.* identifies all two-component entries in the user's working directory. *.pl1 identifies all two-component entries in the user's working directory that have pl1 as their second component. prog*.pl1 identifies all two-component entries whose first component begins with the letters prog followed by any number of other characters (including none), and whose second component is pl1. sub_dir>my_prog.new.* identifies all three-component entries in the directory sub_dir (which is immediately inferior to the user's working directory) that have my_prog.new as their first and second components. interest_*_data.*.* identifies all three-component entries whose first component begins with interest_, ends with _data, and has any number of characters (including none) in between. *.**.my_seg identifies all entries with two or more components of which the last is my_seg. ** identifies all entries in the user's working directory. **.pl1 identifies all entries with pl1 as the last (and possibly only) component. my_prog.** identifies all entries with my_prog as the first (and possibly only) component. sub_dir>prog?.**.pl1 identifies all entries in the directory sub_dir (which is immediately inferior to the user's working directory) with two or more components, of which the first component has exactly five characters and begins with prog, and the last component is pl1. *foo* identifies any one-component entries in the user's working directory that has the substring "foo" in their name. **foo* identifies any name in the user's working directory which has the substring "foo" in its last component. **foo** identifies any name which contains the substring foo in any component. *.**.**.** identifies all entries in the user's working directory. Any name which contains at most one single star component, at least one doublestar component, and nothing else will match anything. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved