SEARCH argument - opinion asked

[Jan van den Ende]

Hi all.

At the Dutch edition of the Technical Update Days today (GREAT event!! They move to London Thursday & Friday, then Austra somewhere - didn't get where exactly - Monday & Tuesday, and then Frankfurt a.M. Thurstday & Friday IIRC. Pick one, but, Europeans, BE THERE!!) and one of the sessions was by Guy Peleg on DCL enhancements.
Of course he ended asking for customer input, and one of the suggestions was for SEARCH
to incluse end-of-line in the argument.
One quick, non-trivial example: Find the lines NOT ending on "."
That would be done by
$ pipe SEARCH | search SYS$PIPE "."/match=nor

Another example:
Find all line beginning with "abc"

$ SEARCH "abc"

After some discussion the temporary conclusion was to go after user reactions eighther in support of the idea, or not interested.

So,

what does our ITRC crowd think?

I will stand as the second vote in support(obviously the first vote goes to Frits Storms as the suggester).


Cheers.


Havo one on me.


jpe

[Hein van den Heuvel]

YES 'Anchors' are a very useful search tool.
NO... can not be both begin and end.
How can there even be a discusion on this?!
There is only one way to solve this: Regular expressions!
The EOL anchor is "$"
The BOL anchor is "^"
That's just the way it is... in Unix land.
If you need to search for either character then either disable, or do not request, regexprs. Or 'escape' them with a "\".
Why "\"? Because that is just the way it is... in Unix land.

;-) ;-) ;-)

Hein.

[Uwe Zessin]

Of course that is useful!

But in that case I rather like to see full support for regular expressions. Well, I guess that is what 'grep' is for ;-)

[Ian Miller.]

I vote for regular expressions. There is a old DEC tool FIND/REPLACE which does regular expressions already so they could use the code from there.

http://h71000.www7.hp.com/freeware/freeware60/find015/

[John Gillings]

I tend to agree with Hein and Uwe. It's not necessary to add features to SEARCH one by one, when the end result will be an incompatible duplication of regular expressions. Keep SEARCH simple and self explanatory. If you want to do more complex pattern matching, use GREP - maybe make if an official DCL command?

[Bojan Nemec]

If part or whole regexp (or something similar) will be implemented in SEARCH there must be a qualifier (say /REGEXP or something like this) which will instruct to use the parameter as a regular expression. To retain backward compatibility.

So my vote is for but with caution to backward compatibility.

Bojan

[John Gillings]

re: Bojan's comment:

>If part or whole regexp (or something similar) will be implemented in SEARCH there must be a qualifier (say /REGEXP or something like this)

As of V8.2, SEARCH has a new qualifier: /WILDCARD_MATCHING allowing * (match any string) and % (match any single character) to be used as wildcards in the search string. There's also /SKIP=n to skip the first n matches.

[Ian Miller.]

John,
the new support for VMS wildcards in SEARCH V8.2 looks good and I see can see uses for it. However I still think regular expression support (selected with a new qualifier) would also be useful.

[Willem Grooters]

I like the idea. It can be very handy.

I agree with John, to keep SEARCH as simple as possible. But this one is quite trivial.

Willem

[faris_3]

$ search /highlight=(underline,bold,blink) ?

:-)

[Willem Grooters]

I posted another one (limit search to part of line) in advocacy - as has been suggested in another thread). Will show up next monday (if I read all well).

Willem

[Antoniov.]

I embrace the Bojan idea.
Keep SEARCH simple, new qualifier for regoular expression.

Antonio Vigliotti

[Garry Fruth]

How about SEARCH/WILD and SEARCH/WILD=REGEXP?

[John Gillings]

re: Willem "I posted another one (limit search to part of line)"

See $ SEARCH/KEY=(pos:n,size:m)

(since V6.2)

My point about regular expressions is that GREP (and variants) already exist, with well known semantics and behaviour. They already work on OpenVMS. If SEARCH requires a qualifier to enable regular expressions then you're comparing:

$ grep parameters...

with:

$ SEARCH/GREP parameters...

So what's gained except a more complex SEARCH command? How will it interact with other qualifiers? Will all the standard Unix switches be implemented? How?

We have the luxury of being able to sequester any useful Unix commands. So, if you want GREP, then use GREP, rather than a reimplementation (which will inevitably have minor, but annoying differences). There's no need to re-invent that particular wheel.

[Jan van den Ende]

Thanks all

This whole stream will be presented to Guy Peleg, and I think we can trust him to take all remarks into account, and come up with something that will be the best possible synthesis of all these ideas.
I know he is in Europe till end of next week, so any brilliant additions can be posted until then.

Cheers.

Have one on me.

Jan

[Ian Miller.]

another point is that grep has to be added. SEARCH is already there.

[Cass Witkowski]

Although I like the Pipe command in OpenVMS I don't want the command set to deteriorate to Grep, Awk and Yacc. (Please no flames)

One thing I really like about DCL is that is was architected, and consistent. I hope that any new command or addon to Search is done to the same high standard.

[Uwe Zessin]

No flame intended, but the PIPE feature is just a framework to combine program input / output and has nothing to do with the interface of the individual program.

I don't think anybody asked that established programs morph into their Unix counterparts, but some features like regular expressions are really useful.