Help answer threads with 0 replies.
Go Back > Forums > Linux Forums > Linux - Distributions > Bedrock Linux
User Name
Bedrock Linux This forum is for the discussion of Bedrock Linux.


  Search this Thread
Old 12-23-2022, 01:28 PM   #1
Registered: Mar 2009
Distribution: Bedrock, Devuan, Slackware, Linux From Scratch, Void
Posts: 646
Blog Entries: 128

Rep: Reputation: 187Reputation: 187
Bedrock Linux: accessibility of some a file in /usr/share/doc

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:
bob@moonshadow:~ $ cd /usr/share/doc/nasm                       
bob@moonshadow:nasm $ gpicview nasmlogw.png 
strat: warning: unable to set cwd to
for stratum
due to: no such directory (ENOENT).
falling back to root directory
bob@moonshadow:nasm $
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:
bob@moonshadow:nasm $ strat slackware feh /usr/share/doc/nasm/nasmlogw.png 
strat: warning: unable to set cwd to
for stratum
due to: no such directory (ENOENT).
falling back to root directory
feh WARNING: /usr/share/doc/nasm/nasmlogw.png does not exist - skipping
feh: No loadable images specified.
See 'man feh' for detailed usage information
bob@moonshadow:nasm $
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.

Last edited by jr_bob_dobbs; 12-23-2022 at 01:30 PM.
Old 12-29-2022, 10:07 AM   #2
Bedrock Linux Founder
Registered: Feb 2016
Distribution: Bedrock Linux
Posts: 179

Rep: Reputation: Disabled
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

bob@moonshadow:nasm $ strat slackware feh /usr/share/doc/nasm/nasmlogw.png
would have worked had you instead run

bob@moonshadow:nasm $ strat slackware feh /bedrock/strata/$(brl which)/usr/share/doc/nasm/nasmlogw.png
If you're not uncomfortable with command substitution like this, you could instead do:

bob@moonshadow:nasm $ brl which # ask Bedrock which stratum provides your shell
<shell-stratum> # I don't know what this will output for you; you didn't provide enough information.
bob@moonshadow:nasm $ strat slackware feh /bedrock/strata/<shell-stratum>/usr/share/doc/nasm/nasmlogw.png

Last edited by ParadigmComplex; 12-29-2022 at 05:19 PM.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] bedrock: bedrock poki remains on UTC no matter what jr_bob_dobbs Bedrock Linux 5 09-03-2019 06:10 AM
Slackware-current: /usr/share/cmake and /usr/share/cmake-3.3 directories igor29768 Slackware 1 11-07-2015 01:37 AM
[SOLVED] bedrock not using brsh.conf, dropped to bedrock's /bin/sh Siljrath Linux - Distributions 2 08-25-2014 06:47 AM
Redirect an app resource folder from system /usr/share to /home/user/[app]/usr/share minyor Linux - Software 2 04-23-2013 07:44 AM
Konqueror + file:/usr/share/doc/HTML/index.html jon_k Linux - Software 2 11-25-2003 06:06 AM > Forums > Linux Forums > Linux - Distributions > Bedrock Linux

All times are GMT -5. The time now is 03:18 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration