Feature Request: Dynamic Variable Placeholders

[SylverSK40]

Hi Giuseppe and CherryTree Team,

First of all, thank you so much for creating and maintaining CherryTree. It is an incredible, staple tool for my offensive security and documentation workflows, and I rely heavily on it for my daily notes.

I want to propose a feature enhancement for the Rich Text notes, specifically interacting with the existing "Execute Code Line or Selection" right-click feature. In cybersecurity and system administration, we frequently save long, complex command templates that require quick parameter adjustments (e.g., changing a target IP address, a specific domain, or a file path) right before execution.

The Idea:

Instead of modifying Code Nodes or Code Boxes (which might be complex to implement), it would be an incredible productivity boost if CherryTree supported dynamic variable placeholders directly within standard Rich Text. This would allow a user to update a target parameter once in a central text box, and have it automatically apply to any command string they highlight and execute from the right-click menu.

Proposed Workflow & Implementation:

1. Variable Input UI: A small, toggleable side-panel or an input block at the top of the node where users can define temporary variables (e.g., target_ip = 10.10.10.1, domain = example.com).
2. Placeholder Syntax: Users write commands in standard rich text using a specific placeholder syntax matching those variables. Two great options that won't conflict with native bash code are:
   • Option A (Double-Brace Style): nmap -sV {{target_ip}} (Highly readable, similar to Pentest.ws/Jinja)
   • Option B (Enclosed Dollar-Sign Style): nmap -sV $TARGET_IP$ (Feels natural to CLI users, but enclosed so it isn't confused with a literal local bash variable)
3. Execution Logic: When a user highlights a command string in the rich text, right-clicks, and selects "Execute Code Line or Selection", CherryTree would automatically swap out the placeholders with the current live values before sending the final string to the terminal/shell.

Technical Note (C++ / Regex Execution):

Since CherryTree is built in C++, this could potentially be implemented quite cleanly at the string parsing layer. Right before the application passes the highlighted rich text string to the execution engine, a standard std::regex_replace could search for the defined placeholder syntax (like {{...}}) and swap them out with the live user strings on the fly. This keeps the core note data intact while modifying only the payload string sent to the shell.

How it looks in other workflows:

• Pentest.ws (Web platform): Has a dedicated command substitution feature where you define variables at the top of your workspace, and the command string changes automatically.
• Obsidian (Local notebook): Uses a community plugin system (Meta Bind) where typing a value into a central UI text box dynamically feeds into text blocks and command scripts.

For users with massive, established CherryTree databases, a native feature like this would be a complete game-changer. It would allow us to maintain our entire note repository in CherryTree while giving us the live, rapid-fire template execution found in newer platforms.

Thank you for considering this idea for the roadmap!

[giuspen]

Hi @SylverSK40 it makes sense to me, however I am wondering if using environment variables would be a better solution to this?
This actually would already work now if you set up environment variables manually then run cherrytree, then close cherrytree, change the environment variables and then run cherrytree again with the exact same code.
I could add support for setting up environment variables in cherrytree automatically before executing commands based on input that can be discussed.
Then there would be no need of any substitution because your code no matter the language can point to environment variables.
What do you think?

[SylverSK40]

Hi @giuspen ,

First of all, thank you for taking the time to reply to my feature request. I really appreciate you considering it and offering an alternative approach.

I definitely understand where you're coming from with using environment variables. From an implementation standpoint, that seems like a very clean solution, and I like that it would work across different scripting languages without requiring CherryTree to perform any text substitution.

The challenge, at least for my workflow, is that these values tend to be temporary and specific to the note I'm currently working on. I regularly switch between Windows and Linux systems, so I'd either have to maintain environment variables differently on each platform or include commands in my notes to set them before execution. If I did that, many nodes would end up containing both the Windows and Linux methods for defining the same variables.

Another issue is that I often jump between unrelated notes while working. One node might expect TARGET_IP, another might use DOMAIN, another LHOST and LPORT, and I'd need to remember to redefine those variables whenever I switched contexts. Since environment variables live outside the notebook itself, the notebook becomes less self-contained.

The reason I originally suggested placeholder substitution is that everything needed to execute the command would live within the note. I could simply change a value like {{target_ip}} (or another placeholder syntax) once in that node, and then execute any highlighted command immediately, without worrying about the underlying operating system or the current shell environment.

That said, I do think your idea of allowing CherryTree to automatically define environment variables before executing commands is interesting. If those variables were managed per node (rather than relying on the user's existing shell environment), it might actually provide many of the same benefits while remaining language-agnostic. I think that could be a great compromise if it's easier to integrate into CherryTree's execution model.

Thanks again for considering the idea and for all the work you put into CherryTree. It's become an indispensable tool in my documentation workflow, and I really appreciate your willingness to discuss feature ideas with the community.

[ShadowCreator250]

What you are describing reminds me very strongly of Jupyter Notebooks.
I assume you have your reasons why you use CherryTree instead of Jupyter?

I agree that a variable system would be a strong addition to CherryTree, but it also will be a challenge to implement. Especially if you want to separate contexts by node and support access from different coding languages.

CherryTree would basically have to add a layer between environment variables and the code execution.
Or CherryTree has to gain the ability to manage the setup/teardown of the environment variables so that the correct variables are created/destroyed on node open/close.

[giuspen]

Once the mechanism is defined to check if the user has set up environment variables for the current node, then it is easy to set up / overwrite the environment variables before executing the code.
The environment variables are set only for cherrytree and the subprocesses started from cherrytree, not at operating system level.
I am not even sure if it is necessary to do a cleanup as this is only local to cherrytree and if you want to be sure that an environment variable has a particular value for a node you set it in the relevant node(s) anyway. Still, the cleanup can be done keeping track of the existence and value of the variable before the setup and undoing maybe when the user changes node (would be easier)

[SylverSK40]

Thank you again for the reply and for taking the time to think through this idea. I also appreciate the clarification that the environment variables would exist only within CherryTree and its subprocesses, rather than modifying the operating system's environment. That makes a lot more sense than what I originally envisioned based on your first response.

After thinking about it more, I also realized that I may not have explained my original idea very well. My primary goal wasn't actually about passing variables to the execution environment; it was about making the notebook itself dynamic.

What I had in mind was more of a node templating system, where CherryTree maintains a set of variables for the current node and automatically resolves placeholders throughout the note. For example:

Variables
---------
target_ip = 10.10.10.5
domain    = example.com

Then anywhere in the note I could write:

nmap -sV {{target_ip}}
gobuster dir -u http://{{target_ip}}
ffuf -u http://{{target_ip}}/FUZZ

Changing target_ip once would update every reference throughout the node. Executing a command would simply use the resolved value, but execution is really just one use case.

For me, the bigger benefit is having reusable, self-contained note templates. During an engagement, I may need to swap a target IP, domain, username, file path, or callback address dozens of times. Being able to change those values in one place and have the entire note reflect the change would make maintaining documentation much easier, regardless of whether I'm executing commands.

Another advantage is that it remains shell- and platform-agnostic. Since CherryTree would resolve the placeholders itself, I wouldn't need to worry about Bash using $TARGET, PowerShell using $env:TARGET, or Command Prompt using %TARGET%. The notebook would remain portable across Windows and Linux without maintaining multiple versions of the same commands.

I think your idea of per-node environment variables is still a very interesting approach, especially since it's language-agnostic from the execution side. I just wanted to clarify that my vision was centered more on reusable, parameterized notes than on the execution mechanism itself.

Thank you again for taking the time to discuss this. I really appreciate your openness to community ideas and all the work you put into CherryTree.