File: XTree:\Forum archive |Bottom_of_page

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive

FileSpec enhancement PROPOSAL

Posted By: Walter Rassbach <>
Date: Friday, 18 September 1998, at 9:40 p.m.

I would like to propose a "small" set of extensions/enhancements to FileSpec, which are somewhat similar to the datespec extensions, plus one (or maybe two) configurable modification(s) to correct some problems. This write-up is fairly long because I have tried to give numerous examples and to cover ALL of the exceptions/ambiguities/etc. (as one HAS TO in a real/good design), BUT, the actual extensions are fairly simple (and the set really is not that large).

1) I have always wanted to have a way to specify/select files according to the file ATTRIBUTES (i.e., RASH), and would propose that the '\' character be used (like ' ') as a prefix character to indicate selection by attributes. For example, a FileSpec (without quotes) like "\-A" would select only files with the "A"rchive flag off, "\+R" would select "R"ead-only files, and "\+R+S+H" would select only files that had all three of those flags on.

. .The proposed treatment of "tags" as just another "attribute" fits in quite nicely here and would significantly increase the usefulness of this extension.

. .NOTE: In specifying attribute strings, ZTree currently forces one to always enter either a + or a - before each letter. I would like to propose, as an independent extension, allowing the + to be omitted, making (e.g.) R-SH mean the same thing as +R-S+H. Alternatively, we could specify that the last sign applied (and start with an implicit +), and R-SH would then be the same as +R-S-H. This should be a trivial extension for Kim to implement. Does anyone see any reason to object or have a preference as to form? (SEE the posting at URL: http://www.serve.com/vico/www04/pages04/382.html )

. .BUG: In alt-T, with a string of +R+S+H, ZTree currently tags files with ANY ONE of the three attribute flags ON while XTree tags only files with ALL three ON. I strongly believe XTree's semantics to be correct and have reported it as a bug (see the posting at the URL above).

2) Similarly, but probably less critical, would be to select files according to size. I would propose that >, and == be used for size selection along exactly the lines that , and = are used for dates. The size specification should allow K and M abbreviations (we can argue about whether K means 1000 or 1024, or maybe have 'k' mean one and 'K' the other although that is maybe confusing or even dangerous).

. .For opened ARCHIVEs (alt-F5), selection by (and sort by) compression ratio and compressed size might be useful, but I am not sure that Kim even captures that information. If so, we could use (say) /, =/ for ratio and |, and =| for compressed size.

3) Again, I am not sure Kim actually captures the information, but there are really three dates associated with a file, the date-last-written, the date-last-accessed, and the date-created. For the most part everyone uses just the date-last-written and ignores the others. I would suggest that ?, and =? be used to specify filtering against date-last-accessed and \, and =\ for filtering against date-created (I would also like to see sort options for these if Kim does capture the information...).

4) I would REALLY(!!) like to see the ctrl-"I"nvert/"F"ileSpec function implemented/enabled.

5) Now that spaces and commas are allowed in file names their use as separators in a FileSpec string is ambiguous and there is a somewhat non-standard (not really confusing, but...) set of rules for using double-quotes to resolve the ambiguity (see the threads on the "Bugs in ZTree" board starting at the linked URL below and the thread linked to by that posting at http://www.serve.com/vico/www04/pages04/293.html). At a minimum, I would like to see the quoting rules relaxed a bit to match the Windows usage, which handles things like:

. . . dir "adaptec "*.*
. . . dir adaptec" "*.*
. . . dir adaptec" *".*

. .just fine, while ZTree requires/allows only "adaptec *.*". What I would really like to see is a relaxation of the quoting rules AND a configuration option which allows one to specify what the separator is, with the following options:

. . . . .(A) space and comma (and '|'),
. . . . .(B) comma (and '|'),
. . . . .(C) vertical-bar (i.e., '|' [only]), and
. . . . .(any other possibilities?).

. . . . .NOTE: As part of option (B), and possibly as an extension of current usage with (A), we might want to specify that a double-comma (no spaces) is to be treated as an "open-form" comma in a WildCardSpec rather than as a separator... This is a fairly standard practice and is significantly easier to type/use/see than having to put quotes around any wildcard string containing a comma.

. . . . .NOTE: With options (B) and (C), leading and trailing spaces should be allowed (and stripped-off/ignored) for purposes of readability. In addition, since spaces are NOT allowed in the middle of a DateSpec (or an AttributeSpec, SizeSpec, etc.), a space can be used to resolve certain rare ambiguities in the use of '/' and colon...

. .A vertical-bar CANNOT appear in a FileSpec and is thus unambiguous (and mnumonic for all us programmers...). Moreover, a vertical bar is a very "visible" character (unlike space and comma), and I would VERY much like to see it added as a separator in any case... The default probably has to be (A) due to current usage, but my guess is that (B) is going to be the best choice since comma SELDOM (unlike space) occurs in a filename and may be used provide a useful extension to the semantics/flexibility, either in conjunction with item (9) below or independently (see the posting linked to below).

6) Along similar lines, the use of '-' and '=' as prefix characters to indicate inversion and a specific date can cause problems. I assume that Kim handles a FileSpec of (say) abc-x*.* correctly, i.e., '-' (or '=') is handled as inversion (date-equal) ONLY if it is the leading character, and file names which start with either of them are rare. Moreover, such cases can be handled using ""s, but it is a pain... Using these characters as prefixes also causes problems with the "AND-semantics" extension proposed in item (9) below, and I would propose that:

. . .a) The '/' (ForwardSlash) character be implemented (without regard to whether '-' is enabled or disabled in (c)) as an alternative to, or replacement for, '-'. However, '/' is specifically defined to be applicable to ANY "kind" of FileSpec items, including WildCardSpecs, DateSpecs, AttributeSpecs, SizeSpec, etc., i.e., it performs a simple logical-"NOT" modification of ("operation" against) the FileSpec item which follows.

. . . . .The possible use of '/' in a DateSpec could conflict with its use as an "and-not" conjunction in the "local"-AND semantics proposed in item (9). This conflict should be resolved by either requiring the use of a space before the slash for a conjunctive-not usage when a (slashed) DateSpec is preceeds it (SEE the examples in (9)) -- however, if one places any DateSpec portion last in a conjunctive sequence, the conflict never arises anyway... Moreover, this conflict can also be solved merely by using '-' rather than '/' in that particular DateSpec (since you get to use one or the other but not both)...

. . .b) The ':' (colon) character be implemented as (again, regardless of (c)) a replacement/equivalent/alternative to '='. There is a MINOR conflict between:

. . . . . . . The current usage of ':' for "labels" (and/or as part of a "TimeSpec") and

. . . . . . . The usage proposed here (or its extended usage usage as part of the "labelled FileSpec call-out" proposed in item (7)) when used as part of a conjunctive "local"-AND in the extension proposed in (9) below).

. . . . . The resolution of this conflict is discussed in item (7.c) below.

. . .c) Provide a configuration option which disables the prefix usage of '-' and '=' for invert/date-equal, and possibly forces the use of a double-colon or colon-space for labelling (this feels natural to me anyway, it's that C++ thing... ;-).

7) With the introduction of "labelled" FileSpecs, an interesting possibility arises: Allow a labelled FileSpec to be "called out" as a sub-FileSpec in other FileSpecs (just like a subroutine). At a minimum this extension would save some typing, but it would be especially powerful in conjunction with the extensions proposed in items (8) and (9) below and the override "trick" I propose here. What I propose is essentially an extension of the date-equal usage of colon proposed in item (6.b) above, as follows:

. . .a) Restrict the characters used in a label to just letters, numbers, and some special "glyph" characters like ` ~ _ - + ! # $ % & ( ) [ ] { } and (probably) SPACE if it is disabled as a separator via the configuration option proposed in item (5.c). In particular, the special characters @ | \ / * ? " . , ; : (the last four are period, comma, semi-colon, and colon) should NOT be allowed in a "label".

. . .b) A labelled FileSpec definition is "called out", in another FileSpec, by a FileSpec item consisting of a colon followed by the "label". This might seem to allow a potential conflict (given the usage of colon proposed in item (6.b) above) with a FileSpec item like :TODAY (i.e., date-equal to today), but, in fact, provides a VERY nice "override" feature for TODAY, and for the others like it proposed in item (8) below, as follows: When a colon item is encountered, ZTree FIRST searches the labelled FileSpecs (probably case insensitive) and uses the (most recent) one found, if any. If it does not find the "label" it THEN searches its internally defined "labels" (like TODAY) for a match and uses that one. As a very nice consequence (e.g.), if one has a number of FileSpecs using :TODAY and needs to modify them temporarily (e.g., it just rolled past midnight), one does NOT need to go edit those FileSpecs and have to later go change them back (or copy or retype them), you merely define a new FileSpec labelled TODAY, and delete it when you are done! This mechanism also gives Kim a nice, extensible way of implementing "special" FileSpecs like TODAY, since they are merely defined internally as just another FileSpec...

. . .c) A file is considered to be selected by, and/or to match/"satisfy", a "called-out" FileSpec, as a FileSpec ITEM, when it would independently satisfy the referenced FileSpec, AS-A-WHOLE. In other words, the referenced FileSpec is treated as a "blackbox" -- The actual effect is very much like surrounding the referenced FileSpec with parentheses.

. . .d) There is a small potential ambiguity between the use of a colon to set off the label in a labelled FileSpec and (SPECIFICALLY) its usage for either date-equal or call-out in a "local"-AND (conjunctive) item (see item (9) below) which is the first FileSpec item in a FileSpec. This amibiguity would RARELY arise in practice (in fact, one has to go out of one's way to construct a case, but...), and can be resolved in a number of ways. The ambiguous case is a FileSpec (w/o the ""s) like: "recent:TODAY,YESTERDAY,LAST_WEEK" which could be interpreted as either a FileSpec labelled "recent" selecting files named "TODAY", etc. or a FileSpec selecting a file named "recent" (only) if it is dated with today's date along with files named "YESTERDAY", etc. The proposed resolution is as follows:

. . . . .i) The FileSpec string above must, for upward compatibilty, be treated as a labelled FileSpec (unless the configuration option in (6.c) is used/active -- see item (iv) below...).

. . . . .ii) The second interpretation can be obtained in a number of different ways, for example:

. . . . . . . . . . "YESTERDAY,recent:TODAY,LAST_WEEK"

. . . . . . . . . . ",recent:TODAY,YESTERDAY,LAST_WEEK" (start with comma -- the first item is "empty" and matches nothing)

. . . . . . . . . . "recent.:TODAY,YESTERDAY,LAST_WEEK" (the period, specifying an empty extension, means that "recent" can't be a label -- Note that the file selected is the SAME...)

. . . . . . . . . . "xxx: recent:TODAY,YESTERDAY,LAST_WEEK" (supply a false label)

. . . . .iii) More delicately (and possibly iffy), interpret

. . . . . . . . . . "recent: TODAY,YESTERDAY,LAST_WEEK" as a labelled FileSpec, and

. . . . . . . . . . "recent :TODAY,YESTERDAY,LAST_WEEK" using the second, "local"-AND interpretation

. . . . .iv) As part of the configuration item proposed in (6.c) require that a double-colon be used for labelling in ambiguaous cases, yeilding:

. . . . . . . . . . "recent:TODAY,YESTERDAY,LAST_WEEK" uses the second, "local"-AND interpretation,

. . . . . . . . . . "recent::TODAY,YESTERDAY,LAST_WEEK" is the labelled version, and

. . . . . . . . . . "recent: :TODAY,YESTERDAY,LAST_WEEK" (note the SPACE) or
. . . . . . . . . . "recent:::TODAY,YESTERDAY,LAST_WEEK" is a labelled FileSpec starting with a DateSpec of :TODAY... (Note: It has to work this way to avoid further ambiguities...)

. . . .Given the clear gain in functionality provided by this extension, the estoteric rarity of the ambiguous case (in particular, most "locally"-ANDed [actual] FileSpecs will contain a '*', a '?', a '.' [period], or some other non-label character BEFORE the colon is encountered), along with the fact that the resolutions above clearly solve it, I do not think that this ambiguity should stand in the way of implementing this feature (NOTE: Before we start, I think that a colon is the only real choice for a prefix character here, in part because of the mnumonic tie between its use for labelling and its use for call-out [AND overrides of things like TODAY], and in part because I have already proposed other useful usages for all of the other special characters which can easily be used for prefix characters).

. .An example usage might be something like the following set of FileSpecs:

. . . . . . . headers: *.H | *.INC | MAKEFILE
. . . . . . . C code: *.C | :headers
. . . . . . . C++ code: *.CPP | :headers

8) The DateSpec TODAY feature that was recently put into ZTree is very nice because it lets one specify an adaptible DateSpec. I would propose that the following kinds of things be added (all w/o the ""s):

. .Relative date forms:
. . . ":." or " ..." or ">-2" Later than 2 days ago (i.e., yesterday or today)
. . . ">.-2M" or ">-2M" In the last two months (Month, Week, Year, others?)
. . . ":*" A possible, more "visible" alternative to ":." for :TODAY, but using * might lead to problems/ambiguities with other (e.g., wildcard) uses of * (e.g., what is ":*-98" -- Is it "98 days ago" or is it [see below] "any month in 1998"??).

. .Period forms (NOTE: The "FileSpec ' ' includes..." configuration option should NOT affect/change the meaning of any "period" form, e.g., ' *-1@12-00" Since noon yesterday
. . . ":3/3/98@3:*AM" Between 3:00 and 3:59:59 on 3/1/98
. . . ">@15" or ">@3P" Since 3:00PM (today) -- 24-hour clock unless A, AM, P, or PM specified.
. . . ">@-48:30" In the last 4.5 hours

. .Julian Dates (ASIDE: I would like to see Julian dates added as one of the date format configuration options, and would also like to see it accepted anywhere dates are entered, indicated by separation of the day-number from the year by a semi-colon...):
. . . ">52;98" Julian date (same as 2/21/98)

. .These are merely examples, and we can probably add these or any of a large number of other formats when or as needed. I particularly would like to see the "wildcard"/period forms and the "relative" forms, and being able to refine a DateSpec down to a specific time would be nice.

. .As one further extension for DateSpecs, I would like to propose that '>=' and ' :') be implemented/provided as prefixes with the obvious interpretations. This would eliminate the need for the "FileSpec ' ' include..." configuration option although it probably must be kept for upward compatibility.

9) Unfortunately, this posting is getting long and the full description of the grouping and handling of FileSpecs with multiple items must be fairly detailed (and pendantic) to make sure that everything is covered (it is much like the specification of computer language syntax -- one must make sure everything is fully defined and covered, because if one leaves a hole or a cliff a computer will walk right into/over it...). However, briefly, the scheme is as follows:

. .Three "levels" of grouping are applied to the individual specification items.

. .The first level consists of items which are juxtaposed/concatenated and/or separated by spaces and is called a "local"-AND group. If space is disabled as a separator (see item (5.c)), leading and trailing spaces (i.e., not embedded in a WildCard string) are ignored -- they are allowed for readability and to allow some minor lexical ambiguities to be clarified/solved. There can be only ONE unprefixed WildCard string (if none, defaults to *.*), and a file matches the "local"-AND group if it matches the WildCard string and ALL of the other (prefixed) items in the grouping.

. .If spaces are configured as separators the only difference is that there may be multiple "unprefixed" WildCard strings, and a file matches if it matches any one of those strings and (again) ALL of the other prefixed items.

. .The second level, called the "grouped"-AND level, consists of "local"-AND groupings separated by commas. The precise/complete definition of when a file is considered to match/satisfy the "grouped"-AND grouping "as-a-whole" is a bit "trickier", but, IN PRACTICE (i.e., the common/frequent cases) it is actually quite obvious and intuitive. For the most part, with simple items, it works just like the "local"-AND grouping, i.e., if the commas were replaced by spaces (and space separation turned ON) the effect would be the same. The main exception (with simple items) is the way in which DateSpecs combine, and a FileSpec like " 3/1/98" works out just fine (ZTree currently CAN NOT DO this one -- it matches no files).

. .The real power of using two levels here only really comes into play when the "local"-AND groupings. Elaboration of this is left to the attached sub-posting (see below).

. .The third level consists of "grouped"-AND groupings separated by '|' and comprises the whole FileSpec. A file matches the FileSpec if it matches any one of the "grouped"-AND groupings, i.e., pure OR-semantics are used. Again, this allows FileSpecs which do things that ZTree currently cannot do.

The full detailed description of how this is done will be attached in a sub-posting... -- Walter

>Glitches in FileSpec handling

Messages in This Thread

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive is maintained by Mathias Winkler with WebBBS 3.21.

 
---<>---
 
Xtree and XtreeGold are registered trademarks of Symantec Inc.
Other brands and products are trademarks of their respective holders.


FILE COMMANDS:  Directory_view Previous_file   Next_file cuRrent   /Help |Top_of_page