{{site_title_here}}

File Editing, Chromebooks, and Development

Written by

jonathanb

in

Continuing on a tilt from my previous post on developing from a Chromebook, there are still lots of rough edges, even for developing toy projects, primarily stemming from file-system access. A simple rule has kept me out the weeds: for Node.js projects develop only from Android apps using Android app-private storage.

The File System

The Termux documentation partitions storage into three categories: private-app, shared-internal, and external. You won’t see the shared-internal storage from Termux until you run termux-setup-storage.

It appears that under Chrome OS, all Android apps have the same file permissions, which will allow you to edit source files using vim to be read by Node.js, for example. There are, however, lots of operations from Android that fail with shared-internal storage. Creating symbolic links (ln) and updating permissions fail (chmod). Running npm from the shared-internal storage results in lots of errors of the form “Error: EPERM: operation not permitted…”

The default Chrome OS document root used for file selection runs on top of the Storage Access Framework, but the default root only provides access to video, music, and SD-card, not to the private Android emulator storage. Here lies the obstacle between using Chrome apps to build executables for Termux or Crouton.

Editors

Given the rift between Android app-private and shared storage, I find it’s easiest to edit files using Android apps. There are several editors available within a few keystrokes of Termux, e.g. vim, though I wish I knew how to have multiple Termux windows open at once.

A work around to multiple windows is to use another Android app as an editor. Turbo Editor can access Termux private data once you enable the storage-access-framework option under settings. It provides syntax highlighting for HTML and JavaScript files. Under my installation, it periodically pauses, sometimes forgetting to remove the dialog box announcing the pause.

Other Directions

I’ve been scurrying about today looking for alternative methods of editing source code and general file-system access from Chromebooks:

  • Use window.webkitRequestFileSystem() Chrome has supported HTML5 file-system operations for several years now. File access is partitioned by the requesting website and stored locally in Chrome private storage.
  • Chrome app file storage. Google has discontinued support for Chrome apps outside of Chrome OS. Will they do the same within Chrome OS? chrome.fileSystem is not available to Chrome extensions.
  • Chrome storage. Chrome provides a key-value service similar to window.localStorage, except that the data are synced with the user across machines.
  • Expose file-operations to a web client. noide is an Node.js application that provides a web interface to edit source files. It has gyp dependencies that are broken from Chrome OS. There are a couple of projects that provide web-client editor widgets, one could leverage to present a front-end for a file server build with Express.
  • Use Eclipse Che or Cloud 9, but that’s not really developing on a Chromebook….
  • Switch to developer mode and replace Termux with Crouton, which reportedly yields a more faithful Linux experience, including running Electron.
  • Drop any notion of keeping local files.

More posts