Discussion:
wgrep expression
(too old to reply)
Paul S Person
2019-01-01 03:17:41 UTC
Permalink
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
2019-01-01 12:47:18 UTC
Permalink
Am 01.01.19 um 04:17 schrieb Paul S Person:

Hello Paul,
Happy New Year
Post by Paul S Person
Given this input file in directory
4c4
< %%CreationDate: 11:00:26 December 31, 2018
---
%%CreationDate: 22:24:22 November 1, 19115
[...]
Post by Paul S Person
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[***@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
2019-01-01 13:58:45 UTC
Permalink
Post by Frank Beythien
Hello Paul,
Happy New Year
Post by Paul S Person
Given this input file in directory
4c4
< %%CreationDate: 11:00:26 December 31, 2018
---
%%CreationDate: 22:24:22 November 1, 19115
[...]
Post by Paul S Person
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>.
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.
After some playing around this works:
patternfile:

\^\[
\^\]

wgrep -c @patternfile testfile

CU/2
Frank
Paul S Person
2019-01-01 17:31:52 UTC
Permalink
Post by Frank Beythien
Hello Paul,
Happy New Year
Post by Paul S Person
Given this input file in directory
4c4
< %%CreationDate: 11:00:26 December 31, 2018
---
%%CreationDate: 22:24:22 November 1, 19115
[...]
Post by Paul S Person
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>.
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.
\^\[
\^\]
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!
--
"I begin to envy Petronius."
"I have envied him long since."
Mat Nieuwenhoven
2019-01-02 09:26:37 UTC
Permalink
Post by Paul S Person
Post by Frank Beythien
Hello Paul,
Happy New Year
Post by Paul S Person
Given this input file in directory
4c4
< %%CreationDate: 11:00:26 December 31, 2018
---
%%CreationDate: 22:24:22 November 1, 19115
[...]
Post by Paul S Person
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>.
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.
\^\[
\^\]
\^<
\^>
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?

Mat Nieuwenhoven
Frank Beythien
2019-01-02 13:04:30 UTC
Permalink
[...]
Post by Mat Nieuwenhoven
Post by Paul S Person
\^<
\^>
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.
Post by Mat Nieuwenhoven
Mat Nieuwenhoven
CU/2
Frank
Steven Levine
2019-01-02 16:46:06 UTC
Permalink
On Wed, 2 Jan 2019 13:04:30 UTC, Frank Beythien <***@gmx.de>
wrote:

HI all,
Post by Frank Beythien
Post by Mat Nieuwenhoven
<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 <***@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------
Paul S Person
2019-01-02 18:07:59 UTC
Permalink
On Wed, 2 Jan 2019 16:46:06 +0000 (UTC), "Steven Levine"
Post by Steven Levine
HI all,
Post by Frank Beythien
Post by Mat Nieuwenhoven
<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.
--
"I begin to envy Petronius."
"I have envied him long since."
Paul S Person
2019-01-02 18:06:10 UTC
Permalink
Post by Frank Beythien
[...]
Post by Mat Nieuwenhoven
Post by Paul S Person
\^<
\^>
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.
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.
--
"I begin to envy Petronius."
"I have envied him long since."
Mat Nieuwenhoven
2019-01-05 22:24:09 UTC
Permalink
Post by Frank Beythien
[...]
Post by Mat Nieuwenhoven
Post by Paul S Person
\^<
\^>
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.
I was referring to the special use of \^< and \^> , and whatever other
special escapes there might be.

Mat Nieuwenhoven
Hans-Bernhard Bröker
2019-01-06 00:01:02 UTC
Permalink
Post by 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.
Paul S Person
2019-01-02 18:04:58 UTC
Permalink
On Wed, 02 Jan 2019 10:26:37 +0100 (CET), "Mat Nieuwenhoven"
[snip]
Post by Mat Nieuwenhoven
Post by Paul S Person
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.
--
"I begin to envy Petronius."
"I have envied him long since."
Hans-Bernhard Bröker
2019-01-02 23:07:09 UTC
Permalink
Post by 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
2019-01-03 17:48:58 UTC
Permalink
On Thu, 3 Jan 2019 00:07:09 +0100, Hans-Bernhard Bröker
Post by Hans-Bernhard Bröker
Post by 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. :-)
I actually tried that with diff.

I wanted to see if /it/ could just return the number of changes.
--
"I begin to envy Petronius."
"I have envied him long since."
Hans-Bernhard Bröker
2019-01-01 17:09:14 UTC
Permalink
Post by 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
2019-01-01 17:41:09 UTC
Permalink
On Tue, 1 Jan 2019 18:09:14 +0100, Hans-Bernhard Bröker
Post by Hans-Bernhard Bröker
Post by 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.
Post by 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.
That explains why, when I tried it, it did not work.
Post by Hans-Bernhard Bröker
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.
Post by Hans-Bernhard Bröker
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.
--
"I begin to envy Petronius."
"I have envied him long since."
Frank Beythien
2019-01-07 08:58:23 UTC
Permalink
Post by 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.
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.
Post by Hans-Bernhard Bröker
Maybe you really should consider switching to a more useful
implementation of grep --- even NT's "findstr" might qualify.
+1

Frank
Paul S Person
2019-01-07 17:27:17 UTC
Permalink
Post by Frank Beythien
Post by 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.
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.
Post by Hans-Bernhard Bröker
Maybe you really should consider switching to a more useful
implementation of grep --- even NT's "findstr" might qualify.
+1
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.
--
"I begin to envy Petronius."
"I have envied him long since."
n***@efbe.prima.de
2019-01-12 17:59:47 UTC
Permalink
Post by Paul S Person
Post by Frank Beythien
Post by 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.
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.
Post by Hans-Bernhard Bröker
Maybe you really should consider switching to a more useful
implementation of grep --- even NT's "findstr" might qualify.
+1
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.
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
2019-01-15 17:32:15 UTC
Permalink
Post by n***@efbe.prima.de
Post by Paul S Person
Post by Frank Beythien
Post by 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.
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.
Post by Hans-Bernhard Bröker
Maybe you really should consider switching to a more useful
implementation of grep --- even NT's "findstr" might qualify.
+1
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.
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.
Thanks.

You also extended OW one step further into full Linux support.
The Linuxen should thank you too!
--
"I begin to envy Petronius."
"I have envied him long since."
Loading...