[Bug 1154] Allow include statement to operate on directories and/or wildcards

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1154

--- Comment #7 from hoxu at users.sf.net ---
(In reply to Ismo Puustinen from comment #6)
> Consider this directory structure where dir1 and dir2 are include directories
> (nft -I dir1 -I dir2 ...):
> 
> dir1/
>      cba.nft
>      acb.nft
> dir2/
>      abc.nft
>      dir3/
>           a.nft
> 
> What about the following include cases:
> 
> include "*"
> 
> This means that all files in all include directories get added. However,
> what do
> we do for directory "dir3"? Should that cause an error or not?

Would a recursive include cause problems?

> include "a*"
> 
> Files starting with 'a' are in both include directories. Should we add the
> files
> in alphabetic order [abc.nft, acb.nft] or in include directory order
> [acb.nft, abc.nft]?

I would probably expect the latter; an alphabetical order including the
directories.

> include "foo*.nft"
> 
> There is no match. I think this shouldn't cause an error, because the whole
> point of implementing globbing is that we can include files from potentially
> empty directories. Do you agree?

Absolutely!

> include "foo.nft"
> 
> There is no match. Should this be an error, or do we think of this as a
> special
> case of glob with no wild cards, and thus not an error?

This leaves me wondering whether the globbing include should be a distinct
keyword/statement?

Otherwise I'd expect an error.

> include "dir4/*"
> 
> There is no such directory. Should this be an error? Or what would it mean?

I see this as a similar case to the earlier "foo*.nft". No matches with a
wildcard = no errors.

For example, a distribution could ship /etc/nftables.conf with:

include "nftables/rules-enabled/*.nft"

and that directory wouldn't need to exist by default. (granted, a naive
example)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170616/244eb1e8/attachment.html>