Hello,
I wonder what's the reason we're not allowing the use of dash (-) in the section names in the uci.
Thanks.
I just found the comment in the code at https://git.openwrt.org/?p=project/uci.git;a=blob;f=util.c;h=12aec9bd3596103741b564198cd969e97207a165;hb=HEAD#l69
/*
* validate strings for names and types, reject special characters
* for names, only alphanum and _ is allowed (shell compatibility)
* for types, we allow more characters
*/
What shell compatibility?
1 Like
... this shell compability: https://git.openwrt.org/?p=project/uci.git;a=blob;f=sh/uci.sh;h=cb01a7df1e813f70c4ad1d2391c544c007338ec6;hb=HEAD
Pretty cool stuff.
shell compatibility in this context is for the names only those characters are allowed which dont have any special meanings
Hyphen is regarded as magic char used in a lot many situations
cd -
in mutt command also
adding sitches to the commands
nc -l -p 123 | tar xvzf -
in switching accounts su -
i hope this will give u an idea
Actually, more precisely, "shell compatibility" is a requirement for a section name to be compatible with env (or sh/ash/bash) variable key. And that is needed to make evaluating uci files as shell scripts simple and avoid doing escaping. Ever noticed uci configs look like a series of command invocations? That's because if you source that uci.sh (I think you're not supposed to do it directly though) you actually can then eval $YOUR_UCI_CONFIG.
Technically we could allow dashes in the config names, and make the shell binding do the escaping, but it's not as clean, so I like the way we do it now better.
Alternatively, we could rewrite shell bindings in such a way that config values are not represented as native variables in the shell... This actually might make some sense, since I think you're not supposed to access those exposed variables directly as variables, and use getter functions instead.
I'm interested in what the original authors of the design have to say about this.
I feel like it works, and works good, but at the same time not being able to use dash is annoying.
@nbd, can you comment on this?
plz elaborate on why this restriction is on section name only why not on section type ?
Take a look at https://git.openwrt.org/?p=project/uci.git;a=blob;f=sh/uci.sh;h=cb01a7df1e813f70c4ad1d2391c544c007338ec6;hb=HEAD#l66
config () {
local cfgtype="$1"
local name="$2"
export ${NO_EXPORT:+-n} CONFIG_NUM_SECTIONS=$(($CONFIG_NUM_SECTIONS + 1))
name="${name:-cfg$CONFIG_NUM_SECTIONS}"
append CONFIG_SECTIONS "$name"
[ -n "$NO_CALLBACK" ] || config_cb "$cfgtype" "$name"
export ${NO_EXPORT:+-n} CONFIG_SECTION="$name"
export ${NO_EXPORT:+-n} "CONFIG_${CONFIG_SECTION}_TYPE=$cfgtype"
}
I don't really know that codebase, so this is the rationale I could find without digging deep.
Here we can see that name is used in the variable name aka key (CONFIG_SECTION="$name" and CONFIG_${CONFIG_SECTION}_TYPE), so that restriction applies (shell variable names can't have - in them, and this is not something that's under our control). $cfgtype is only used as variable value - meaning there are no restrictions of that sort.
This demonstrates a particular case where the restriction on the section name comes from. However it doesn't show that the type isn't used somewhere as the variable name. I mean, it's definitely not used in the code above, but it would be impossible to prove that for any possible code. Anyway, what I'm trying to say is, the restriction on type is not there because it wasn't needed for the implementation shell bindings, and it is on the name because it was needed.
From what I saw in the C code there's no internal need to restrict the use of -, so that's why I had this question in the first place.
I think getopts function from c which shell also utilises to parse the arguemts need this restrictions as suppose
section name is = " -radio "
and it is used somewhere as arguemnt then ?
"command -i eth0 -b ok . -c -radio " this will raise issue as it will expect word after -c to be a litral "
So, you mean that the consumers of the uci configuration can be sensitive to - - that is true, but section names are not exposed outside of the uci format itself. Or, at least, that seem to be what is intended by design. Furthermore, option values definitely can have - in them.
To sum up, I'm afraid this can't be the reason.
1 Like
Section names are used as variable names (export CONFIG_${sectionname}_${optionname}=${optionvalue}), hence the restriction to [A-Za-z0-9_].
1 Like
**
it says only option values can have dash that also when properly quoted
**
and yes that is because they will ultimately form a shell variable name like in what @jow mentioned
export CONFIG_radio-1_option-1 = value-1
the left hand site may form a expression
another case is
shell brace expansions
if we use abc-xyz and it has to be used further inside brace as @jow said its meaning will get totally different