Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Yep, common use case for what I work on is BLAH_BLAH_THINGY_CONFIG_FILE in the environment being a path to some file that the library will open to read config, instead of having the config itself in the environment (maybe it's a large unwieldy JSON thing).
https://github.com/DataDog/dd-trace-cpp/blob/6dacac2922d08f4...
It's not secure, but I'm not worried about bad actors monitoring /tmp in my test container so they can make my tests fail anyway.
It would be nice if there were a "file paths that start with a null character belong to an ad hoc in memory file system specific to the process," or something. /tmp/tmp.eJaVgxtV0x/ is close enough.
Open to code golfing suggestions on the code linked above.
Java has in-memory file systems that are essentially geared for this exact use case, eg jimfs[0]. You create your filesystem and any files you need when your tests are starting up, and your classes talk to them rather than the “real” ones. Maybe a similar project exists for the C++ ecosystem?
[0] https://github.com/google/jimfs
This is a problem that Bazel (https://bazel.build) solves in a very convenient way. You can just keep using the paths relative to the repository root, and as long as you properly declare your test needs that file it will access it without problems. Or you can use the runfile libraries to access them too.