Sys: Support Executalbe Paths relative to `.ecalsys` file

[mfp85]

Context

I'm using an .ecalsys file to provide a simple possibility to start the individual components of my application.

The application structure typically looks like

- comp1
- comp2
- demo.ecalsys

This application could be installed into any folder and could be run by starting the demo.ecalsys which would start the components.

Ecalsys currently only supports absolute paths to the individual components thus one has to workaround using conventions for installation folders or environment variables storing the path etc.

Since all components are located within subfolders of the application, they can be addressed with relative paths from the .ecalsys file, like ./comp1

Proposal

• Add support for ecalsys to start applications via relative paths to the ecalsys file like: './path/to/component'
• Alternatively, a dedicated variable could be used like $HOST{ECALSYS_DIR}

Tasks and updates

No response

[FlorianReimold]

eCAL sys should already be able to start applications from relative paths. It probably just doesn't work as you expect it to work:

As I understand, you expect a relative path to be evaluated relative to the directory that your .ecalsys path is in. That is not the case, you are right about that.

What eCAL Sys will do instead is what every other application will also do: It will interpret the relative path to be relative to the current working directory. So what you can easily do is to start eCAL Sys from the directory, that your .ecalsys file is in. On Windows that is as easy as double-clicking the file. On Linux you can cd to the directory and call ecal_sys_gui myfile.ecalsys from there. I think double-clicking the .ecalsys file should also work for most Linux-distributions, but I am not 100% sure.

The issue with the idea of having a $HOST{ECALSYS_DIR} is, that this would have to evaluate to "" (-> empty string) in the following cases:

• The file is not saved, yet
• The user requests a target evaluation: $TARGET{ECALSYS_DIR}

Kind Regard Florian

[mfp85]

Hi Florian,

thanks for your answer - great to hear that this is already working. It's also exactly how I would expect it to work.

The problem seems to be that I wanted to specify both the executable and the working dir as relative paths:

-> If I leave the working dir empty, it does work as expected.

But it would be good to be able to specify the working directory relative to the ecalsys file (meaning the working directory from where the .ecalsys file is invoked...) as well

[FlorianReimold]

In your case, the Task Working directory should be relative to the eCAL Sys working directory. So let's say you .ecalsys file is in D:\foo\ and you double-clicked it, so eCAL Sys GUI is started from that directory. The working directory of your task should now be D:\foo\comp1\. If you specify a Task working directory, your Executable will be launched relative to that (if a relative path is specified). Therefore, eCAL Sys will try to start D:\foo\comp1\comp1\print1.bat. To help you understanding what eCAL Sys will actually execute, it prints the preview below the "Arguments" input box. In your case you probably have the print1.bat directly in D:\foo\comp1, so you can specify Executable: .\print1.bat, as long as you keep your Task working directory set.

I know that this does not solve anything, when you started ecal_sys_gui from the "wrong" directory, i.e. you didn't double-click the .ecalsys file, but maybe this helps you anyways.

[mfp85]

Ok, generally it's fine for me to assume that the ecalsys file is started by double-clicking / running it from the folder where it's located in.

Assuming that is given, I still don't really get how to specify both the working directory and the executable with a relative path. I've tried combinations like:

I'll attach the minimal example with the batchscripts printing the working directory: ecalsysTest.zip

My hope would be that the first variant would work (specify the relative working directory of the component (.\comp1) and then specify the relative path to the executable within the component-working directory (.\print1.bat))...

[FlorianReimold]

Thanks for providing the zip file. So yea, I have no idea why that doesn't work. I have to check it myself, it actually looks like there must be a bug somewhere 🤔

What you can do with your batch files is launch it with cmd.exe:

Nevertheless, I will check what is going wrong.