When trying to refer to a previously stored CustomName from an Entity or minecraft:custom_name component from items with macro functions the returned value does not include escaping of special character like single quotation marks, which causes dynamic functions to break.
So for example if I store the name of an entity which has "Bob's Burger" as a name with the command:
/data modify storage test:storage saved_name set from entity @n[type=!player] CustomNameIt would then store the data as:
saved_name: '"Bob\'s Burger"'But when I then try to use the stored data in a macro command it removes the escaping of the single quotation mark which causes the command/function to fail. Here's also an example of a command I've tried for testing:
$execute as @a at @a if items entity @s container.* minecraft:goat_horn[minecraft:custom_data={wawo:goat_horn_tp},minecraft:custom_name='$(saved_name)'] run say success(Same happens with any other command when I use the variable and I've also tested it without the single quotation marks for the custom_name field)
Comments 6
Thanks for the explanation. Might be that I understood your comment wrongly but the problem here is not that it stores the value as "Bob\'s Burger" but rather than when using the variable in a macro command it's being pasted as "Bob's Burger" which makes it impossible to set custom names from storage data since the escaping of ' in Bob's Burger is missing (in that example)
They are inserted without outer quotes, which means they also get rid of a layer of escaping which belong to it.
You actually ca do what you're trying to achieve by adding yet another layer of escaping: '"Bob\\\'s Burgers"'
I'm sorry but how can I add another layer of escaping to a stored value? There isn't really something like data modify storage .. stuff or similliar as far as I'm aware and to expect anybody using the data pack to add that layer of escaping when renaming items in an anvil is simply not an option.
Don't get me wrong, I really do appreciate the help but I still don't see why it's more reasonable for the value which is stored with escaping to remove it apparently before resolving the macro command.
But maybe we're just still talking different tongues so here's another more detailed example:
Let's say we have an item like the one from this summon command (which can also be just renamed one from a player using an anvil):
/summon item ~ ~ ~ {Item:{id:"minecraft:dirt",count:1,components:{"minecraft:custom_name":'"Pete\'s Dirt"'}}}and I store the CustomName value with
/data modify storage test:storage saved_name set from entity @n[type=item] CustomNamethen I'm asking for the storage with
/data get storage test:storage saved_namethis returns the following
Storage test:storage has the following contents: '"Pete\'s Dirt"'if I then try to use the variable in a function to ask for an item in a players inventory with the same minecraft:custom_name with
$execute as @a if items entity @s container.* minecraft:dirt[minecraft:custom_name='$(saved_name)'] run say successthe command will be executed without the escaping like this:
$execute as @a if items entity @s container.* minecraft:dirt[minecraft:custom_name='"Pete's Dirt"'] run say successwhich obviously runs into an error.
I'd expect the stored value to be pasted the same way it is shown to me when I use /data get and not to be formatted further.
You can do so via signs' messages, making it fetch NBT from storage, non-interpreted, and then using the resolved message as macro argument.
Macro arguments are not NBT, data type definitions are removed. 0b,0s,0,0l, 0d,0f all resolve to a macro value of 0, and what is the data type defining part of a string...? the outer quotes. The only reason the escaping of inner quotes exists is to prevent them from interfering with the outer quotes, ending the definition prematurely. No outer quotes means a layer of escaping less.
If escaping were to be kept, other macro insertions would break, such as just inputting plain text: say $(message) with message being '"There\'s 1 moon"' would return say "There\'s one moon", something that can then never be corrected, unlike your situation.
This is in no way a bug, and functions exactly as it is intended to.
This is simply how string macros are inserted, without the outer quotes (and as such also removing a layer of escaping which belong to said outer quotes).
If this was changed, you wouldn't be able to insert the string
"Bob's Burgers"(without the outmost single quotes compared to your stored value) without it becoming"Bob\'s Burgers"or\"Bob's Burgers\"in ANY situation.Reminder that macros are inserted and only after that is the command syntax read.