=== Technical & design support
=== Simulation & design Tools
=== CCSTUDIO-THEIA
===   Executable Actions in CCS seems like an unfinished and untested feature.

Appologies in advance, if this text comes off as a rant. There is a lot to learn from it, too.

I've been experimenting the last few hours with Executable Actions and have found several inconsistances and errors, that makes it hard to actually trust and use the feature for now.

Most noteable:

1. Sometimes all of the defined Executable Actions are grayed out, and can not be accessed.

It seems to be related to the way the an Executable Action exits, although I can not make a reliable test case.
It also seems to sometimes be the case after renaming an Executable Action. Again no reliable test case.
The only way I have found to be able to restore access to the Executable Actions are to restart CCS.

2. Sometimes the Multi-line editor in Executable Actions fails when adding a new action.

On rare occations (I have had it happen 5 times) this has resulted in a corrupt CCS project file.
This happens just after accepting a new action from the multi-line editor, where for some reason the action does not get added to the list of actions - it appea to be some sort of error that happen during the encoding of the content for the <executableActions> tag in the .ccsproject file. Sometimes the .ccsproject file is modified with the new content.
When this error happens, the project properties are no longer available, as well as all of the Executable Actions defined are grayed out and no longer managable.
Even after a restart of CCS, the error resumes - the only way I have found to restore the project, is to revert the .ccsproject file to the old version (if it was modified) or make a tiny modification to the .ccsproject file with a text editor. I guess the file is cached somewhere?

3. Variable expansion fail specatcular on a few ocations.

This leads to some of the same errors described in 2, above.



Details:

The only documentation for Executable Actions I can find is here: https://downloads.ti.com/ccs/esd/documents/users_guide_ccs_20.2.0/ccs_project-management.html#executable-actions

Two examples are shown (in a picture only):
Action 1, how to execute a batch file: C:\project\setup.bat
Action 2, how to get the contents of a directory: cmd /c dir

From this it's very clear that the invocation on an Executable Action, spawn a process directly.
Thus, in order to to get access to build in commands in cmd, such as dir, the more complex "cmd /c dir" syntax is needed.

The Executable Actions defined end up in a single <executableActions> tag in the .cssproject file, like this:

<executableActions value="Current Directory=cmd /c dir"/>

Multiple Executable Actions are linked together in a custom format, like this:

<executableActions value="Current Directory=cmd /c dir,;Current Directory2=cmd /c dir,"/>

Thus the action seperator is: ",;"

Executing one of the example Executable Actions, results in the following truncated (...) output:

**** Project 'myProject': Running executable action 'Current Directory' ****

> cmd /c dir
 Volume in drive C is Windows 
 Volume Serial Number is 5EE2-BE8C

 Directory of C:\Projects\myFolder\myProject\debug

2025-11-09  11:18    <DIR>          .
2025-11-08  02:45    <DIR>          ..
2025-10-29  12:00    <DIR>          .clangd
2025-11-09  11:17               825 ccsObjs.opt
...

              11 File(s)      2.148.615 bytes
               5 Dir(s)  378.574.336.000 bytes free


The directory here, identifies that the command is executed with the projects output folder as working directory. Very nice to know.


The Executable Actions editor is a (very limited) multi-line editor, but each line is appended together in the same line in the .cssproject file:

<executableActions value="Current Directory=cmd /c dir;cd"/>

Thus the line separator is; ";"

Each line from the editor is, executed by a separate spawned process, so if I add a second line, where I just want to execute "cd" (another build in cmd command), the result is an error like in this truncated output:

**** Project 'myProject': Running executable action 'Current Directory' ****

> cmd /c dir
...

> cd

Cannot run program "cd" (in directory "C:\Projects\myFolder\myProject\debug"): CreateProcess error=2, The system cannot find the file specified
--------------------

From this, it is evident that an Executable Action is a series of unrelated spawned processes.

Note: After executing this kind of faulty Executable Action, it seems theres a higher chance all the Executable Actions are ghosted on the next access to the menu.



A few "Current env" Executable Actions can help up discover the enviroment that the system have set up for us. Here's the (filtered and truncated) output of listing the environmental variables:

**** Project 'myProject': Running executable action 'Current cmd env' ****

> cmd /c "set"
CCS_HOST_OS=win32
CCS_IDE_MODE=desktop
CCS_INSTALL_DIR=C:\ti\ccs2020\ccs\
CCS_JAVA_HOME=C:\ti\ccs2020\ccs\eclipse\jre
CCS_PROJECT_DIR=C:\Projects\myFolder\myProject
CCS_PROJECT_TEMP_DIR=C:\Users\XXXXX\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\b764cdc318d02483594a7ffd9f984570\.metadata\.plugins\org.eclipse.core.resources\.projects\myProject\.temp
CCS_UTILS_DIR=C:\ti\ccs2020\ccs\utils
CCS_WORKSPACE_DIR=c:\Projects\myFolder
CCS_WORKSPACE_TEMP_DIR=C:\Users\XXXXX\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\b764cdc318d02483594a7ffd9f984570\.metadata\.temp
CG_TOOL_ROOT=C:\ti\ccs2020\ccs\tools\compiler\ti-cgt-c2000_22.6.2.LTS
COM_TI_C2000WARE_INSTALL_DIR=C:\ti\c2000\C2000Ware_5_04_00_00
CWD=C:\Projects\myFolder\myProject\debug
PWD=C:\Projects\myFolder\myProject\debug
RIPGREP_CONFIG_PATH=C:\Users\XXXXX\AppData\Local\Texas Instruments\CCS\.ccs-server\workspaces\b764cdc318d02483594a7ffd9f984570\.metadata\.persistentFiles\ripgrepConfiguration
SESSIONNAME=Console
THEIA_APP_PROJECT_PATH=C:\ti\ccs2020\ccs\theia\resources\app.asar
THEIA_CONFIG_DIR=C:\Users\XXXXX\AppData\Local\Texas Instruments\CCS\ccs2020\0\theia
THEIA_DEFAULT_PLUGINS=local-dir:/c:/ti/ccs2020/ccs/theia/resources/app/plugins
THEIA_ELECTRON_TOKEN={"value":"2d5c6845-a038-4ed0-a9ec-303d90dc4206"}
THEIA_ELECTRON_VERSION=30.1.2
VSCODE_API_VERSION=1.96.0


An almost identical list of variables ( only ${PWD} is different ) can be extracted in bash (only tested using bash from WinGit, which is in my path at "C:\Program Files\Git\bin\bash.exe"), using this command:

bash --noprofile --norc -c "env"



Testing how Executable Actions respond to return codes, and output to StdErr, with a series of lines is unfortunately a pretty sad sight:

**** Project 'myProject': Running executable action 'Test exit codes' ****

> cmd /c "echo test 0 return 0 & exit 0"
test 0 return 0

> cmd /c "echo test 1 return 1 & exit 1"
test 1 return 1

> cmd /c "echo test 2 return 2 & exit 2"
test 2 return 2

> cmd /c "echo test 2 return -1 & exit -1"
test 2 return -1

> cmd /c "echo test output to etderr & echo oops 1>&2 & exit 2"
test output to etderr
oops

> cmd /c "echo test 0 return 0 & exit 0"
test 0 return 0



It appears Executable Actions does not at all react to return codes, nor does anything special to text sent to stdErr, which is just shown as normal StdOut. :-(
It would be very convinient it it was possible, per line or per Executable Action, to control the reaction to errors.
And it would be extreamly usefull if output to StdErr was highlighted - just like it's the case for the CIO console.


Testing CCS Internal variable expansion in Executable Actions also reveals some inconsistances.
A command line like cmd /c "echo ProjDirPath = ${ProjDirPath}" is immidiately expanded in the Executable Actions overview, which is nice!

However, slightly more advanced Executable Actions are destroyed by the encoding to the .ccsproject entry, and subsequent decoding.

A good example is this line:

bash --noprofile --norc -c "{ echo CD=\"$(pwd -W)\"; env | sort; }"

which is added to the <executableActions> tag as:

;,Adv bash test=bash.exe --noprofile --norc -c &quot;{ echo CD@eq\&quot;$(pwd -W)\&quot;; env | sort; }&quot;

which in turn is decoded back as multiple lines in a command:

bash --noprofile --norc -c "{ echo CD=\"$(pwd -W)\"
env | sort
}"

This clearly shows that the the choise to use semicolon as line separators and comma and semicolon Action separator isn't solid, as neithor of those characters are a special XML character and therefore isn't escaped by a typical XML serializer.

In this case the .ccsproject file and the project survive, but the Executable Action obviously break.


I did find some serious error in variable expansion, in relation to Executable Actions, too.
A very typical variable to use on other Eclipse based IDE's is ${project_loc}.
However, it turns out, in CCS the ${project_loc} variable isn't defined (instead it's ${PROJECT_LOC}) - however the lover-case version of the variable still does something, although I can't really explain what it does, but lines in the multi-line editor that contains the variable, disapear, and isn't executed!


Try to add these three lines in an action, and accept it to see the expansion:

Intro-line
project_loc - ${project_loc} - complete line disapears.
Extro-line

An even worse example, that corrupts the .ccsproject file, is this:

python "${project_loc}/scripts/report_program_size.py" "${workspace_loc:/${ProjName}/${ConfigName}/${ProjName}}.map"

A workaround for this error is:

python "${PROJECT_LOC}/scripts/report_program_size.py" "${PROJECT_BUILD_DIR}/${ProjName}}.map"

However, it should never have been a problem in the first place.



As part of this study, I have added a few Executable Actions, and it's evident that the <executableActions> tag in the .ccsproject file is quickly becomming a mess to read and diff, too:

<executableActions value="Current Directory=cmd /c dir,Test exit codes=cmd /c &quot;echo test 0 return 0 &amp; exit 0&quot;;cmd /c &quot;echo test 1 return 1 &amp; exit 1&quot;;cmd /c &quot;echo test 2 return 2 &amp; exit 2&quot;;cmd /c &quot;echo test 2 return -1 &amp; exit -1&quot;;cmd /c &quot;echo test output to etderr &amp; echo oops 1&gt;&amp;2 &amp; exit 2&quot;;cmd /c &quot;echo test 0 return 0 &amp; exit 0&quot;,Current bash env=bash --noprofile --norc -c &quot;env&quot;,Currenth cmd env=cmd /c set,Test variables=cmd /c &quot;echo ProjDirPath @eq ${ProjDirPath}&quot;,Adv bash test=bash --noprofile --norc -c &quot;{ echo CD@eq\&quot;$(pwd -W)\&quot;;env | sort;}&quot;,Variable expansion tests=project_loc - ${project_loc} - complete line disapears. Must be an error?;PROJECT_LOC} - ${PROJECT_LOC} - Full path to project root. Uses /;PROJECT_ROOT - ${PROJECT_ROOT} - Full path to project root. Uses /;ProjDirPath - ${ProjDirPath} - Full path to project root. Uses \;workspace_loc:/ProjName - ${workspace_loc:/${ProjName}} - Full path to the project root. Uses \;;build_var (project) - ${build_var:/${ProjName}/PROJECT_BUILD_DIR} - Full path to the project output/build folder. Uses \;PROJECT_BUILD_DIR - ${PROJECT_BUILD_DIR} - Full path to the project output/build folder. Uses /;;workspace_loc - ${workspace_loc} - full path to workspace location. Uses \;WORKSPACE_LOC - ${WORKSPACE_LOC} - full path to workspace location. Uses /;PARENT_LOC} - ${PARENT_LOC} - full path to workspace location. Uses /;;ProjName - ${ProjName} - The project name;ConfigName - ${ConfigName} - Name of the build configuration;;ECLIPSE_HOME - ${ECLIPSE_HOME} - Full path to the Eclipse folder. Uses /;CCS_INSTALL_ROOT - ${CCS_INSTALL_ROOT} - Full path to the CCS instalation. Uses /;CG_TOOL_ROOT - ${CG_TOOL_ROOT} - Full path to the CG tools. Uses /,Get program Size=python &quot;${PROJECT_LOC}/scripts/report_program_size.py&quot; &quot;${PROJECT_BUILD_DIR}/${ProjName}.map&quot;"/>

The whole point of using xml, is to make it easily digestable, and the current selfmade format certainly is not easily readable. And as shown above, the current format is very prone to introduse errors, too.

Instead it ought to look something like this:
<executableActions>
    <action name="Current Directory" errorAction="fail last">
        <line>cmd /c dir</line>
    </action>
    <action name="Test exit codes" errorAction="fail first">
        <line>cmd /c &quot;echo test 0 return 0 &amp; exit 0&quot;</line>
        <line>cmd /c &quot;echo test 1 return 1 &amp; exit 1&quot;</line>
        <line>cmd /c &quot;echo test 2 return 2 &amp; exit 2&quot;</line>
        <line>cmd /c &quot;echo test 2 return -1 &amp; exit -1&quot;</line>
        <line>cmd /c &quot;echo test output to etderr &amp; echo oops 1&gt;&amp;2 &amp; exit 2&quot;</line>
        <line>cmd /c &quot;echo test 0 return 0 &amp; exit 0&quot;</line>
    </action>
    <action name="Current bash env" errorAction="none">
        <line>bash --noprofile --norc -c &quot;env&quot;</line>
    </action>
    <action name="Current cmd env">
        <line>cmd /c set</line>
    </action>
</executableActions>

I took the liberty to add an errorAction switch, that either ignores errors (as it is now), fails on the first error, or on the last error. This would be a very helpfull adition.

While it's still not super readable to see whats going on, it's much better than the current selfmade format, and will solve all of the encoding/decoding problems I've found. And git diffs are so much easier this way!!



I'm well aware this is a huge text, with multiple errors reported as well as multiple feature requests. I hope you will create the necessary number of entries in your issue-tracker.

Thank you.