I've mentioned this before, but it would be really nice if DCL could
be enhanced to list all the possible candidates in the error message
if you enter an ambiguous keyword.

An increasing number of Linux utilities do this, and it's a very
nice feature.

Just a suggestion.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-27 18:57:23 +0000, Simon Clubley said:

> I've mentioned this before, but it would be really nice if DCL could be
> enhanced to list all the possible candidates in the error message if
> you enter an ambiguous keyword.

Pending any hypothetical and unannounced future changes to DCL, the
following might be useful for writing scripts^Wcommand procedures:
https://www.digiater.nl/openvms/freeware/v80/dcl_check/

> An increasing number of Linux utilities do this, and it's a very nice feature.

So too are command completion and filename completion capabilities.

DCL itself needs work. But that's been discussed before.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, 27 May 2021 at 19:57:25 UTC+1, Simon Clubley wrote:
> I've mentioned this before, but it would be really nice if DCL could
> be enhanced to list all the possible candidates in the error message
> if you enter an ambiguous keyword.

Not exactly what you want but you could try this:

$ SET COMMAND SYS$INPUT:
DEFINE VERB DCLSPELL
CLIROUTINE SETDCL
QUALIFIER SPELL_CHECK,NEGATABLE

$ DCLSPELL/SPELL

This will spot commands with typos (which will work if the typo is beyond the fourth character or so):

$ directofy
%DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC

The command still works, it just gives you this extra warning.

It catches qualifiers too:

$ dir/totalness
%DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC

I assume that the odd error messages are because it was either never finished or it was withdrawn/never released and has rotted since.

Antonio

On 5/27/2021 2:57 PM, Simon Clubley wrote:
> I've mentioned this before, but it would be really nice if DCL could
> be enhanced to list all the possible candidates in the error message
> if you enter an ambiguous keyword.

It must be in CLI$DCL_PARSE the magic should happen.

$ type pars1.cld
define verb pars
image "sys$disk:[]pars1.exe"
qualifier a1
qualifier a2
$ type pars1.pas
[inherit('sys$library:pascal$cli_routines')]
program pars1(input, output);

begin
if odd(cli$present('A1')) then writeln('A1') else writeln('not A1');
if odd(cli$present('A2')) then writeln('A2') else writeln('not A2');
end.
$ pas pars1
$ link pars1
$ set command pars1
$ pars
not A1
not A2
$ pars /a1
A1
not A2
$ pars /a
%DCL-W-ABKEYW, ambiguous qualifier or keyword - supply more characters
\A\
$ type pars2def.cld
module pars2def

define verb pars
qualifier a1
qualifier a2
$ type pars2.pas
[inherit('sys$library:pascal$lib_routines',
'sys$library:pascal$cli_routines')]
program pars1(input, output);

var
pars2def : [external] integer;

var
args : varying[255] of char;

begin
lib$get_foreign(args.body, 'Arguments: ', args.length);
if odd( cli$dcl_parse('pars ' + args, pars2def)) then begin
if odd(cli$present('A1')) then writeln('A1') else writeln('not A1');
if odd(cli$present('A2')) then writeln('A2') else writeln('not A2');
end;
end.
$ set command/object pars2def
$ pas pars2
$ link pars2 + pars2def
$ pars := $sys$disk:[]pars2
$ pars
not A1
not A2
$ pars /a1
A1
not A2
$ pars /a
%CLI-W-ABKEYW, ambiguous qualifier or keyword - supply more characters
\A\
%TRACE-W-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF800833F8
FFFFFFFF800833F8
DCL ?
?
0 FFFFFFFF800833F8
FFFFFFFF800833F8
DCL ?
?
0 FFFFFFFF800833F8
FFFFFFFF800833F8
pars2 0 0000000000020644
0000000000020644
pars2 PARS1 PARS1 12 000000000000012C
000000000002012C
0 FFFFFFFF80340964
FFFFFFFF80340964
%TRACE-I-END, end of TRACE stack dump

Arne

On 5/28/2021 9:57 AM, Arne Vajhøj wrote:
> On 5/27/2021 2:57 PM, Simon Clubley wrote:
>> I've mentioned this before, but it would be really nice if DCL could
>> be enhanced to list all the possible candidates in the error message
>> if you enter an ambiguous keyword.

Ya know, perhaps it already does?

Type HELP L to see what happens ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-05-28, arca...@gmail.com <arcarlini@gmail.com> wrote:
> On Thursday, 27 May 2021 at 19:57:25 UTC+1, Simon Clubley wrote:
>> I've mentioned this before, but it would be really nice if DCL could
>> be enhanced to list all the possible candidates in the error message
>> if you enter an ambiguous keyword.
>
> Not exactly what you want but you could try this:
>
> $ SET COMMAND SYS$INPUT:
> DEFINE VERB DCLSPELL
> CLIROUTINE SETDCL
> QUALIFIER SPELL_CHECK,NEGATABLE
>
> $ DCLSPELL/SPELL
>
> This will spot commands with typos (which will work if the typo is beyond the fourth character or so):
>
> $ directofy
> %DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC
>
> The command still works, it just gives you this extra warning.
>
> It catches qualifiers too:
>
> $ dir/totalness
> %DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC
>

Thanks for the info but DO. NOT. WANT. :-)

CLIs should either give an error or process the command line input unchanged.

One of the Linux shells does spell checking. I think its a terrible idea.

> I assume that the odd error messages are because it was either never finished or it was withdrawn/never released and has rotted since.
>

I wonder what other features might be hidden in DCL and if any
of them might be misused if someone was sufficiently creative ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-28, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/28/2021 9:57 AM, Arne Vajhøj wrote:
>> On 5/27/2021 2:57 PM, Simon Clubley wrote:
>>> I've mentioned this before, but it would be really nice if DCL could
>>> be enhanced to list all the possible candidates in the error message
>>> if you enter an ambiguous keyword.
>
> Ya know, perhaps it already does?
>
> Type HELP L to see what happens ...
>

And if you have installed a custom command which isn't in the help ?

As mentioned in the title, but not in the body, I'm also talking
about qualifiers as well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2021-05-28, arca...@gmail.com <arcarlini@gmail.com> wrote:
>>
>> Not exactly what you want but you could try this:
>>
>> $ SET COMMAND SYS$INPUT:
>> DEFINE VERB DCLSPELL
>> CLIROUTINE SETDCL
>> QUALIFIER SPELL_CHECK,NEGATABLE
>>
>> $ DCLSPELL/SPELL
>>
>> This will spot commands with typos (which will work if the typo is beyond the fourth character or so):
>>
>> $ directofy
>> %DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC
>>
>> The command still works, it just gives you this extra warning.
>>
>> It catches qualifiers too:
>>
>> $ dir/totalness
>> %DCL-I-MISSPELL, !AC !AD is misspelled, using !AC !AC!AC
>>
>
> Thanks for the info but DO. NOT. WANT. :-)
>
> CLIs should either give an error or process the command line input unchanged.
>

By extension, I should also point out I consider the 4-character thing
in DCL to be a terrible idea as well. :-)

> One of the Linux shells does spell checking. I think its a terrible idea.
>

Interesting about the above however. I had no idea it was there in DCL.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <843dce8d-94ff-45b7-9ab1-fa7a6441313en@googlegroups.com>,
"arca...@gmail.com" <arcarlini@gmail.com> writes:

> On Friday, 28 May 2021 at 20:06:14 UTC+1, Simon Clubley wrote:
>
> > By extension, I should also point out I consider the 4-character thing
> > in DCL to be a terrible idea as well. :-)
>
>
> There was an early release not that pointed out that the
> four-character thing specifically didn't apply to qualifiers that
> started with NO, those needed 6 characters.

But that doesn't apply to /NOTIFY. :-)

Den 2021-05-28 kl. 20:54, skrev Simon Clubley:

>
> One of the Linux shells does spell checking. I think its a terrible idea.

Like this?

$ sql shwo table
%SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
User tables in database with filename SQL$DATABASE
ARTLAB
DB_SUBMIT
DW101T
...
...

On 5/28/21 5:27 PM, Jan-Erik Söderholm wrote:
> Den 2021-05-28 kl. 20:54, skrev Simon Clubley:
>
>>
>> One of the Linux shells does spell checking. I think its a terrible idea.
>
> Like this?
>
> $ sql shwo table
> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
> User tables in database with filename SQL$DATABASE
>      ARTLAB
>      DB_SUBMIT
>      DW101T
>      ...
>      ...

Now *that's* a bad idea -- automatically substituting what the user said
with what s/he might have meant, although I suppose it can't do much
damage in a show command. I hope that that "drool database" doesn't get
automatically turned into "drop database" and there went the whole
enchilada.

Using a soundex algorithm or something similar to suggest what might
have been intended and permitting the user to try again with the
suggested alternative does make sense and is actually pretty common
these days. For example:

$ git lob
git: 'lob' is not a git command. See 'git --help'.

The most similar command is
log

On 5/28/2021 6:57 PM, Craig A. Berry wrote:
>
> On 5/28/21 5:27 PM, Jan-Erik Söderholm wrote:
>> Den 2021-05-28 kl. 20:54, skrev Simon Clubley:
>>
>>>
>>> One of the Linux shells does spell checking. I think its a terrible
>>> idea.
>>
>> Like this?
>>
>> $ sql shwo table
>> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
>> User tables in database with filename SQL$DATABASE
>> ARTLAB
>> DB_SUBMIT
>> DW101T
>> ...
>> ...
>
> Now *that's* a bad idea -- automatically substituting what the user said
> with what s/he might have meant, although I suppose it can't do much
> damage in a show command. I hope that that "drool database" doesn't get
> automatically turned into "drop database" and there went the whole
> enchilada.
>
> Using a soundex algorithm or something similar to suggest what might
> have been intended and permitting the user to try again with the
> suggested alternative does make sense and is actually pretty common
> these days. For example:
>
> $ git lob
> git: 'lob' is not a git command. See 'git --help'.
>
> The most similar command is
> log
>

Some of these ideas are almost as good as J.F. Meizi's idea about
password completion.

I think I'll stick with a bit more precision.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/28/2021 2:57 PM, Simon Clubley wrote:
> On 2021-05-28, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/28/2021 9:57 AM, Arne Vajhøj wrote:
>>> On 5/27/2021 2:57 PM, Simon Clubley wrote:
>>>> I've mentioned this before, but it would be really nice if DCL could
>>>> be enhanced to list all the possible candidates in the error message
>>>> if you enter an ambiguous keyword.
>>
>> Ya know, perhaps it already does?
>>
>> Type HELP L to see what happens ...
>>
>
> And if you have installed a custom command which isn't in the help ?
>
> As mentioned in the title, but not in the body, I'm also talking
> about qualifiers as well.
>
> Simon.
>

Either know what you want to do, and do it right, or, don't do it at all.

For someone as security conscious as you claim to be, you come up with
some questionable ideas.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Den 2021-05-29 kl. 00:57, skrev Craig A. Berry:
>
> On 5/28/21 5:27 PM, Jan-Erik Söderholm wrote:
>> Den 2021-05-28 kl. 20:54, skrev Simon Clubley:
>>
>>>
>>> One of the Linux shells does spell checking. I think its a terrible idea.
>>
>> Like this?
>>
>> $ sql shwo table
>> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
>> User tables in database with filename SQL$DATABASE
>>       ARTLAB
>>       DB_SUBMIT
>>       DW101T
>>       ...
>>       ...
>
> Now *that's* a bad idea -- automatically substituting what the user said
> with what s/he might have meant, although I suppose it can't do much
> damage in a show command.  I hope that that "drool database" doesn't get
> automatically turned into "drop database" and there went the whole
> enchilada.

SQL> crea datatase file test;
%SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
SQL>

SQL> drool datatase file test;
drool datatase file test;
^ %SQL-F-LOOK_FOR_STMT, Syntax error, looking for a valid SQL
statement, found DROOL instead
SQL>

SQL> drol datatase file test;
%SQL-I-SPELLCORR, identifier DROL replaced with DROP
%SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
SQL>

Have worked like this for 20+ years and I guess there have never
been any reason to change it.

Note that this is only in the interactive SQL interface, not when
using SQL in application code.

>
> Using a soundex algorithm or something similar to suggest what might
> have been intended and permitting the user to try again with the
> suggested alternative does make sense and is actually pretty common
> these days.  For example:
>
> $ git lob
> git: 'lob' is not a git command. See 'git --help'.
>
> The most similar command is
>     log
>

In article <s8t1sq$f2e$1@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> >>> One of the Linux shells does spell checking. I think its a terrible idea.
> >>
> >> Like this?
> >>
> >> $ sql shwo table
> >> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
> >> User tables in database with filename SQL$DATABASE
> >>       ARTLAB
> >>       DB_SUBMIT
> >>       DW101T
> >>       ...
> >>       ...
> >
> > Now *that's* a bad idea -- automatically substituting what the user said
> > with what s/he might have meant, although I suppose it can't do much
> > damage in a show command.

With SHOW, there is little danger.

> > I hope that that "drool database" doesn't get
> > automatically turned into "drop database" and there went the whole
> > enchilada.
>
> SQL> crea datatase file test;
> %SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
> SQL>
>
> SQL> drool datatase file test;
> drool datatase file test;
> ^
> %SQL-F-LOOK_FOR_STMT, Syntax error, looking for a valid SQL
> statement, found DROOL instead
> SQL>
>
>
> SQL> drol datatase file test;
> %SQL-I-SPELLCORR, identifier DROL replaced with DROP
> %SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
> SQL>
>
> Have worked like this for 20+ years and I guess there have never
> been any reason to change it.

Note also that, in Rdb, not only are INSERT, DELETE, UPDATE, and
(trivially) SELECT reversible via ROLLBACK, but also things like CREATE
TABLE and, yes, even DROP DATABASE. So even here there is not a huge
danger. Apparently the match has to be pretty close before it is
replaced, and there is little possibility that the intent was actually
something else.

> Note that this is only in the interactive SQL interface, not when
> using SQL in application code.

Right.

Den 2021-05-29 kl. 12:04, skrev Phillip Helbig (undress to reply):
> In article <s8t1sq$f2e$1@dont-email.me>,
> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
> writes:
>
>>>>> One of the Linux shells does spell checking. I think its a terrible idea.
>>>>
>>>> Like this?
>>>>
>>>> $ sql shwo table
>>>> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
>>>> User tables in database with filename SQL$DATABASE
>>>>       ARTLAB
>>>>       DB_SUBMIT
>>>>       DW101T
>>>>       ...
>>>>       ...
>>>
>>> Now *that's* a bad idea -- automatically substituting what the user said
>>> with what s/he might have meant, although I suppose it can't do much
>>> damage in a show command.
>
> With SHOW, there is little danger.
>
>>> I hope that that "drool database" doesn't get
>>> automatically turned into "drop database" and there went the whole
>>> enchilada.
>>
>> SQL> crea datatase file test;
>> %SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
>> SQL>
>>
>> SQL> drool datatase file test;
>> drool datatase file test;
>> ^
>> %SQL-F-LOOK_FOR_STMT, Syntax error, looking for a valid SQL
>> statement, found DROOL instead
>> SQL>
>>
>>
>> SQL> drol datatase file test;
>> %SQL-I-SPELLCORR, identifier DROL replaced with DROP
>> %SQL-I-SPELLCORR, identifier DATATASE replaced with DATABASE
>> SQL>
>>
>> Have worked like this for 20+ years and I guess there have never
>> been any reason to change it.
>
> Note also that, in Rdb, not only are INSERT, DELETE, UPDATE, and
> (trivially) SELECT reversible via ROLLBACK, but also things like CREATE
> TABLE and, yes, even DROP DATABASE. So even here there is not a huge
> danger. Apparently the match has to be pretty close before it is
> replaced, and there is little possibility that the intent was actually
> something else.
>

Yes, many things are possible to ROLLBACK, but dropping a database is
not one of those. FWIM...

>> Note that this is only in the interactive SQL interface, not when
>> using SQL in application code.
>
> Right.
>

In article <s8t3q3$f2e$2@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> Yes, many things are possible to ROLLBACK, but dropping a database is
> not one of those. FWIM...

Right. Other DROP statements yes, DROP DATABASE no. Basically,
anything within a transaction can be rolled back, but DROP and CREATE
DATABASE are not within a transaction.

Still, the probability that one writes DROL but doesn't mean DROP is
negligible.

In article <s8r9l6$2t9$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 5/28/2021 9:57 AM, Arne Vajhøj wrote:
>> On 5/27/2021 2:57 PM, Simon Clubley wrote:
>>> I've mentioned this before, but it would be really nice if DCL could
>>> be enhanced to list all the possible candidates in the error message
>>> if you enter an ambiguous keyword.
>
>Ya know, perhaps it already does?
>
>Type HELP L to see what happens ...

I wish I had Ehud's DCL procedure to speed up system disk backups so that
I could post it to this thread! :P

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2021-05-28, arca...@gmail.com <arcarlini@gmail.com> wrote:
> On Friday, 28 May 2021 at 19:57:04 UTC+1, Simon Clubley wrote:
>> And if you have installed a custom command which isn't in the help ?
>>
>> As mentioned in the title, but not in the body, I'm also talking
>> about qualifiers as well.
>> Simon.
>
> I assume (but haven't checked) that DCL builds up tables that cover all the commands that it knows about at that moment. So if you add a new command then it would get the benefit of this spell checking too.
>

I was referring to David's comment about using the online help.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-28, arca...@gmail.com <arcarlini@gmail.com> wrote:
> On Friday, 28 May 2021 at 20:06:14 UTC+1, Simon Clubley wrote:
>
>> By extension, I should also point out I consider the 4-character thing
>> in DCL to be a terrible idea as well. :-)
>
>
> There was an early release not that pointed out that the four-character thing specifically didn't apply to qualifiers that started with NO, those needed 6 characters.
>
> I think the motivating example was MOUNT/NOUN[LOAD] which became ambiguous when /UNIT appeared.
>
> I don't suppose 6 is much better than 4 for you though :-)
>

You assume correctly. :-)

If you enter the extra characters, and they are wrong, then the command
should be outright rejected.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-28, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2021-05-28 kl. 20:54, skrev Simon Clubley:
>
>>
>> One of the Linux shells does spell checking. I think its a terrible idea.
>
> Like this?
>
> $ sql shwo table
> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
> User tables in database with filename SQL$DATABASE
> ARTLAB
> DB_SUBMIT
> DW101T
> ...
> ...
>

Whoever thought it was acceptable to implement _that_ in a SQL utility
and in the way that it is shown above is an idiot.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-05-28, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Either know what you want to do, and do it right, or, don't do it at all.
>
> For someone as security conscious as you claim to be, you come up with
> some questionable ideas.
>

$ set response/mode=good_natured

Just because you haven't learnt any of those new ideas over the
last 30 years doesn't automatically make them questionable. :-)

$ set response/mode=normal

Giving a list of valid options when something is ambiguous: good idea.

Automatically replacing a mistyped command: terrible, terrible idea.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/31/2021 8:54 AM, Simon Clubley wrote:
> On 2021-05-28, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2021-05-28 kl. 20:54, skrev Simon Clubley:
>>
>>>
>>> One of the Linux shells does spell checking. I think its a terrible idea.
>>
>> Like this?
>>
>> $ sql shwo table
>> %SQL-I-SPELLCORR, identifier SHWO replaced with SHOW
>> User tables in database with filename SQL$DATABASE
>> ARTLAB
>> DB_SUBMIT
>> DW101T
>> ...
>> ...
>>
>
> Whoever thought it was acceptable to implement _that_ in a SQL utility
> and in the way that it is shown above is an idiot.
>
> Simon.
>

Beware, there ARE idiots. Lots of them.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/31/2021 8:58 AM, Simon Clubley wrote:
> On 2021-05-28, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Either know what you want to do, and do it right, or, don't do it at all.
>>
>> For someone as security conscious as you claim to be, you come up with
>> some questionable ideas.
>>
>
> $ set response/mode=good_natured
>
> Just because you haven't learnt any of those new ideas over the
> last 30 years doesn't automatically make them questionable. :-)
>
> $ set response/mode=normal
>
> Giving a list of valid options when something is ambiguous: good idea.
>
> Automatically replacing a mistyped command: terrible, terrible idea.
>
> Simon.
>

As a parallel example, there are two words, when used in aviation, that
quite often result in disaster.

WATCH THIS!

I'd think similar results might happen when not being precise with
instructions to a computer.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 31/05/2021 13:53, Simon Clubley wrote:
> On 2021-05-28, arca...@gmail.com <arcarlini@gmail.com> wrote:
>> On Friday, 28 May 2021 at 20:06:14 UTC+1, Simon Clubley wrote:
>>
>>> By extension, I should also point out I consider the 4-character thing
>>> in DCL to be a terrible idea as well. :-)
>>
>>
>> There was an early release not that pointed out that the four-character thing specifically didn't apply to qualifiers that started with NO, those needed 6 characters.
>>
>> I think the motivating example was MOUNT/NOUN[LOAD] which became ambiguous when /UNIT appeared.
>>
>> I don't suppose 6 is much better than 4 for you though :-)
>>
>
> You assume correctly. :-)
>
> If you enter the extra characters, and they are wrong, then the command
> should be outright rejected.
>
> Simon.
>
It was sometimes useful to add an incorrect character to avoid a symbol
definition - for example deletes

--
Chris Townley