mailcap to mc.ext script
Hi!
I've just wrote a script which generates a /etc/mc/mc.ext file using
information from mime.types and mailcap files.
I found it very useful. It takes a list of extensions from mime.types
then check if in mailcap we've got support for that extension.
If yes it put this extension do mc.ext and assings action (run-mailcap).
I think, it's very good to automate generating mc.ext file.
When user install software that provides /etc/mailcap record it will be
automagically added to mc.ext.
Please, share with me with your opinions.
PS.
I'm not good in writing shell scripts, and this script is running very
slow. If you can, please improve it.
Regards.
Marcin
--
.---, --: mcINEK :--
/ ,. \ ' T h e O w l s a r e n o t
| | ; ;W h a t T h e y S e e m . . . '
\ `._ /wrote on Debian GNU/Linux SID
# !/bin/bash
# This script converts /etc/mailcap records to Midnigh Commander
# configuration file /etc/mc/mc.ext.
#
# Author: mcINEK <[EMAIL PROTECTED]>
mailcap_file="/etc/mailcap"
mime_types_file="/etc/mime.types"
mc_ext_file="mc.ext" # just debug, change it to /etc/mc/mc.ext
tmp_file="/tmp/mc.ext.tmp"
if [ ! -e $mailcap_file ]; then
echo "Can't find $mailcap_file"
echo "Be sure that mail-support package is installed."
exit
fi
echo "Generating $mc_ext_file ..."
cat $mime_types_file | sed '/^#.*/d' | sed '/^$/d' > $tmp_file
{
echo "# This file is generated by a script."
echo
} > $mc_ext_file
while read line; do
mime_type=`echo $line | awk -F' ' '{ print $1 }'`
mime_ext=`echo $line | awk -F' ' '{ for(i=2;i<=NF;i++) {print $i} }'`
ext_count=`echo $mime_ext | awk '{ print NF }'`
if [ $ext_count == "0" ]; then
continue
fi
is_in_mailcap=`grep "$mime_type" $mailcap_file`
if [ "$is_in_mailcap" == "" ]; then
echo -n "."
continue
fi
# put a mime type into file (optional)
# you can comment it out
echo "# $mime_type" >> $mc_ext_file
if [ $ext_count == "1" ]; then
echo "shell/.$mime_ext" >> $mc_ext_file
else
for ((i=0; i<$ext_count; i++)); do
mime_ext=`echo $mime_ext | sed 's/ /|/'`
done
echo "regex/\\.($mime_ext)\$" >> $mc_ext_file
fi
echo " Open=run-mailcap $mime_type:%f" >> $mc_ext_file
echo >> $mc_ext_file
echo -n "o"
done < $tmp_file
rm $tmp_file
echo
signature.asc
Description: PGP signature
Re: mailcap to mc.ext script
W liście z wto, 13-05-2003, godz. 12:43, Andreas Tille pisze: > > Please, share with me with your opinions. > If I would be you I would file a wishlist bug against mc package and > tag it "patch" by providing your script. But first I wanna know if it what I done is good ;) So, I will wait for opinions. Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap to mc.ext script
I found better solution. Don't generate a mc.ext file, just use
run-mailcap for default action for every file. And also we can keep a
few special treating files, like ie. archives.
I've attached my proposition of mc.ext and I'm going to add this to a
wishlist.
Regards.
Marcin
--
.---, --: mcINEK :--
/ ,. \ ' T h e O w l s a r e n o t
| | ; ;W h a t T h e y S e e m . . . '
\ `._ /wrote on Debian GNU/Linux SID
# Midnight Commander 3.0 extension file
# Warning: Structure of this file has changed completely with version 3.0
#
# All lines starting with # or empty lines are thrown away.
# Lines starting in the first column should have following format:
#
# keyword/descNL, i.e. everything after keyword/ until new line is desc
#
# keyword can be:
#
#shell (desc is, when starting with a dot, any extension (no wildcars),
# i.e. matches all the files *desc . Example: .tar matches *.tar;
# if it doesn't start with a dot, it matches only a file of that name)
#
#regex (desc is an extended regular expression)
# Please note that we are using the GNU regex library and thus
# \| matches the literal | and | has special meaning (or) and
# () have special meaning and \( \) stand for literal ( ).
#
#type (file matches this if `file %f` matches regular expression desc
# (the filename: part from `file %f` is removed))
#
#directory (matches any directory matching regular expression desc)
#
#include (matches an include directive)
#
#default (matches any file no matter what desc is)
#
# Other lines should start with a space or tab and should be in the format:
#
# keyword=commandNL (with no spaces around =), where keyword should be:
#
#Open (if the user presses Enter or doubleclicks it),
#
#View (F3), Edit (F4)
#
#Include is the keyword used to add any further entries from an include/
#section
#
# command is any one-line shell command, with the following substitutions:
#
# %% -> % character
# %p -> name of the current file (without path, but pwd is its path)
# %f -> name of the current file. Unlike %p, if file is located on a
# non-local virtual filesystem, i.e. either tarfs, mcfs or ftpfs,
# then the file will be temporarily copied into a local directory
# and %f will be the full path to this local temporal file.
# If you don't want to get a local copy and want to get the
# virtual fs path (like /#ftp:ftp.cvut.cz/pub/hungry/xword), then
# use %d/%p instead of %f.
# %d -> name of the current directory (pwd, without trailing slash)
# %s -> "selected files", i.e. space separated list of tagged files if any
# or name of the current file
# %t -> list of tagged files
# %u -> list of tagged files (they'll be untaged after the command)
#
# (If these 6 letters are in uppercase, they refer to the other panel.
# But you shouldn't have to use it in this file.)
#
#
# %cd -> the rest is a path mc should change into (cd won't work, since it's
# a child process). %cd handles even vfs names.
#
# %view -> the command you type will be piped into mc's internal file viewer
# if you type only the %view and no command, viewer will load %f file
# instead (i.e. no piping, so it is different to %view cat %f)
# %view may be directly followed by {} with a list of any of
# ascii (Ascii mode), hex (Hex mode), nroff (color highlighting for
# text using backspace for bold and underscore) and unform
# (no highlighting for nroff sequences) separated by commas.
#
# %var -> You use it like this: %var{VAR:default}. This macro will expand
# to the value of the VAR variable in the environment if it's set
# otherwise the value in default will be used. This is similar to
# the Bourne shell ${VAR-default} construct.
#
# Rules are applied from top to bottom, thus the order is important.
# If some actions are missing, search continues as if this target didn't
# match (i.e. if a file matches the first and second entry and View action
# is missing in the first one, then on pressing F3 the View action from
# the second entry will be used. default should catch all the actions.
#
# Any new entries you develop for you are always welcome if they are
# useful on more than one system. You can send your modifications
# by e-mail to mc-devel@gnome.org
### Changes ###
#
# 2003-05-13 Using run-mailcap
#
# Reorganization: 2000-05-01 Michal Svec <[EMAIL PROTECTED]>
### Archives (to enable 'passing thru' like dirs) ###
# .tgz, .tpz, .tar.gz, .tar.z, .tar.Z
regex/\.t([gp]?z|ar\.g?[zZ])$
Open=%cd %p#utar
View=%view{ascii} gzip -dc %f 2>/dev/null | tar tvvf -
mailcap next step
Hello! I was wondering how to improve mailcap system to become useful. First step was to able mc use mailcap. Now, I want to make nautilus to use mailcap. And I have a few questions. 1. Where nautilus (gnome2?) keeps info about mime types? 2. (more complicated) Does run-mailcap differs x and non x applications? Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? Regards. Marcin -- .--, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: > If you already parsed mailcap into mc's configuration, you should've > seen this (picking out a random one): > > application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; > test=test "$DISPLAY" != "" ; description="OpenOffice.org 1.0 Drawing"; > nametemplate=%.sxd > > Take extra care to the 'test' parameter. > > > Could be posible run ie. links in mc and galeon in nautilus by the same > > run-mailcap command? > > If you can create a test to accomplish that, sure. Yes, I've seen it. BUT... This is galeon entry in /etc/mailcap: text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n "$DISPLAY"; nametemplate=%s.html Even if I change it, to run links if not $DISPLAY it would be bad solution. User can't choose which browser use. In addition, it's another record from the same file. text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n "$DISPLAY"; nametemplate=%s.html We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) text/html; if DISPLAY run x-www-browser else run www-browser that's all. When user want to change one of browsers just use update-alternatives --config. This mechanism may be applied not only for browser, but image-viewers etc. What do you think about that? (I hope you understanded me ;) Regards. Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: > Here's your error: if you do that, it's not the user who can change his > browser, but the system administrator. Those two are not always the > same. But, does it eliminate my soluton? As you wrote later, user always can change /etc/mailcap. I didn't wonder how it would be on multi-users machines but I don't think it could be 'worse'. On the contrary, for one-user machines it will be very good and fast solution to make their programs runing apps like they want. The don't need to wonder what app will be starded, just that what they choose by update-alternatives. And also, this apps may be different for xwindows or console. What is more, everything will be doing automatically. I think it can be interesting. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: > I really think it would be a bad idea to go the alternatives road here. But why? Could you give me any reasons? I've said why yes, so you tell why not ;] > If you must, you could write a front-end that parses /etc/mailcap, and > for a given MIME type, allows a user to pick the application of his/her > choice; the front-end could then write that to ~/.mailcap. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 13:49, Wouter Verhelst pisze: > Alternatives and mailcap are two different worlds. Please keep them > separated. OK, so leave alternatives. > > It won't work, because the aren't any 'standards'. I don't have idea how > > make x/non-x choice from mailcap. I REALLY think alternatives could be > > good. > > It's done in there, all over the place! There's a 'test' option, which > is meant to use a line conditionally; it's commonly used to test whether > $DISPLAY is set, which is *exactly* what you need. No, it doesn't. There can be more tjan one line describing the same mime type. And what then? Solving this problem will be sorting content of /usr/lib/mime/packages by appropiate types, such as: /usr/lib/mime/packages/text-html/mozilla, content (example): x,/usr/bin/mozilla /usr/lib/mime/packages/text-html/links content: text,/usr/bin/mozilla And on that base update-mime can generate /etc/mailcap. Of course if they'd be more browsers it only can choose one, but in the present time it's the same. If there'd be a types tree like that making front-end will make sense, otherwise no. User'd choose a program from that directory structure. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: > Uh. You can create such a tree in-memory, no? Parsing the file is not > *that* hard. Of course, I can. But I don't understand why don't improve BAD mechanism. If sth is bad and doesn't pass our requests we should change it. Is update-mime a 'holy cow'? Nevertheless if it's just my opinion I won't argue and don't touch anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: > I fail to see why it would be bad. It's not perfect, but that's far from > the same thing. Moreover, I think your ideas would make things worse, > rather than better. It's not perfect. Importand bugs are for me: * doesn't allow to choose what program use * it skip more than one application for one type Our task is to think, when it would be good, and what we're gonna do. Of course, we can leave it as it is now, but then we won't go further in making Debian better and more and more useful. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 15:42, Wouter Verhelst pisze: > Yes it does. Create a ~/.mailcap with the application of your choice for > a given MIME-type at the top. > > My suggestion of a front-end was to create some application that would > help $USER to manage ~/.mailcap. I think it's good idea too. It could be done even now. But that what I'm trying to say, is we shouldn't use long ways. Solution you suggested is a 'little bubble' which you wan't stick to exist mechanism. I will work, however, it's just a bypass. It's a fine frontend to ulgy mechanism, which indeed doesn't work (if you have to parse generated file, it doesn't work). The clue is to think about efficient mechanism, which works globally and can be adapted by user in *simple* ways (not by a giant/slow script which parse conf file). > Please point me to where I said we should leave things as they are. You didn't say that, but you want use *minimal* solution, which aren't always good. PS1. Windows are done this way. MS created took w2k and sticked more,more and more programmic 'bubbles' and created one big shit :) PS2. Maybe I wrote my definition of 'bubble': 'Bubble' is a short code, which you can put(stick) to original code without changing anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: > What's that supposed to mean? Doing that does have its advantages, too > (such as "you don't have to re-integrate everything with the new > system"). > > Granted, pushing that to extremes will end you up with an unworkable > system with hundreds of incompatible API's. That's not what this does. But only if this API is good. If API is wrong and don't have support for new useful options, should be changed or improved. API is a solid, stable base for building additions, however, it must be simple and thought over. Besides, it's not such a basic feature, which requires change system core. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
W liście z czw, 15-05-2003, godz. 17:06, Wouter Verhelst pisze: > It is, IMHO. IMHO not, because doesn't provide things I mentioned before. > Who says it doesn't? Like above. > No, but lots of applications use it. Yes, that's true. Nevertheless, it shouldn't be a brake in improving it. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
I'm attaching two scripts. One just converts 'old'
/usr/lib/mime/packages/ directory to 'new' one. Why I'll explain later.
Next is replacement for update-mime script to use 'new' format. It
generates full compatible mailcap file, but inserts just one application
(x and non x) for each mime type. I think this solution isn't worse than
original. Although this script has one *big* disadvantage... It's shell
script and it's very slow. I'm sorry but I don't know perl. Nevertheless
it can't be improved, it's just a sample.
Now, why I think my structure of files in /usr/lib/mime/packages is
better. It's very simple to take control of it. System wide script (my
update-mime2) looks at .default files for each type and puts into
mailcap. If it doesn't find defaults (admin didn't choose one) it puts
first from directory (such as old one). In conclusion, we see that we
generally don't loose usability but we're getting new one. Of course,
this script propably doesn't use all of original update-mime features,
because I don't even know them, but I can be improved.
In contrast the 'power' of this special directory structure is appearing
for user, not administrator. It's very easy to write a frontend to
select apps from that tree. For each type it can show user all
posibilities and extra show administrator suggestion (.default). Then in
*simple* way it'd generate ~/.mailcap file.
As we see, we don't loose usability, even compatibility. I replaced just
one script, and provide converter for temporary. Please, look at it, and
thinks is it interesting. Say rather about 'idealogic' solution, not
technically scripts, because they can be improved by someone, who's good
at it.
PS. I'm now using this on my computer and I don't have any problems. I
work know on a kind of frontend.
PS2. For tests, you can change directiories in scripts vars.
Regards,
Marcin.
--
.---, --: mcINEK :--
/ ,. \ ' T h e O w l s a r e n o t
| | ; ;W h a t T h e y S e e m . . . '
\ `._ / wrote on Debian GNU/Linux SID
#! /bin/bash
#
# This sctipt is a replacment for update-mime.
# It uses new format of /usr/lib/mime/packages dir.
#
# Author: mcINEK <[EMAIL PROTECTED]>
#
if [ -x /usr/sbin/update-mimedir ]; then
/usr/sbin/update-mimedir
fi
mime_dirs="/usr/lib/mime/packages"
mailcap="/etc/mailcap"
dirs=`find $mime_dirs -type d | sort`
if [ "$mime_dirs" == "" ]; then
echo "Is /usr/lib/mime/packages using new format?"
exit
fi
echo "# File generated by update-mime2 script." > $mailcap
echo >> $mailcap
for dir in $dirs; do
[ ! "$dir" == "$mime_dirs" ] || continue
dir=`echo "$dir" | awk -F\/ '{ print $NF}'`
cd "$mime_dirs/$dir"
# check, if there's any program
[ ! "`ls`" == "" ] || continue
# looking for non x program, sed to make sure if chosen only one
x_program=`ls x.*.default 2> /dev/null | sed q1`
if [ ! "$x_program" ]; then
# choose first available
x_program=`ls x.* 2> /dev/null | sed q1`
fi
# if not will use terminal program
# chech for a default term program
term_program=`ls --ignore='x.*' 2> /dev/null | grep .*.default | sed q1`
if [ ! "$term_program" ]; then
term_program=`ls --ignore='x.*' 2> /dev/null | sed q1`
fi
mime_type=`echo $dir | sed 's/\./\//'`
#echo "X - $x_program T - $term_program"
if [ "$x_program" ]; then
echo "$mime_type; `cat $mime_dirs/$dir/$x_program`" >> $mailcap
fi
if [ "$term_program" ]; then
echo "$mime_type; `cat $mime_dirs/$dir/$term_program`" >> $mailcap
fi
echo >> $mailcap
echo -n .
done
echo
#! /bin/bash
#
# This script converts old /usr/lib/mime/packages
# to new format.
#
# Author mcINEK <[EMAIL PROTECTED]>
#
mimedirs="/usr/lib/mime/packages"
new_mimedirs=$mimedirs
files=`find $mimedirs -type f -maxdepth 0 | awk -F\/ '{ print $NF }'`
[ ! "$files" == "" ] || exit
for file in $files; do
while read line; do
[ ! "$line" == "" ] || continue
mime_type=`echo $line | awk -F\; '{ print $1 }'`
mime_dir=`echo $mime_type | sed 's/\//./'`
#echo $mime_type # choose one of two: this
echo -n . # or this
mkdir "$new_mimedirs/$mime_dir" 2> /dev/null
if [ "`echo $line | grep DISPLAY`" == "" ]; then
echo $line | awk -F' ' '{ for(i=2;i<=NF;i++) {printf("%s ",$i)} }' \
> "$new_mimedirs/$mime_dir/$file"
else
echo $line | awk -F' ' '{ for(i=2;i<=NF;i++) {printf("%s ",$i)} }' \
> "$new_mimedirs/$mime_dir/x.$file"
fi
done < "$mimedirs/$file"
rm "$mimedirs/$file" 2> /dev/null
done
echo
signature.asc
Description: PGP signature
Re: mailcap next step
W liście z pią, 16-05-2003, godz. 13:05, Michał Politowski pisze: > You obviously haven't read man mailcap.order? I've read, when you first time told me. It's just a step to provide that usability like my script. Please, look at this two opions objectively. Forget, that one of them is already implemented. First in administrator point of view. When you are administrator on non-your computer, you propably don't care about mime types, and you even don't change mailcap.order. If it's your machine, of course you can modify mailcap.order. But when you install apps or remove you must edit it manually. When you've got a lot of preferences mailcap.order is big and it's hard to find sth. Nevertheless, you propably use user account to work. And here is 'magic'. If you are advanced user (and of course you are :) you could copy /etc/mailcap to ~/.mailcap, sort it, and than just erase dubbling lines to chose that apps you want. It's ok, and it wasn't as much difficult (for you). However, imagine a user who doens't know a lot about all sfuff conencted with mime types (They are people like them too!!!). He propably won't know what to do. Here comes help. A frontend. Certainly, you can write a frontend parsing big file, and after hard work you propably will manage it to show info in simple way to user. But what for??? Now, it's so much easier to write a good, *fast* frontend in every language. Because, you've got clean (and soft :) directory structure with types. Besides, there's still a posibility to generate full mailcap like old one (if you want to). You can ask: why change sth? And I'd tell you: Because new solution is easier to improve, it's solid base to make any kind of apps making sth with mime. And if is not right now (I'm sure about it), we should improve it, or even find better. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
