Commandbox - install path behavior differs based on how Commandbox is run?

Hi all,

I’m running into some behavior with CommandBox that I don’t quite understand and I’m hoping that someone can help to clarify. Depending on how I start CommandBox, it seems like sometimes it can follow relative paths to dependencies and mappings and sometimes it can’t.


I have an application with the following structure (p.s. It’s a LONG story why we’re using a zip file):

|- install/
|- box.json

The box.json file declares an application dependency for myModule and points to the file in the install directory:

# box.json contents
"dependencies": {

The problem

Depending on how I run the install command in CommandBox CLI, I get different results.

Method 1 (Successful)
I do most of my work in VSCode using the integrated terminal. Generally I use gitBash as my terminal shell, but when I need to do some CommandBox awesomeness I generally switch into commandbox using the “box” command:

  1. Happily coding away in my project folder in VSCode
  2. Open a terminal (defaults to the project root folder)
  3. Type box to enter the CommandBox CLI (box.exe is in the windows path)
  4. Read the CommandBox message of the day :slight_smile:
  5. Type install in CommandBox CLI

Result: CommandBox successfully installs the module from the Project-Folder/install/ location. And there is much rejoicing!

Method 2 (CommandBox can’t find file):
Unfortunately if I start off by loading the CommandBox CLI by double-clicking on box.exe and then try and run the install script, CommandBox throws an error that indicates that it can’t find the file based on the relative mapping:

  1. Launch box.exe via Windows explorer (as adminsitrator) to open CommandBox CLI interface
  2. cd to Project-Folder (validating location using pwd)
  3. Type reload to force CommandBox to reload the shell (just in case it matters)
  4. Type install in CommandBox CLI


× | Installing ALL dependencies
   | × | Installing package [file:install/]
   |   | > file or directory [install/] does not exist
   |   |--------------------------------------------------------------------

ERROR (5.0.1+00137)

file or directory [install/] does not exist

Can someone help me understand why CommandBox might be having a hard time following the dependencies (and mappings) in the second scenario above? Is there something that I’m missing or forgetting to do? I was assuming that a reload would reset the context that CommandBox is running in and the relative paths would work (the way it does in the VSCode/Integrated terminal example) but my mental model here is far from complete.

Environment Details

  • OS: Windows 10
  • CommandBox Version (verified behavior in 5.0.1 and 5.1.1)


The problem here is that the file endpoint doesn’t expand file paths, it assumes they are absolute. That means that you’re at the mercy of how Lucee decides to interpret what install/ means.

In this case, the difference is due to the working directory of the Java process that Lucee is running inside of. The folder that box.exe is started becomes the working directory of the JVM, and Lucee when running in JSR-223 mode, adopts that as its “web root” (even though the CLI is not a web server). Therefore the expandPath() behavior that happens behind the scenes on this line of code

zip action="unzip" file="#package#" destination="#packagePath#" overwrite="true";

is influenced by where Lucee thinks the “web root” is. When box.exe is started from the root of the project, it will magically “find” folders that are in that same folder. But if you start box.exe by double clicking on it, the working directory of the process is typically your user home.

You can confirm the difference by running thse commands from the CLI in each scenario:

Echos the working directory of the java process as reported by the JVM

❯ echo ${user.dir}

Outputs the location of the “web root” as Lucee see it (which will be the same as above)

❯ #expandPath ""

The short answer is you need to use absolute paths. The longer answer is, we could probably enhance the file endpoint to expand the paths based on the CLI’s working directory or the location of the box.json. Honestly, I’ve rarely ever used the file endpoint so it’s just not been put through too many paces.

Awesome - I appreciate the education Brad - that’s exactly what I needed to know!