[arch-general] Automatic File Associations Alloting

Jayesh Badwaik jayesh.badwaik90 at gmail.com
Fri Nov 25 21:18:02 EST 2011

Yeah. I too have my personal stuff for that. I have a script actually
which uses a file and from that creates the default.list file which is
then used by anyone who cares to use it (Firefox, KDE etc). But I am
now tired of the custom stuff. I just wanted to explore. And XML
seemed quiet universal in the sense.

And I have heard a lot but I still don't get it. Why is XML a beast? I
have read everything from every source where people have even given
point wise listings. But I am not able to appreciate anything. XML is
just a way of writing data, right? Instead of parsing text you parse
tags and their values. The only difference and advantage is that the
stuff is more human readable.

Cheers and Regards
Jayesh Vinay Badwaik
Electronics and Communication Engineering

On Sat, Nov 26, 2011 at 2:48 AM, clemens fischer
<ino-news at spotteswoode.dnsalias.org> wrote:
> 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

More information about the arch-general mailing list