[Info-vax] DCL and scripting

[John E. Malmberg]

TL;DR:

My vote would be to keep DCL the way it is, but to provide a good 
interactive Python shell for scripting that needs to be 64+ bit aware, 
with applications designed to handle serialized objects.

Imagine a SHOW DEVICE/TO_XML or /TO_YAML, etc command in VMS that could 
be invoked by by interactive python or other scripting languages.

Or a set foobar/from_xml command etc.

On 12/11/2018 10:30 AM, Stephen Hoffman wrote:
<snip>
> If you're not already looking at it or similar tools, interactive Python 
> (IPython) is a different approach with different design compromises and 
> different strengths, and focuses more toward scripting and data access: 
> https://ipython.org   For broader usage beyond Python and ilk, bash and 
> maybe fish or another interactive shell would be more commonly 
> encountered.   Microsoft also wishes PowerShell to be more widely 
> installed and more commonly available, though the success of that 
> open-sourcing effort remains to be seen.  For embedded scripting, prolly 
> Lua.

You keep mentioning PowerShell.

Have you done any significant coding in PowerShell?

Last time I was using it, I was spending a lot of time fixing scripts 
migrated to PowerShell to work around bugs and omissions in PowerShell.

There are massive easy ways to get your self into trouble.  There were 
significant gaps in the methods available for PowerShell to do simple 
basic operations used for system configuration and testing.

For example, operations on Powershell on mapped drive letters are 
incompatible with the DOS commands for doing the same thing and the 
PowerShell API is incomplete.  But there is also a COM interface to 
Powershell, and a COM interface to the mapped drive letters.

It of course is totally incompatible with the documented PowerShell API 
that should do the same function.  That they are incompatible is not 
documented of course.

Trying to use COM from PowerShell to fill in the gaps will result in 
days spent trying to figure out why the simple scripts for concept 
testing worked, but the long running tests that use them periodically 
randomly go into the weeds until you find out that is simply a 
feature/bug of the COM interface that can not be disabled, so everything 
with the drive mapping has to be converted back to DOS commands.

And it would help if someone at Microsoft would issue an edict that an 
application can not ship unless it can be installed and configured 
completely by PowerShell over a network connection.

For some reason Microsoft wants the only installation for several 
products to be through logged in user at the GUI for what they call the 
"Out of the Box" experience, where you have to play 20 questions to get 
the system setup.  And they seem to be actively trying to break any 
automated way of installing / configuring, even for testing purposes 
with each new release.

Is the grass greener there?

And what is the big feature of Powershell?  Passing objects.

How are the objects passed between independent applications?  They are 
serialized into a format like XML, or read in as XML.  I Seem to 
remember there being two options, one of them being XML.  You can 
specify them as options to the PowerShell commands.

Powershell aware applications can know in a pipeline they should default 
to write the output in XML or other serialized format, and the same for 
reading, but when run interactively to format the output in a human 
readable form.

That feature could be added to DCL commands and system utilities on VMS.

> It's utterly absurd that single-user mode is even remotely necessary for 
> basic system and cluster configuration maintenance work; for the 
> password-reset and for licensing-related "fun", and for user-startup 
> troubleshooting.  The world has moved past the use of command line for 
> these and similar maintenance tasks.

Linux still needs single user mode for recovery of a system where you do 
not know the root password, especially with the current practice of not 
setting a root password at all.

Almost all automatic and large scale system setup and maintenance is via 
the command line under the covers at the implementation point.  Remote 
GUI console access is way too expensive when a "small" collection of 
systems is in the middle double digits and a typical collection is much 
larger.

All debugging is over serial connections.

Linux is also covering a mass of backward [in]compatibility with layers 
of symbolic links and scripts in an attempt to hide distro differences.
Each application of course uses a different method.

Regards,
-John