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