Environment variables

[Taitava]

Add configurable environment variables, that will be passed to the executed processes. This way you could for example tell your own made script/program that you initiated it from Obsidian, in case it happens to have practical benefits.

This is just on an idea level: I'm sill pondering if this is actually needed? If you think you could use this feature, please comment below.

[Taitava]

I moved this to the active ideas category now. I have been thinking about issue #11 (escaping certain characters in variable values), and while I have not come up with a robust idea to solve it yet, I have realized that environment variables can offer a helpful workaround to the escaping problem.

Edit 2021-10-14: Environment variables actually do not prevent their content from being interpreted as arbitrary commands. I was wrong about it, and noticed it now that I tested environment variables more. Still, I might add support for environment variables at some point, but not as a workaround for issue #11.

Let's say that an environment variable named MY_VARIABLE is defined with a value cat in it. This variable can be referred to in a shell command like this: echo $MY_VARIABLE (on Linux).

I have two ideas for environment variables, with the first one being more important for the issue #11 .

1. Assigning values to environment variables

For each shell command, there would be a list of defined environment variables. The list is empty by default. A user can add as many environment variables as they want. Each environment variable will have two fields:

• Name: A literal name for the variable ({{variables}} cannot be used in the names, but this might change later if needed). Allowed environment variable characters depends on the currently used operating system and shell. On linux, according to this Stack Overflow answer, it's best if the names restrict to only use uppercase letters, digits, and underscore _, and do not begin with a digit. However, I think that SC should not place any character restrictions.
• Value: Can be a literal value like Hello world!, or a variable like {{date:format}}, or a combination like Currently, {{file_name}} is open in Obsidian..

The benefit of using environment variables to enclose SC's {{variables}} is that there is no risk of an environment variable's value to be interpreted accidentally as an arbitrary shell command. Take the following example:

• Let's say that {{clipboard}} contains a text " && rm *.* && \.
• A shell command that shows the clipboard content without using environment variables: echo "{{clipboard}}".
• This shell command would be parsed by SC quite badly: echo "" && rm *.* && \", which would basically lead to deleting all files in a current directory, instead of just echoing something.
• But if {{clipboard}} would be contained in an environment variable like CLIPBOARD, it could be used in the shell command like this: echo $CLIPBOARD. As $CLIPBOARD would now be a native variable in the current shell, and not something parsed by SC, it's now completely safe to contain whatever, AFAIK. I'm not an expert with environment variables, so there might be caveats that I do not know, but in theory this should work.

2. Export current note's YAML key value pairs as environment variables

I'll just write this shortly now. It would be implemented later, after idea 1.

Let's say you have the following YAML in your note:

---
alias: Another name for this note
my_variable: My value
---

Each shell command could have a toggle setting whether to export the YAML values as environment variables (off by default). YAML key alias would become an environment variable $ALIAS, and my_variable would become $MY_VARIABLE.

There could also be a global prefix setting for YAML derived environment variables. It might default to e.g. OBSIDIAN_, so e.g. YAML key alias would become $OBSIDIAN_ALIAS. This could prevent collisions between YAML keys and already existing environment variable names, such as $HOME and $PATH.

More designing is still needed for how to parse nested values, like:

---
tags:
  - FirstTag
  - SecondTag
my_complex_set_of_values:
  my_key: my_value
  another_key:
    more: nested
    values:
      - ABC
      - DEF
      - GHI
---

[jvsteiner]

I would like this enhancement. I tend to think that the environment variables should be implemented as Idea 1 above, not idea 2, if there is a mutually exclusive choice.

[Taitava]

Yea, the idea 2 is not so important.