home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 262,429 of 264,096   
   Stephen Hoffman to Dan Cross   
   Re: Local Versus Global Command Options   
   21 Feb 25 16:42:56   
   
   From: seaohveh@hoffmanlabs.invalid   
      
   On 2025-02-19 21:53:17 +0000, Dan Cross said:   
      
   > Be that as it may, the person you are responding to, and that you   
   > regularly interact with at length, has shown repeatedly that he is not   
   > acting in good faith.   
   >   
   > Technical answers to technical questions, and even spirited debates   
   > with vigorous disagreement, are all well and good as long as all   
   > parties are at least attempting to honor a collegial spirit of   
   > cooperation.  But in this case, as with most cases involving Lawrence,   
   > the base conditions in which to have the discussion are simply not met.   
   >   
   > This is the sort of thing that ought to be in an FAQ.   
      
   Is it feasible for DCL?  Sure. Though it'll likely involve passing some   
   of the syntax to lib$table_parse or ilk for parsing, as do a few DCL   
   commands I've encountered (or have written) over the years.  Or can go   
   directly to lib$table_parse for the rest of the command, for that   
   matter.   
      
   There've also been a few discussions about providing getopt_long()-like   
   support with DCL parsing "underneath" the classic C parsing, and work   
   to overhaul the DCL CLD APIs, but the results of that design and   
   development effort never seemed compelling.   
      
   There are commands around that have four or more interfaces, too:   
   getopt() or getopt_long() foreign command, SET COMMAND and DCL   
   invocation, RUN with prompting, and callable API. Adding a DCL parsing   
   loop inside the app is feasible, too. (There's at least one in OpenVMS   
   itself with the first four.)   
      
   The whole area of command parsing, command options and syntax, saving   
   and maintaining app-related preferences data storage and management,   
   and related details within OpenVMS are all disjoint and ad-hoc at best,   
   and as has been discussed before.   
      
   The size of the audience for DCL command syntax for FFmpeg is also   
   approximately zero. A similar discussion and realization arose with the   
   IP network diagnostic tool command syntax. The folks using those tools   
   expected the syntax they expected, while very few sought  out the DCL   
   syntax.   
      
   To Dan's point quoted above: Will the OP learn anything from this   
   thread? Probably not. That seems about as likely as re-hosting OpenVMS   
   onto the Linux kernel, as the OP had repeatedly proposed.   
      
      
      
   --   
   Pure Personal Opinion | HoffmanLabs LLC   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca