wgrep expression

[Paul S Person]

Given this input file in directory
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs:

4c4
< %%CreationDate: 11:00:26 December 31, 2018
---
> %%CreationDate: 22:24:22 November 1, 19115

This works (it should be all on one line, of course):
wgrep -c \^>
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs

and this works:
wgrep -c \^<
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs

in both cases producing:

C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs\c_readme.txt
Lines: 1

but what I want is to catch both cases, that is, to show "Lines: 2".

This form

wgrep -c (\^<|\^>)
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs

produces
'\>)' is not recognized as an internal or external command,
operable program or batch file.

and this form

wgrep -c [\^<\^>]
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs

produces no output.

These are all at the command line, for easy testing, but I /really/
want it to work inside a BAT file.

Any ideas on how to get wgrep to count both lines starting with "<"
and those starting with ">"?

Both must be checked because diff only output one line if a new line
is added or an old line is deleted.
--
"I begin to envy Petronius."
"I have envied him long since."

[Frank Beythien]

Am 01.01.19 um 04:17 schrieb Paul S Person:

Hello Paul,
Happy New Year

> Given this input file in directory
> C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\DOCS\diffs:
>
> 4c4
> < %%CreationDate: 11:00:26 December 31, 2018
> ---
>> %%CreationDate: 22:24:22 November 1, 19115
>

[...]

>
> Any ideas on how to get wgrep to count both lines starting with "<"
> and those starting with ">"?

with

grep (GNU grep) 2.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see
<http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
13:39:34[frankb@terrassd2 ~ 0] grep -c ^[\>\<] testfile
2

I get the correct result. At linestart, look for either < or >.
The < > are escaped to prevent in/out redirection.

But, this did not work for me with OS/2 and wgrep.
Perhaps you should try another grep.

CU/2
Frank

[Frank Beythien]

Am 01.01.19 um 13:47 schrieb Frank Beythien:

After some playing around this works:
patternfile:

\^\[
\^\]

wgrep -c @patternfile testfile

CU/2
Frank

[Hans-Bernhard Bröker]

Am 01.01.2019 um 04:17 schrieb Paul S Person:
> but what I want is to catch both cases, that is, to show "Lines: 2".

That fails because wgrep is really more like a traditional 'fgrep' than
'grep'. It doesn't have regular expressions, instead it supports
searching for multiple literal strings (but that can hardly be used
directly from the command line, thanks to the way MS command line shells
work).

The -e option helps, once you've got past an undocumented feature: if
you use -e for one search string, you have to use it for all of them.

This works, sort of:

wgrep -c -e \^^\[ -e \^^\] input.diff

But there's another catch. The \^ pattern for matching begin-of-line
apparently fails work on the first line of a file. For most 'diff'
files that would do, but some may not have the leading line reporting
how diff was invoked, so YMMV.

Maybe you really should consider switching to a more useful
implementation of grep --- even NT's "findstr" might qualify.

[Paul S Person]

On Tue, 1 Jan 2019 14:58:45 +0100, Frank Beythien <fbey...@gmx.de>
wrote:

Yes, it does work -- and so does this in patternfile:

\^<
\^>

when patternfile has an explicit path.

For some reason, wgrep cannot find it simply by name even though it is
in a directory that is on the PATH.

But, what does that matter? The batch file now does what I want it to
do!

Thanks!

[Paul S Person]

On Tue, 1 Jan 2019 18:09:14 +0100, Hans-Bernhard Bröker
<bro...@physik.rwth-aachen.de> wrote:

>Am 01.01.2019 um 04:17 schrieb Paul S Person:
>> but what I want is to catch both cases, that is, to show "Lines: 2".
>
>That fails because wgrep is really more like a traditional 'fgrep' than
>'grep'. It doesn't have regular expressions, instead it supports
>searching for multiple literal strings (but that can hardly be used
>directly from the command line, thanks to the way MS command line shells
>work).

That explains a few things.

>The -e option helps, once you've got past an undocumented feature: if
>you use -e for one search string, you have to use it for all of them.

That explains why, when I tried it, it did not work.

>This works, sort of:
>
> wgrep -c -e \^^\[ -e \^^\] input.diff
>
>But there's another catch. The \^ pattern for matching begin-of-line
>apparently fails work on the first line of a file. For most 'diff'
>files that would do, but some may not have the leading line reporting
>how diff was invoked, so YMMV.

The OW diff (in the repository) starts with a number on the first
line, presumably giving the location in the file (thus "4c4" /might/
mean "line 4 changed into line 4", but then, it might not, who can
say?) so I don't expect that to be a problem. But I will keep it in
mind as I start work on c_readme with WHELP.

>Maybe you really should consider switching to a more useful
>implementation of grep --- even NT's "findstr" might qualify.

Although this is currently for use only on my local computer, it may
well grow into a regression test should our wgml ever reach
completion. So I am using the diff and the wgrep which are found in
the repository, in the hope that they will work on all supported
hosts.

[Mat Nieuwenhoven]

<snip>
Should this not be documented?

Mat Nieuwenhoven

[Frank Beythien]

Am 02.01.19 um 10:26 schrieb Mat Nieuwenhoven:

> On Tue, 01 Jan 2019 09:31:52 -0800, Paul S Person wrote:
>

[...]

>>> wgrep -c @patternfile testfile
>>
>> Yes, it does work -- and so does this in patternfile:
>>
>> \^<
>> \^>
>>
>> when patternfile has an explicit path.
>>
>> For some reason, wgrep cannot find it simply by name even though it is
>> in a directory that is on the PATH.
>
> <snip>
> Should this not be documented?

Why? In my understanding is the PATH environment variable for finding
executables only, not datafiles.

> Mat Nieuwenhoven

CU/2
Frank

[Steven Levine]

On Wed, 2 Jan 2019 13:04:30 UTC, Frank Beythien <fbey...@gmx.de>
wrote:

HI all,

> > <snip>
> > Should this not be documented?

> Why? In my understanding is the PATH environment variable for finding
> executables only, not datafiles.

What might work is if the file in DPATH. The is how OS/2 applications
are supposed to find DATA files. Not every application supports this
and I have not checked if wgrep supports this on any platform.

Because OpenWatcom is cross-platform not every platform specfic
feature is going to be implemented.

Steven



--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------

[Paul S Person]

On Wed, 02 Jan 2019 10:26:37 +0100 (CET), "Mat Nieuwenhoven"

<mni...@dontincludethis.zap.a2000.nl> wrote:

>On Tue, 01 Jan 2019 09:31:52 -0800, Paul S Person wrote:

[snip]

>>when patternfile has an explicit path.
>>
>>For some reason, wgrep cannot find it simply by name even though it is
>>in a directory that is on the PATH.
>
><snip>
>Should this not be documented?

So far as I can tell, the only "documentation" is the display when
"wgrep" is entered at the command line.

But perhaps I looked in the wrong help file, or didn't check the Wiki
thoroughly enough.

[Paul S Person]

On Wed, 2 Jan 2019 14:04:30 +0100, Frank Beythien <fbey...@gmx.de>
wrote:

A good point, and something I had not considered.

Too many years of working with wgml, which searches PATH for it's data
files, no doubt.

[Paul S Person]

On Wed, 2 Jan 2019 16:46:06 +0000 (UTC), "Steven Levine"
<ste...@nomail.earthlink.net> wrote:

>On Wed, 2 Jan 2019 13:04:30 UTC, Frank Beythien <fbey...@gmx.de>
>wrote:
>
>HI all,
>
>> > <snip>
>> > Should this not be documented?
>
>> Why? In my understanding is the PATH environment variable for finding
>> executables only, not datafiles.
>
>What might work is if the file in DPATH. The is how OS/2 applications
>are supposed to find DATA files. Not every application supports this
>and I have not checked if wgrep supports this on any platform.
>
>Because OpenWatcom is cross-platform not every platform specfic
>feature is going to be implemented.

Another good point: an explicit path is more portable.

Well, not the one I am using, since it is specific to my machine, but
something based on the repository should work just fine if a wgml
regression checker is ever needed.

[Hans-Bernhard Bröker]

Am 02.01.2019 um 19:04 schrieb Paul S Person:
> So far as I can tell, the only "documentation" is the display when
> "wgrep" is entered at the command line.

Given that this tool is never exposed to end users, i.e. it exists only
inside the OW source/build tree, the source itself should provide
sufficient documentation --- there's only 37 KiB of it, too. :-)

[Paul S Person]

I actually tried that with diff.

I wanted to see if /it/ could just return the number of changes.

[Mat Nieuwenhoven]

I was referring to the special use of \^< and \^> , and whatever other
special escapes there might be.

Mat Nieuwenhoven

[Hans-Bernhard Bröker]

Am 05.01.2019 um 23:24 schrieb Mat Nieuwenhoven:

> I was referring to the special use of \^< and \^> , and whatever other
> special escapes there might be.

Those are already documented right there in the "wgrep -h" blurb.

[Frank Beythien]

Am 01.01.19 um 18:09 schrieb Hans-Bernhard Bröker:

> The -e option helps, once you've got past an undocumented feature: if
> you use -e for one search string, you have to use it for all of them.
>
> This works, sort of:
>
> wgrep -c -e \^^\[ -e \^^\] input.diff
>
> But there's another catch. The \^ pattern for matching begin-of-line
> apparently fails work on the first line of a file. For most 'diff'
> files that would do, but some may not have the leading line reporting
> how diff was invoked, so YMMV.

I fixed the first line bug, but noticed wgrep does not work at all on
linux for me, the path seperator is hard coded as \.
I looked at the github fork, but there is no change.

> Maybe you really should consider switching to a more useful
> implementation of grep --- even NT's "findstr" might qualify.

+1

Frank

[Paul S Person]

On Mon, 7 Jan 2019 09:58:23 +0100, Frank Beythien <fbey...@gmx.de>
wrote:

So ... the bottom line here is that wgrep, which presumably works on
both (extended?) DOS and OS/2, should be abandoned for findstr, which
is -- what? -- Windows-specific? Or maybe available for DOS?

Fixing wgrep would seem to be a better idea. IIRC, you fixed wgml to
work with Linux paths as well as DOS/OS/2/Windows paths, so it
shouldn't be all /that/ hard.

But perhaps I'm its only user.

[nospa...@efbe.prima.de]

Am 07.01.19 um 18:27 schrieb Paul S Person:

That may well be the case. But I hopefully fixed the linux version.
opendir in linux fails for a single filename, whereas OS/2 succeeds.
And of course the Pathseparator had to be adjusted.

CU
Frank

[Paul S Person]

Thanks.

You also extended OW one step further into full Linux support.
The Linuxen should thank you too!