Feature: implicit booleans

[ghost]

It would be useful to allow a variable with no specified value to be implicitly a boolean true, such as in the FreeBSD jail.conf format:

host.hostname = "${name}";
path = "/system/jails/${name}";

mount.devfs;
devfs_ruleset = "11";

exec.clean;
exec.system_user = "root";
exec.jail_user = "root";
exec.consolelog = "/var/log/jail_${name}_console.log";

Here mount.devfs and exec.clean would be implicitly true.

[Crest]

I know this is the jail.conf(5) syntax, but even there I consider it an anti-feature that makes the syntax more irregular without making it more readable (subjective). Have you verified that this syntax change would be unambiguous and backward compatible?

[ngortheone]

I agree with @Crest. Jail syntax while resembles UCL is not compatible with it.
Lets begin with the fact that setting variables in general like we do in jail.conf is not possible in UCL.

This kind of construct is illegal in UCL.

jail.conf:
$id = "10";
$ip = "10.0.0.$id";

The closest you can get to it is to add custom macros to UCL to allow setting variables, but even then the syntax will look different.

[Crest]

I'm working on a set of macros to "fix that" as part of adding a .include_dir macro with support for capturing (relative) path, realpath, basename, dirname, stripped basename, stripped parent's name as variables (within a certain recursion depth). My implementation approach generates a UCL snippet fed into the parser using ucl_parser_insert_chunk. Afaik it has to be a complete object since libucl isn't a streaming parser so I had to change variables by adding additional macros to be invoke from inside said snippet.

[ngortheone]

@Crest are you working on UCL syntnax for jail configs? It could be easier to extend existing jail.conf parser to emit AST, from which UCL can be generated

[Crest]

You could be right, but there're several annoying limitations to the current jail.conf syntax and its parser that aren't easy to fix in a backward compatible way e.g. how the exec.* hooks need double escaping (once for jail.conf once for /bin/sh). It doesn't export the jail variables and parameters in a sane, safe way. The resulting flexibility assuming I get it right would also be useful for several other designed ad-hoc parsers in the base system with the goal of not having to modify the default configs in ways that have to be merged during upgrades. Breaking configuration files up into enough files so that you can atomically replace snippets or symlinks to them also helps with automation instead of having to patch or template out a few bigger files.