On Wed, 24 Jul 2019 08:30:46 -0400, Sri h Kolusu wrote: >> >• Basic Regular expressions (BRE) >> >• Extended Regular expressions (ERE) >> > There seems to be no keyword differentiating these. Does that leave >> any ambiguity. > >Paul, > >The Extended Regular expressions differs in the meta characters and also >support the hex character input. > Is this clearly documented?
>> Using the word "default" suggests that the programmer can choose the >> case-sensitive alternative. How might one do this? > >By "default" DFSORT when processing regular expressions forces the search >to be case-insensitive. Currently we do not support the option of >overriding the case-sensitivity.The traditional DFSORT Include/OMIT >processing is indeed Case sensitive. > So, the choice DFSORT makes for regular expressions is contrary to what programmers have come to expect for other DFSORT options. "default" is contrary to common usage. DFSORT seems to be using it to mean "only". But "[c]urrently" gives hope. It would take only a couple more keywords, such as ISPF Edit kindly provides, to control the setting of REG_ICASE in the call to regcomp(). >> The "NULL-terminated string" discussion seems to be an internal which >> does not concern and might only confuse the programmer. However, >> if the programmer is so rash as to introduce a NULL in a regex in SYSIN >> using a hex editor, might there be unexpected results? > >NO. If the programmer is smart enough to add a null terminated string >using hex mode at the end, DFSORT does not append the null terminating >string. Null terminated string discussion is added , so that the > But what happens if the programmer is foolish enough to use \00 in the *interior* of a regex? Should this be documented? >> Regular expressions are probably described at length in other z/OS >> publication(s). It might be better to provide a cross reference than >> to repeat the syntax description here. > >If the linked publication enhanced the Regular Expression support or >dropped the support , it would affect DFSORT. So we chose to add the >description to our publications where we have control of the contents. As >is I have seen people preferring the information to be available in one >place. > But a Google search of z/OS publications finds regular expressions described not "in one place", but in numerous places, even in both the UNIX System Services Command reference and the UNIX System Services Users Guide. Hoarding of documentation to maintain "control of the contents" is counterproductive. >> DFSORT Application Programming Guide >> IBM [part number obscure] > >Not sure what you meant by obscure but I was able to copy and paste the >documentation number SC23-6878-40. I tried opening the PDF in Firefox as >well as the saved copy on PC. > Both Kees Vernooij and I found it an irritator to attempt to copy the doc number from the cover of the PDF where it appears as an image rather than text. Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
