oglr is a REPL (Read-Eval-Print-Loop) CLI (Command-Line-Interface) tool for viewing various nested filesystems within deployed Pear & Bare applications
Git Repository: https://github.com/holepunchto/oglr
Applications are filesystem containers
A Pear application is a build folder assembled with pear build, synchronized to a Hyperdrive managed by Pear CLI with the pear stage, pear provision and pear multisig commands, remotely exposed with pear seed and addressed by pear:// links for installation and peer-to-peer over-the-air updates.
A Bare standalone executable is built with bare-build, which creates a native bootstrap into a Bare bundle container.
The build folder assembled with pear build contains standalone executables and/or application builds per OS: .app files for macOS, .AppImage files for Linux and .msix files for Windows. These are also filesystem containers, .app is a plain directory, .msix files are actually .zip files and .AppImage files are self-executing SquashFS blobs.
With oglr these nested filesystems can be inspected all the way down, which means applications can be inspected before installing them.
oglr explores nested filesystems
oglr takes a path or URL and opens it as a filesystem:
oglr pear://<key>
oglr ./app.bundle
oglr ./release.AppImage
With no subcommand, oglr opens an interactive REPL. Commands can then be used to navigate, inspect, and extract files.
@ /> ls
/app.bundle
# /app.bundle> cd /app.bundle
# /app.bundle /> tree
...
The prompt shows the container you're currently inside, making it possible to move between nested filesystems with cd and up.
oglr understands several application and archive formats:
@—pear://Hyperdrive#— Bare bundle%— standalone binary=— MSIX+— tar / tar.gz&— AppImage / SquashFS
Container files can themselves contain filesystems, so cd can descend into them. up returns to the parent container.
The usual filesystem commands are available:
ls
cd <path>
pwd
up
cat <path>
tree <path>
size <path>
info <path>
cat detects binary files and truncates large output. size reports file sizes or directory totals. info reports container metadata including kind, ID, main/addons, file count.
Subtrees can also be copied to the local filesystem:
mirror ./out /path/to/files
Walkthroughs
The Ecosystem Spotlight: swap article introduced the swap Pear app, with the pear:// link: pear://swapb14acos6iasoz5jg8bj46zt8emdk9rmm4n9j18mtjmwbqmwo.
We can pass that link to oglr and explore it:
oglr pear://swapb14acos6iasoz5jg8bj46zt8emdk9rmm4n9j18mtjmwbqmwo
This will open a new prompt, let’s try ls:
pear://swapb14acos6iasoz5jg8bj46zt8emdk9rmm4n9j18mtjmwbqmwo@/> ls
by-arch/
package.json 2.0 KB
Get a deeper view with tree:
pear://swapb14acos6iasoz5jg8bj46zt8emdk9rmm4n9j18mtjmwbqmwo@/> tree
by-arch/
darwin-arm64/
app/
swap
darwin-x64/
app/
swap
linux-arm64/
app/
swap
linux-x64/
app/
swap
win32-arm64/
app/
swap.exe
win32-x64/
app/
swap.exe
package.json
We can cd into any binary:
pear://swapb14acos6iasoz5jg8bj46zt8emdk9rmm4n9j18mtjmwbqmwo@/> cd by-arch/win32-x64/app/swap.exe
There may be a delay between running cd by-arch/win32-x64/app/swap.exe and the new prompt displaying – this is because the data is remote. The swap.exe blob has to be downloaded in order to inspect it.
Once inside a new container (swap.exe in this case) the prompt reflects that, we can use any command from there, for example we can ls then cat a file:
swap.exe#/> ls
node_modules/
app.js 4.1 KB
bin.mjs 3.0 KB
package.json 2.0 KB
swap.exe#/> cat bin.mjs
import { command, arg, flag, summary, bail, description } from 'paparam'
import { persistent } from 'bare-storage'
import os from 'bare-os'
import { isWindows } from 'which-runtime'
.....
That covers a Pear terminal application, let’s try inspecting a Pear desktop application. The pear:// link for an application can always be found in its package.json upgrade field. For example the PearPass link is pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o (https://github.com/tetherto/pearpass-app-desktop/blob/4378c33479368eb9e46d91c95a779551ffc0e740/package.json#L8).
Let’s inspect PearPass with oglr:
oglr pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o
This will open a new prompt, let’s try ls:
pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o@/> ls
by-arch/
package.json 10 B
Note the tab-complete feature, type cd by-arch/ then hit the tab button, this will display directories that can be entered:
pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o@/> cd by-arch/
darwin-arm64/ darwin-x64/ linux-arm64/ linux-x64/ win32-arm64/ win32-x64/
Let’s explore the Linux x64 build, type linux-x64/ and hit tab twice to autocomplete the AppImage path:
pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o@/> cd by-arch/linux-x64/app/PearPass.AppImage
The new prompt won’t show until the AppImage has downloaded, once it is the new prompt will be:
PearPass.AppImage&/>
We can explore this filesystem just the same:
PearPass.AppImage&/> ls
locales/
resources/
usr/
AppRun 2.3 KB
LICENSE.electron.txt 1.1 KB
LICENSES.chromium.html 8.7 MB
chrome_100_percent.pak 148.4 KB
chrome_200_percent.pak 224.8 KB
chrome_crashpad_handler 2.5 MB
icudtl.dat 10.0 MB
libEGL.so 253.8 KB
libGLESv2.so 6.6 MB
libffmpeg.so 2.6 MB
libvk_swiftshader.so 4.6 MB
libvulkan.so.1 2.1 MB
pearpass-app-desktop 95 B
pearpass-app-desktop.bin 177.7 MB
pearpass-app-desktop.desktop 219 B
resources.pak 5.7 MB
snapshot_blob.bin 309.1 KB
v8_context_snapshot.bin 671.4 KB
vk_swiftshader_icd.json 107 B
PearPass.AppImage&/> cat vk_swiftshader_icd.json
{"file_format_version": "1.0.0", "ICD": {"library_path": "./libvk_swiftshader.so", "api_version": "1.0.5"}}
PearPass.AppImage&/> cd ..
pear://dbkezmhetxwo95ab1kcojfraw1eryzf7kex5cahykf6b9c3amd6o@/by-arch/linux-x64/app>
Evergreen Architecture
The prior Ecosystem Spotlight: swap article discussed making swap with the hello-pear-bare daemon variant boilerplate. While swap is a one-shot CLI, oglr is designed primarily as a REPL (Read-Eval-Print-Loop) – an interactive session interface supplied by the command. Like a GUI, or a TUI, the user-interface lives long enough for updates to be checked in a reasonable time, whereas a one-shot command like swap must rely on a daemon to check for updates. So oglr is based on the main hello-pear-bare variant.
Both swap and oglr use the same minimal deployment flow: CI creates a build deployment folder per pear build and releases it as a tar file. The build tar is then downloaded, extracted and deployed per the pear stage → pear provision → pear multisig production release flow.
Install
With Pear CLI:
pear install pear://og1rsj1br745iyde6x1ya6j1sa99yx7r93igg9zky7t1yz5s1why
Or bootstrap with npm:
npm init oglr
Either command installs oglr onto the machine’s local binary directory.
Note if using npm instead of pear to install oglr it’s npm init oglr – “init”, not “install”. The name field of the package.json is create-oglr but the productName field is oglr. So the application is deployed peer-to-peer with pear as oglr, that’s the name of the binary executable, but a bootstrap installer is published to npm as https://www.npmjs.com/package/create-oglr.
Any npm package starting with “create-” can be executed using npm init without the “create-” portion of the namespace. The bin field is { "oglr": "install.js" } which causes npm init oglr to run install.js but the make* scripts fields point bare-build at the bin.mjs entrypoint, while pear uses the bin object key (oglr) in the pear build and pear install commands. When executed via npm init the pear-install library is used (as it is in the pear install command) to fetch the oglr binary peer-to-peer and place it into the local binary directory. The runtime for install.js is always Node.js (via npm), the runtime for bin.mjs is always Bare – embedded in a standalone binary executable with bare-build.
The “create-” prefixed namespace on npm is underutilized and there can be friction to publishing to a namespace, even when it’s available. The “oglr” namespace is available but according to npm it’s too similar to a pre-existing package named “ol”. But there’s no friction around publishing as the “create-oglr” namespace. The oglr repository demonstrates this pattern for utilizing the “create-” prefixed namespaces for P2P bootstrap installation to surface the notion that this is a pattern worth considering.
What will you build?
The oglr and swap repositories are applied demonstrations of what can be built and deployed with Pear, what would you like to build?
The boilerplates provide a basis for creating and deploying peer-to-peer applications with over-the-air updates. For CLIs use a hello-pear-bare variant for Desktop GUIs start with hello-pear-electron.
Join the Pear Development group on Keet to share what you’re building and follow the ecosystem as it grows.
