Surprising changes in RouterOS7 cli vs RouterOS6 cli

Hi, is there a good reason to change this (which is easy to read):

[admin@RouterOS6] > /ip firewall filter 
[admin@RouterOS6] /ip firewall filter>

into this (which is eye bleeding):

[admin@RouterOS7] > /ip/firewall/filter/ 
[admin@RouterOS7] /ip/firewall/filter>

And best part is that in ROS7 old, space separated syntax still works! I found somewhere on the forum that it might be to match up with API. Really? Please spare fellow admins, /slashes/as/token/separators/are/only/good/for/machines, and we are just humans that still need decent typography to save our eyes.

Also why to sacrifice question mark (which is instant near one finger hit just below enter/return) for far north “F1” key, which require to raise and reposition your hand (even on laptop keyboard - on a standard desktop its a whole trip to isolated key row now).

I’m fiddling with ROS6 long-term branch versions full-time and over for a month now for a project my company is into. Just as reference on one device had to check if ROS7 solves problems found in ROS6. And was quite surprised with those two annoyances. I tried digging (not only) forum for that matter, found only vague side mentions.

Maybe I’m just old, my eyes are no good anymore and my brain is refusing to memorize something that is at the tip of my pinkie, but why to sacrifice good user experience? Hope someone can explain it to me.

+1
I totally agree!

I do not agree on ? because is problematic when the ? must be used on terminal as characters,
less characters must be escaped, better is, like \ ? " $
but after many years of " " instead of “/” is better without the / for sure, and also have better readability…

+1 for rextended

I too dont want to disagree with that cat…

slashes seem more logical, like entering a new directory in a shell, but entering a new subsection of config. it’s nice that spaces still work too but I have no problem with the slashes personally

I like the slashes too, as mentioned it makes it look more like a file path. If we can tolerate slashes in file paths, we should be able to tolerate them as separators for levels in the RouterOS command tree, and this is very logical.

And what are use cases for literal “?” in console? I can only think of:
a) regex,
b) literal strings - do you put questions in your logs? :wink:
Heck, there’s even no ternary operator.


I’ve seen ultra logical and well structured user interfaces that were terrible to use, learn and explain to anyone but computer science nerds. When comes to UI design it must be balance between logic and efficiency (and there is no One True Logic). Also / (and other non space variants) as path separator were chosen because spaces were already used to separate other syntax tokens (like execution options) that already were in place when file paths were introduced and it was in the days when CRT terminals could do 80x25 characters (if you were lucky, otherwise you had only 10cpi printer output). Now RouterOS has well defined set of tokens (menu names) that do not have spaces in them, so there is no risk of misinterpretation. Aside personal preferences typography has it figured out almost since invention of modern writing. (Example follows, I’m not shouting) YOU DO NOT GO CAPITALS like Romans did, youdonotsqash n o r s t r e t c h text for a reason - well separated words make it easier to read. And when you must read a lot it makes the difference. Besides it was already there, easily readable commands, why “tolerate” going backward? I want to believe that there is someone at Mikrotik who will look at it and say “Hold on a moment: Why does our UI drift back to XX century? We do not have hardware constraints that were in place back then!” Finally my experience tells me that if one cannot figure tree structures because of missing slashes then in 9 out of 10 cases he just can’t get them at all. Don’t take it personal mducharme but I can see you are Mikrotik Trainer so I assume that your approach is to explain RouterOS command structure on a file path equivalent. I have to review lots of config files. Cisco devices have space separated tokens, 3com/hpe/aruba the same, even damned Huawei separates tokens with spaces! Tolerate? C’mon! Until Mikrotik gives reasonable technical explanation I’m assuming noone had a second tougth about it and it seems they wanted to unify cli and api interface and unifying human and machine interfaces… well, I really hope they will reconsider.

To be honest, I really don’t see the problem with using space or /.
It’s still a key stroke on the same keyboard so … ?
I vote for keeping both options so everybody is happy.


Off topic: that’s exactly what they DID do. They concurred all the capitals !

Unfortunately, this “surprising change” exist already for several years.
Since then there were only a few users who did not like the change and some even liked the new method. The old input method with spaces is not removed and will not be removed because of the exact reason that some users might not like typing slashes.
You are not forced to use spaces, nor slashes, use whatever method suits you.

Mrz, thank you for reply. Please do not take critics about one feature as critics over whole device/company etc. Mikrotiks are great anyway, but…


I’m working with Mikrotik devices for at least 3 years now. The ones used in production environment, sorry we do not go for testing branch very often, we also rather avoid stable and stick with long-term (to avoid e.g. missing routing tables problems or at least to gain awarenes). The only reason we went for stable 7 was to check the limits for smaller devices we prepare for our customers, hence surprise. We are in no way network device developers, we just use them, and use them a lot, stability is our main concern.


I would say, perhaps most heavy weight users are going to discover it when they arrive to ROS7 with its first long-term release? Early adopters tend to be hyped about new features and usually don’t care for little nuisances of everyday mundane tasks present in production environments. (Highly speculative opinion, based on my own and coworkers experience, prove me wrong but please do not jump on me.)


In a fact I am. Autocomplete with - I got slashes, default prompt with “path” - slashes… is there a switch/option to change it? Must have missed it.


Glad to hear it, but this somewhat contradicts my suspicion that the goal is to have one parser for cli and api and still raises my curiosity: Then why?

Ok, so you are using tabs for autocompletion, then yes, it defaults to the new slash method and at the moment there is no option to switch back to spaces, for display as well. We will see what we can do to make that option.

The initial reason was exactly that, to mimic API, leave spaces for compatibility with older v6 scripts and deprecate, and probably somewhere in 7.xx drop spaces support, but since then the plan has changed.

Please!


just some incongruence?
use / for mimic directory?
and winbox?
for example, users are on /user (without S and not under /system) and on winbox are on System**/Users**
like also certificates under /certificate (without S and not under /system) on terminal and under System**/Certificates**
this really make confusion…

Old RouterOS had WinBox with “Certificate” and “Users” at root level (also “SNMP”, “Ports” and “Telnet”), and perhaps some even older one had “User”, I don’t know. Problem is that if you want to rearrange it, e.g. because root level in WinBox is too prominent place for those things, then if you want to keep WinBox and CLI in sync, you can either break all scripts and exported configs, or not rearrange it at all.

And at this point, you understand why is a worst idea add another “variable”, like the / instead of spaces…

Fixing cli names do not cause any problem, like /user print still works also if new name are /users
because this “/sys rou pri” and similar works…

Is more logical the name “users” than simly “user”, just for example, obviously

It may not break CLI input where you have autocompletion, but it will definitely break everything where there is no autocompletion, like API, for example.

Ok, right