[Tutor] a program which list ALL the errors

[Cameron Simpson]

On 25Oct2020 00:15, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
>On 24/10/2020 23:08, Cameron Simpson wrote:
>> On 18Oct2020 12:34, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
>>> But it must be said that its an unusual strategy.
>>> Most programs detect the first error and stop.
>>
>> And those programmes are user experience disasters. I hate them with a
>> passion.
>
>> When that logic is buried deep in a subsidiary script, the user is
>> massively annoyed. I submitted a small patch to probe for _all_ the
>> software, complain about each missing comonepnt, and _then_ quit. Really
>> easy and avoids much anger in the end user.
>
>Interesting. I absolutely hate that behaviour. Some compilers
>do it and its a massive pain finding the first error and fixing
>it then trying to find another, and another,  and then discovering
>that fixing the first actually changed the second! It's much,
>much easier IMHO to fix one thing at a time.
>
>Of course the program should give useful hints as to what it is
>expecting up front. But not give me a raft of error messages - my poor
>brain can only cope with one at a time! :-0

For a long compiler error listing, perhaps so. A good terminate which makes 
"jump back to the previous shell prompt" just a keystroke would help 
there. I think iterm can be asked to do that, for example.

But for your average vaguely complicated command line invocation, I much 
prefer this:

    [~/hg/css-cloud(hg:cloud)]fleet2*2> dev cloudbackup -j 0 -A s4://foo/bah
    cloudbackup: -j: value < 1: 0
    cloudbackup: invalid cloud_area: s4://foo/bah: no module 'cs.cloud.s4' for cloud service 's4'
    cloudbackup: no backup_name specified
    The following backup names exist:
      cs
      test
    cloudbackup: bad options
    Usage: cloudbackup [options] subcommand [...]
    [... full usage message here ...]

over bouncing back and forth getting each option correctly tuned.

Cheers,
Cameron Simpson <cs at cskk.id.au>