Option to use metadata list item as tokens to command

[jeetsukumaran]

I have some front matter that specifies a command to be executed to view/edit/cd to a various project directories.

project-links:
 - title: "Manuscript Directory"
   directory: "/home/user/projects/p1/manuscript"
   open-command: "gnome-terminal"
 - title: "Manuscript"
   directory: "/home/user/projects/p1/manuscript"
   open-command: "nvim src/p1.tex"
 - title: "Something else"
   directory: "/home/user/projects/p1/manuscript"
   open-command: "command --args1 --args2 src/p1.tex"

And I have the following shell commands defined:

• cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command}}
• cd {{yaml_value:production-links.1.directory}} && {{yaml_value:production-links.1.open-command}}
• cd {{yaml_value:production-links.1.directory}} && {{yaml_value:production-links.2.open-command}}
  etc.

This works for the first case, but for the second and third I have to disable escaping variables fpr the command to work:

• cd {{yaml_value:production-links.1.directory}} && {{!yaml_value:production-links.1.open-command}}
• cd {{yaml_value:production-links.1.directory}} && {{!yaml_value:production-links.2.open-command}}

The recommendation NOT to disable escaping (https://publish.obsidian.md/shellcommands/Variables/Escaping+special+characters+in+variable+values), makes me think of alternate ways to doing this.

One option to add separate metadata for each argument:

production-links
 - title: "Manuscript"
   directory: "/home/user/projects/p1/manuscript"
   open-command: "nvim"
   open-arguments: "src/p1.tex"

• cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command}} {{yaml_value:production-links.0.open-arguments}}

This works in the simple case (i.e., single argument), but that gets out of control as the number of arguments might vary and increase and need to be anticipated.

Another option would be if Shell Command has an option that can "expand" a list argument with a separator. For example {{yaml_value:production-links.0.open-command:join(" ")}}

Then the YAML could be:

production-links
 - title: "Manuscript"
   directory: "/home/user/projects/p1/manuscript"
   open-command: ["nvim", "--arg1", "--arg2", "src/p1.tex"]

And the shell command is also a lot simpler:

• cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command:join(" ")}}

Another syntax could be like the disable token, e.g. {{@yaml_value:production-links.0.open-command}}

[Taitava]

Hi, thank you for your message! 🙂

And I have the following shell commands defined:

• cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command}}

• cd {{yaml_value:production-links.1.directory}} && {{yaml_value:production-links.1.open-command}}

• cd {{yaml_value:production-links.1.directory}} && {{yaml_value:production-links.2.open-command}}
  etc.

This works for the first case, but for the second and third I have to disable escaping variables fpr the command to work:

• cd {{yaml_value:production-links.1.directory}} && {{!yaml_value:production-links.1.open-command}}

• cd {{yaml_value:production-links.1.directory}} && {{!yaml_value:production-links.2.open-command}}

The recommendation NOT to disable escaping (https://publish.obsidian.md/shellcommands/Variables/Escaping+special+characters+in+variable+values), makes me think of alternate ways to doing this.

Hmm, I think the documentation page needs some updating. The general idea of escaping is good, and works as a safe default way on how to do things. It's good that you have thought about alternative ways. However, in your situation I think it's perfectly fine to disable escaping. I think these could be rules of thumb:

• Enable escaping, if you use variables for passing literal values as arguments (without a need for varying amounts of arguments). (so, not for your use-case)
• Disable escaping, if you use variables for defining commands. (like in your use-case)

The documentation page assumes that {{variables}} are usually used just for passing verbatim data as parameters. It doesn't take your use-case into account. I'll add that to the list of exceptions on the same page.

In your use-case, you know that whatever you put to your open-command YAML property, will be interpreted as a shell command, so it's fine. You know that special characters in that property will be interpreted as normal parts of a shell command, so disabling escaping should be safe. 🙂

If your shell command would be something like echo {{!selection}} >> anotherFile.md then you might run into a terrible surprise, if your highlighted text happens to contain e.g. && rm an-important-file, so your complete command would become echo && rm a-lot-of-important-files >> anotherFile.md. That would be a wrong situation to disable escaping and could lead to bad data loss.

---

But now let's have a look at your suggestion. 🙂

Another option would be if Shell Command has an option that can "expand" a list argument with a separator. For example {{yaml_value:production-links.0.open-command:join(" ")}}

Then the YAML could be:

production-links
 - title: "Manuscript"
   directory: "/home/user/projects/p1/manuscript"
   open-command: ["nvim", "--arg1", "--arg2", "src/p1.tex"]

And the shell command is also a lot simpler:

• cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command:join(" ")}}

This has actually been on my mind for way too long, but I still haven't made up my mind on the syntax, so that's why I haven't implemented it yet.

Currently, the {{tags:, }} variable is the only variable that has a joining feature implemented. I just don't like the form of how the join separator is defined using the colon : syntax. I think joining should be defined outside variable parameters context. Discussion #147 ponders on an idea like {{tags}}->join{{, }} (just an example, not decided yet).

In your case, it could be:

cd {{yaml_value:production-links.0.directory}} && {{yaml_value:production-links.0.open-command}}->{{ }}

Note that there are no quotes " around the space.

We can continue this join discussion in #147. 🙂

Another syntax could be like the disable token, e.g. {{@yaml_value:production-links.0.open-command}}

Sorry, I didn't understand this.

[jeetsukumaran]

Thank you so much for responding so thoroughly!

By {{@yaml_value:production-links.0.open-command}}, I meant a special token, like "!", that applies special processing, in this case, "concatenate". But will follow up in #147.