Difference between [ find ] and [ find default=yes ] when trying to set option to all objects?

When doing /export one can often see something like (example from 7.15.2 stable):


/ip smb users set [ find default=yes ] disabled=yes

But the above can also be written without that “default=yes” part like so:


/ip smb users set [ find ] disabled=yes

But whats the difference?

At first I thought that “default=yes” is a flag so when the object have been reconfigured its no longer default but that doesnt seem correct when I did some tests in the console.

For example running a disabled=yes with [ find default=yes ] first time would work for untouched object but running it a second time like disabled=no [ find default=yes ] would not get a hit (as in the setting would not change to disabled=no) - but it did.

You get lost in a glass of water…

Omitted default=yes means to deactivate all objects.
If default=yes is specified, it only modifies undeletable DEFAULT existing objects.
An object always remains “default” no matter if it is modified or not.

Apparently “guest” in routeros v7 is buggy.
In v6 it prevented deletion, here not, even if it is seen as “default”.

I would say that
[find]
will return all existing objects whilst
[find default=yes]
will return only objects that have the property “default” with value “yes”.

Or at least this should be the theory.

If you have all items with property default=yes, the two commands should give you the same result, but it is a coincidence.

Thanks!

In my case I have created a script based on output of “/export terse show-sensitive file=flash/custom.rsc” where I noted during cleanup that some guides (perhaps outdated?) wrote the find the same as the /export (in 7.15.2 stable) do as in “[ find default=yes ]” while some other guides wrote it just as “[ find ]”.

More particullary its these settings that uses “[ find default=yes ]” in /export:


/ip ipsec proposal set [ find default=yes ] auth-algorithms=sha512 disabled=yes enc-algorithms=aes-256-cbc,aes-256-gcm pfs-group=ecp521
/ip smb users set [ find default=yes ] disabled=yes
/ip hotspot profile set [ find default=yes ] html-directory=flash/pub
/ip ipsec profile set [ find default=yes ] dh-group=ecp521 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512
/ip smb shares set [ find default=yes ] directory=/flash/pub
/ipv6 nd set [ find default=yes ] disabled=yes hop-limit=64

And while Im at it - it would have been nice if Mikrotik stopped mixing “enabled=no” and “disabled=yes” in the syntax…

You sure you don’t mean “started separating” … :confused:

Well whatever syntax they prefer but its a mess that one line of config use “enabled=no” to disable a feature while the next line uses “disabled=yes” to do the same thing…

usually enable yes/no is reserved to a service, like ntp, snmp, etc.
instead disabled is reserved to interfaces, usernames, items on one list, etc.

Everywhere is possible to use [find] is everytime disabled yes/no

I do not remember any enabled yes/no on lists.

I believe that this issue is not unusual :wink: .

In pure theory the property should be “neutral”, i.e. “status”, and the value have a binary 1/0 or translatable in binary yes/no, enabled/disabled.
So:
status=enabled
status=disabled

The moment you allow the property to have a positive or negative meaning name, particularly in larger codebases where multiple programmers work, things like:
enabled=yes
disabled=no
in different areas may well happen.

For commands (or verbs) the positive or negative is instead allowed and actually welcome:
enable item
disable item
is much more readable than
set item enabled=yes
set item enabled=no
or (horror :open_mouth: )
set item disabled=no
set item disabled=yes

OT, there is a similar (minor) quirk in grub/grub4dos, there are (for partitions) the “hide” and “unhide” commands, but also the “hiddenflag set” and “hiddenflag clear” command, that may cause confusion.