> On 3 Feb 2024, at 15:18, Willy Tarreau <w...@1wt.eu> wrote:
>
> Quite honestly, we've though about it several times but you can't enforce
> such a change on 20 years of configs everywhere.
That is why I directly mentioned it being some form of opt-in behavior, because
indeed we can’t expect everyone to update their config (or even agree with the
change at all).
> Also that
> complicates concatenation and mixing of multiple modes (single/double quotes
> for example).
I think forcing only one would be okay if that was necessary for it, but I
don’t quite see why?
As I imagine it, it’d mostly be adding an indirection step when consuming
individual string/regex, checking the strictness flag, and rejecting at parse
time if not well-quoted.
But still operate 1 string at a time, so with consistent quote style per
invocation.
> And after all, in shell, strings do not need to be quoted and
> when this becomes a difficulty, users just learn to put quotes to visually
> isolate their words.
Frankly, shell (and even bash) are not very good in that regard. Even quite bad
I think.
They are incredibly useful, and pipe chaining is one of the brightest ideas in
computing I think, but its string handling is… not good.
One super common example is: who ever remembers things like when to use $*, $@,
or "$@" or not, and for what kind of argument splitting?
I certainly still have to look it up almost everytime after years and years,
and I don’t believe I will remember them better in another 10 years either.
> That's exactly the same in shell, you never know how many backslashes you
> have to insert inside quotes to put other quotes.
Indeed. And I’d much prefer to be unable to forget quotes without an error. If
I could do that with a flag, I would enable it in shell scripts and yaml files
for sure. Just like I never write any shell script without set -euo pipefail
anymore.
It’s for the same reasons as using zero-warning in haproxy, -Wall in all
compilers and languages that support it, and so on:
1. I am a dumb human that makes dumb mistakes all the time
2. I have spent way more many hours staring at my screen in confusion until I
noticed a typo was at fault than any other kind of bug, by far
>>> It does already exist, with -dW. In fact the diag mode enables emission
> of more warnings than the default one, and purposely takes the risk of
> emitting false positives which the user has to sort out.
Nice then! I wasn’t sure if they were treated the same as non-diag warnings in
that regard but that’s perfect if it does.
> I checked here, and among 435 test configs that emit zero warnings, only
> 15 are caught by -dD, essentially due to "weight 0" on a server line, or
> due to a "global" section placed after another section (typically after
> a "ring" one for traces).
Funny you mention it, I’m pretty sure I’m guilty of the ring/global ordering
one.
I will check that later.
Tristan
