First, backwards compatibility is a powerful force blocking possible improvement. I was using Sun OS and Solaris in nineties. Later I
looked at Solaris from 2007. In 2007 they shipped crappy '/bin/sh'
which had exactly the same problems as I remembered from my earlier
use. I suspect that it was bug-for-bug compatible with '/bin/sh'
which they shipped in 1984. And I suspect that if you get current
Solaris from Oracle, you will get the same crappy '/bin/sh'.
Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:
On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:
User written lexical functions, on the other hand, would be a real
bonus. There are, for one, still many parts of the operating system for
which you need to get information, and the only possible way to do it is >>> to parse some output (think of everything TCP/IP, for example), while
there is a callable interface available to get the info properly.
POSIXish shells seem to feel less need for such built-in extensions.
Is this a reflection on the ease of doing command substitutions in them,
vis-|a-vis DCL?
Some newer commands in the Linux world have the option to produce output
in JSON format, which also helps.
First, backwards compatibility is a powerful force blocking
possible improvement. I was using Sun OS and Solaris in
nineties. Later I looked at Solaris from 2007. In 2007
they shipped crappy '/bin/sh' which had exactly the same
problems as I remembered from my earlier use. I suspect
that it was bug-for-bug compatible with '/bin/sh' which
they shipped in 1984. And I suspect that if you get
current Solaris from Oracle, you will get the same crappy
'/bin/sh'.
The same forces that prevent improvments to '/bin/sh' work
for DCL, so chance of change here is very small.
Second, early Unix had relatively cheap process creation,
but some implementations (PDP-11 and 16-bit Xenix) had
thight limit on process size. So, there was preference
to using external commands for extentions. Unix provides
commands (and /proc filesystem in Linux) so that information
is available in textual form, meaning less need for
libraray API.
Third, Unix shell does not play as distingished role as
DCL in VMS, users can have different shells. There are
scripting languages and for programming shell is just
one of available scripting languages. Some scripting
languages (like Perl) give access to system calls, most
have FFI, so that one can call code in shared libraries.
On 12/5/25 7:41 PM, Arne Vajh|+j wrote:
A reimplementation of DCL in C (or another language, but C is
probably the current preference) is not a solution:
* risk only achieving 99.9% compatiblity instead of 100% compatibility
* expensive
Why not make a 2nd DCL, one that can live on the system in parallel with
the current DCL.-a Call it DCL64 since it would use 64-bit variables
instead of 32-bit.-a Which DCL a given process used would be specified in sysuaf or creprc (and, possibly, spawn).-a I'd would also like to see the following:
1. Variables can be integer, string, or floating-point.
2. Longer string lengths.
3. Enhance SYS$FAO to support floating-point.
4. New constructs (e.g. loops, arrays, etc.)
5. Lexicals match system functions.
-a-a (i.e., easy for the vendor to update lexicals to match new functions
-a-a-a or enhanced functionality and being able to specify multiple items
-a-a-a to return in a single lexical call)
6. An option to make pipe syntax the default without having to specify
the pipe command.
7. An option to make Set process/parse=extend and Set process/
token=extend as default.
8. Commands and switches match on 8 chars instead of 4.
-a-a (e.g., I'd like to see both open and openssl exist as separate commands).
9. No automatic upcasing the command line.-a (Internal parsing is case- insensitive).-a The idea is to reduce the need for lib$initialize in utilities written in C.
10. Otherwise, still DCL.
11. Perhaps even make the character set UTF-8 instead of ASCII.-a (Of course, then I'd be asking for a DECterm that used UTF-8).
Benefits:
No need to be 100% backwards compatible.-a Make it as backwards
compatible as possible but the edge cases that make it difficult to
rewrite DCL in a HLL wouldn't apply since the original DCL is still
there to handle them.
On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:
User written lexical functions, on the other hand, would be a real
bonus. There are, for one, still many parts of the operating system for
which you need to get information, and the only possible way to do it is
to parse some output (think of everything TCP/IP, for example), while
there is a callable interface available to get the info properly.
POSIXish shells seem to feel less need for such built-in extensions.
Is this a reflection on the ease of doing command substitutions in them, vis-|a-vis DCL?
On Sat, 6 Dec 2025 18:46:52 -0500, Arne Vajh|+j wrote:
PS is *the* shell for Windows admins, but has it caught on with Linux
admins?
No. And judging from some of the struggles Windows users are having with
it, it may not be that well-supported on Windows now, either.
BTW, I have never liked PS - it just doesn't appear logical to me, but
that is just my personal opinion.
I have this feeling that more and more Windows diehards (inside and
outside Microsoft) are simply installing WSL2 and using the Linux command line instead.
I will grant you that it is annoying to have to assume the subset
of behavior defined by 7th Edition research Unix for "portable"
shell scripts, and increasingly even that is tenuous on Linux systems.
Ubuntu's replacement of classic sh by the not-entirely-compatible
dash was a particular low point there.
On 12/13/2025 8:41 PM, Lawrence DrCOOliveiro wrote:
I have this feeling that more and more Windows diehards (inside and
outside Microsoft) are simply installing WSL2 and using the Linux
command line instead.
Not likely.
As it would be practically useless for Windows admin tasks.
On Mon, 15 Dec 2025 11:59:51 -0500, Arne Vajh|+j wrote:
On 12/13/2025 8:41 PM, Lawrence DrCOOliveiro wrote:
I have this feeling that more and more Windows diehards (inside and
outside Microsoft) are simply installing WSL2 and using the Linux
command line instead.
Not likely.
As it would be practically useless for Windows admin tasks.
Most of those use point-and-click anyway. Or this new rCLAgentic AIrCY
thing.
On 12/15/2025 6:01 PM, Lawrence DrCOOliveiro wrote:
On Mon, 15 Dec 2025 11:59:51 -0500, Arne Vajh|+j wrote:
On 12/13/2025 8:41 PM, Lawrence DrCOOliveiro wrote:
I have this feeling that more and more Windows diehards (inside and
outside Microsoft) are simply installing WSL2 and using the Linux
command line instead.
Not likely.
As it would be practically useless for Windows admin tasks.
Most of those use point-and-click anyway. Or this new rCLAgentic AIrCY
thing.
No.
The normal end users like GUI, but the serious Windows admins script a
lot.
And today that is mostly PS.
[...] But with people using scripting
languages to process massive vectors to train LLM models, it all seems
pretty puny.
On Mon, 15 Dec 2025 19:28:42 -0500, Arne Vajhoj wrote:
On 12/15/2025 6:01 PM, Lawrence D?Oliveiro wrote:
Most of those use point-and-click anyway. Or this new ?Agentic AI?
thing.
No.
The normal end users like GUI, but the serious Windows admins script a
lot.
And today that is mostly PS.
Somehow I doubt that. Remember, Microsoft spent years, decades,
conditioning its users to be allergic to the command line.
Then they did an about-face and introduced PowerShell. But something tells me that has not been as big a success as some might have hoped.
In article <10h3upk$3f20l$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
[...] But with people using scripting
languages to process massive vectors to train LLM models, it all seems
pretty puny.
This is a good point, but, I sometimes wonder if, perhaps, we
need to recalibrate what we mean when we say, "scripting
language." I imagine that you are referring to Python here, as
that seems to be the thing that the kids are all hip on these
days when it comes to model training and such-like, but I think
it's fair to say that that language has grown far beyond
traditional "scripting" use.
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant, and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
There is, evidently, a need (or at least desire) for a really
good interpreted language to script various system management
tasks; I gather folks feel that DCL is a bit long in the tooth
and insufficient for that. As I mentioned before, I feel like
that is qualitatively different than using DCL as an interactive
CLI; perhaps the solution here is just to build out a really
nice set of officially supported modules for, say, Python (or a
similar suitable language) and call it a day.
But there is an important category of script that starts off as one
long command, gets split into two or more commands, wrapped in a
loop, parameterized for different inputs, put in a subroutine, and
has features added like e-mailing the output to a distribution list.
Now you've got a program, and there is no obvious point in that
process where it's free or easy to switch languages.
I work in a big-ish Windows environment. GUI is used when necessary,
and everything else is scripted. With PS. I'm a network engineer, so
I use WSL2 and Linux VMs, but I don't really manage anything
Windows.
It is well-received amongst the Windows admins I'm surrounded by.
Nobody is saying they wish they could just clicky-click several
hundred times to do something that could go in a for loop. Most of
our Windows VMs don't even have a GUI installed (datacenter
edition).
As to Arne's earlier question of PS adoption in Linux... Hell NO. PS
runs counter to how *nix people think. It is bloated, excruciatingly
verbose, and its "everything's an object" model breaks pipelining in
the *nix paradigm. This doesn't even address the religious
objections. No thank you.
On 12/16/25 8:05 AM, Dan Cross wrote:
There is, evidently, a need (or at least desire) for a really
good interpreted language to script various system management
tasks; I gather folks feel that DCL is a bit long in the tooth
and insufficient for that.-a As I mentioned before, I feel like
that is qualitatively different than using DCL as an interactive
CLI; perhaps the solution here is just to build out a really
nice set of officially supported modules for, say, Python (or a
similar suitable language) and call it a day.
Python, Perl, and Lua all exist. Probably all could use additional work
for VMS-specific administrative tasks.-a Not sure the state of Ruby,
but
there is JRuby.
-a And at least a couple of other JVM-based scripting
options.
In article <10h3upk$3f20l$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
[...] But with people using scripting
languages to process massive vectors to train LLM models, it all seems
pretty puny.
This is a good point, but, I sometimes wonder if, perhaps, we
need to recalibrate what we mean when we say, "scripting
language." I imagine that you are referring to Python here, as
that seems to be the thing that the kids are all hip on these
days when it comes to model training and such-like, but I think
it's fair to say that that language has grown far beyond
traditional "scripting" use.
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant,
and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
But I really do like Groovy.
(and I have also written a lot about it and how to integrate
it with stuff on VMS)
On 12/16/2025 4:20 PM, Craig A. Berry wrote:
Not sure the state of Ruby,
I don't remember ever seeing MRI being ported to VMS.
On Tue, 16 Dec 2025 17:38:47 -0000 (UTC), Sam Thomas wrote:
I work in a big-ish Windows environment. GUI is used when necessary,
and everything else is scripted. With PS. I'm a network engineer, so
I use WSL2 and Linux VMs, but I don't really manage anything
Windows.
It is well-received amongst the Windows admins I'm surrounded by.
Nobody is saying they wish they could just clicky-click several
hundred times to do something that could go in a for loop. Most of
our Windows VMs don't even have a GUI installed (datacenter
edition).
As to Arne's earlier question of PS adoption in Linux... Hell NO. PS
runs counter to how *nix people think. It is bloated, excruciatingly
verbose, and its "everything's an object" model breaks pipelining in
the *nix paradigm. This doesn't even address the religious
objections. No thank you.
Let me see if I understand this: you have Windows-using colleagues who
are fond of PowerShell, while you would avoid it like the plague for *nix-based workflows.
These same colleagues are using the ?Datacenter edition? of Windows
Server. Worth pointing out that on-prem editions of Windows Server are
no longer getting quite the same love from Microsoft as the cloud
version. They are putting more effort into the cloud versions going
forward.
And the cloud is, of course, dominated by Linux. So the future of
Windows Server here, too, seems a bit limited.
On 12/16/25 8:05 AM, Dan Cross wrote:
In article <10h3upk$3f20l$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
[...] But with people using scripting
languages to process massive vectors to train LLM models, it all seems
pretty puny.
This is a good point, but, I sometimes wonder if, perhaps, we
need to recalibrate what we mean when we say, "scripting
language." I imagine that you are referring to Python here, as
that seems to be the thing that the kids are all hip on these
days when it comes to model training and such-like, but I think
it's fair to say that that language has grown far beyond
traditional "scripting" use.
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant, and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
Yes, of course. The scripting language will use a library (e.g., NumPy
or PyTorch) that exposes interfaces to various kinds of hardware >acceleration. But eventually there is processed data returned that gets >manipulated using ordinary constructs of the calling language.
My
comment arose in the context of DCL and Arne's suggestion of a new
wrapper language around DCL supplying new features; if any of those new >features tries to put more than 8192 bytes into a DCL symbol, that ain't >gonna work. And the same would be true for a new lexical function in
current DCL.
There is, evidently, a need (or at least desire) for a really
good interpreted language to script various system management
tasks; I gather folks feel that DCL is a bit long in the tooth
and insufficient for that. As I mentioned before, I feel like
that is qualitatively different than using DCL as an interactive
CLI; perhaps the solution here is just to build out a really
nice set of officially supported modules for, say, Python (or a
similar suitable language) and call it a day.
Python, Perl, and Lua all exist. Probably all could use additional work
for VMS-specific administrative tasks. Not sure the state of Ruby, but
there is JRuby. And at least a couple of other JVM-based scripting
options. So it's not like people are struggling between DCL and nothing.
In a way I agree with you that a good scripting language should not have
to be a good CLI and vice versa. But there is an important category of >script that starts off as one long command, gets split into two or more >commands, wrapped in a loop, parameterized for different inputs, put in
a subroutine, and has features added like e-mailing the output to a >distribution list. Now you've got a program, and there is no obvious
point in that process where it's free or easy to switch languages.
So while it's certainly not the only paradigm for writing scripts, it's
darn convenient to have a CLI that can also function as a decent
programming language. DCL would have fit the bill 30 years ago but now
not so much. Thus the discussion about enhancing or replacing DCL.
On 12/16/2025 9:05 AM, Dan Cross wrote:
In article <10h3upk$3f20l$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
[...] But with people using scripting
languages to process massive vectors to train LLM models, it all seems
pretty puny.
This is a good point, but, I sometimes wonder if, perhaps, we
need to recalibrate what we mean when we say, "scripting
language." I imagine that you are referring to Python here, as
that seems to be the thing that the kids are all hip on these
days when it comes to model training and such-like, but I think
it's fair to say that that language has grown far beyond
traditional "scripting" use.
ML, data processing and web has certainly passed admin
scripting in usage.
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant,
Most still use CPython.
None of the JIT implementations PyPy, GraalPy, Codon etc. has
really gotten traction.
(CPython 3.13+ actually comes with JIT, but it does not provide
the same speedup as PyPy and GraalPy can for those CPU intensive
cases that should never be done in Python)
Reason: fear of compatibility issues combined with the fact that
JIT usually does not matter.
Because:
and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
If CPython interpretation use 0.1-1.0% of total CPU usage
and native library execution use 99.0-99.9% of total CPU usage,
then ...
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Let me see if I understand this: you have Windows-using colleagues who
are fond of PowerShell, while you would avoid it like the plague for
*nix-based workflows.
Exactly. I assume if one wants to do scripting for Windows in a way
that has reasonable access to system API in a MS-supported way, there
is really only one choice.
In article <10ht0rk$34qt0$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 12/16/2025 9:05 AM, Dan Cross wrote:
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant,
Most still use CPython.
In your world of enterprise IT? Sure.
For numerical analysis? Directly in Python? No.
None of the JIT implementations PyPy, GraalPy, Codon etc. has
really gotten traction.
Reason: fear of compatibility issues combined with the fact that
JIT usually does not matter.
Because:
and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
If CPython interpretation use 0.1-1.0% of total CPU usage
and native library execution use 99.0-99.9% of total CPU usage,
then ...
See above. I'm talking about software that's doing numerical
analysis directly in Python, _not_ via FFI.
VBScript is:
* 30 years old
* deprecated and scheduled for removal in future Windows version
* only works with stuff that expose a COM API
On Wed, 17 Dec 2025 20:34:23 -0500, Arne Vajh|+j wrote:
VBScript is:
* 30 years old
* deprecated and scheduled for removal in future Windows version
* only works with stuff that expose a COM API
Are you talking about VBA?
On 12/16/2025 4:20 PM, Craig A. Berry wrote:
there is JRuby.
Yes.
It was ported to VMS in the past.
And a recent version can build code on PC and run code on VMS.
On 12/16/25 7:17 PM, Arne Vajh|+j wrote:
On 12/16/2025 4:20 PM, Craig A. Berry wrote:
-aNot sure the state of Ruby,
I don't remember ever seeing MRI being ported to VMS.
There was a port for Alpha 20 years ago:
https://xiaotuanzi.github.io/vmsruby/en/index.html
and an incomplete attempt to revive it 7 years ago:
https://github.com/bg/vmsruby/commits/master/
On 12/17/2025 11:57 AM, Dan Cross wrote:
In article <10ht0rk$34qt0$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:
On 12/16/2025 9:05 AM, Dan Cross wrote:
Python is interpreted, yes, but people who are using it to do
numerical analysis are often using the jit-compiled variant,
Most still use CPython.
In your world of enterprise IT? Sure.
For numerical analysis? Directly in Python? No.
None of the JIT implementations PyPy, GraalPy, Codon etc. has
really gotten traction.
Reason: fear of compatibility issues combined with the fact that
JIT usually does not matter.
Because:
and
more often the actual heavy computational lifting is being done
in a library that's exposed to Python via an FFI; so the actual
training code is in Fortran or C or some more traditional
compiled language.
If CPython interpretation use 0.1-1.0% of total CPU usage
and native library execution use 99.0-99.9% of total CPU usage,
then ...
See above. I'm talking about software that's doing numerical
analysis directly in Python, _not_ via FFI.
But practically nobody does that.
By using the high level packages (pandas, polars,
tensorflow, pytorch, numpy, scipy etc.) they can
do what they need to do using much higher level
constructs. No need to fiddle with LAPACK, BLAS,
matrix multiplication and inversion algorithms.
And on top of having to deal with much less
much higher level code they get way better
performance. The standard libraries are
much faster than custom Python code even
if it is JIT compiled.
Nobody want to write 5-10 times more lines
of code to run 5-10 times slower.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:37:42 |
| Calls: | 1,101 |
| Calls today: | 1 |
| Files: | 1,339 |
| Messages: | 276,095 |