On Sat, Feb 03, 2024 at 01:18:30PM +0000, Tristan wrote:
>
>
> > 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).
I think it would just add complication for users who copy-paste config
elements from other places, in issue reports etc. Dealing with multiple
syntaxes in general causes real consistency problems.
> > 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?
Imagine for example building a regex like this:
"^http://${HOSTNAME}/${PATH}";'.ext$'
It's less readable and more error-prone than using a single quote model
where needed such as:
^http://"${HOSTNAME}/${PATH}".ext$
Some would easily add a space between the two distinct quotes or embed
one into the other.
> 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.
In the example above, we couldn't say that the string ends on the quote,
it would actually be two adjacent quote-delimited blocks that together
form a single word.
> > 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.
I agree but the opposite is that you'd have to enter quotes everywhere
on the command line, for "cp", "ls", "mount" etc. That would be really
annoying. Imagine using git the following way:
$ "git" "commit" "-s" "-a" "*.c"
You quickly notice that quotes become extremely annoying. Not to mention
that it would break globbing on the last one.
> They are incredibly useful, and pipe chaining is one of the brightest ideas
> in computing I think, but its string handling is... not good.
It's more user-friendly than computer-friendly actually.
> 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.
I use them every single day multiple times a day and for me the difference
is perfectly clear ;-) For me it's clear that $* was a mistake that was
later fixed by $@ but it was too late to change it given the amount of code
relying on it. It's easy to remember, "$@" preserves the number of words,
despite the quoting while "$*" creates a single word by concatenating all
of them. A simple example:
$* will split words around spaces:
$ set "1" "2 3" "4 5 6"
$ set -- $*
$ echo $1
1
$ echo $2
2
$ echo $3
3
$ echo $4
4
once in quotes, you have a single word with all the contents:
$ set "1" "2 3" "4 5 6"
$ set -- "$*"
$ echo $1
1 2 3 4 5 6
$ echo $2
while with "$@" you keep the same words:
$ set "1" "2 3" "4 5 6"
$ set -- "$@"
$ echo $1
1
$ echo $2
2 3
$ echo $3
4 5 6
As a quick reminder, you should always use "$@" and never "$*" when using
lists, arguments, etc, otherwise you'll break anything involving a space.
My "make-*" scripts all have "$@" at the end of the "make" command line
to pass all excess arguments verbatim. And $@ is equivalent to $* when
unquoted.
But we're digressing ;-)
> > 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.
I'm pretty sure that we'd end up with twice as many quotes as there are
spaces in a config, but I could be wrong of course.
> 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
That's the same for everyone, but warnings cannot catch all typos. For
example we found only last week that nobody used the newreno congestion
algo with QUIC because of a typo, it was spelled "newrno" in the code.
No single quote or warning will catch this one.
> >>> 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.
Yes, the goal was clearly to make it possible to automate the tests.
However I found a mistake that I fixed, which is that some of the
extra tests (essentially the check for same server cookies) was not
called with -c because placed too far in the startup sequence.
> > 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.
No, you're not guilty, it's because at the moment we cannot use a forward
declaration for a ring, so we need to have had that ring section declared
and only then we can reference it in the "trace" keyword of the global
section, hence an annoying global/ring/global sequence. I don't know if
we'll be able to address this before the release, I remember that it's a
bit tricky because some parts may be emitted during boot so we need to be
careful.
Cheers,
Willy
