[Info-vax] DCL and scripting

[Arne Vajhøj]

On 12/12/2018 9:47 AM, John E. Malmberg wrote:
> 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.

I think many agrees with that.

:-)

> On 12/11/2018 10:30 AM, Stephen Hoffman wrote:
>> 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.

I have not used PS for anything serious.

But I do know a few things about it.

First one should note that PS is .NET based, so no surprise that
PS and COM can give some "interesting" problems.

Second an important benefit of PS is the ability to extend it
with cmdlets written in C# (or another .NET language). So even
though it out-of-the-box may have some limitations, then
its extendability provides some options.

Arne