On Windows, when executing a child process using the equivalent of execvp, the directory that contains the current process's executable is automatically included in the path.

This is most likely NOT the case in OSX (or linux for that matter) - the ecl executable may need to arrange for a similar effect explicitly.

Neither were on on the path. The two command lines (less parameters, with results) are:

LN-MacBook-Pro:~ holtjd$ /opt/HPCCSystems/5.2.0/clienttools/bin/ecl packagemap
ecl 'packagemap' command not found

LN-MacBook-Pro:~ holtjd$ /opt/HPCCSystems/5.2.0/clienttools/bin/ecl-packagemap
Usage:
ecl packagemap <command> [command options]
packagemap Commands:
add Add a package map to the environment
delete Delete a package map
activate Activate a package map
deactivate Deactivate a package map (package map will not get loaded)
list List loaded package map names
info Return active package map information
validate Validate information in the package map file
query-files Show files used by a query and if/how they are mapped

Were both ecl-packagemap and ecl executables both on the path? Can you give me the exact command lines you ran in each case?

This seems like the kind of error that could be marked for "anyone" to fix. Maybe someone with a Mac would look into it.

ecl packagemap list should execvp out to "ecl-packagemap list".

If the error being reported is "ecl 'packagemap' command not found". That should mean when ecl cli tried to execvp it is setting errno to ENOENT. "No such file or directory"

Not sure if execvp behaves differently in Mac OS.. documentation looks similar.

I'm not currently set up to debug Mac OS.