[Info-vax] Unix tools on VMS, was: Re: September 6, 2016 - new Roadmap and State of the Port updates now on VSI website

[David Froble]

Stephen Hoffman wrote:
> On 2016-09-11 12:18:10 +0000, David Froble said:
> 
>> Simon Clubley wrote:
>>>
>>> Really simple example: GNU diff is vastly superior to the VMS version.
>>
>> Never having used it, I'll have to take your word for this ....
> 
> GNU and BSD diff tools are easily better, yes.
> 
> bash has some severe ugly, it's cryptic, and it can be wildly 
> inconsistent, but it and the capabilities of the Unix command tools are 
> generally superior to what are available on OpenVMS via DCL and the DCL 
> utilities.
> 
> Not that "''DCL'" syntax &is always 'entirely' clear to new users, 
> "either."   DCL is definitely simpler, it's more typing, but it's 
> unfortunately also certainly not gotten around to dealing with regular 
> expressions or pipes or functions at all well, nor limitations around 
> dealing with (no metadata, untagged, always-assumed ASCII or maybe MCS) 
> text.
> 
> bash has limits here too, but there are bash ports that deal with UTF-8.

So nothing is perfect.  Differing strengths and weaknesses.

>>> With GNU diff, as well as having a much more readable unified diff 
>>> output format, you can also compare differences between two directory 
>>> trees.
>>
>> Now, what was I writing?  Oh, yes, implement on VMS.  I've got a 
>> simple tool I call COMPARE that does just that, on VMS, compare 
>> differences in two directories.  Most likely not the same, and I'll 
>> admit the tool could be greatly improved.  Works for me.
> 
> Yes, we all have those tools.    Which work for us.   Which we all 
> implement.   
> http://www.digiater.nl/openvms/freeware/v80/hoffman_examples/diff_directories.com 
>   Which should tell you a little something about the adequacy of the 
> base operating system for its appointed tasks, too.

Ok, correct me if I'm wrong, but many of those *ix tools began as someone's 
individual work.  Where have I seen this before?  Perhaps DECUS?

Now, why is such on *ix good, and the same thing on VMS bad?  This is part of 
the lack of understanding I have.  I tend to see a double standard.

Or perhaps it might be the disinclination of the OS owner to adopt such 
independently developed tools and subsequently support them?

>>> Second example: bash offers all kinds of UI features not present in 
>>> DCL or which have been implemented in a clumsy manner in DCL (such as 
>>> searching for previous commands).
>>
>> Ok, taking your word for this also.
>>
>> But, how does any of what you've written justify blaming VMS for not 
>> being able to just compile, link, and run the *ix tools?  That's my 
>> issue.  And my question.
>>
>> If you want the tools on VMS, then feel free to implement them there.  
>> That's how they got on *ix, right?  Somebody did some work.
> 
> With OpenVMS, various C APIs either don't work (e.g. SSIO), or are 
> missing or down-revision (q.v. JR's "whiteboard"), or are less than 
> integrated (q.v. TLS, PKE).

And so, not being familiar with *ix, you lead me to believe that in that 
environment it's not the OS that provides services, it's the C language?

If so, well, that just isn't, or at least should not be, the VMS way. 
Capabilities should be available to all languages on VMS.  Ok, now I guess we 
are getting to my concerns.

Personally, I'd think byte range locking, or whatever you want to call it, could 
be a useful tool.  If implemented on VMS, then it should not be limited to only 
one language, but available as an OS service.  Gets me remembering HP's 
statement that OpenSSL can only be used from C.

>   So we all go off and implement the pieces 
> and parts, or hack around them.    We then all have different ports or 
> different versions, and with different issues and vulnerabilities, 
> different maintenance scheduled and updates.   We end up with bugs and 
> misfeatures and such, too.    With the associated costs.

And that doesn't also happen on *ix?

> This isn't just C, either.   The same general problem holds for 
> application code written to newer other and newer compilers, too.    
> BASIC needs more than a little work to update it and overhaul it, and to 
> haul it past the 1980s.

It's not going to get that, if it is denied access to new capabilities.

>  Or to replace it with a different language that 
> works as well or better.    We have the limits of the older non-OO or 
> non-RT APIs, too.    But that's all fodder for another time.