Proposal: use /usr/bin/open as an alternative for run-mailcap and others.
smcv at debian.org
Wed Oct 7 23:17:34 BST 2020
On Thu, 08 Oct 2020 at 05:54:27 +0900, Charles Plessy wrote:
> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
> As I maintain the mime-support package (soon to be split in `mailcap`
> and `media-types`, seee #964850), that provides the `run-mailcap`
> command to open files, I propose to provide /usr/bin/open as a symbolic
> link to it using the alternatives system.
> While `run-mailcap` has mutiple command-line options, I would like to
> define the "interface" of /usr/bin/open as having a single argument
> only, which is a path to a file or a directory. This would give the
> opportunity for other packages such as xdg-utils to provide
> /usr/bin/open if they wish so.
Is this intentionally a filename, and not a URI reference like the
argument to xdg-open(1), the `gio open` subcommand in gio(1), and macOS
open(1)? In particular, if we're using this name by analogy with the
command in macOS, it doesn't seem great to be using a different invocation
(In most cases a relative or absolute path turns into a URI reference
that evaluates to the file:/// URI of the file you first thought of,
although there are differences - you'd have to prepend './' to filenames
with a ':' before '/', and filenames with '%' could be misinterpreted.)
If open(1) is defined to take only a single local file or directory
argument, and URI-based programs like xdg-open and gio open are allowed
to be alternatives for it, then I think it's inevitable that we will
have bugs where people incorrectly assume that open(1) is *always*
able to act on a URI argument, unless the URI-based programs are always
invoked via a wrapper something like this (untested):
if [ "$#" != 1 ]; then
... error ...
case "$url" in
(/* | ./*)
exec xdg-open "$url"
More information about the Pkg-freedesktop-maintainers