I'm currently running Bedrock, with Void as the hijack & init stratum. Other stratum include devuan, arch and slackware.

In the following, all actions were performed by a non-root user.

I was looking at the directory /usr/share/doc/nasm and in that directory I saw a file named nasmlogw.png. Directory and file are owned by root but world has read & execute rights on that directory and read rights on the png.

I double-clicked on the png and got a message that the file does not exist. Erm, OK. I called the same image viewer that the file manager uses (gcpiview) but from the command line, specifying the full path and ... same error. I ran xxd to look at the file and that went without incident. So I copied the file to my home directory and then ran the image viewer on the copied file. The picture came up in a window just fine. Oh. Interesting.

Then I tried this:
I am unsure what is going on, save that (a) the error message mentions strat (2) the current working directory was already set when I cd'd to that directory?

Then it got interesting. I used a different image viewer, I used feh. Annnd, no problem.

So, I am guessing that gpicview likes to write to the directory that the image is in? Odd, if so.

Note: gpicview is pinned to the slackware stratum.

So I guess this is a gpicview problem and not a Bedrock problem but I'm not 100% sure. Can anyone clarify? Thank you.

Oh, wait a minute... I tried to mimic the effects of a pin by calling feh from another stratum:
Then I tried it specifying the devuan version of feh. Same error.
Aha, not just a gpicview thing and not a slackware oddity. My head hurts.

You seem to be tripping up on one of the fundamental concepts with which Bedrock users are expected to be familiar. I'll type out an answer for you here, but in case you're missing other similar fundamentals, you might want to refresh yourself on Bedrock's basics, either via the interactive tutorial accessible via `brl tutorial basics` or by reading the basic usage documentation.

Different distros may expect different contents at a given file path. For example, Debian's `apt` and Ubuntu's `apt` need to see different mirror contents at `/etc/apt/sources.list`. Bedrock resolves this problem by providing multiple possible instances of such paths, one for each stratum; these are referred to as local paths. Every process on a Bedrock system sees its own stratum's instance (or lack of an instance) for a given local path. There are other types of paths as well with which you should be familiar with as a Bedrock user, but are out of the scope of what's needed to understand the immediate issue at hand.

`/usr` is normally managed by distros themselves, e.g. their package managers. The odds of a conflict between different distros at such paths are high, and thus Bedrock is configured to consider it a local path by default, and thus every stratum has its own instance (or lack of an instance) of `/usr/share/doc/nasm`. Processes from your bedrock, void, devuan, arch, and slackware strata may each see something different at that path.

You can check which stratum provides a given resource in a given context - including but not limited to which stratum provides a given local path in the current context - with `brl which`. If you're ever trying to investigate something like this, `brl which` should be one of the first things you check.

With this background (which is all in the Bedrock introductory documentation), the following should now make sense to you:

• Your shell stratum (you didn't specify it; you could have checked with `brl which` without any arguments) has a directory at its local instance of `/usr/share/doc/nasm`. This is why your shell can `cd` into it.
• Your slackware stratum does not have a directory at its local instance of `/usr/share/doc/nasm`. This is why when you try to launch a slackware process with the current working directory set to `/usr/share/doc/nasm` you get an warning: slackware doesn't have a `/usr/share/doc/nasm` directory to utilize as its current working directory.
• Your initial feh stratum (you didn't specify it; you could have checked with `brl which feh`) happens to have contents at `/usr/share/doc/nasm`. Maybe it's the same stratum as your shell, or maybe it's just a coincidence that your feh stratum has similar packages installed. Thus, it can set its current working directory to `/usr/share/doc/nasm` and it can read contents at that path.
• When you later launched slackware's instance of feh, it tried to use slackware's local `/usr/share/doc/nasm` path, which as was established with slackware's gpicview, lacks a directory at that path. Slackware also lacks a `/usr/share/doc/nasm/nasmlogw.png` (which is not surprising, as we've established there's no directory to contain such a file).

If you want to use one stratum's software to read or write another stratum's local path, you should use `/bedrock/strata/<stratum>/<local-path>`. Your

would have worked had you instead run

If you're not uncomfortable with command substitution like this, you could instead do: