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 pattern. (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): #!/bin/bash if [ "$#" != 1 ]; then ... error ... fi url="${1/[%]/%25/}" case "$url" in (/* | ./*) ;; (*) url="./$url" ;; esac exec xdg-open "$url" Regards, smcv