Re: mc <F3> to view *.gif/jpg/pgm ...?

[kilgota banach math auburn edu]

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