On Wed, 10 Jan 2024 08:38:18 -0500, Arne Vajhøj wrote:

> On 1/10/2024 5:00 AM, Bob Eager wrote:
>> On Wed, 10 Jan 2024 00:11:24 +0000, Lawrence D'Oliveiro wrote:
>>> On 9 Jan 2024 23:57:19 GMT, Bob Eager wrote:
>>>> Oh, I've examined the documentation (and books) in detail. But by
>>>> that time, I'd been using REXX for years, and it does all I need.
>>>> It's surprisingly powerful.
>>>
>>> I had a look at the Wikipedia overview
>>> <https://en.wikipedia.org/wiki/Rexx>, and I see it gushes a lot over
>>> the PARSE statement, but it doesn’t seem to have regular expressions.
>>> Is that overview out of date?
>>
>> REXX is a sparse language. But it has lots of libraries, and there are
>> regexp libraries.
>>
>> Personally, I think regexps are overrated! And I first started using
>> them in 1975.
>
> There is the famous quote:
>
> <quote>
> Some people, when confronted with a problem, think "I know, I'll use
> regular expressions." Now they have two problems.
> </quote>
>
> It is an obscure syntax.
>
> But it is powerful and very widely available (small differences but
> available), so my conclusion is: learn it.

Oh, I learned it. Back in the 1970s, and I've kept up to date. But they
are still overrated.

In article <l07mnrFklcmU4@mid.individual.net>,
Bob Eager <news0009@eager.cx> wrote:
>On Wed, 10 Jan 2024 08:38:18 -0500, Arne Vajhøj wrote:
>> On 1/10/2024 5:00 AM, Bob Eager wrote:
>>> On Wed, 10 Jan 2024 00:11:24 +0000, Lawrence D'Oliveiro wrote:
>>>> On 9 Jan 2024 23:57:19 GMT, Bob Eager wrote:
>>>>> Oh, I've examined the documentation (and books) in detail. But by
>>>>> that time, I'd been using REXX for years, and it does all I need.
>>>>> It's surprisingly powerful.
>>>>
>>>> I had a look at the Wikipedia overview
>>>> <https://en.wikipedia.org/wiki/Rexx>, and I see it gushes a lot over
>>>> the PARSE statement, but it doesn’t seem to have regular expressions.
>>>> Is that overview out of date?
>>>
>>> REXX is a sparse language. But it has lots of libraries, and there are
>>> regexp libraries.
>>>
>>> Personally, I think regexps are overrated! And I first started using
>>> them in 1975.
>>
>> There is the famous quote:
>>
>> <quote>
>> Some people, when confronted with a problem, think "I know, I'll use
>> regular expressions." Now they have two problems.
>> </quote>
>>
>> It is an obscure syntax.
>>
>> But it is powerful and very widely available (small differences but
>> available), so my conclusion is: learn it.
>
>Oh, I learned it. Back in the 1970s, and I've kept up to date. But they
>are still overrated.

That's sort of a weird take. Regular expressions, in their
purest form, are simply a notation for denotating elements of
the set of regular languages. It turns out that they're useful
for all sorts of applications. They may be overused, but
describing them as "overrated" kind of strikes me as being
similar to describing algebra as overrated.

- Dan C.

On 10 Jan 2024 10:00:57 GMT, Bob Eager wrote:

> Personally, I think regexps are overrated! And I first started using
> them in 1975.

How about starting with a simple thing, like being able to treat multiple
separators as one:

re.split(r"\s+", "the quick brown fox")

giving

['the', 'quick', 'brown', 'fox']

On Wed, 10 Jan 2024 13:16:56 -0000 (UTC), Simon Clubley wrote:

> On 2024-01-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 9 Jan 2024 14:19:50 +0000, chrisq wrote:
>>
>>> Very useful for whole file system copies:
>>
>> I use rsync for that. It also does incremental updates.
>
> Likewise. You can also run it over a ssh transport when syncing between
> two different systems. You can also run it a second time in checksum
> mode to make sure nothing else gets transferred (I use this as a verify
> pass).

And, with the --link-dest option, you can do incremental backups that
look, for restoration purposes, just like full backups.

A powerful tool, with a million uses.

On Wed, 10 Jan 2024 18:04:16 +0000, Dan Cross wrote:

> In article <l07mnrFklcmU4@mid.individual.net>,
> Bob Eager <news0009@eager.cx> wrote:
>>On Wed, 10 Jan 2024 08:38:18 -0500, Arne Vajhøj wrote:
>>> On 1/10/2024 5:00 AM, Bob Eager wrote:
>>>> On Wed, 10 Jan 2024 00:11:24 +0000, Lawrence D'Oliveiro wrote:
>>>>> On 9 Jan 2024 23:57:19 GMT, Bob Eager wrote:
>>>>>> Oh, I've examined the documentation (and books) in detail. But by
>>>>>> that time, I'd been using REXX for years, and it does all I need.
>>>>>> It's surprisingly powerful.
>>>>>
>>>>> I had a look at the Wikipedia overview
>>>>> <https://en.wikipedia.org/wiki/Rexx>, and I see it gushes a lot over
>>>>> the PARSE statement, but it doesn’t seem to have regular
>>>>> expressions.
>>>>> Is that overview out of date?
>>>>
>>>> REXX is a sparse language. But it has lots of libraries, and there
>>>> are regexp libraries.
>>>>
>>>> Personally, I think regexps are overrated! And I first started using
>>>> them in 1975.
>>>
>>> There is the famous quote:
>>>
>>> <quote>
>>> Some people, when confronted with a problem, think "I know, I'll use
>>> regular expressions." Now they have two problems.
>>> </quote>
>>>
>>> It is an obscure syntax.
>>>
>>> But it is powerful and very widely available (small differences but
>>> available), so my conclusion is: learn it.
>>
>>Oh, I learned it. Back in the 1970s, and I've kept up to date. But they
>>are still overrated.
>
> That's sort of a weird take. Regular expressions, in their purest form,
> are simply a notation for denotating elements of the set of regular
> languages. It turns out that they're useful for all sorts of
> applications. They may be overused, but describing them as "overrated"
> kind of strikes me as being similar to describing algebra as overrated.

Perhaps 'overused' is a better term. I see a lot of instances where they
are simply not the right tool for the job. I use them where they are
appropriate.

On 10 Jan 2024 21:59:20 GMT, Bob Eager wrote:

> Perhaps 'overused' is a better term. I see a lot of instances where they
> are simply not the right tool for the job. I use them where they are
> appropriate.

The main thing to realize is that REs are a Chomsky Type 3 grammar. In
simple terms, they cannot count arbitrarily-nested parentheses. Once
you grasp this point, you will have a better idea when not to use them
<https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454>.

On Wed, 10 Jan 2024 22:12:29 +0000, Lawrence D'Oliveiro wrote:

> On 10 Jan 2024 21:59:20 GMT, Bob Eager wrote:
>
>> Perhaps 'overused' is a better term. I see a lot of instances where
>> they are simply not the right tool for the job. I use them where they
>> are appropriate.
>
> The main thing to realize is that REs are a Chomsky Type 3 grammar. In
> simple terms, they cannot count arbitrarily-nested parentheses. Once you
> grasp this point, you will have a better idea when not to use them
> <https://stackoverflow.com/questions/1732348/regex-match-open-tags-
except-xhtml-self-contained-tags/1732454#1732454>.

I know that. But many people don't.

(I taught compiler theory and practice for many years!)

On 10 Jan 2024 22:30:13 GMT, Bob Eager wrote:

> (I taught compiler theory and practice for many years!)

Cool! Have you heard of these new-fangled “PEG” things? Python is using
one for its parser now.

Perhaps they could be used for more powerful pattern-matching purposes
than REs. Or maybe they will simply introduce their own pitfalls, if not
used with care, like undecidability and endless loops.

On Mon, 8 Jan 2024 14:21:18 -0000 (UTC), Simon Clubley wrote:

> Filename globbing.

Coming back to this, it’s worth pointing out that you cannot simply add
features, willy-nilly, to a framework that was not designed with them in
mind.

Consider how the whole VMS mindset expects the command-line to work: there
is a distinction between filespecs separated by spaces and those separated
by commas, and even plus-signs. The CLI never does wildcard expansion, and
on the one hand this puts the burden on the program (which has the
powerful RMS $PARSE service to call on) to expand input filespecs, and on
the other hand it allows wildcards to appear in output filespecs as well
(again, supported by $PARSE) to indicate “use the same value here as in
the input filespec”.

That latter meaning is something I have sometimes missed on *nix systems.

In the *nix world, there is actually no requirement for filename globbing
to happen in a command at all. Shells usually do it, and they usually
provide a way to tell them not to do it. (If only because, believe it or
not, those globbing wildcard characters are valid in filenames, too.) If
one user program is directly spawning another, without going through a
shell, then it has to explicitly call some library routine to do globbing,
otherwise it doesn’t happen.

There is no equivalent to CLD files in the *nix world. (In my time on VMS,
I found them too fiddly to use, anyway, and relied on a simple “foreign”
command using LIB$TPARSE instead.) But one thing that improves the
situation is that the “command line” is not a simple string, but an array
of strings. And by default the shell will do word-splitting on the command
line the user passes, to build this array. So it is possible to implement
very simple option parsing in any program, without resorting to very
elaborate libraries, to support a useful range of command-line options.

On 2024-01-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 8 Jan 2024 14:21:18 -0000 (UTC), Simon Clubley wrote:
>
>> Filename globbing.
>
> Coming back to this, it?s worth pointing out that you cannot simply add
> features, willy-nilly, to a framework that was not designed with them in
> mind.
>
> Consider how the whole VMS mindset expects the command-line to work: there
> is a distinction between filespecs separated by spaces and those separated
> by commas, and even plus-signs. The CLI never does wildcard expansion, and
> on the one hand this puts the burden on the program (which has the
> powerful RMS $PARSE service to call on) to expand input filespecs, and on
> the other hand it allows wildcards to appear in output filespecs as well
> (again, supported by $PARSE) to indicate ?use the same value here as in
> the input filespec?.
>

Fine. Then add the globbing pattern capabilities to the current VMS wildcard
lookup APIs without changing anything else. That gives you the same ability
to use more powerful pattern matching expressions on VMS without having to
change anything else in your code.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/10/2024 6:23 PM, Lawrence D'Oliveiro wrote:
> Consider how the whole VMS mindset expects the command-line to work: there
> is a distinction between filespecs separated by spaces and those separated
> by commas, and even plus-signs. The CLI never does wildcard expansion, and
> on the one hand this puts the burden on the program (which has the
> powerful RMS $PARSE service to call on) to expand input filespecs,

Note that it is SYS$SEARCH that does the heavy lifting in this regard.
SYS$PARSE is just for prepping.

> and on
> the other hand it allows wildcards to appear in output filespecs as well
> (again, supported by $PARSE) to indicate “use the same value here as in
> the input filespec”.

Yes.

> There is no equivalent to CLD files in the *nix world. (In my time on VMS,
> I found them too fiddly to use, anyway, and relied on a simple “foreign”
> command using LIB$TPARSE instead.) But one thing that improves the
> situation is that the “command line” is not a simple string, but an array
> of strings. And by default the shell will do word-splitting on the command
> line the user passes, to build this array. So it is possible to implement
> very simple option parsing in any program, without resorting to very
> elaborate libraries, to support a useful range of command-line options.

That is what CLD does.

And a lot simpler than LIB$GET_FOREIGN and LIB$T[ABLE]_PARSE.

Arne

On Thu, 11 Jan 2024 13:52:52 -0000 (UTC), Simon Clubley wrote:

> Fine. Then add the globbing pattern capabilities to the current VMS
> wildcard lookup APIs without changing anything else. That gives you the
> same ability to use more powerful pattern matching expressions on VMS
> without having to change anything else in your code.

I’m not really sure that’s worthwhile. One could argue that the existing
VMS wildcard patterns are already equivalent in power (or a bit beyond, in
the case of “...”), based on the corresponding constructs in the filename
specs.

Regular expressions, on the other hand, are somewhat more powerful. I did
one project where I had to do my own globbing against user-provided
patterns in the usual shell-wildcard syntax, and I found it easier to
convert those wildcards to RE patterns, and use those to scan against a
list of filenames, than to use the provided glob-expansion services.

On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Jan 2024 13:52:52 -0000 (UTC), Simon Clubley wrote:
>
>> Fine. Then add the globbing pattern capabilities to the current VMS
>> wildcard lookup APIs without changing anything else. That gives you the
>> same ability to use more powerful pattern matching expressions on VMS
>> without having to change anything else in your code.
>
> I?m not really sure that?s worthwhile. One could argue that the existing
> VMS wildcard patterns are already equivalent in power (or a bit beyond, in
> the case of ?...?), based on the corresponding constructs in the filename
> specs.
>

The main thing missing on VMS is that you can't use a grouping
operator such as [a-d] to restrict the files selected or to select
everyting not in the grouping operator. There's nothing similar
to the {} expansion operator either.

I use that kind of selection criteria all the time on Linux.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Fri, 12 Jan 2024 13:21:42 -0000 (UTC), Simon Clubley wrote:

> The main thing missing on VMS is that you can't use a grouping
> operator such as [a-d] to restrict the files selected or to select
> everyting not in the grouping operator.

Ah, true. I suppose that could be added as a new kind of wildcard option
to the existing wildcard syntax. After all, there is no shortage of
characters that are currently illegal in filespecs, that could be used. ;)

For those who are wondering about the usefulness of this on *nix systems,
here

ls -ld ~/.[!.]*

is a command to list all dotfiles/dotdirectories in my home directory.

(As to why they need to clutter up the top level of my home directory, is
another peeve.)

(As to why every directory needs to contain those useless “.” and “..”
entries, is yet another peeve.)

> There's nothing similar to the {} expansion operator either.

That's not in POSIX, that’s a bash-ism. And it’s not really a “wildcard”,
either.

On 1/12/2024 8:21 AM, Simon Clubley wrote:
> On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Jan 2024 13:52:52 -0000 (UTC), Simon Clubley wrote:
>>
>>> Fine. Then add the globbing pattern capabilities to the current VMS
>>> wildcard lookup APIs without changing anything else. That gives you the
>>> same ability to use more powerful pattern matching expressions on VMS
>>> without having to change anything else in your code.
>>
>> I?m not really sure that?s worthwhile. One could argue that the existing
>> VMS wildcard patterns are already equivalent in power (or a bit beyond, in
>> the case of ?...?), based on the corresponding constructs in the filename
>> specs.
>>
>
> The main thing missing on VMS is that you can't use a grouping
> operator such as [a-d] to restrict the files selected or to select
> everyting not in the grouping operator. There's nothing similar
> to the {} expansion operator either.
>
> I use that kind of selection criteria all the time on Linux.
>
> Simon.
>

Maybe you do, but, in the past I've done the same on VMS, and more.

Now, to be specific, I read the above to be select filenames beginning with the
letters a thru d. Is that correct?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2024-01-12 8:21 a.m., Simon Clubley wrote:
> On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Thu, 11 Jan 2024 13:52:52 -0000 (UTC), Simon Clubley wrote:
>>
>>> Fine. Then add the globbing pattern capabilities to the current VMS
>>> wildcard lookup APIs without changing anything else. That gives you the
>>> same ability to use more powerful pattern matching expressions on VMS
>>> without having to change anything else in your code.
>>
>> I?m not really sure that?s worthwhile. One could argue that the existing
>> VMS wildcard patterns are already equivalent in power (or a bit beyond, in
>> the case of ?...?), based on the corresponding constructs in the filename
>> specs.
>>
>
> The main thing missing on VMS is that you can't use a grouping
> operator such as [a-d] to restrict the files selected or to select
> everyting not in the grouping operator. There's nothing similar
> to the {} expansion operator either.
>
> I use that kind of selection criteria all the time on Linux.
>
> Simon.
>

$ dir *.txt

Directory DKA100:[test]

atest.txt;1 btest.txt;1 ctest.txt;1 dtest.txt;1
etest.txt;1 ftest.txt;1 gtest.txt;1

Total of 7 files.

$
$ $ type testglob.c
/* -------- start of testglob.c --------- */
/* experimenting with RTL glob on OpenVMS */

#include <stdio.h>
#include <glob.h>
/*
* From:
*
https://docs.vmssoftware.com/vsi-c-run-time-library-reference-manual-for-openvms-systems/
* The glob function defaults to OpenVMS mode unless one of the
* following conditions is met (in which case glob uses UNIX mode):
* - The DECC$GLOB_UNIX_STYLE is enabled.
* - The DECC$FILENAME_UNIX_ONLY feature logical is enabled.
* - The glob function checks the specified pattern for pathname
* indications, such as directory delimiters, and determines it to
* be a UNIX style pathname.
*/

int main(int argc, char *argv[])
{ const char *mypattern = "[a-c]*";
glob_t myglob;
int result;
size_t count;

printf("pattern is:%s\n", mypattern);
result = glob(mypattern, 0, NULL, &myglob);
if (result == 0) {
for (count = 0; count < myglob.gl_pathc; ++count) {
if (myglob.gl_pathv) {
printf("%s\n", myglob.gl_pathv[count]);
}
}
globfree(&myglob);
} else {
printf("glob() failed (%s).\n",
(result == GLOB_ABORTED) ? "GLOB_ABORTED"
: (result == GLOB_NOMATCH) ? "GLOB_NOMATCH"
: (result == GLOB_NOSPACE) ? "GLOB_NOSPACE"
: "unknown error");
}
} /* -------- end of testglob.c --------- */
$ cc testglob.c
$ link testglob
$ run testglob
pattern is:[a-c]*
glob() failed (GLOB_NOMATCH).
$ $ DEFINE DECC$GLOB_UNIX_STYLE ENABLE
$ $ run testglob
pattern is:[a-c]*
atest.txt
btest.txt
ctest.txt
$ DEAS DECC$GLOB_UNIX_STYLE
$

On 2024-01-12, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/12/2024 8:21 AM, Simon Clubley wrote:
>> On 2024-01-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Thu, 11 Jan 2024 13:52:52 -0000 (UTC), Simon Clubley wrote:
>>>
>>>> Fine. Then add the globbing pattern capabilities to the current VMS
>>>> wildcard lookup APIs without changing anything else. That gives you the
>>>> same ability to use more powerful pattern matching expressions on VMS
>>>> without having to change anything else in your code.
>>>
>>> I?m not really sure that?s worthwhile. One could argue that the existing
>>> VMS wildcard patterns are already equivalent in power (or a bit beyond, in
>>> the case of ?...?), based on the corresponding constructs in the filename
>>> specs.
>>>
>>
>> The main thing missing on VMS is that you can't use a grouping
>> operator such as [a-d] to restrict the files selected or to select
>> everyting not in the grouping operator. There's nothing similar
>> to the {} expansion operator either.
>>
>> I use that kind of selection criteria all the time on Linux.
>>
>
> Maybe you do, but, in the past I've done the same on VMS, and more.
>
> Now, to be specific, I read the above to be select filenames beginning with the
> letters a thru d. Is that correct?
>

Yes. You can also negate the pattern to find everything not in that pattern.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2024-01-12, mjos_examine <m6502x64@gmail.com> wrote:
>
> $ dir *.txt
>
> Directory DKA100:[test]
>
> atest.txt;1 btest.txt;1 ctest.txt;1 dtest.txt;1
> etest.txt;1 ftest.txt;1 gtest.txt;1
>
> Total of 7 files.
>
> $
> $
> $ type testglob.c

[snip]

Cute. :-) Now get that added to the native VMS filename lookup API using
VMS-suitable syntax and make it available in DCL... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Fr 12 Jan 2024 at 20:17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> Ah, true. I suppose that could be added as a new kind of wildcard option
> to the existing wildcard syntax. After all, there is no shortage of
> characters that are currently illegal in filespecs, that could be used. ;)
>
> For those who are wondering about the usefulness of this on *nix systems,
> here
>
> ls -ld ~/.[!.]*
>
> is a command to list all dotfiles/dotdirectories in my home directory.

I think you meant

> ls -ld ~/.[^.]*

'Andreas

On Mon, 22 Jan 2024 07:16:16 +0100, Andreas Eder wrote:

> On Fr 12 Jan 2024 at 20:17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> For those who are wondering about the usefulness of this on *nix
>> systems, here
>>
>> ls -ld ~/.[!.]*
>>
>> is a command to list all dotfiles/dotdirectories in my home directory.
>
> I think you meant
>
>> ls -ld ~/.[^.]*

That might work in Bash, but the first is POSIX-compliant.

In article <8734up7v0v.fsf@eder.anydns.info>,
Andreas Eder <a_eder_muc@web.de> wrote:
>On Fr 12 Jan 2024 at 20:17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Ah, true. I suppose that could be added as a new kind of wildcard option
>> to the existing wildcard syntax. After all, there is no shortage of
>> characters that are currently illegal in filespecs, that could be used. ;)
>>
>> For those who are wondering about the usefulness of this on *nix systems,
>> here
>>
>> ls -ld ~/.[!.]*
>>
>> is a command to list all dotfiles/dotdirectories in my home directory.
>
>I think you meant
>
>> ls -ld ~/.[^.]*

The POSIX shell notation is kind of strange; it was, as I was
told, originally based on ksh88, which uses this notation for
negation in pattern matching. In particular, section 2.13.1 of
the current standard says that `!` takes the place of `^` in
shell pattern matching:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13

Beats me why Korn chose this syntax. Historically, the 7th
Edition shell by Bourne didn't support negation in patterns
at all.

- Dan C.