File: XTree:\Forum archive |Bottom_of_page

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

XTree Forum archive

FileSpec enhancement PROPOSAL/UPDATE - Grouping & Interpretation

Posted By: Walter Rassbach <>
Date: Sunday, 27 September 1998, at 1:17 a.m.

In Response To: FileSpec enhancement PROPOSAL (Walter Rassbach)

This sub-posting attempts to present, in detail (hopefully full and complete), the scheme I would like to propose for grouping and interpreting FileSpec strings. The presentation is, unfortunately, somewhat "complex" and pendantic since I am trying to present it as an implementable design rather than just as a general description -- This means that the presentation carries a lot of the "flavor" of a computer language syntax/semantics, since, after all, a FileSpec is really just a program in a limited language which ZTree "compiles". As far as is possible, I have tried to clarify the presentation with appropriate examples...

FORMATTING NOTES: To avoid problems with less-than and greater-than being interpreted by the posting board as parts of HTML tags, those symbols have been replaced throughout by (respectively) '{' and '}'. Example FileSpec strings or fragments are enclosed in []'s as delimiters to aid in their recognition and to set them off accurately. In addition, leading periods are often used for formatting (the board eats multiple spaces).

GOALS: The scheme proposed has three main goals, as follows:

. .1) Preserve ZTree's current interpretation of FileSpec strings. A few variances in areas where ZTree currently will interpret a FileSpec string as matching no files, e.g., [{1/1/97,}1/1/98] may be acceptable.
. .2) Increase the flexibility, range, and power of the FileSpec mechanism. In particular, it should be possible to specify things like the disjoint date ranges.
. .3) Keep the FileSpec syntax/semantics (reasonably) intuitive and easy to remember.

As a result of thinking about these goals, the scheme presented below differs somewhat from the original scheme I had started out with when I wrote the parent posting... The scheme presented below is both more flexible and stays closer to ZTree's current interpretation of various FileSpec strings. The suggested set of prefix markers has been changed as well to provide slightly better mnumonic value and to avoid a few more minor lexical ambiguities.

A quick review:
. .a) Provide one or two configuration options to control whether '-' and '=' continue to be used as "prefixes" or are completely replaced by '/' and colon, and, whether the new FileSpec scheme is used or not, and, if so, whether space is still used as a separator or not (along with maybe allowing double comma to be used to represent a filename comma, etc.).
. .b) Add FileSpec items for attributes and size, and possibly created and accessed dates and compression ratio and compressed size in archives. The addition of specification items for attributes is significantly enhanced by the inclusion of "tags" (and possibly some other flags) as "attributes".
. .c) Extend the DateSpec syntax to include relative dates, time, Julian dates, time-periods (YEAR/MONTH/wildcards/etc.), with the appropriate ones also being available for NewDate operations.
. .d) Allow "labelled" FileSpecs to be "called out" in other FileSpecs.
. .e) The following "prefix markers" and special character combinations (ligatures) are currently proposed (NOTE: These are slightly different than the ones proposed before and a few have been added -- all are w/o ""s):

. . . Representation escapes for WildCard strings:
. . . . . ",," An "open form" comma (no quotes needed) in a wildcard string (since comma is a separator).
. . . . . "\," Alternative form (backslash-comma)
. . . . . "\." An embedded period, never for extension (e.g., [Fx.E*] vs. [Fx\.E*] match different files)
. . . . . ".." Possible alternative (but iffy...)
. . . . . "\_" Possibly could use for an embedded SPACE (if space separation is ON)
. . . . . "\:", "\\", "..." For "anchored"/DirSpec WildCard strings (SEE BELOW)

. . . Special values and Range operators:
. . . . . "*" "Universal value", primarily used for domain control (SEE BELOW)
. . . . . "~" Range indicator for dates, sizes, etc. (e.g., [1/1/97~1/1/98])
. . . . . "^" Exclusionary range (e.g., [1/1/97^1/1/98] means any date outside the range)
. . . . . "~", ";", "^" [Attributes} Exclusion, or, xor (e.g., R~RSH -- SEE BELOW)

. . . Prefix Markers (and operators), also serve to separate items:
. . . . . "/" [As a prefix for a WildCard string:] WildCard Exclusion.
. . . . . "\" AttributeSpec
. . . . . ":" Labelled FileSpec "call-out" (colon also overloaded for labeling and for:)
. . . . . "{", "}", ":", "{:", "}:" DateSpec for date-last-updated (usual date)
. . . . . "{/", "}/", ":/", "{:/", "}:/" DateSpec for date created (SEE NOTES BELOW)
. . . . . "{\", "}\", ":\", "{:\", "}:\" DateSpec for date last accessed
. . . . . "{|", "}|", ":|", "{:|", "}:|" Later of date-last-updated and date-created (date-written)
. . . . . ":{", ":}". ":=", ":{=", ":}=" SizeSpec (could exchange with the next set)
. . . . . "\{", "\}", "\=", "\{=", "\}=" Compressed size
. . . . . "{{". "}}", "{}" Compression ratio ("{}" equals case for ranges)

. . . .NOTES: 1) Remember that '{' and '}' represent the less-than and greater-than characters.
. . . . . . . 2) The '/', '\', or '|' in the alternative DateSpecs really are part of the DATE and could be extended to other date usages (e.g., NewDate).
. . . . . . . 3) The "{:" and "}:" (rather than "{=" and "}=") are used in the DateSpec forms (but NOT the size forms) for consistency with ":", to allow '=' to be used either as a "wildcard" in dates or to preserve those ligatures for other, future uses.

. . . Separators and operators used to group items in a FileSpec ("high precedence" first):
. . . . . "/" [When in front of a prefix:] "Tight" NOT or Inversion monic operator.
. . . . . "/|" "Tight" AND-separator
. . . . . "\|" "Tight" OR-separator
. . . . . "\!" "Loose" monic NOT (semi-prefix)
. . . . . "\'" "Loose" monic AS-IS (semi-prefix), mainly used to replace SPACE when space-separation is OFF
. . . . . TAB [If not otherwise used!] Could be used as a "local domain grouping" separator to replace:
. . . . . SPACE [If space-separation ON] "local domain grouping", along with
. . . . . Juxtapositioned prefixed items: "local domain grouping"
. . . . . "|" First level OR-separator.
. . . . . "." "Global domain grouping" separator
. . . . . "||" Outer level OR-separator
. . . .NOTE: Even if space-separation is OFF, spaces can be used as whitespace between items for readability, resolution of minor lexical ambiguities, etc. Leading and trailing spaces are treated as whitespace and stripped.

WildCardSpec EXTENSION: There have been a number of postings recently which suggested or requested a DirSpec feature, primarily to allow exclusion of certain directories. Rather than implementing a whole new function, I would propose that we merely extend the capabilities of the FileSpec WildCard strings to include directories. The ligatures "\\" and "\:" are used in "open" WildCard strings to represent backslash and colon (within quotes these escapes are not needed), with "..." used to represent zero or more levels of directories. Some examples (all w/o []s):

. . . . . [/cache\\] Excludes all files and sub-directories below any directory named "cache"
. . . . . [/cache\\*.*] or [/cache\\*] Excludes all files (but NOT sub-directories) below "cache"
. . . . . [/cache\\*\\] Excludes all sub-directories (but NOT files) below any directory named "cache"
. . . . . [/SDK\\...\\alpha\\] Exclude files used for Alpha processors in the SDK.
. . . . . [/E\:\\*\\*\\] Exclude all third (and above) level directories on E:
. . . . . [/\:\\XYZ\\] Excludes first level directories named XYZ (on ANY drive).
. . . . . [XYZ\\..\\ABC\\*] This one is TRICKY and might not work -- It should select files in any ABC directory WHICH HAS a "brother" directory named XYZ (but not in ABC directories without such a "brother"!).

ATTRIBUTE OPERATORS: For attribute specification/selection strings (both here and in commands like alt-Tag), it is proposed that the glyphs (in high to low precedence order) "^", ";" (semicolon), and "~" be used to represent xor, or, and exclusion (and-not) operators. [ASIDE: These do not apply to the attribute modification strings used in the ctrl-Attributes command -- however, there it is also suggested that '!' be used to specify inversion of an attribute in the same way that '-'/'+' indicate clearing or setting it.]. Some examples:

. . . . . R-SH Still specifies read-only and hidden but not system.
. . . . . R~SH Read only except not (R)SH files.
. . . . . R;SH Read only files plus system and hidden files
. . . . . R^SH Read only files plus system and hidden files, but not RSH files

LEXICAL Issues:

If '-' and '=' are enabled as prefixes (it is STRONGLY suggested that they be disabled), they are recognized as prefixes ONLY when they clearly START an item (e.g., after a comma or other separator) and are not recognized as separators in their own right. If they are enabled, a WildCard string which starts with either must be quoted.

SPACEs are generally treated as just "whitespace" and leading and trailing spaces are always stripped from all items (including WildCard strings even if space-separation is turned off -- WildCard strings with significant leading or trailing spaces must be quoted [this is normal practice anyway]). Spaces are never allowed within an AttributeSpec or SizeSPEC item (they can occur just after the prefix), and may not be allowed within a DateSpec item (this is discussed below), and a space following such an item which is not immediately followed by a prefix or separator is treated as a "whitespace separator" at the "local grouping" level (and introduces a WildCard string, e.g., [*.INI \R *.TXT] works even if space-separation is OFF...). Spaces are also NEVER allowed in the various ligatures (two or three special-character prefixes/separators/etc.), and can thus be used to resolve some minor lexical ambiguities (primarily regarding the various uses of colon and slash).

If space-separation is ON, spaces not associated with another separator (e.g., the space in [*.INI *.TXT]) are classified as "whitespace separators" at the "local grouping" level, with the item following treated as a WildCard string (by the conditions it cannot be anything else since there is no prefix which follows...). In this case, WildCard strings containing embedded spaces must be quoted and FileSpec labels used for call-outs cannot contain spaces (OR, we may allow quoting here as well). DateSpecs with a TimeSpec may or may not be allowed to contain an embedded space between the date and time -- see the discussion below.

If space-separation is turned OFF, spaces can be freely embedded in both WildCard strings and FileSpec labels (leading and trailing spaces still require quotes) -- Given the prevalence of spaces in modern day file names, it is expected that space-separation will be turned OFF by most users. Spaces still cannot be embedded in either Attribute or Size specifiers and may or may not be allowed in DateSpecs. Although one might expect that this would mean that one could not have a FileSpec with multiple WildCard strings and no explicit separators, the FileSpec [*.INI :1/1/98 *.TXT] clearly cannot be interpreted in any other way...

Since TAB is probably not a very useful as an editing command/operation when editing or entering a FileSpec, it seems reasonable to allow it to be used as a "whitespace separator" in lieu of SPACE when space-separation is turned OFF. It is suggested that it be represented in the display string by one of the glyphs 0x1E, 0xFE, or maybe one of 0xB0-0xB2 or 0xDC-0xDF (an upward pointing carret or one of the "box" type drawing characters).

If DateSpecs are extended to allow times to be specified, it has been proposed that the '@' sign be used to separate the date part from the time part and/or introduce the time part. With this usage, a DateSpec can always be written without embedded spaces and we may require that this is always the case in a FileSpec string. However, historical usage has generally allowed a space to be used to separate the date and time parts and we may want to consider if there is a way to allow this usage without introducing a number, or at least, too many, of lexical ambiguities -- This may depend on whether space-separation is ON or OFF. However, spaces are NOT otherwise allowed in a DateSpec, they can appear ONLY between the date part and the time part.

There is a small lexical ambiguity regarding the use of '/' (slash) both in a DateSpec and as a prefix/monic "operator"/glyph. This ambiguity is resolved by specifying that a slash is considered to be part of a DateSpec item whenever possible, and is only interpreted as a prefix/monic when it cannot be part of a DateSpec. The fact that a slash which is part of a DateSpec cannot be preceded by a space (the only possible spaces in a DateSpec are between the date and time) can be used to resolve cases where one wants to use a prefix/monic slash following a DateSpec by simply preceeding it with a space.

A similar set of potential ambiguities occur with colon which may be used to indicate labelling, as a prefix for a DateSpec or CallOut, and as part of a time-string in a DateSpec. For the ambiguity between usage in as a prefix for CallOut/Date-equals and usage in a time-string, the method used for slash (above) is sufficient, merely preceed a CallOut/Date-equals colon by a space. For FileSpec labelling, a sequence of characters which may be a "label" (i.e., letters, digits, [maybe] space, and a few special characters) followed by a colon is always taken to be a label. If the user's intention was to specify a WildCard string followed by a CallOut or Date-equals, he must either append a period ('.') to the WildCard string (this does NOT affect the meaning), provide a "false" label, rearrange the FileSpec to avoid the problem, or possibly insert a leading comma or vertical bar at the very front of the FileSpec (which should, in most cases, have no effect on the meaning).

FileSpec SYNTAX and SEMANTICS:

The syntax and grouping of the individual FileSpec items (the special purpose range and attribute "operators" are really considered to be part of an individual item here) is fairly straightforward, following the standard pattern of grouping items together by "attaching" prefixes and monics (only '/') to the associated items and then by grouping them together using the "highest precedence" separator(s) (or operator(s)) first. The prefixes also serve as separators (along with space if space-separation is ON) at the "local grouping" level (SEE BELOW).

The hard part is defining the meaning or semantics of a FileSpec due to the fact that the various FileSpec items filter or select against competely different and independent "aspects" of the actual files, i.e., its name, date(s), attributes, size, etc. In effect, a FileSpec is building a Venn diagram in a multi-dimensional space using only (based on) "slices" obtained by restrictions on only one of the perpendicular/orthogonal "axes" (i.e., name/date/etc.) at a time. There is, unfortunately, a seemingly inherent conflict between the multi-dimensional "search space" (defined by the various characteristics of the actual files) and the essentially one-dimensional (linear) nature of the FileSpec string. Although it does not completely resolve this conflict, the scheme presented below attempts to make reasonable use of the multi-dimensional characteristics while still remaining fairly intuitive, easy-to-use, and powerful.

Each FileSpec item and grouping (expression) is considered to belong to one of the following "domains" (listed in order from the widest or most general to the narrowest), which are described using the basic kind of items which are included, prima face, in that "domain":

. . . . WildCard Inclusion -- Normal WildCard strings (with the directory extensions above).
. . . . WildCard Exclusion -- WildCard strings prefixed by '/' (or '-' if not disabled and "obvious").
. . . . Attribute -- An attribute specification or restriction item.
. . . . Inverted Attribute -- An attribute item preceeded by a monic inversion (i.e., slash)
. . . . Size/Date -- A size, compressed size, compression ratio, or any one of the various DateSpec forms.

. . . . Groupings (at any level) are classified as being in the widest "domain" of any of the (explicit) items contained therein.
. . . . FileSpec CallOut items are also classified according to the widest domain of the included items.

This breakdown and ordering seems to result in the most natural, intuitive, and useful results/semantics. Although it might increase the flexibility to differentiate the domains (especially Size/Date) further and/or provide an Inverted Size/Date domain, the slight increase in flexibility does not seem to be worth the increase in complexity. Moreover, the availability of ranges and the "tight" operator/separators should cover most cases of interest.

An item or grouping classified in one domain can be "promoted" to a wider domain (just like the promotion of an integer to a float in languages like C). A "promotion" can be either implicit (as needed) or explicitly forced through the appropriate inclusion of a "universal value" item drawn from the desired domain (the uses of "universal values" and explicit promotion are clarified below).

The "combinatorial" separators/operators (i.e., "/|". "\|", "|", and "||") all operate simply by, if necessary, implicitly promoting one operand to match the other if it is "wider", and then performing the specified "logical operation". However, at the "local" and "global" grouping levels, the sub-groupings/items (operands) are combined "multi-dimensionally" according to the domains, with items/sub-groupings from narrower domains acting as, essentially, modifiers or restrictions on files satisfying the specifications for the wider domains -- The specific way in which this is done is described in detail below.

The "universal value" items (i.e., *, /*, \*, /\*, :*, etc.) are provided to allow some explicit control over the domain in which a grouping is classified. Inclusion of a "universal value" item in a grouping will NEVER affect the files selected-by/matching/satisfying that grouping, without regard to whether it uses AND, OR, or "domain grouping" semantics. However, inclusion of a "universal value" item CAN/DOES affect which domain the grouping falls into, and thus the way in which the grouping as-a-whole is handled at either the "local" or the "global" grouping levels. For example, a FileSpec like "*.INI,:1/1/98" selects just *.INI files with a date of 1/1/98 (the two specifiers are in different domains, with the DateSpec modifying/restricting the WildCardSpec), while "*.INI,*:1/1/98" selects ALL *.INI file and ALL files with a date of 1/1/98 because the DateSpec was promoted to the WildCard domain and the FileSpec is then treated very much like a FileSpec like "*.INI,*.TXT" -- This is fairly characteristic of the ways in which explicit promotions are used and should also help clarify cases where the promotions are implicit.

As a special case, akin to a "universal value" usage, a '\' FOLLOWED BY A SPACE and then another prefix (the space means that the '\' is not part of a ligature...) will "promote" the prefixed item (or inversion) that follows into the Attribute domain. This applies even to WildCard Exclusion items (prefixed by a '/') where the effect is really a "demotion". Because there are no ligatures containing the character sequence "\/", the implementation can relax the requirement for a space between '\' and '/' in this particular (and common) case.

Although, for the most part, a given user will generally use either the "local" or "global" domain-grouping levels (depending on whether they favor commas or spaces -- the majority will probably use commas) for most FileSpecs, the availability of two distinct "levels" yeilds a SIGNIFICANT increase in the power and flexibility of the FileSpec mechanism. The multiple levels of OR-semantics operators/separators allow the specification of FileSpecs which simply cannot be expressed in the current ZTree, while the "tight"-AND operator/separator permits one to deal effectively with various combinations of sizes and dates. Although there are no explict parentheses provided, the same effect can be obtained through the use of a FileSpec CallOut.

The syntax/grouping and meaning/semantics of a FileSpec are, from the tightest/most-binding/highest-precedence level, built up as follows:

A) The FileSpec string is broken down into its various lexical parts. Prefixes are considered to be part of the actual specification items themselves rather than as full separators/operators. However, prefixes do also serve as LEXICAL separators with any implicit separator effect (e.g., in something like [*.INI:TODAY]) treated as, effectively, a "whitespace separator" (even though there is no actual whitespace) at the "local grouping" level.

B) Items preceeded by a monic '/' (slash) are marked as "inverted" -- However, note that a WildCard string immediately preceeded by a slash is a WildCard Exclusion item and NOT an "inverted" WildCard Inclusion item, and a string like [//*.INI] is an inverted WildCard Exclusion. In addition, inversion of an item classified as an Attribute item changes its domain to "Inverted Attribute". A slash preceeding one of the "loose" monic operators turns it into a "tight-inverted" form, so the string [/\'*.INI] is an inverted WildCard Inclusion as is [/\!*.INI] (the latter is an INVERTED inclusion of all files which are NOT *.INI files -- the effect is much like specifying just [*.INI] but there are some differences in the way it is handled...). For the most part "inversion" is much like specifying a "NOT" but it will, in essence, "change" the domain of a WildCard or Attribute specification.

C) Prefixed items or inversions (but not WildCard strings) preceeded by a standalone, "universal value"-like, '\' FOLLOWED BY A SPACE (or TAB) (ensuring that it is not part of some ligature... -- see above for one possible exception) are promoted to the Attribute domain (or, in the case of a WildCard Exclusion, "demoted"). A monic '/' preceeding such a monic-'\' would then have the effect of inverting the Attribute domain item into an Inverted Attribute domain item...

D) A group of items and/or inversions separated by "tight"-AND operators ("/|") forms a "tight"-AND-grouping, and a file matches or satifies the grouping as-a-whole if and only-if it satisfies every item and inversion in the grouping.

E) A group of items, inversions, and/or "tight"-AND-groupings separated by "tight"-OR operators forms a "tight"-OR-grouping, and a file matches or satifies the grouping as-a-whole if and only-if it satisfies one or more of the individual elements in the "tight"-OR-grouping.

F) A "loose" monic NOT ("\!") or AS-IS ("\'") operator (not preceeded by a slash -- see above) can be applied to an item, inversion, or "tight"-grouping (or a "unit" formed by another such monic), applies to the LARGEST such grouping that follows, and turns it into a "unit". This means that these operators can be used to achieve some kinds of parenthetical effects, e.g., there is no other (usefully meaningful) way to interpret a string like [*.INI /| \' A*.* \| B*.*] other than as (with parentheses) [*.INI AND (A*.* OR B*.*)] -- Although this example is trivial, there are other cases where this unitizing effect is quite useful. The AS-IS operator is provided both for this unitizing effect and because it can, effectively, be used to separate multiple WildCard Inclusion items when space-separation is turned OFF, e.g., the FileSpec string [*.INI\'*.TXT] is equivalent to the space-separated string [*.INI *.TXT]. Note that a loose AS-IS monic is equivalent to a pair of loose monic NOT operators, i.e., "\'" is identical in effect to "\!\!"...

G) A sequence or group of items, inversions, "tight"-groupings, or "units" (collectively "elements") separated by either explicit (e.g., TAB or SPACE) or implicit (due to the separating effect of prefixes) "whitespace" form a "local"-level "domain grouping". Actual "whitespace" characters are NOT required in front of items introduced with a prefix since the prefix acts implicitly as "whitespace", e.g., [*.INI\R:1/?/98] and [*.INI \R :1/?/98] are identical in effect since the '\' and ':' prefixes also, in essence, implicitly provide a "whitespace" separation. Other than for lexical purposes, the ordering of the elements in a "local"-grouping does not affect the meaning/semantics of the grouping as-a-whole, although the ordering may be lexically critical, e.g., with space-separation turned OFF, the string [*.INI \R *.TXT] cannot be re-ordered to [*.INI *.TXT \R] since the former clearly has two distinct WildCard Inclusion items while the latter only has ONE (namely, "*.INI *.TXT").

. .The various "elements" in the "local"-grouping are separated into sub-groups according to "domain" and a file is considered to satisfy or match the grouping as-a-whole if and only-if it:

. . . 1) Matches or satisfies ANY ONE of the WildCard Inclusion elements (OR-semantics).
. . . 2) Matches or satisfies ALL of the WildCard Exclusion elements (AND-semantics).
. . . 3) Satisfies ANY ONE of the Attribute elements.
. . . 4) Satisfies ALL of the Inverted Attribute elements.
. . . 5) Satisfies ALL of the Size/Date elements.

. .The reasons for selecting this particular mixture of OR-semantics and AND-semantics is discussed below.

. .Note that a SINGLE "element", surrounded by low-precedence separators (i.e., '|'. comma, and '||') is still considered to be a "local"-level domain grouping which matches or is satisfied if and only-if the element itself is satisfied or matches.

H) A sequence or group of "local"-level domain groupings separated by '|' separators/operators is called a "first-level-OR grouping" and a file satisfies or matches the grouping, as-a-whole, if and only-if it matches or satisfies any one (or more) of the "local"-level domain groupings.

I) A sequence or group of "local"-level-domain and/or first-level-OR groupings separated by commas is called a "global"-level domain grouping. As for "local"-level groupings, the individual "local"-level and first-level-OR are separated into domains and a file satisfies the "global" domain grouping using the same semantics as those used for "local" domain groupins -- The only difference is the "level" of the grouped elements...

J) Finally, a FileSpec is made up of "global"-level-domain, first-level-OR, and "local"-level-domain groupings separated by second-level-OR )"||") operators/separators. A file matches or statisfies the FileSpec as-a-whole if and only-if it satisfies any one of the included elements.

Although the scheme presented above may seem complex, a fair portion of the apparent complexity is really the result of the necessarily pendantic nature of the description, which must provide for and cover all cases and usages. Both the parsing of a FileSpec string and the code to check whether a given candidate file matches or satisfies the FileSpec are actually fairly straightforward. The most complex part is really the semantics for the two domain-grouping levels, which were selected for the following reasons:

1) The semantics/handling for the WildCard Inclusion, WildCard Exclusion, and Date(/Size) domains mirrors the current handling of those kinds of specification items in ZTree. Moreover, the use of AND-semantics for WildCard Exclusions really correlates with the handling of WildCard Inclusions since "(exclude 'a') AND (exclude 'b')" is logically exquivalent to "exclude ('a' OR 'b')".

2) For Attribute specifications, OR-semantics are used (more useful) because individual attribute strings already inherently use AND-semanatics, e.g., [\RS] already specifies that a file will satisfy the string only if it has BOTH the read-only and system attributes active, which is exactly the same as [\R AND \S] -- In other words, using AND-semantics here is fairly pointless since the same effect can be obtained, in simple cases, merely by concatenating the two attribute strings.

3) Using AND-semantics for Inverted Attributes echoes the handling differences between WildCard Inclusions and Exclusions, based on the principle that inversion/NOT switches AND and OR.

4) The alternation of AND and OR semantics up the domain heirarchy, combined with the availability of explict domain promotion/control increases the flexibility and power of the FileSpec mechanism...

HISTORY Extension:

Given the increased FileSpec capabilities and, in particular, the availability of the CallOut mechanism, it is probably desirable (and is thus proposed) to increase the size of the FileSpec history buffer. In addition, it may also be desirable to provide a side buffer, under explicit user control, of labelled FileSpec items to avoid "pollution" of the main FileSpec history buffer with a large number of "locked down" entries.

A set of examples are provided in a further sub-posting (due to posting size).

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