[Info-vax] 64 bit DCL ?

[Stephen Hoffman]

On 2015-01-17 02:17:20 +0000, JF Mezei said:

> Just so I can understand the role of DCL.exe : (so this is all conceptually)

The Internals and Data Structures Manual (IDSM) will help with some 
details of the DCL command line interpreter (CLI), and CLIs in general.

What's the goal?   Leading with an implementation — and with not a goal 
and a design — is how technical debt is often accrued, after all.

Using bash or similar as a VMS CLI?  That's been done before, as part 
of the DEC/shell CLI.

As for the SHOW.EXE wrapper, that seems like a very nice path deep into 
a two-level shrubbery of technical debt.

Probably easier to implement a "dcl" verb within the command 
interpreter you're working on, as was done in various environments.  
Certainly using the existing cli$ routines and the sys$cli system 
service to allow an executable image to communicate with the current 
CLI — whichever CLI is present in the process — is also entirely 
feasible, and it's also conceivably feasible to use the variant command 
line definition (CLD) command compiler SET COMMAND to convert a CLD 
file into another form, but then the SHOW.EXE executable and most other 
DCL executables don't really work like a bash command would, you'd need 
to figure out how to deal with arcana such as the SHOW$DEBUG logical 
name, and then there's that nagging issue around how bash commands 
parse that stuff, and VMS doesn't traditionally want to commit to a 
specific command output format; parsing command output was usually 
considered unsupported.

Then there's that most shell scripts would expect to use the at(1) 
batch command here and not some DCL-ish command syntax.

It wouldn't surprise me that there's no clean mapping between some of 
what a CLD can support, and what bash expects, too.

Beyond the at(1) batch commands, I might even expect to query a queue 
device such as a Plan 9-ish /vms/qmgr or /qmgr or QMG0: to get the 
queue data, too.

As for passing data around and for PIPE-like processing between CLIs in 
a parent and a subprocess, DCL uses a mailbox to communicate DCL 
context from the parent process to the spawned subprocess, and it's 
certainly possible for some other language to mimic that processing 
when passing data into a DCL CLI subprocess.

If your goal is a different CLI, then bash with DCL wrappers is 
probably going to cause as many problems as it solves.  If not more.   
You're going to end up supporting the odd-ball syntax, and DCL wasn't 
ever intended to have its output parsed, and parsing command output is 
fundamental to many shell scripts.   Bash never really figured out how 
to pass data objects around without embedding your own marshalling and 
unmarshalling, either — PowerShell can do that, as well as various 
other niceties.    Unlike DCL and bash, PowerShell, Lua and some other 
interpreters can be embedded directly into an application, too.

Now if your goal is a new and different command interpreter, then 
starting with bash doesn't seem all that sensible.  Unless your goal is 
recreating almost-bash, of course.  If you're going to design and build 
a new command interpreter, then I'd hope the goal is to do at least as 
well as bash and PowerShell, and preferably better in at least some 
areas.  Because if I want bash, then I'm probably not really going to 
be looking for the "show queue -a -this -that hello" syntax.  Now 
getting objects directly from devices (akin to /proc on Linux, whether 
via /vms/qmgr or QMG0: device driver or whatever), now that's more 
interesting.

Related: <http://en.wikipedia.org/wiki/Windows_PowerShell>

-- 
Pure Personal Opinion | HoffmanLabs LLC