better-opn
better-opn copied to clipboard
Colon-delimitation of commands in `BROWSER` is not respected
Projects with Storybook set up (which it seems uses better-opn
) fail to start for me, unless I override BROWSER
for the command. For a dozen years or more mine has been set to x-www-browser:www-browser
.
I forget what prompted me to set it that way originally, and it's a bit hard to find documentation of exactly what BROWSER
is supposed to be. After a bit of digging I found this Stackoverflow question which asks where the docs are, and one of the answers says
The
BROWSER
variable is not in the same league asEDITOR
orPAGER
- it is not mentioned by the standards. However, some programs may use them, likeman
:
man 1 man
(Debian):BROWSER If $BROWSER is set, its value is a colon-delimited list of com- mands, each of which in turn is used to try to start a web browser for man --html. In each command, %s is replaced by a filename containing the HTML output from groff, %% is replaced by a single percent sign (%), and %c is replaced by a colon (:).
Right now when it's set with a colon-separated list, better-opn
fails:
node:events:368
throw er; // Unhandled 'error' event
^
Error: spawn x-www-browser:www-browser ENOENT
at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
at onErrorNT (node:internal/child_process:477:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
at onErrorNT (node:internal/child_process:477:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -2,
code: 'ENOENT',
syscall: 'spawn x-www-browser:www-browser',
path: 'x-www-browser:www-browser',
spawnargs: [ 'http://localhost:6006/' ]
}
because I don't have anything called x-www-browser:www-browser
.
To follow the way man
uses the variable better-opn
would try each of the commands in turn. If that's overkill, just splitting by colon then running the first one would be an improvement.
Hey @tremby, sorry for the late reply.
This definitely sounds reasonable to me given it appears to be a common convention in unix tooling.
Would you be open to contributing?