HP3000-L Archives

September 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Fri, 5 Sep 1997 11:26:42 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
Hi,

Re: FSYNTAX.

Since you're returning a string, *and* since your examples
use "pos" to determine if a particular feature was used, it would
seem better to drop "MPE_WILD_LOCK" and replace it with:
   "MPE, WILD LOCK"

I.e., the string returned consists of one or more comma-separated
tokens from the set:
>   "ERROR_nnn"       where nnn is a CIERROR number
>   "MPE"             filename is a MPE name
>   "WILD"            filename has any wildcard characters
>   "LOCK"            filename contains a lockword
>   "FEQ"             filename is a backreference to a file equation
>   "$FILE"           filename is a system defined file like $null
>   "REMOTE"          filename has an :environment ID
>   "POSIX"           filename is a POSIX name

In that manner, future combinations that aren't currently
possible don't need new result strings.  E.g., POSIX & FEQ
or POSIX & REMOTE.

Also, in the above, I dropped the word "simple".  The user could say
that a file title is "simple" if a POS (",") of the FSYNTAX result
returns false, or if FSYNTAX (...) = "MPE" or = "POSIX".

BTW, I'd have called this FPARSE, to be similar (in spirit) to the
FPARSE intrinsic.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

ATOM RSS1 RSS2