Re: date: unclosed date string comments

[Kaz Kylheku (Coreutils)]

On 2020-08-05 18:52, sunnycemetery@gmail.com wrote:
> Hello.  Given this documentation:
>
> > Comments may be introduced between round parentheses, as long as 
> > included  parentheses are properly nested.
>
> Is this considered a bug:
>
> > ■ LC_ALL=C date -d '(test 1 2 3'
> > Wed Aug 5 00:00:00 EDT 2020
> > ■ LC_ALL=C date -d '((test 1 2 3)'
> > Wed Aug 5 00:00:00 EDT 2020
>
> Thank you.

This is a lack of diagnosis that adds up to it being a feature
that a comment which does not close is closed implicitly by
the end of the string.

Once this kind of thing escapes into the wild, the safest thing
is to document it. A fix for this (like making date exit with
a diagnostic and failed termination status) will break something
for someone somewhere.

Unix is historically awful for this sort of looseness. For
instance an extra closing parenthesis in an extended regex is
treated as literal. Too late to fix, this had to be enshrined
in POSIX scripture:

   The <right-parenthesis> shall be special when matched with
   a preceding <left-parenthesis>, both outside a bracket
   expression.

Particularly in the earlier history of Unix, a lot of it
was geared toward getting the happy cases working with the
least amount of code.

At least the C compilers grew up quite a bit. You can fix
looseness in compilers more easily because when you tighten
something in a compiler, the diagnostic blows up in the face
of a developer.

If you tighten something in a utility, something breaks in
the field, because it is a run-time check.