[systemd-devel] systemctl escaping of unit names

Lennart Poettering lennart at poettering.net
Sun Jul 6 13:12:45 PDT 2014


On Sun, 06.07.14 16:01, Gero Treuner (gt_18_lists.freedesktop.org at innocircle.com) wrote:

> 
> 1. Extend systemctl unit name interpretation with a syntax to escape in
>    controlled manner, preferably capable of escaping only parts of a
>    given name to support compound names with verbatim content (given by
>    users typing anything they imagine in their GUI).
> 
> 2. The syntax must match this criteria
>    * no valid C escaped string (to clearly distinguish valid names)
>    * a possible end token could be easily preencoded in shell and
>      common languages
> 
> 3. Document this.
> 
> Possible syntax:
> Start token: '\' + '#' + number of characters to be encoded (C-lib-parsed) + '#'
> End token:   none ;-)
> 
> Example 1 (UTF-8, decimal number):
> Raw:         tunnel_\#14#Nürnberg-Link.device
> Escaped:     tunnel_N\xC3\xBCrnberg\x2DLink.device
> 
> Example 2 (Latin1, hex number)
> Raw:         tunnel_\#0xD#Nürnberg-Link.device
> Escaped:     tunnel_N\xFCrnberg\x2DLink.device
> 
> In POSIX shell:
> 	name="Nürnberg-Link"
> 	LC_ALL=C
> 	systemctl start tunnel_\\#${#name}#${name}.device
> 
> 
> Reasons
> 
> I and possible more in the world are really tired of implementing
> nested escapes. Therefore the approach is to give the number of
> characters instead of any end token. This is friendly to programmers
> and CPUs, isn't it?

I'd prefer if we wouldn't make things more complex by inventing new
syntaxes. I think I'd prefer if we'd simply add a new tool
"systemd-escape" which escapes or unescapes all parameters, depending on
some switch. (And maybe we could even add an extra switch to allow users
to query whant unit_name_mangle() would normally do, without actually
using it immediately.) With that in place you could then do:

      systemctl status foobar@$(systemctl-escape $XYZ).service

Which feels quite OK to me, and is reasonably simple to understand.

(And I think I would prefer this as seperate tool from systemctl -- and
not just as new verbs), since this appears to not be directly related to
what systemctl otherwise does which is control the system...)

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list