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

[johnwallace4 at yahoo.co.uk]

On Sunday, 11 September 2016 16:47:21 UTC+1, David Froble  wrote:
> 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.

Top marks for the DECUS reference. Anybody here *not* know that
the Digital Equipment Computer Users Society formerly distributed
a variety of free tools intended for use with the various DEC
operating systems? Everything from games to utilities to compilers
and more.

After there was DECUS, and specifically for VMS, there was VMS
Freeware. 

Where's that these days? A quick search seems to led to a maze
of twisty little websites, all different. 

As you say, nothing is perfect. Needs vary. "Better" implies
a set of requirements. Low apparent cost, wide user base and
broad applicability is what some people wanted. There's been
Windows for that for the last couple of decades, though the 
five-year-out picture for MS is very unclear right now. Even
today, some people still want something outside what MS (or
even Linux) brings to the table.

A readily available VMS POSIX (or GNV) environment in principle
allows the people who find the underlying VMS characteristics
attractive to also benefit from some of the widely available
(one might even say "industry standard") tools. Without
necessarily losing the things that make VMS attractive in some
situations.

It's the same kind of logic that makes the Cygwin and MinGW 
fake-UNIX environments interesting to some people whose world
is mainly centred on Window boxes. Cygwin and MinGW aren't
perfect, but for many people they're good enough for some
important things. 

If only there was some kind of natural affinity between VMS
and NT, so that Cygwin and/or MinGW could be trivially ported
to VMS... ouch, I've gone a bit recursive, and worse, invoked
memories of Wollongong Eunice (a BSD4.x environment that ran,
like a dog, on VAX VMS in the V3.7 era)... sorrrrrry.