This explanation makes perfect sense. ISPF was written to allow utter maximum flexibility in command coding. Of course the t appears to stand for 'text'. I can't try this out now, but I wonder if using " instead of ' for the entire string would give the desired result.
FIND "isn't on" That's how I would code it on principle anyway. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Bill Godfrey > Sent: Friday, January 8, 2016 10:59 AM > To: [email protected] > Subject: [Bulk] Re: Regex (was: Sort for not there?) > > On Fri, 8 Jan 2016 10:25:05 -0600, Paul Gilmartin wrote: > > >On Thu, 7 Jan 2016 18:07:11 -0700, Alan Young wrote: > >> > >>The spaces also need the escape backslash like this > >> > >>FIND r'foo\ \'\ bar\ \"\ wombat' > >> > >This is bizarre. I've coded a fair amount of regular expressions and > >I've never needed to escape a blank in a regular expression. In fact, > >Single UNIX says: > > > > The interpretation of an ordinary character preceded by a > > <backslash> ( '\\' ) is undefined, > > > >The z/OS XL C/C++ Runtime Library Reference in the description of > >regcmp(), which is described as "withdrawn and are not supported as > >part of Single UNIX Specification ..." states: > > > > Note: An non-special character preceded by \ is a one-character > > RE which matches the non-special character. > > > >The description of the newer regcomp() makes no such statement. > > > >Is backslash escaping elaborated by ISPF EDIT or by regcomp()? > > > >I have an RCF in requesting a clarification of ISPF's syntax of > >delimited strings. My case in point is that with the subject: > > > > My aunt's pen isn't on the table. > > > >The command: > > > > FIND 'aunt's pen' > > > >matches successfully, but the very similar: > > > > FIND 'isn't on' > > > >fails with a syntax error. I can find no explanation of the difference > >in current ISPF manuals. I suspect a historical explanation. > > In this case, the parser considers this: > 'isn't > the equivalent of this: > t'isn' > and stops there, and anything after that is expected to be something like > NEXT, > PREV, FIRST, LAST, or ALL. > > If there was some character other than t, c, p, r, or x after the quote, it > would > work. > > If there was some character other than a space after the 't it would work. > > Not defending it, just explaining what's going on. > > Bill ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
