It would be nice to have additional parameter to list not only bundles ids for a type identifier but also their paths.
For example, in muCommander I had to used mdfind to get the path for a given bundle id - this is additional call just to get the path of an application (kinda related to bug here: https://github.com/mucommander/mucommander/issues/1162). The path is needed to: a) invoke an app for a given file, b) to display its icon. Calling mdfind adds additional delay (ok, we cache the results, but still), but it uses spotlight (some people turn it off, especially if they get annoyed by spotlight indexing external drives).
Of course the parameter name and the output is just a suggestion. I know that duti is able to return paths when using -x but only for a default app.
Additionally :) - in muC we have to run duti -e jpg to get public.jpeg, then we need to run duti -l public.jpeg - it would be also nice for -l (or hopefully -L) to accept also extensions, for example: duti -l .jpg - anything prefixed with a dot could be then considered as an extension and all the hard lifting done internally by duti and therefore lowering the number of calls to duti and making muC more responsive :)
It would be nice to have additional parameter to list not only bundles ids for a type identifier but also their paths.
For example, in muCommander I had to used
mdfindto get the path for a given bundle id - this is additional call just to get the path of an application (kinda related to bug here: https://github.com/mucommander/mucommander/issues/1162). The path is needed to: a) invoke an app for a given file, b) to display its icon. Callingmdfindadds additional delay (ok, we cache the results, but still), but it uses spotlight (some people turn it off, especially if they get annoyed by spotlight indexing external drives).So, for example now
duti -l public.jpegproduces:What about if there was for example
-Lto produce:Of course the parameter name and the output is just a suggestion. I know that
dutiis able to return paths when using-xbut only for a default app.Additionally :) - in muC we have to run
duti -e jpgto getpublic.jpeg, then we need to runduti -l public.jpeg- it would be also nice for-l(or hopefully-L) to accept also extensions, for example:duti -l .jpg- anything prefixed with a dot could be then considered as an extension and all the hard lifting done internally bydutiand therefore lowering the number of calls todutiand making muC more responsive :)