Jayesh Badwaik wrote:
> Now whenever a new package is installed. It will contain an XML file
> containing description of the mimetype in the same manner. When the
> package is installed, the file will be transferred to a folder. The
> main file which contains the descriptions of the mime type will be
> somewhere else. This folder will contain the mime files which have not
> yet been incorportated into the main file.
>
> Now, a program would run which will take this folder and the original
> file as the default arguments and then update the file types. If there
> is a conflict, especially if the priority of the application for the
> mime type is already taken, then there can be a ncurses based
> resolution window, letting window resolve the conflict (modeled on the
> file association selectors in Windows applications). The priority in
> the package files can be -1 if the file wants to go to the last
> priority if possible. (like the nice factor of the processes)
>
> But no one can occupy the priority zero. Suppose a user opens an app
> using open with command and then checks the box, then automatically an
> entry is created in the folder with priority zero and then it is
> updated. This way, automatic software will never trump the user set
> defaults under any circumstances and the conflict management would
> prevent the irritation at the file open time. I am sure people are
> more careful during install than they are during file opening.
>
> Now the final XML file is created. This file can be then modified into
> whatever is demanded by any DE etc etc. What do you think?
XML is such a nasty beast to handle, especially for such a simple
application. I'm using a custom lessopen command as a companion to
less(1). My lessopen keeps a simple textfile with one
mimetype/extension/open-helper per line. Each file is checked against
this "database" with "file -Lsbz --mime-type" or "file -Lsb
--mime-type". If a specific mimetype/extension/open-helper tuple cannot
be found, the user is queried for it.
In your case you want a unified database, because new programs may
suggest some entry. This requires merging and conflict resolution.
I wouldn't go this way, I'd just use two different databases, where the
user supplied one is checked first and a distribution one second (or
last, in case the searching stops here).
Database entries look like this (mimetype "_:_" extension ":::" helper):
application/vnd.ms-cab-compressed_:_CAB:::7z l
# an entry with a catchall (wildcard)
application/x-executable_:_*:::readelf -d "${FILE}"; strings -a <
If a filename contains several dots, the last few are taken to be the
extension unless a catchall entry exists. Using extensions for
additional differentiation lets one use different programs in special
cases. The variable "$FILE" can be used in case the helper wants a real
file, the "<" redirection operator lets the shell handle the readonly
case.
If lessopen isn't used by less, it can equally well be used for
interactive, even GUI programs.
I wrote the script because I was not at all satisfied with the official
version, which is very complicated, doesn't let me configure my own
programs and doesn't use a separate database, everything is needlessly
hardcoded. My version is simpler and more versatile.
clemens
