Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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
On 2024-01-07, Scott Dorsey <kludge@panix.com> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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:
On 1/8/2024 9:21 AM, Simon Clubley wrote:
Things I would like to see from bash in DCL:
Filename globbing.
Don't have a clue what globbing is. Probably don't want to know anyway.
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.
On 1/8/2024 10:35 AM, Dave Froble wrote:
On 1/8/2024 9:21 AM, Simon Clubley wrote:
Things I would like to see from bash in DCL:
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.
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
On 1/8/2024 10:35 AM, Dave Froble wrote:
On 1/8/2024 9:21 AM, Simon Clubley wrote:
Things I would like to see from bash in DCL:
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.
On 2024-01-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/8/2024 10:35 AM, Dave Froble wrote:
On 1/8/2024 9:21 AM, Simon Clubley wrote:Wildcard expansion in the shell not the program.
Things I would like to see from bash in DCL:
Filename globbing.
Don't have a clue what globbing is. Probably don't want to know anyway. >>
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.
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.
[globbing]
On 2024-01-08 1:33 p.m., Arne Vajhøj wrote:
But there are two aspects:[...]
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?
On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
On 2024-01-08 9:21 a.m., Simon Clubley wrote:
SupportsSynchronised permanent storage of command history across sessions.
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.
Things I would like to see in bash on Linux:
Ctrl-T
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
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 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
On 2024-01-08 9:21 a.m., Simon Clubley wrote:
SupportsSynchronised permanent storage of command history across sessions.
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...
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
Things I would like to see in bash on Linux:
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.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
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 1/8/2024 4:14 PM, Dan Cross wrote:
In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
On 1/8/24 19:02, mjos_examine wrote:
On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
On 2024-01-08 9:21 a.m., Simon Clubley wrote:
using multiple sessions at the same time and only writes the changes >>>>>> fromSynchronised permanent storage of command history across sessions. >>>>>> Supports
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.
In article <l037lbF2supU10@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
On 1/8/2024 4:14 PM, Dan Cross wrote:
In article <unhkr1$1lj0v$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
On 1/8/24 19:02, mjos_examine wrote:
On 2024-01-08 9:38 a.m., Arne Vajhøj wrote:
On 2024-01-08 9:21 a.m., Simon Clubley wrote:
using multiple sessions at the same time and only writes the changes >>>>>>> fromSynchronised permanent storage of command history across sessions. >>>>>>> Supports
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.
In article <unhrqa$6f4$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <l037lbF2supU10@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
[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.
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
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
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.
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.
Things I would like to see in bash on Linux:
Ctrl-T
For scripting, I use sh (not bash).
It also has much more powerful pattern matching than DCL offers, which
is why I would like to see it on VMS.
On 9 Jan 2024 00:59:38 GMT, Bob Eager wrote:
For scripting, I use sh (not bash).
bash really offers a lot more useful stuff than a vanilla POSIX shell.
Like coproc.
Things I would like to see from bash in DCL:
Ya know Simon, JF once asked for password completion. Not all
desires are reasonable.
On 1/8/2024 5:09 PM, Dan Cross wrote:
In article <l037lbF2supU10@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
[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.
On Mon, 8 Jan 2024 18:25:07 -0000 (UTC), Simon Clubley wrote:
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.
On Mon, 8 Jan 2024 14:21:18 -0000 (UTC), Simon Clubley wrote:
Things I would like to see in bash on Linux:
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 <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
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 Mon, 2024-01-08 at 10:37 -0500, Dave Froble wrote:
Things I would like to see from bash in DCL:
Ya know Simon, JF once asked for password completion. Not all
desires are reasonable.
The mind boggles.
https://man7.org/linux/man-pages/man1/rename.1.html
On 2024-01-09, Single Stage to Orbit <alex.buell@munted.eu> wrote:
On Mon, 2024-01-08 at 10:37 -0500, Dave Froble wrote:
Things I would like to see from bash in DCL:
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...
Very useful for whole file system copies:
But at that point I use other labguages.
On 9 Jan 2024 08:49:07 GMT, Bob Eager wrote:
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.
On Tue, 09 Jan 2024 20:34:57 +0000, Lawrence D'Oliveiro wrote:
On 9 Jan 2024 08:49:07 GMT, Bob Eager wrote:
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.
On 2024-01-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
On 9 Jan 2024 23:57:19 GMT, Bob Eager wrote:
On Tue, 09 Jan 2024 20:34:57 +0000, Lawrence D'Oliveiro wrote:
On 9 Jan 2024 08:49:07 GMT, Bob Eager wrote:
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?
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.
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.
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.
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.
Personally, I think regexps are overrated! And I first started using
them in 1975.
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).
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.
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.
On 10 Jan 2024 21:59:20 GMT, Bob Eager wrote:except-xhtml-self-contained-tags/1732454#1732454>.
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-
(I taught compiler theory and practice for many years!)
Filename globbing.
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?.
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”.
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.
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.
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.
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
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?
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 ~/.[^.]*
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.
ls -ld ~/.[^.]*
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 ~/.[^.]*
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 439 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:18:56 |
| Calls: | 9,147 |
| Files: | 13,433 |
| Messages: | 6,041,772 |