|
|
Post by Stefan on Feb 15, 2022 11:24:34 GMT -5
Hi George,
(v2.5.22014)
I apologise in advance, I know this resides in a most hateful bit of code...
FIND command fails to locate an unquoted <search-string> that starts with a '[' character when a <start-column> operand is specified without an <end-column> operand.
I was working with a CFGMAINT -EXPORT file Bounds set to 1 MAX
Issued the command FIND [ODEFAULT] 1 Unexpected result was "Bottom of data reached"
FIND "[ODEFAULT]" 1 ===> works (string in quotes)
FIND [ODEFAULT] ===> works (without the <start column> operand) FIND ODEFAULT] 2 ===> works (string doesn't start with '[')
I moved the [ODEFAULT] string one column to the right (i.e. the '[' is now in column 2 rather than col 1
FIND [ODEFAULT] 2 ===> doesn't work (string starts with '[')
FIND [ODEFAULT] 2 99 ===> works (<end-column> also specified> BUT leading '[' char is not highlighted)
|
|
|
|
Post by Stefan on Feb 16, 2022 4:06:57 GMT -5
Hi Robert,
Good to hear from you following your spell in hospital. I hope you are resonably comfortable.
On the matter in hand, however, I respectfully disagree.
The <search string> is a string of characters - any characters.
Quotes are required only if the search argument includes breaks (blanks) and to allow the command parser to differentiate the search argument from other arguments that may start with or contain non-alphanum chars.
As such, the square bracket isn't even a special character.
I appreciate that '[' has special meaning in some contexts, but such context is invariably signalled by means of a 'wrapper', e.g. R'regular expression', P'picture string', F'format string', etc.
If I'm mistaken, please describe an occasion where a leading '[' is used without such a 'wrapper' for a particular purpose.
|
|
|
|
Post by George on Feb 16, 2022 10:13:49 GMT -5
Stefan: A real oldie here. If we go back many versions, before macros existed, we had a command called FILTER, which provided a way to use external programs to manipulate the data. FILTER was removed a few versions after Macros came along.
The syntax for FILTER required using [ and ]. Obviously the parse code still contains that old support. I'll have a look at yanking it out.
Just FYI, here's an exerpt from the V7 Help file for FILTER
George
Syntax
FILTER command [ [ parameters ] ] [ line-control-range ]
[ X | NX ]
[ MX | DX ]
[ DEBUG ]
Operands
command
A command as would be entered on a Windows command line. If the command contains blanks or special characters,
it must be quoted. The command must be located in the current PATH or in the directory where SPFLite
is located, or else it must be fully qualified, to be found.
parameters
Zero or more parameters used by the command, just as would be entered on a Windows command line.
The notation [ [ parameters ] ] above means that (a) parameters are optional as shown by the outer
[ ] brackets, and (b) if included on the FILTER command, parameters must be enclosed in actual brackets,
as shown by the inner [ ] brackets. The brackets you use on the FILTER command are not passed
along to the Windows command line; they are just part of the FILTER command's syntax.
You only need to type the [ ] brackets in the command if you actually have command arguments.
So, to run a command like
MY_UTILITY ARG1 ARG2
you would issue the FILTER command as:
FILTER MY_UTILITY [ARG1 ARG2]
The FILTER command assigns special meaning to arguments specified literally as %1, %2 and/or %3.
See the description below for more information.
|
|
|
|
Post by George on Feb 16, 2022 14:36:12 GMT -5
Robert: Doesn't matter, [ and ] are still being used in the SUBMIT command syntax.
And I really didn't want to touch parse anyway. I guess quoting the operand is sometimes the best answer. I know I search for lots of odd strings without quotes, I really didn't want to restrict special characters either.
George
|
|
|
|
Post by Stefan on Feb 18, 2022 12:12:11 GMT -5
LOL... I think v7 may have been before my time with SPFLite. (At least that's my excuse for my unfamiliarity with the FILTER command  ) And without a baby z/OS system at home(  ), I've never needed to SUBMIT anything, so the concept of ' [' being used also escaped my attention.
It only felt like a bug because the parser accepts it, but then doesn't find a blatently obvious string in the data.
In all other cases where a quoted string is needed, you'll likely get an error from a confused parser.
Given that there's an established reason for '[' being a 'special' char, don't risk code changes, especially in a 'thorny' area. This can easily be addressed by a minor documentation change.
Most folks naturally assume that quotes are required:
- if the search string includes a 'break' character (e.g a blank)
- if the search string includes a (reserved) word or keyword (e.g. ALL or LEFT or PREV, etc)
It seems for SPFLIte, a third reason is
- if the search string begins with a '[' character.
I tried to find a good place in the doc for such a change, but I failed to find any mention of circumstances when the <search-string> needs to quoted. The " FIND - Find a Character String" chapter is already quite busy.
The "Finding and Changing Data" chapter has a section called "Specifying the Search String". It includes sub-headings on "Simple strings" and "Quoted Strings". Maybe that would be a good place to add some words as above.
By the way,
The section on "Restrictions on the use of LAST and PREV with Regular Expressions" appears in chapter "Finding and Changing Data" and chapter "FIND - Find a Character String". Probably doesn't deserve to appear twice.
|
|
)
), I've never needed to SUBMIT anything, so the concept of '[' being used also escaped my attention.