Unix and DCL shells

[Simon Clubley]

The whole command-line concept on VMS is fundamentally flawed. Notice that
on *nix, the command line is not a single string, it is an array of
strings. This makes it easy to pass special characters that might mean
something to the shell, simply by bypassing the shell.

Having made the Unix-to-VMS transition in the late eighties, the two things
I really liked about DCL were the handling of wildcards and the ability to
use [....] for recursive file paths. I would love to have those two things
in bash.

Things I would like to see from bash in DCL:

Filename globbing.

Tab completion of files/directories with list of matches at each stage.

Ability to edit lines longer than the terminal width.

Easy incremental recall of commands (Ctrl-R in bash).

Synchronised permanent storage of command history across sessions. Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

Things I would like to see in bash on Linux:

Ctrl-T

Simon.

[Arne Vajhøj]

Post by Simon Clubley

The whole command-line concept on VMS is fundamentally flawed. Notice that
on *nix, the command line is not a single string, it is an array of
strings. This makes it easy to pass special characters that might mean
something to the shell, simply by bypassing the shell.

Having made the Unix-to-VMS transition in the late eighties, the two things
I really liked about DCL were the handling of wildcards and the ability to
use [....] for recursive file paths. I would love to have those two things
in bash.

Filename globbing.

Backwards compatibility will show its ugly head again.

$ define dcl$enable_globbing true

to enable?

foobar *.xyz *.abc

Foreign command expand to:

foobar 1.xyz 2.xyz 3.abc 4.abc ! 4 arguments

CLD expand to:

foobar 1.xyz,2.xyz 3.abc,4.abc ! 2 arguments

Or?

Post by Simon Clubley
Tab completion of files/directories with list of matches at each stage.

Would be very nice indeed and should not break anything.

Post by Simon Clubley
Ability to edit lines longer than the terminal width.

Ditto.

Even though I believe we usually get a long story about how DCL
and the terminal driver interacts.

Post by Simon Clubley
Easy incremental recall of commands (Ctrl-R in bash).
Synchronised permanent storage of command history across sessions. Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.

But other may like the history you propose.

Arne

[mjos_examine]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.

Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

[chrisq]

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

Not a problem now, bash, csh and perhaps others. all support command
line recall, with cmdline buffer length a terminal setup parameter.
history (aliased h), shows the whole list, with !<line number>,
selecting and running any item.

Can be a steep learning curve, and easily forgotten without use,
but so much workflow power in the unix shell...

Chris

[Dan Cross]

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

tcsh, bash, zsh all had such functionality in the early 1990s,
of course, using both the csh syntax as well as the ability;
tcsh starting in the 80s. ksh (at least 93) might be
configurable to do something similar, but I can't recall now.

Post by chrisq
Not a problem now, bash, csh and perhaps others. all support command
line recall, with cmdline buffer length a terminal setup parameter.
history (aliased h), shows the whole list, with !<line number>,
selecting and running any item.
Can be a steep learning curve, and easily forgotten without use,
but so much workflow power in the unix shell...

Yup.

- Dan C.

[bill]

Post by Dan Cross

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

bill

[Dan Cross]

Post by bill

Post by Dan Cross

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.

Ultrix had csh.

- Dan C.

[Scott Dorsey]

Post by Dan Cross

Post by bill

Post by Dan Cross

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.
Ultrix had csh.

It did, but I installed tcsh off some net repository because it was so
much better.
--scott

[Dan Cross]

Post by Scott Dorsey

Post by Dan Cross

[snip]
I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.
Ultrix had csh.

It did, but I installed tcsh off some net repository because it was so
much better.

Yeah. Tcsh was more or less requisite on a BSD-ish system for a
long while. At least for interactive use; "program with Bourne,
type with Joy" was a motto back in those days.

I stuck with tcsh for a long while until I started working at
Google. Then, network effects made me switch to Bash. These
days, it's mostly zsh everywhere.

- Dan C.

[Bob Eager]

Yeah. Tcsh was more or less requisite on a BSD-ish system for a long
while. At least for interactive use; "program with Bourne,
type with Joy" was a motto back in those days.
I stuck with tcsh for a long while until I started working at Google.
Then, network effects made me switch to Bash. These days, it's mostly
zsh everywhere.

We never had a PDP-11 with separate I and D space, so we never really had
room for BSD on the 11. Once we got the VAX machines, we ran it. I've been
using it ever since (now on FreeBSD).

I moved to csh when it first came out and have never changed. At some
point csh was linked to tcsh, and I do use the extra facilities.

For scripting, I use sh (not bash). Or I use REXX.

[Lawrence D'Oliveiro]

Post by Bob Eager
For scripting, I use sh (not bash).

bash really offers a lot more useful stuff than a vanilla POSIX shell.
Like coproc.

[Bob Eager]

Post by Lawrence D'Oliveiro

Post by Bob Eager
For scripting, I use sh (not bash).

bash really offers a lot more useful stuff than a vanilla POSIX shell.
Like coproc.

I'm sure it does. But at that point I use other labguages.

[Lawrence D'Oliveiro]

Post by Bob Eager
But at that point I use other labguages.

Which I have done. But, you know, it turns out bash has one or two more
useful capabilities up its sleeve than you might give it credit for.

[Bob Eager]

Post by Lawrence D'Oliveiro

Post by Bob Eager
But at that point I use other labguages.

Which I have done. But, you know, it turns out bash has one or two more
useful capabilities up its sleeve than you might give it credit for.

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.

[Lawrence D'Oliveiro]

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
But at that point I use other labguages.

Which I have done. But, you know, it turns out bash has one or two more
useful capabilities up its sleeve than you might give it credit for.

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?

[Bob Eager]

Post by Lawrence D'Oliveiro

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
But at that point I use other labguages.

Which I have done. But, you know, it turns out bash has one or two
more useful capabilities up its sleeve than you might give it credit
for.

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.

[Arne Vajhøj]

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
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.

Arne

[Bob Eager]

Post by Arne Vajhøj

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
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.

<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.

[Dan Cross]

Post by Bob Eager

Post by Arne Vajhøj

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
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.

<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.

[Bob Eager]

Post by Bob Eager

Post by Arne Vajhøj

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Bob Eager
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.

<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.

[Lawrence D'Oliveiro]

Post by Bob Eager
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>.

[Bob Eager]

Post by Lawrence D'Oliveiro

Post by Bob Eager
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!)

[Lawrence D'Oliveiro]

Post by Bob Eager
(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.

[Lawrence D'Oliveiro]

Post by Bob Eager
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']

[bill]

Post by Dan Cross

Post by bill

Post by Dan Cross

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done during
my last session, whether 5 minutes, or 5 days, or 5 months later, can be
very useful and convenient.
Couple that with the sister-feature of being able to back-scroll through
all the terminal output from the last session, and now you are really
talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's

`csh` certainly had command history, though not "recall" in the
sense of using an arror key or ^P or something to bring a
previously executed back back to the prompt for editing. Korn's
shell had similar functionality, and various people hacked it
into `sh` at different times.

I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.
Ultrix had csh.

I just checked. No arrow keys in Ultrix-11. I wonder if
BSD2.11 had it? But most likely FreeBSD which I have used since it's
inception.

bill

[Dan Cross]

Post by bill

Post by Dan Cross

[snip]
I use the arrow keys all the time in csh. Been doing that
since at least the SunOS days. Don't remember if Ultrix
even had csh. Guess I should check.

Unlikely. Tcsh, sure, but not /bin/csh.
Ultrix had csh.

I just checked. No arrow keys in Ultrix-11. I wonder if
BSD2.11 had it? But most likely FreeBSD which I have used since it's
inception.

Nope, not there either.

FreeBSD ditched the traditional Berkeley csh a while back and
replaced it with tcsh, with a link to /bin/csh, so that when you
run `csh` on FreeBSD you're really running `tcsh`. Tcsh
supports arrow key navigation for command recall, as you noted,
but actual csh never has; it only supported the `!` style
history mechanism.

- Dan C.

[bill]

Post by chrisq

Post by mjos_examine

Post by Arne Vajhøj

Post by Simon Clubley

Post by Simon Clubley
Synchronised permanent storage of command history across sessions.

Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

I usually just write a COM file if I want to preserve my commands.
But other may like the history you propose.

I have to agree that being able to up-arrow through commands done
during my last session, whether 5 minutes, or 5 days, or 5 months
later, can be very useful and convenient.
Couple that with the sister-feature of being able to back-scroll
through all the terminal output from the last session, and now you are
really talking useful and convenient.

One of the most irritating things about working on terminal
based systems was the lack of command line recall. To be fair
though, early unix systems with csh or sh lacked that as well.

csh has terminal command line recall. I use it all the time.
csh is still my favorite shell.

I really thought DCL had it,too. DCL in RSTS/E V10.1L does.

Post by chrisq
Solution here was to select tcsh, which did have command line recall
capability, even back in the early 1990's
Not a problem now, bash, csh and perhaps others. all support command
line recall, with cmdline buffer length a terminal setup parameter.
history (aliased h), shows the whole list, with !<line number>,
selecting and running any item.
Can be a steep learning curve, and easily forgotten without use,
but so much workflow power in the unix shell...

bill

[Dave Froble]

Post by Simon Clubley

The whole command-line concept on VMS is fundamentally flawed. Notice that
on *nix, the command line is not a single string, it is an array of
strings. This makes it easy to pass special characters that might mean
something to the shell, simply by bypassing the shell.

Having made the Unix-to-VMS transition in the late eighties, the two things
I really liked about DCL were the handling of wildcards and the ability to
use [....] for recursive file paths. I would love to have those two things
in bash.

Filename globbing.

Don't have a clue what globbing is. Probably don't want to know anyway.

Post by Simon Clubley
Tab completion of files/directories with list of matches at each stage.

You're discussing something that might be useful on a personal workstation. Not
something very useful on a server type of system.

Post by Simon Clubley
Ability to edit lines longer than the terminal width.

That is a valid bitch. The explanation has been that getting into the terminal
driver is similar to a maze of twisty little passages.

Post by Simon Clubley
Easy incremental recall of commands (Ctrl-R in bash).

Not sure what you want Simon? Doesn't RECALL do it? Does for me.

Post by Simon Clubley
Synchronised permanent storage of command history across sessions. Supports
using multiple sessions at the same time and only writes the changes from
that session to the history file.

Ah, see above about personal workstation ...

Post by Simon Clubley
Ctrl-T

Not a problem, don't use Linux, use VMS ...

[Arne Vajhøj]

Post by Simon Clubley
Filename globbing.

Don't have a clue what globbing is.  Probably don't want to know anyway.

Wildcard expansion in the shell not the program.

If you have a VMS Basic program that you run with:

$ mcr []df *.bas

then your Basic program sees one argument with *.bas and can lookup
the matching files with LIB$FIND_FILE or whatever.

If Simons idea get implemented and enabled then your Basic program
would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
the wildcards instead of leaving it to the program.

It is a *nix thing.

Post by Simon Clubley
Tab completion of files/directories with list of matches at each stage.

You're discussing something that might be useful on a personal
workstation.  Not something very useful on a server type of system.

I think system managers of servers could benefit as well.

Arne

[Chris Townley]

Post by Arne Vajhøj

Post by Simon Clubley
Filename globbing.

Don't have a clue what globbing is.  Probably don't want to know anyway.

Wildcard expansion in the shell not the program.
$ mcr []df *.bas
then your Basic program sees one argument with *.bas and can lookup
the matching files with LIB$FIND_FILE or whatever.
If Simons idea get implemented and enabled then your Basic program
would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
the wildcards instead of leaving it to the program.
It is a *nix thing.

Post by Simon Clubley
Tab completion of files/directories with list of matches at each stage.

You're discussing something that might be useful on a personal
workstation.  Not something very useful on a server type of system.

I think system managers of servers could benefit as well.
Arne

Problem there is line length limits. I have frequently had that problem
on *nix

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley
Filename globbing.

Don't have a clue what globbing is.  Probably don't want to know anyway.

Wildcard expansion in the shell not the program.
$ mcr []df *.bas
then your Basic program sees one argument with *.bas and can lookup
the matching files with LIB$FIND_FILE or whatever.
If Simons idea get implemented and enabled then your Basic program
would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
the wildcards instead of leaving it to the program.
It is a *nix thing.

It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

For David's benefit:

https://tldp.org/LDP/abs/html/globbingref.html

DCL doesn't have anything that even begins to compare with that.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
Filename globbing.

Don't have a clue what globbing is.  Probably don't want to know anyway.

Wildcard expansion in the shell not the program.
$ mcr []df *.bas
then your Basic program sees one argument with *.bas and can lookup
the matching files with LIB$FIND_FILE or whatever.
If Simons idea get implemented and enabled then your Basic program
would see N arguments with DF.BAS, X.BAS, Y.BAS etc. - DCL would expand
the wildcards instead of leaving it to the program.
It is a *nix thing.

It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.
https://tldp.org/LDP/abs/html/globbingref.html
DCL doesn't have anything that even begins to compare with that.

But there are two aspects:
1) VMS *% vs the let us call it "regex like"
2) whether it happens in DCL or inside .EXE/.COM file

The first one is not so hard. There will be some decisions to make
regarding syntax as [] may not be a good choice on VMS. But when
syntax is agreed then I assume that a change to SYS$SEARCH
will make LIB$FIND_FILE and F$SEARCH work.

The second could be a little tricky to implement without
breaking too much.

Arne

[mjos_examine]

[globbing]
[...]

Post by Arne Vajhøj
2) whether it happens in DCL or inside .EXE/.COM file
[...]
The second could be a little tricky to implement without
breaking too much.

Does the pipe command glob before passing the command line arguments on?

[Arne Vajhøj]

Post by mjos_examine
[globbing]
[...]

Post by Arne Vajhøj
2) whether it happens in DCL or inside .EXE/.COM file
[...]
The second could be a little tricky to implement without
breaking too much.

Does the pipe command glob before passing the command line arguments on?

No. But obviously /GLOB could be added to PIPE.

Arne

[Scott Dorsey]

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.

But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.
--scott

[Arne Vajhøj]

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.

But DCL is not bash.

I actually think it could work in DCL.

$ SET PROC/GLOB=ON
$ REN *.TXT "*.DAT"

could be interpreted as:

$ REN 1.TXT,2.TXT,3.TXT *.DAT

Arne

[mjos_examine]

Post by Arne Vajhøj

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory.  This is the downside.

But DCL is not bash.
I actually think it could work in DCL.
$ SET PROC/GLOB=ON
$ REN *.TXT "*.DAT"
$ REN 1.TXT,2.TXT,3.TXT *.DAT

In the "spitballing" department, and wanting solutions that don't "break
too much", are the two things outlined below possible today?

$ VMSGLOB -command "[a-c]*" -symbol foo
$! my_ported_unix_program expects globbing to be done already
$ my_ported_unix_program 'foo'

VMSGLOB could carry out glob-style filename expansion in the same manner
as globbing does on UNIX, and store the result (via -symbol arg) in the
symbol specified, possibly with each resulting file name enclosed in
quotations ( if -quoted arg included maybe?).

If you wanted to use the glob results in DCL:

$ VMSGLOB -command "[a-c]*" -symbol foo -delim "|"
$ NUM = 0
$ LOOP:
$ MYFILE = F$ELEMENT(NUM,"|", foo)
$ IF MYFILE .EQS. "|" THEN GOTO DONELOOP
$ DIRECTORY 'MYFILE'
$ NUM = NUM +1
$ GOTO LOOP
$ DONELOOP:

I think that might already be possible today, if you had the VMSGLOB
foreign command to look after the -command arg, -symbol arg, -delim arg,
-quoted.

On a similar note, since DCL already respects the DECK and EOD commands,
example:
$ CREATE FILE.LIS
$ DECK
File data
File data
$ EOD
there could be a VMSBASH foreign command, where you could utilize the
DECK command, like so:
$ VMSBASH
$ DECK
if ! test -f /path/to/file; then
echo "File does not exist."
fi
$ EOD

You could (in theory) place any arbitrary bash script, for
interpretation and execution by a VMSBASH foreign command that expects
to operate in that way, between $DECK and $EOD.

The command preceding the DECK command could function somewhat like the
niche of #!/bin/bash on UNIX for specifying the desired interpreter for
the arbitrary syntax that is between $DECK and $EOD.

[Arne Vajhøj]

Post by mjos_examine
there could be a VMSBASH foreign command, where you could utilize the
    $ VMSBASH
    $ DECK
    if ! test -f /path/to/file; then
    echo "File does not exist."
    fi
    $ EOD
You could (in theory) place any arbitrary bash script, for
interpretation and execution by a VMSBASH foreign command that expects
to operate in that way, between $DECK and $EOD.
The command preceding the DECK command could function somewhat like the
niche of #!/bin/bash on UNIX for specifying the desired interpreter for
the arbitrary syntax that is between $DECK and $EOD.

bash is part of the GNV kit. And it works fine with deck & eod, but
if no bash commands start with $ then deck + eod should not be needed.

This works fine:

$ bash
for i in {1..3}
do
echo $i
done
$
$ bash
$ deck
for i in {1..3}
do
echo $i
done
$ eod
$ exit

Output:

1
2
3
1
2
3

Arne

[Dan Cross]

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.

True, but there are things like http://mcvoy.com/lm/move.shar
that give you such functionality.

People often forget that the globbing functionality in Unix is
entirely internal to the shell (though, in fairness, there are a
couple of userspace libraries that provide essentially the same
thing), and the shell is just another userspace program, so if
one really wanted, one could always replace the shell with
something that did wildcard expansion differently. Of course,
how that would _expand_ in e.g. the `mv` case is another
matter.

- Dan C.

[Bob Eager]

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file
extension in the current working directory. This is the downside.
--scott

Agreed. But there is a commonly available utility for that.

[Simon Clubley]

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.

On Linux, you can try the following:

https://man7.org/linux/man-pages/man1/rename.1.html

As per the manpage advice, make sure you _always_ do it on a copy of
the files. Also be aware that there have been multiple versions of the
rename command across different distributions, so always check the
manpage first.

Simon.

[bill]

Post by Simon Clubley

Post by Scott Dorsey

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

regexps are built into a lot of Unix utilities at fairly low levels and
this is incredibly powerful.
But I cannot say "mv *.txt *.dat" in order to change every file extension
in the current working directory. This is the downside.

https://man7.org/linux/man-pages/man1/rename.1.html
As per the manpage advice, make sure you _always_ do it on a copy of
the files. Also be aware that there have been multiple versions of the
rename command across different distributions, so always check the
manpage first.

I always found it way too easy to use ls and vi to create a script
to do that. Writing as program would have been trivial but more
work than the script solution.

bill

[Lawrence D'Oliveiro]

Post by Simon Clubley
https://man7.org/linux/man-pages/man1/rename.1.html

Also this one:
<https://manpages.ubuntu.com/manpages/bionic/man1/mmv.1.html>

[Lawrence D'Oliveiro]

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

But not as powerful as the “find” command. I find if I need to do more
complex types of file-filtering, I don’t bother with globbing, I go
straight to find.

[chrisq]

Post by Lawrence D'Oliveiro

Post by Simon Clubley
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.

But not as powerful as the “find” command. I find if I need to do more
complex types of file-filtering, I don’t bother with globbing, I go
straight to find.

In agreement there. Very useful for whole file system copies:

#!/bin/sh
#
# Copy Filesystem to Filesystem
#
cd $1
find . -print -depth | cpio -pdmuV $2

Chris

[Lawrence D'Oliveiro]

I use rsync for that. It also does incremental updates.

[Simon Clubley]

Post by Lawrence D'Oliveiro
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).

Simon.

[Lawrence D'Oliveiro]

Post by Simon Clubley

Post by Lawrence D'Oliveiro
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.

[Dave Froble]

The whole command-line concept on VMS is fundamentally flawed. Notice that
on *nix, the command line is not a single string, it is an array of
strings. This makes it easy to pass special characters that might mean
something to the shell, simply by bypassing the shell.

Having made the Unix-to-VMS transition in the late eighties, the two things
I really liked about DCL were the handling of wildcards and the ability to
use [....] for recursive file paths. I would love to have those two things
in bash.

Ya know Simon, JF once asked for password completion. Not all desires are
reasonable.

:-)

[Single Stage to Orbit]

Ya know Simon, JF once asked for password completion.  Not all
desires are reasonable.

The mind boggles.

[Simon Clubley]

Post by Single Stage to Orbit

Ya know Simon, JF once asked for password completion.  Not all
desires are reasonable.

The mind boggles.

In case you never encountered him, JF was just being JF when he
made that suggestion. :-) Wonder what he is up to these days...

Simon.

[bill]

Post by Simon Clubley

Post by Single Stage to Orbit

Ya know Simon, JF once asked for password completion.  Not all
desires are reasonable.

The mind boggles.

In case you never encountered him, JF was just being JF when he
made that suggestion. :-) Wonder what he is up to these days...

If it weren't for all this snow I would have said riding his bike.

bill

[Stephen Hoffman]

Post by Single Stage to Orbit

Ya know Simon, JF once asked for password completion.  Not all desires
are reasonable.

The mind boggles.

In case you never encountered him, JF was just being JF when he made
that suggestion. :-) Wonder what he is up to these days...

JF has been directing energy and attention at various and entirely
worthy goals, both within Montréal and further afield.

As for OpenVMS, two-factor authentication with FIDO or ilk would be
interesting, now that USB is available on most boxes.

Password completion is available for modern APIs via password managers,
but not much accesses and manages OpenVMS via https or ilk.

(Yeah, I know it was meant a joke.)

[Scott Dorsey]

Post by Simon Clubley
Ctrl-T

That IS a cool thing, I agree. I remember running BRL Unix on an 11/730,
which I think was 4.1BSD with a lot of additional stuff from the Army
Ballistics Research Lab, and one of the features was a ctrl-T to show
process status. I have no idea how it was implemented and what signal
ugliness was involved, though.
--scott

[Dan Cross]

Post by Scott Dorsey

Post by Simon Clubley
Ctrl-T

That IS a cool thing, I agree. I remember running BRL Unix on an 11/730,
which I think was 4.1BSD with a lot of additional stuff from the Army
Ballistics Research Lab, and one of the features was a ctrl-T to show
process status. I have no idea how it was implemented and what signal
ugliness was involved, though.

BSD still supports this; SIGINFO is the signal. Of course, it
has to be caught by the program and the program has to elect to
do something intelligent with it, and many do not.

- Dan C.

[Lawrence D'Oliveiro]

Post by Simon Clubley
Ctrl-T

The terminal driver is one part of VMS that I remember fondly. But in *nix
systems, terminal drivers are “character devices”, and there is no concept
of I/O request packets--unless you do all your driver calls via ioctl, I
guess.

I don’t feel the need for CTRL/T simply because I have something like a
dozen or two dozen terminal sessions open at any one time, and it is easy
enough to check up on a hung-looking process from another session. I can
even rummage around in procfs to check the status of open files and memory
usage in the problem process, which is way more than you can do with CTRL/
T anyway.

[Simon Clubley]

Post by Lawrence D'Oliveiro

Post by Simon Clubley
Ctrl-T

The terminal driver is one part of VMS that I remember fondly. But in *nix
systems, terminal drivers are ?character devices?, and there is no concept
of I/O request packets--unless you do all your driver calls via ioctl, I
guess.

FreeBSD supports it, and as already mentioned, it's implemented there
as a signal.

Post by Lawrence D'Oliveiro
I don?t feel the need for CTRL/T simply because I have something like a
dozen or two dozen terminal sessions open at any one time, and it is easy
enough to check up on a hung-looking process from another session. I can
even rummage around in procfs to check the status of open files and memory
usage in the problem process, which is way more than you can do with CTRL/
T anyway.

Programs can intercept Ctrl-T and output program-specific information.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Lawrence D'Oliveiro
I don?t feel the need for CTRL/T simply because I have something like a
dozen or two dozen terminal sessions open at any one time, and it is easy
enough to check up on a hung-looking process from another session. I can
even rummage around in procfs to check the status of open files and memory
usage in the problem process, which is way more than you can do with CTRL/
T anyway.

Programs can intercept Ctrl-T and output program-specific information.

Yes - it is a choice whether to use DCL default or a program
specific handler.

$ type some1.c
#include <stdio.h>

int main(int argc, char *argv[])
{
puts("Press enter to exit");
getchar();
return 0;
}
$ cc some1
$ link some1
$ r some1
Press enter to exit

ARNE4::ARNE 20:31:33 some1 CPU=00:00:12.63 PF=95154 IO=13861 MEM=330
ARNE4::ARNE 20:31:33 some1 CPU=00:00:12.63 PF=95155 IO=13862 MEM=331
ARNE4::ARNE 20:31:34 some1 CPU=00:00:12.63 PF=95155 IO=13863 MEM=331

$ type some2.c
#include <stdio.h>

#include <descrip.h>
#include <iodef.h>
#include <libclidef.h>
#include <lib$routines.h>
#include <starlet.h>

static int n = 0;

void catcher(int c)
{
n++;
printf("You pressed CTRL/T %d times\n", n);
}

int main(int argc, char *argv[])
{
long newmask, oldmask, oobmask;
$DESCRIPTOR(ttdesc, "TT:");
short chan;
newmask = LIB$M_CLI_CTRLT;
lib$disable_ctrl(&newmask, &oldmask);
sys$assign(&ttdesc, &chan, 0, 0);
oobmask = 1 << ('T' - 'A');
sys$qiow(0, chan, IO$_SETMODE|IO$M_OUTBAND, 0, 0, 0, catcher,
&oobmask, 0, 0, 0, 0);
puts("Press enter to exit");
getchar();
lib$enable_ctrl(&oldmask);
sys$dassgn(chan);
return 0;
}
$ cc some2
$ link some2
$ r some2
Press enter to exit

You pressed CTRL/T 1 times
You pressed CTRL/T 2 times
You pressed CTRL/T 3 times

Arne

PS: And note that I managed to get something strongly VMS
related into the post!

[Lawrence D'Oliveiro]

Post by Simon Clubley
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.

[Simon Clubley]

Post by Simon Clubley
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.

[Lawrence D'Oliveiro]

Post by Simon Clubley
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.

[Simon Clubley]

Post by Simon Clubley
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.

[Lawrence D'Oliveiro]

Post by Simon Clubley
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.)

Post by Simon Clubley
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.

[Andreas Eder]

Post by Lawrence D'Oliveiro
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

Post by Lawrence D'Oliveiro
ls -ld ~/.[^.]*

'Andreas

[Lawrence D'Oliveiro]

Post by Andreas Eder

Post by Lawrence D'Oliveiro
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

Post by Lawrence D'Oliveiro
ls -ld ~/.[^.]*

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

[Dan Cross]

Post by Andreas Eder

Post by Lawrence D'Oliveiro
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

Post by Lawrence D'Oliveiro
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.

[Dave Froble]

Post by Simon Clubley

Post by Simon Clubley
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?

[mjos_examine]

Post by Simon Clubley

Post by Simon Clubley
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
$

[Arne Vajhøj]

Post by Lawrence D'Oliveiro
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.

Post by Lawrence D'Oliveiro
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.

Post by Lawrence D'Oliveiro
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