I'm looking to write some scripts to handle various situations I keep finding myself in (Steam/Proton/Wine issues, recursive path issues with bedrock, etc) and was wondering if there was a preferred method of interacting with Bedrock so I can write my scripts. Generally speaking, parsing human-readable program output isn't a good way to do things, but is that the only option I would have in this situation for things like strata and program detection?

Hi. I don't really understand what do you mean by that. You can use any text editor (your preferred one) to modify config files and write scripts.

Bedrock is a special case. Better to have left the thread on the zero reply auto-bump list.

1 members found this post helpful.

Can you give a more concrete, detailed list of what you're after? It's not obvious to me what you interactions you'd automate with Bedrock for Steam/Proton/WINE issues, and recursive path issues sound like a user error.

I can imagine non-Bedrock cases where this is an issue, but with the Bedrock context it's again not obvious to me what you're referring to here. Most Bedrock command output are written explicitly with automation in mind. They either return non-zero on error or terse, structured, trivially machine parseable output on success.

Apologies, I should've explained better. I'm looking to be able to detect what strata are installed and enabled, and search those strata for programs as needed (at current, mainly Wine and/or Steam, but this may change in future.)

Additionally, the /bedrock folder presents a small issue with trying to search for things from the root of a stratum, as things like Python's `os.walk` will get stuck due to how it's structured, and `find` will continuously complain about the folder as well for minutes at a time before continuing.

asdfasdfNo worries

The expected user-facing solution to this is `brl list`. The output is intended to be easily machine parsable. See `brl list --help`; it has flags for things like enabled vs not enabled vs both. In theory it's possible to bypass it and directly read what `brl` is reading, but there's no guarantee that that will be maintained in future updates; the "stable API" is `brl`.

I'm not exactly sure what you're after here, but here's a scattershot attempt that might hit it:

• If you only care which stratum provides a given command in the current context, `brl which` is what you're interested in. (It can also help with things other than binaries, like `brl which <pid>` will tell you which stratum provides a given running process).
  
• If you're interested in not necessarily commands, but rather packages, Bedrock provides a Package Manager Manager (`pmm`) utility. Its user interface is highly configurable and so it's hard to provide a specific recommendation without knowing your preferred setup. See `pmm --help`.
  
• If you want a list of all strata that could provide a given command, Bedrock does not currently provide a specific solution, but you could script something like:
  
  
  Code:

  #!/bin/sh
  command="${1}"
  echo "Strata which provide ${command}:"
  for stratum in $(brl list); do
  	strat -r "${stratum}" /bedrock/libexec/busybox sh -c "command -v \"${command}\" >/dev/null 2>&1" && echo "${stratum}"
  done

  where:
  
  • `brl list` lists the currently enabled, non-hidden strata.
  • `strat -r` runs something restricted to that stratum, i.e. it won't see commands available from other strata
  • `/bedrock/libexec/busybox` is Bedrock's provided busybox instance that's available from all strata for automation like this, rather than relying on the assumption a given stratum have things like a shell
  • `/bedrock/libexec/busybox sh` is busybox's shell
  • `command -v` is a way to ask a shell if a command is available in the `$PATH`
  
  Feel free to tweak as needed for your use case or use it as inspiration for something completely different.

Gotcha. Yes, there is recursion in `/bedrock/strata/<stratum>/bedrock` that could result in a much longer walk than should really be necessary. AFAIK it is limited to one level of recursion and will bottom out; Python's `os.walk` shouldn't get stuck indefinitely, but I certainly understand if you became impatient with it in your tests and ctrl-c'd it out. `find` detects this and will skip some of the redundancy.

In Bedrock Linux 0.7, there isn't a particularly great solution if you need to scan all of `/bedrock/strata` for something. The obvious solutions to me are to just wait it out, or to tell the walking software to skip the redundancy with something like `find`'s `-prune` flag or maybe something like this for os.walk. Another option may be to loop over the strata, `strat`'ing into each, then doing the search operation while pruning `/bedrock`. I recognize none of these are particularly great.

The architecture plans for the future Bedrock Linux 0.8 will probably resolve the recursion concern here such that this won't be an issue then, but it'll be a while before that's available.

Additionally, you may care to note that (in the current Bedrock Linux 0.7) /bedrock/cross is a virtual directory, similar to /proc or /sys. Those files aren't "real" and you may or may not care about them depending on why you're scanning /bedrock.

find tends to be rather finicky when using it from any scripts that aren't shell scripts. As an example, this call to subprocess.run:

Per documentation, this should work, however, find fails to parse the command (as returned by subprocess.run, using a stratum on my machine and wine as an example file):

The Python solution proposed for os.walk cuts down search time by approximately 60 seconds on an NVMe SSD, in my tests.

Thanks for sharing us a piece of great information that is actually helpful