Hey! On Tue, May 11, 2021 at 12:42:49PM +0200, Pablo Neira Ayuso wrote: > On Tue, May 11, 2021 at 10:50:05AM +0200, Arturo Borrero Gonzalez wrote: > > On 5/11/21 10:24 AM, Phil Sutter wrote: > > > Hi Pablo, > > > > > > On Mon, May 10, 2021 at 06:53:21PM +0200, Pablo Neira Ayuso wrote: > > > > Add a catchall expression (EXPR_SET_ELEM_CATCHALL). > > > > > > > > Use the underscore (_) to represent the catch-all set element, e.g. > > > > > > Why did you choose this over asterisk? We have the latter as wildcard > > > symbol already (although a bit limited), so I think it would be more > > > intuitive than underscore. > > I looked at several programming languages, one of them is using it (a > very trendy one...), so I thought we have to use it / place it at the > deep core of Netfilter for this reason, even if it absolutely makes no > sense. Pablo, this tone is not acceptable: Please keep in mind there are potential readers with complete lack of humour which could find this absolutely offensive! > Actually, the real reason is that I was trying to reduce interactions > with bash, which most distros tend to use. I see. From my PoV though, since asterisk *is* used in nft syntax already, using it in more spots is not making things much worse. OTOH, trying to avoid conflicts with shell is probably a futile task unless we reduce the syntax to alphanumeric characters. The curly braces, for instance, make zsh choke. So I'd just accept it, make the syntax nice for nft scripts and guide users to enclose nft parameters in ticks, similar to e.g. 'perl -e' or 'python -c'. > > Moreover, > > > > instead of a symbol, perhaps an explicit word (string, like "default") may > > contribute to a more understandable syntax. > > I also considered "default" to reduce interactions with bash, problem is > that it's likely to be a valid input value as a key, for example, there > are a few keys in /etc/iproute2/rt_* files that use default, and that > will clash with it. Which is another benefit of "reusing" asterisk as there is little chance for it to clash with something else. Also, there is wildcard_expr (currently dead code) which may find use again. > So I'm more inclined to Phil's proposal to use asterisk, even if it > needs to be escaped in bash, I'll send a v2. Thanks, Phil
