Discussion:
DCL's flaws (both scripting and UI)
(too old to reply)
Simon Clubley
2015-01-18 21:19:35 UTC
Permalink
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.

Some of DCL's UI flaws:

1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.

2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.

With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).

Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.

3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.

4) No elegant incremental search through the command history (bash
Ctrl-R style).

Some of DCL's scripting limitations:

1) No structured programming constructs such as (for example) while
loops.

2) No ability to iterate cleanly over a list of items (bash "for i in"
style)

3) No ability to add site specific lexicals.

4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.

5) No regex support (this is also a UI issue).

6) Pathetic limits on the maximum size of symbol contents.

7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)

DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.

8) You cannot delete a directory tree in one go.

9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.

I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2015-01-18 21:57:51 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
There's no...

UTF-8
asynchronous processing
floating point
unsigned integers
64-bit integers
binary data
objects
dictionaries
arrays
functions that return values
user-written lexical functions
support for menu-based and graphical-based user interfaces
JIT
compilation
embedding
debugging
DCL libraries
More specific error trapping than ON; let me catch specific errors.

etc...

Simon's command completion and command editing and command history, certainly.

Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2015-01-19 01:56:09 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
I guess I'm just in a particular mood tonight. Live with it.

:-)
Post by Stephen Hoffman
There's no...
UTF-8
Should be a VMS data type, or types
Definitely a needful thing
Post by Stephen Hoffman
asynchronous processing
Use Basic and ASTs
Post by Stephen Hoffman
floating point
Basic has it
Post by Stephen Hoffman
unsigned integers
Basic SHOULD have this
Post by Stephen Hoffman
64-bit integers
Basic has it
Post by Stephen Hoffman
binary data
Basic has it
Post by Stephen Hoffman
objects
Can you be specific, don't really understand
Post by Stephen Hoffman
dictionaries
Can you be specific, don't really understand
Post by Stephen Hoffman
arrays
Basic has it
Post by Stephen Hoffman
functions that return values
Basic has it
Post by Stephen Hoffman
user-written lexical functions
Basic has it
Post by Stephen Hoffman
support for menu-based and graphical-based user interfaces
Hmmmmm ........ I've got a menu application ...
Post by Stephen Hoffman
JIT
Basic has it
Post by Stephen Hoffman
compilation
Basic has it
Post by Stephen Hoffman
embedding
Can you be specific, don't really understand
Post by Stephen Hoffman
debugging
Basic has it
Post by Stephen Hoffman
DCL libraries
Basic has object and run time libraries
Post by Stephen Hoffman
More specific error trapping than ON; let me catch specific errors.
Basic has it
Post by Stephen Hoffman
etc...
Simon's command completion and command editing and command history, certainly.
Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
Are we having fun yet?
Craig A. Berry
2015-01-19 04:25:01 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
There's no...
UTF-8
asynchronous processing
floating point
unsigned integers
64-bit integers
binary data
objects
dictionaries
arrays
functions that return values
user-written lexical functions
support for menu-based and graphical-based user interfaces
JIT
compilation
embedding
debugging
DCL libraries
More specific error trapping than ON; let me catch specific errors.
etc...
Simon's command completion and command editing and command history, certainly.
Then there are parts of DCL which are seldom understood or easily misunderstood
scoping
quoting and double-quoting and the two-phase substitution processing
f$getqui
These are mostly good things to add, but very few of them would require
incompatible changes. Quite a few nice-to-have features, such as
character set conversion facilities or regular expressions, just need
new lexicals.

DCL is usually good about throwing a syntax error if it doesn't
understand something, and anything that's a syntax error now is fertile
ground for new features or notations. For example, curly braces don't
really do anything now that I can recall, so that delimiter could be
used for object or hash notation.

New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.

It would be a gigantic mistake to ditch DCL rather than enhancing it.
Microsoft had to start something entirely new with PowerShell because
there was no hope of making DOS into a real language. DCL is infinitely
superior to DOS, even if it has some warts. Also, Microsoft could afford
to invest a ton in PowerShell and if it hadn't worked out, they could
have spent another fortune having another team implement something else.
VSI can't do that.

I spend a lot of my free time keeping Perl running on VMS, and I do
think Perl, Python, and bash should be available on the base
distribution, but for all its shortcomings I think DCL is too good to
give up on.
Simon Clubley
2015-01-19 20:40:16 UTC
Permalink
Post by Craig A. Berry
New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.
I'm not seeing that as a real problem.

For example, if the lexicals start returning objects containing a set
of items instead of individual items as is currently done with the
lexicals, there's no reason why the new lexicals could not be placed in
their own package and referenced as such.

The fact the new lexicals will be returning entire objects instead of
individual strings means the calling sequence is going to change anyway.

For example, consider f$parse().

You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.

For example:

$ ! Old way
$ oname = f$parse(fname, , ,"NAME")
$ odir = f$parse(fname, , ,"DIRECTORY")
$ otype = f$parse(fname, , ,"TYPE")
$ write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
$
$ ! New way
$ oparse = sys.o$parse(fname)
$ write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
" type = ", oparse.type

oparse would have a type of object (and a specific type of object).
However the variables within the oparse object would be of type string
and could be used as normal.

Furthermore, one could move objects around by assigning them to other
variables and the new variable would take on the type of the object
just as happens at the moment when a variable which was originally an
integer has a string assigned to it.

The above behaviour is totally compatible with existing DCL code and
you can mix-and-match old style and new style code in the same command
procedure.

In the above example, there's no reason why you could not say

$ if oname .nes. oparse.name
$ then
$ ! Do something
$ endif

as you would be comparing two string variables. The fact one of them
is contained within an object simply does not matter.

You may not be able to use string/integer operator names within objects
in order to avoid ambiguity when parsing multi-level objects, but apart
from that, I don't see any problem with the above approach.

It would also be nice to be able to write something like:

$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for

That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bob Gezelter
2015-01-19 20:50:11 UTC
Permalink
Post by Simon Clubley
Post by Craig A. Berry
New data types and automatic data conversions would be difficult to do
compatibly, but if the new types were all objects and there were a
distinct object notation, it might be possible to eliminate any ambiguities.
I'm not seeing that as a real problem.
For example, if the lexicals start returning objects containing a set
of items instead of individual items as is currently done with the
lexicals, there's no reason why the new lexicals could not be placed in
their own package and referenced as such.
The fact the new lexicals will be returning entire objects instead of
individual strings means the calling sequence is going to change anyway.
For example, consider f$parse().
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
$ ! Old way
$ oname = f$parse(fname, , ,"NAME")
$ odir = f$parse(fname, , ,"DIRECTORY")
$ otype = f$parse(fname, , ,"TYPE")
$ write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
$
$ ! New way
$ oparse = sys.o$parse(fname)
$ write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
" type = ", oparse.type
oparse would have a type of object (and a specific type of object).
However the variables within the oparse object would be of type string
and could be used as normal.
Furthermore, one could move objects around by assigning them to other
variables and the new variable would take on the type of the object
just as happens at the moment when a variable which was originally an
integer has a string assigned to it.
The above behaviour is totally compatible with existing DCL code and
you can mix-and-match old style and new style code in the same command
procedure.
In the above example, there's no reason why you could not say
$ if oname .nes. oparse.name
$ then
$ ! Do something
$ endif
as you would be comparing two string variables. The fact one of them
is contained within an object simply does not matter.
You may not be able to use string/integer operator names within objects
in order to avoid ambiguity when parsing multi-level objects, but apart
from that, I don't see any problem with the above approach.
$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for
That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.
Simon.
--
Microsoft: Bringing you 1980s technology to a 21st century world
Gentlemen,

Actually, I would rather NOT debate a new or better language. Instead, I would be looking towards documenting and cleaning up the interface between the command line interpreter (CLI) and base system. I suspect that the last thing needed is yet another scripting language.

Cleaning up the interface might provide a better option than a particular language.

There are many languages for which immediate execution modes exist or can be developed (e.g., JavaScript, Python, Ruby, BASIC). The LIB$ routines already underlie the lexical functions. Cleaning up/documenting the CLI interface would allow other languages to be used as CLIs.

The distinction between scripting and programming languages has long since become a distinction without a difference.

- Bob Gezelter, http://www.rlgsc.com
John Reagan
2015-01-19 21:38:16 UTC
Permalink
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls to F$PARSE? The overhead? You are writing in DCL after all...

And you want the lexical to populate all the fields even if you aren't going to use them? Isn't that more expensive? Imagine the overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields? Ugh.
Post by Simon Clubley
$ queue_list = sys.o$getqui(<whatever>)
$ for queue in queue_list
$ write sys$output "queue_name = ", queue.name
$ end for
That's a _lot_ cleaner than the current mess which is f$getqui()
especially when you start working on the entries within those queues
as well.
But probably slower...
Simon Clubley
2015-01-19 21:52:09 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
You would keep f$parse for compatibility with existing DCL code and
it would continue to return individual strings, but you could also
have a (say) sys package with a differently named f$parse returning an
object containing all the parsed fields in one go.
You mean like SYS$FILESCAN? What's your issue with multiple calls
to F$PARSE? The overhead? You are writing in DCL after all...
Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.
Post by John Reagan
And you want the lexical to populate all the fields even if you
aren't going to use them? Isn't that more expensive? Imagine the
overhead of collecting ALL the GETJPI fields or ALL the GETQUI fields?
Ugh.
As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed.

I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2015-01-18 23:25:53 UTC
Permalink
I feel that DCL mostly does what I expect quite OK,
that is running the day to day opertion routines.

Now, there *is* a gap between DCL and compiled tools.
You will probably still write your "true" applications
in some compiled language, but there is still a place
for tools in between, for one-of-a-time "fix" jobs
and similar.

15 years ago some people installed Perl to fill that gap.
Today some uses Python partly becuse it feels more modern
and partly becuse there is a quite good Python port for VMS.

Python isn't perfect, of course. There is the V2 vs. V3
problem and some doesn't like the forced indentation,
mostly a habit and the code get "forced readability".

There are some ports of other tools like LUA for VMS,
but I do not think anything comes close to Python when
looking at built-in VMS integration.
David Froble
2015-01-19 01:46:10 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
Do you mind if I'm an ass for a bit? I promise to be more reasonable at
the end.
Post by Simon Clubley
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
It has been explained in the past that the problem was this stuff was
implemented in the terminal driver. I'd suggest looking at a different
implementation, such as an application that could do the command line
length and buffer and history, and maybe running multiple copies. Yes,
it is a PITA.
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
See above for better implementation, not a patch on the terminal driver.
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same time.
Isn't that multiple sessions?

I also don't understand retaining the history.
Post by Simon Clubley
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
I still remember, with a grin, JF's idea of user name and password
completion.

:-)

:-)
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,

"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
"DCL is not a programming language".
"DCL is not a programming language".
"DCL is not a programming language".

But, there is GOTO ...
Post by Simon Clubley
3) No ability to add site specific lexicals.
Write your own library routines, and call them from a reasonable
language, such as Basic.
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
5) No regex support (this is also a UI issue).
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
"DCL is not a programming language".
"DCL is not a programming language".
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
But, you can have a command procedure to do so ...
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
We know I don't get out much, but when I have something to compare, I
move it to VMS to use DIFF there. Guess I'm missing something.

But yeah, I jump through hoops when I want to compare a bunch of source
programs. I share that pain.
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Simon.
Ok, sorry, got carried away with the "paste" ...

:-)

DEC used to do this thing, they used to let people vote on desired
enhancements, and then choose projects based upon demand. This might be
a good practice to continue. Doing so on the internet, rather than a
couple times a year at DECUS.

Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.

Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
JF Mezei
2015-01-19 03:31:43 UTC
Permalink
Post by David Froble
I also don't understand retaining the history.
I find it useful. Start a new session and you have command recall
available from previous session.
Post by David Froble
I still remember, with a grin, JF's idea of user name and password
completion.
Must be a good suggestion if you remember it ! :-)
Simon Clubley
2015-01-19 21:11:00 UTC
Permalink
Post by David Froble
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
I don't know why anyone would want 2 script processors at the same time.
Isn't that multiple sessions?
Yes. Different terminal sessions running in multiple terminal windows at
the same time.
Post by David Froble
I also don't understand retaining the history.
It acts as a cache of your commonly used commands which are available
for immediate recall across multiple sessions.
Post by David Froble
Post by Simon Clubley
1) No structured programming constructs such as (for example) while
loops.
Learn the mantra,
"DCL is not a programming language".
Yes it is.

It's used to control the startup and operation of VMS.

It's used to control user created batch jobs and interactive command
procedures.

It doesn't matter that it's used in interpreted scripting environments
instead of compiled executables; it's still a programming language and
one which is very dated by today's standards.
Post by David Froble
Through all of what you wrote, there is this "feeling" that you are
writing from the perspective of a workstation, not a "server". Things
such the command line recall and length just don't come up when you're
running programs. As a software person, I can appreciate what you're
asking for. But from a production perspective, I don't see that it's
relavent.
Not saying you should not have all that you listed. But, I'd like you
to discuss them not from a development and / or management station, but
from a "running production" perspective.
These _are_ from a running production perspective (or don't you have
long or frequently used command lines as well as user written command
procedures in production use ?)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Craig A. Berry
2015-01-19 03:30:11 UTC
Permalink
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
DELETE/TREE was added in 8.4 but DFU DELETE/TREE is much better and has
been available for some time. Unfortunately the latter requires
privileges over and above ownership of the directory tree involved.
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
JF Mezei
2015-01-19 03:39:06 UTC
Permalink
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
I am not too concerned about these problems because they can easily be
solved with relatively minor updates to the commands themselves (and as
was pointed out delete/tree was added).

Consider 8.3 when Guy Peleg managed to add a lot of neat features to
DCL, Backup and others stuff.

The big question what what needs to change at the lower "core" level, of
any.

Shoudl DCL continue to be updated and fast forward to 21st century, or
should it be frozen and something new brought in ? I think Hoff has
asked those questions fairly elegantly.
Matthew H McKenzie
2015-01-19 07:29:49 UTC
Permalink
He has,

I think a port of python would probably go a long way towards resolving
these.
- abstracting too, the system calls in wrappers.
- leaving DCL mostly as it is, preserving snippet value.
- reducing the need for C and COBOL code as well.
Post by JF Mezei
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
I am not too concerned about these problems because they can easily be
solved with relatively minor updates to the commands themselves (and as
was pointed out delete/tree was added).
Consider 8.3 when Guy Peleg managed to add a lot of neat features to
DCL, Backup and others stuff.
The big question what what needs to change at the lower "core" level, of
any.
Shoudl DCL continue to be updated and fast forward to 21st century, or
should it be frozen and something new brought in ? I think Hoff has
asked those questions fairly elegantly.
Jan-Erik Soderholm
2015-01-19 12:49:25 UTC
Permalink
Post by Matthew H McKenzie
He has,
I think a port of python would probably go a long way towards resolving
these.
Available today.
http://www.vmspython.org/doku.php
Post by Matthew H McKenzie
- abstracting too, the system calls in wrappers.
Available today (if you are still talkning about Python).

Here is what the interface to SYSQUI looks like.
This lists all queues, all jobs in the queues
and the filename of all files in those jobs:

------------------------------------------------
from vms import queues
for q in queues.all_queues():
print "Queue: ", q.queue_name
for j in q.jobs():
print " Job: ", j.job_name
for f in j.files:
print " Name: ", f.specification
------------------------------------------------

Thats all.

You can of course get all other information and
also "do" things like deleting jobs.
Post by Matthew H McKenzie
- leaving DCL mostly as it is, preserving snippet value.
Yes, DCL does what it does quite OK today...


Jan-Erik.
c***@gmail.com
2015-01-19 14:10:55 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
We've never found any other OS' differencing engine with as usable output as VMS'.
There was a discussion about this a while back in c.o.v, and how the approach
taken by the VMS engine differs from that used by gnu.

But we've taken to using third party products on Windows and Mac, and they do a
nice job with a nice GUI interface. Right now BeyondCompare (Windows or Mac) is
one we really like and any future VMS work on differencing should look at features
in tools such as that. Lot of our Windowsonly users are using CodeDiff, but it writes
HTML with \ in the URLs.
Simon Clubley
2015-01-19 19:50:01 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
DELETE/TREE was added in 8.4 but DFU DELETE/TREE is much better and has
been available for some time. Unfortunately the latter requires
privileges over and above ownership of the directory tree involved.
Interesting; I didn't know that. :-)

I have not used 8.4 yet (and I am not likely to in the near future as
my current job ends in a couple of months) so I have not had the
opportunity to be exposed to this new qualifier.
Post by Craig A. Berry
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
Agreed. That's why I've been using GNU diff on VMS quite a lot for the
last fifteen years or so.
I've used GNU diff on VMS as well and it's capabilities could well do
with being added into the VMS native differences program IMHO.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Phillip Helbig (undress to reply)
2015-01-19 21:32:16 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
This isn't really a DCL issue, though, is it?
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
Yes you can. What version of VMS do you have? Try HELP.
V***@SendSpamHere.ORG
2015-01-19 22:08:27 UTC
Permalink
Post by Simon Clubley
I think it's time once again to build a list of DCL's flaws now that
VSI are around. Don't forget however that DCL is both a scripting
language and a UI. My initial list is below.
1) You can't edit commands across line boundaries. Even Windows CLIs
can do this.
Yes and no. The default behaviour is an issue with the terminal driver;
not DCL.
Post by Simon Clubley
2) You can't save your command history automatically, bash style, and
have it restored automatically at the next session.
A simple hack.
Post by Simon Clubley
With bash, you can have multiple shells active at the same time and
only the commands entered during a specific session will be added to
the history file when that session exits even though the shell has the
full command history from previous shells available (up to a user
defined limit).
Any implementation needs to think about the multiple shells active at
the same time issue before proposing a solution to this.
3) No filename completion. This is _really_ annoying especially since
it even exists (after a fashion) in the command prompt on current
versions of Windows.
I just double-click MB1 and click MB2. ;)
Post by Simon Clubley
4) No elegant incremental search through the command history (bash
Ctrl-R style).
Another simple hack.
Post by Simon Clubley
1) No structured programming constructs such as (for example) while
loops.
That could, IMO, be easily added.
Post by Simon Clubley
2) No ability to iterate cleanly over a list of items (bash "for i in"
style)
See: F$element()
Post by Simon Clubley
3) No ability to add site specific lexicals.
I once hacked such a beast.
Post by Simon Clubley
4) The output from the lexicals should be an immutable collection of
objects which you can then iterate over without having to worry about
the state changing during iteration.
Why? Use a programming language if this is important.
Post by Simon Clubley
5) No regex support (this is also a UI issue).
Perhaps, useful. I loathe the cryptographic nature of regex in unix-born
or C-born lingos.
Post by Simon Clubley
6) Pathetic limits on the maximum size of symbol contents.
7) No array or collection of objects support. (In addition to normal
arrays, DCL should also support associative arrays.)
Why? Use a programming language if this is important.
Post by Simon Clubley
DCL has absolutely no way to group related variables together in the
way you can with structs in C or objects in other languages.
Use a programming language if this is important.
Post by Simon Clubley
8) You cannot delete a directory tree in one go.
$ HELP DELETE file /TREE
Post by Simon Clubley
9) differences is very limited by today's standards. The functionality
in GNU diff, with (for example) it's ability to find differences in
whole directory trees and produce patch files for the differences
in an entire tree, should be the minimum baseline for functionality
these days.
I also find the unified diff output to be a _lot_ more readable than
the output from the DCL differences command.
I prefer DIFFERENCE/PARALLEL so don't muck with my DIFFs! ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Loading...