On Thu, 31 Jan 2008, chris glur wrote:
>> From Theodore Kilgore, via this mail-list I've learned that edited
> entries in mc.ext take effect after mc is restarted.
(blush)
> Images and some other types of files can have two types of 'viewing':
> one initiated by <enter> and the second by <F3=view>.
Chris, there are two available things to do here
1. Enter or mouse-click upon file
2. F3
It seems to me quite logical that, since there are two available methods
to do something to a file, one might reasonably want to make them do two
different things. Further, what those two different things are might
depend upon what type of file it is.
>
> My one installation which uses mc ver 4.5.55, has the 'display'
> application, which works well for images. But a later installation
> uses 'eye of gnome' and I can't find the location/name to call it
> from inside mc.ext.
> Can someone help: where is the executable for 'eye of gnome' ?
I suspect by the name that "eye of gnome" is part of the GNOME package.
Thus, whether it is present or not on your computer will probably depend
upon whether GNOME is installed on your computer, or not. That in turn
probably has something to do with your choice of distro. Some distros run
only GNOME and some others not at all, having gone in the direction of KDE
instead.
One can't expect the MC project, which is producing its own product
independent of both the distros and the makers of various image viewer
programs, to provide an option for all and every image viewer program
which is the default viewer program for distro X, Y, or Z. Well, actually,
come to think of it, more _could_ be done but it probably still would not
suit everybody and therefore would probably be wasted effort. Here follow
a couple of attempts, each of which has obvious shortcomings:
The extensions file is based upon constructions related to bash script;
the main difference being that in a bash script one should put in
something like $1 instead of %f. So let's play. The following syntax does
work at the command line to display the named file:
$ if [ -x /usr/bin/display ]; then display aox_pic001ppm & fi
Note: if you want to try this at home, then type it like this
if [ -x /usr/bin/display ] (hit enter here, and see the >, type more)
> then display aox_pic001ppm & (hit enter again)
> fi (hit enter again and it should now display the file)
Thus, this could be combined in a string where various possibilities are
given, and the first one that comes up will get used. For example, the
following shell script works, passing over the program "eeyes" which is
not here, and then running "display" (I wrote this script just now in a
file called "tester" because that is easier than to make it come out right
on the command line, and then I did "sh tester aox_pic011ppm")
if [ "$DISPLAY" = "" ].
then.
zgv $1
elif [ -x /usr/bin/eeyes ].
then
gqview $1 &.
elif [ -x /usr/bin/display ]
then
display $1 &.
else
echo "No viewer found!"
fi
However, there are some problems here. For example, the following will not
work but gives the message "No viewer found!" instead of giving one a nice
displaying of the image file:
if [ "$DISPLAY" = "" ].
then.
zgv $1
elif [ -x /usr/bin/eeyes ].
then
gqview $1 &.
elif [ -x display ]
then
display $1 &.
else
echo "No viewer found!"
fi
Notice that the problem is the executable file "display" has to be given
according to its full path if we run the test. That is,
elif [ -x display ]
finds no program to run, but
elif [ -x /usr/bin/display ]
successfully checks whether a file by that name exists in /usr/bin and
determines whether the file is executable, or not. When the answers are
"yes" then it runs the executable on the image file.
When I say this is a limitation, then, consider whether it will work or
not to do
elif [ -x /usr/bin/display ]
if the file just happens to be in /usr/local/bin or in /usr/X11/bin or in
the current working directory alongside the file to be viewed. The answer
is obvious, that, alas, in none of those cases would this work as it
stands, under all conceivable circumstances. The command to check for the
executable requires the path to be present, and that's that.
OK, so that approach seems not work out too well in practice; I do not
work on the mc team, but if it would not handle _all_ cases out of the box
then my reaction is that it is not worth going to such complications. It
would therefore not surprise me if I were to learn that the developers
have come to similar conclusions after some tests of their own.
It is also possible to write another program which simply checks if the
command has been successfully run or not, and then exits after the first
successful command has come up. This also works:
if [ "$DISPLAY" = "" ]
then
zgv $1
else
eeyes $1 2>/dev/null
if [ $? -eq 0 ]
then
exit 1
fi
display $1 2>/dev/null
if [ $? -eq 0 ]
then
exit 1
fi
echo "No viewer found!"
if [ $? -eq 0 ]
then
exit 1
fi
fi
However (and this is a problem of another sort) the following does not:
if [ "$DISPLAY" = "" ]
then
zgv $1
else
eeyes $1 2>/dev/null
if [ $? -eq 0 ]
then
exit 1
fi
display $1 & 2>/dev/null
if [ $? -eq 0 ]
then
exit 1
fi
echo "No viewer found!"
if [ $? -eq 0 ]
then
exit 1
fi
fi
You have to hunt for the difference between what worked and what doesn't,
but it is seen in the presence or absence of two "&" symbols. If they are
there, it means that the program to be run should run in the background.
That is probably what you want if you are running a viewer, but the script
will choke on "eeyes $1 &" and crash. For, it has no way now to check if
the program has succeeded or not, which is what the test in the next line
is doing.
Well, that does not work, either. At this point I am curious what has
actually been tried by the developers, because I do agree that you have
hit on a problem.
>
> mc.ext has some explanation of the syntax used, but I can't yet
> understand how/if:
> # C
> shell/.c
> Open=%var{EDITOR:vi} %f
> Compile=%var{CC:cc} -O -c %f
> Link=%var{CC:cc} -O -o %d/`basename %f .c` %f
> ---- would 'process' C-sources.
> Apparently the chosen editor would be 'vi'.
> The mc-default editor is much better ?
Look out. There are those who think that vi is better than sex and sliced
bread. There are others who don't think so. The two groups love to get
into flame wars. Don't go that way. :)
> If the editor is activated by <enter>, how are 'compile' & 'link'
> activated ?
>
Good questions. I do some of that stuff with my own scripting if I find
that I do enough of such things. For example, I am a mathematician and I
use a lot of TeX stuff. The required steps of edit-compile-debug and then
run (in this case equivalent to "view or print finished product") are
similar. I wrote some scripts years ago to handle the busywork. In fact I
wrote them for Norton Dos which had a UNIX-like command shell that allowed
one to write real scripts. Then I installed Win95 and found out everything
I had done was disabled and no appropriate substitutes were available,
either. Win95 stayed on my computer for approximately one week and was
deleted because it was right then that I heard there was a new operating
system called Linux.
>
> It seems a pity not to tune-the-system to be able to save all these
> extra labour-saving mc facilities ?
Well, you don't have to do everything with mc, and in fact you can't. Take
the above as an example, and consider. If I have a file with suffix .tex
then I might want just to use F3 to view it. So I had better leave that
option alone. That leaves "Open." Which do you choose for that. Edit, and
if so with how many options? Or do you choose "run TeX or LaTeX?" Choose
one, unless you write your own frontend script with the selections you
want, and _that_ is your choice for "Open" (as it is for me, in fact). So
my point is that you cannot use an mc kind of interface (or a GUI, for
that matter) for every conceivable thing. What mc does, though, it does
very well.
Theodore Kilgore
_______________________________________________
Mc mailing list
http://mail.gnome.org/mailman/listinfo/mc
