Puzzle about a detailed logic in recognizing next word in a string

28 views
Skip to first unread message

Shawn Qiu

unread,
Oct 13, 2022, 11:35:23 AM10/13/22
to klish-dev
Hello Serj! 
It's been a year the last time I consulted you.
Nice to communicate with you again!

This time I‘d like to ask you a very detailed question. It's in commit d710c0df5e and the specific source code is in file lub/string/string.c, function lub_string_nextword, line 371-373:
371    // Skip strange symbols after quotation
372    while (*string && !isspace(*string))
373        string++;
Could you please tell me why you add this logic? Or would you give me some examples which have "strange symbols after quotation"? Thanks sincerely.

The reason I care about this question is that, these three lines make some xml files, more specifically, some test attributes(in PARAM tag) invalid. For example we have a command like this:

COMMAND name="acl"
    PARAM name="type" ptype="ACL_TYPE"    (ACL_TYPE is selected from l3, l3v6, etc.)
    PARAM name="some_arg" test=' "${type}"!="l3" '

Behavior before the commit: can't input some_arg if type is l3 (which mean result of test is false). (Suppose type is l3, klish can parse the test string to ["l3", "!=", "l3"] correctly)
Behavior after the commit: can input some_arg even if type is l3 (which mean result of test is true). (Suppose type is l3, klish will parse the test string to ["l3"] incorrectly)

The way to make test attribute work again is adding blank space on both sides of unequal sign, e.g. test='"${type}"  !=  "l3"'.
Related call chain is clish_shell_parse_pargv() -> line_test() -> lub_system_line_test() -> lub_argv_new() -> lub_argv_init() -> lub_string_wordcount() -> lub_string_nextword().

Wishing your reply! Best regards!

Serj Kalichev

unread,
Oct 19, 2022, 10:27:12 AM10/19/22
to klis...@googlegroups.com
Hello Shawn
 
Are you sure that code like test=' "${type}"!="l3" ' is really works with versions before d710c0df5e?
Note "test" attribute works similar to unix utility "test". Internally I use code from some BSD source to implement this "test" functions. Now to reproduce your case I'm trying linux's "test" utility. See the following log:

$ a=1; b=2; test "$a"="$b"; echo $?
0
$ a=1; b=2; test "$a"!="$b"; echo $?
0
$ a=1; b=2; test "$a" = "$b"; echo $?
1
$ a=1; b=2; test "$a" != "$b"; echo $?
0

So probably your test expression was ALWAYS true. In my opinion standard "test" (and my copy too) can't parse such expression. It can't get operands and operation. So test it with older klish version.

My "// Skip strange symbols after quotation" means any symbol except space is "strange". I'll try to explain reason for that.

Example of user input:

abc "lll kkk" ppp "ooo ppp"uuuuuuu
(there is no space beetween "ooo ppp" and uuuuuuu)

What does it mean? I need to split the whole string to "words" i.e. arguments. Is there two arguments or a single argument? I really don't know. It's a strange line for parsing.



13.10.2022 18:35, 'Shawn Qiu' via klish-dev пишет:
--
You received this message because you are subscribed to the Google Groups "klish-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/klish-dev/8bb43a2c-8855-4466-a375-fd8e2ba2a633n%40googlegroups.com.


Shawn Qiu

unread,
Oct 20, 2022, 3:05:23 AM10/20/22
to klish-dev
Hi Serj!

I did some experiments both on linux's test and klish's test. Performance of linux's test is same with yours. And I'm sure that code like test='"${type}"!="l3"' could work well with version before d710c0df5e! That is to say, klish's test before d710c0df5e is different from linux's test. They may give opposite result for the same input. The internal reason is the logic of spliting string to words. Linux's test always takes blank space as separator between arguments and klish starts doing like this at d710c0df5e.

Thanks to your example, I have understood your consideration. The user input like that is really confusing and should be avoided. In addition, I prefer to write blank space in test expression myself because it's more readable. It's good to use the improved klish for me!

Thanks for your great explanation and patience!

Serj Kalichev

unread,
Nov 3, 2022, 11:38:20 AM11/3/22
to klis...@googlegroups.com, kl...@googlegroups.com
Hello

New version klish 3.0.0 is out. It's fully rewritten project. It has
another architecture and config files format than previously stable
branch klish 2.2. The goals are refactoring, modularity, security and
new features. Unfortunately right now I have not a documentation for new
version. I'm sorry. But I will write documentation later. Too much work
to do.

The klish-3.0.0 is depend on faux-2.1.0 project for building. See the
https://src.libcode.org/pkun/faux .

Additionally there is new plugin klish-plugin-sysrepo for klish-3.0.0.
It allows to implement Juniper-like configuration. It uses sysrepo and
libyang projects for datastores and YANG schemes. See the
https://src.libcode.org/pkun/klish-plugin-sysrepo .


Reply all
Reply to author
Forward
0 new messages