#19539: uci / regression / lists contain wrong chars
------------------------+------------------------
Reporter: bittorf@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: packages | Version: Trunk
Resolution: | Keywords:
------------------------+------------------------
Comment (by yousong):
Hi, bittorf and nbd,
Replying to [comment:2 bittorf@…]:
> so the minimal testcase is:
>
> {{{
> root@box:~ cat >>/etc/config/system <<EOF
> config x
> list y 'a b c'
> EOF
>
> root@box:~ uci get system.@x[0].y
> 'a b c'
> }}}
>
> in older versions of OpenWrt (e.g. r44945) it outputs (without quotes)
> a b c
It is quoted because we really need a way to distinguish the single list
value `a b c` from 3 list values `a`, `b` and `c`. Shell function
`config_list_foreach` of `/lib/functions.sh` does this right and is used
by at least package `dnsmasq` quite well.
IMHO, using `list y 'a b c'` to define a list type option consisting of 3
elements is kind of abusing the above ambiguity. It also will conflict
with behaviours of `config_list_foreach` which is always there for quite a
long time before the current change.
We can promote good practice with the current behaviour of `uci` command.
- If 3 elements for a list option is intended, then three `list y VAL` is
the right way to go.
- If it is only a single value, then use `option` type.
Replying to [comment:4 bittorf@…]:
> > eval "set -- $(uci get network.@x[0].y)"; echo $1
>
> the problem is, that you *dont know* if your "get" is
> on a 'list' or or normal 'option'. it breaks especially:
>
> {{{
> VAR="$( uci get var )"
> }}}
>
> where you end up with changed content...
Types of options in uci config files are expected to be well-defined, thus
users are expected to know the type of option they are getting with `uci
get`.
{{{
root@OpenWrt:~# cat /etc/config/p
config sec s
list l '1 2'
list l '3'
option o '4 5 6'
root@OpenWrt:~# uci get p.s.l
'1 2' 3
root@OpenWrt:~# uci get p.s.o
4 5 6
root@OpenWrt:~#
}}}
If `var` refers to a list type option, then `VAR="$( uci get var )"` is
really a wrong way to fetching values of it.
--
Ticket URL: <https://dev.openwrt.org/ticket/19539#comment:5>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
