Getting the location of the binary

[cthayer-colinst]

My program requires a configuration file which is placed in the same directory as the executable, however the executable won't necessarily be executed from within that directory, it's intended to be a command-line utility placed in the PATH.

As a result, the cwd of the node environment will not be sufficient to be able to parse the config file.

This is possible with pkg through the use of process.execPath, this returns the path to the node.exe in the caxa temp directory in a caxa package, however.

I'm not certain how something along these lines would even be possible with caxa's design, but i've thought of the following two temporary solutions:

• Add a shortcut like {{caxa}} which can be used to pass the path to the executable into the command
• Add the ability to mark specific files as assets on build, symbolically linking them into the temp directory when the executable is launched

[leafac]

Hi @egrogans-colinst,

First, thanks for reaching out!

---

I think that the best solution would be for caxa to introduce an environment variable containing the path of executable created with caxa before calling Node.js. For example, suppose that your file system looks like:

/usr/bin/binary-created-with-caxa
/usr/bin/binary-created-with-caxa.conf

Then on the command line:

$ pwd
/home/some-user/some/random/folders/
$ binary-created-with-caxa

And from your Node.js program, the following would hold:

process.env.CAXA_EXECUTABLE_PATH === "/usr/bin/binary-created-with-caxa"

How does that sound?

---

Do you think you could start a pull request for this? I think the work amounts to:

1. Create a test along the lines of what I described above.

2. Change the Go stub to include the environment variable.

3. Change the shell stub to include the environment variable.

4. Change the .app stub to include the environment variable. (The .app stub doesn’t have the concept of a temporary directory, so the environment variable won’t be super useful, but I think it’s better to have it there for consistency with the other stubs.)

5. Document this new feature on the README.md.

---

Other ideas I considered that didn’t make the cut:

• Introduce some sort of command-line argument that includes the path of the executable created with caxa. I think this is more intrusive and may get in the way of the command-line parsing in some programs.

• Introduce a special token known by caxa, along the lines of {{caxa}}—something like {{caxa-executable-path}}. (As far as I understand, that’s your first bullet point above.) Again, I think this is more intrusive. So far {{caxa}} is the only special token, and I want to keep avoiding those.

• Symbolic links from within the temporary directory created by caxa pointing at the directory where the executable created with caxa lives. (As far as I understand, that’s your second bullet point above.) Yet again, this is more intrusive. It requires a bit configuration from the person using caxa, and symbolic links are prone to giving headaches, specially when you factor in different operating systems and file systems.

[leafac]

Hi @cthayer-colinst,

Thanks for using caxa and for the conversation here.

I’ve been thinking about the broad strategy employed by caxa and concluded that there is a better way to solve the problem. It includes a PACKAGE environment variable that should solve your issue. Can you please give it a try and report back?

It’s a different enough approach that I think it deserves a new name, and it’s part of a bigger toolset that I’m building, which I call Radically Straightforward · Package.

I’m deprecating caxa and archiving this repository. I invite you to continue the conversation in Radically Straightforward’s issues.

Best.