4 ms·
You mean because it uses foo=bar rather than --foo=bar? I don't know, it's not that weird. I mean, find uses parentheses for forcing evaluation precedence, e.g
by taviso 4y ago
You mean because it uses foo=bar rather than --foo=bar? I don't know, it's not that weird.
I mean, find uses parentheses for forcing evaluation precedence, e.g. -foo -or \( -bar -and -baz \). That's pretty unusual.
- viraptor 4y agoAnd here's uwsgi https://uwsgi-docs.readthedocs.io/en/latest/Options.html https://uwsgi-docs.readthedocs.io/en/latest/Options.html with probably hundreds of options by now. It includes conditionals and basically its own scripting language right in the parameters.
- grumbel 4y agoMost frustrating part with find is: $ find -type f . find: paths must precede expression: `.' It's like the tool knows exactly what you want to do, but still refuses to do it just because.
- tux1968 4y agoIn the same vein: $ git grep Congrats -i fatal: option '-i' must come before non-option arguments Frustrating.
- xg15 4y agoApropos that (though a bit OT) : what exactly is the deal with unescaped parantheses in bash? They just seem to produce a syntax error no matter where I use them. But if they have no purpose, then why not simply treat them as nonspecial characters? E.g. echo hello :-) ; is invalid syntax, even though it doesn't seem to cause any ambiguities with any other bash syntax features. Why not just allow this and treat it like echo "hello" ":-)"; ?