Patch to eliminate temporary scripts in the exec_extention()

Pavel Roskin proski at gnu.org
Tue Nov 5 20:04:36 UTC 2002


Hi, Andrew!

> this patch eliminates temporary scripts in exec_extension().
> Command are written to g_malloc()ed string instead of temporary
> file and executed directly by subshell or passed to popen().
> 
> Weak areas for this solution:
>   1) Shell specific syntax (None noted in the mc.ext.in).
>   2) Possibility to pollute or change environment if subshell support
>      is used (points of view differs).
>   3) exit, return or exec stop subshell execution (None noted in the mc.ext).

Let's consider some ideas for the future so that we decide about the 
direction before we start rewriting mc.ext support.

What if we replace mc.ext with a script (shell or perl) that would take
two arguments - action (Open, View, Edit) and the filename, and then
decide what to do?  That would be very flexible.

The script could check the filename, run "file", check for X11, GNOME,
KDE, select best tools based on their availability (scan PATH).  Even a
scoring system could be implemented (e.g. KDE programs would get +10
points if KDE is running, but if Mozilla has initial score 55 and
konqueror has 40, then Mozilla would be preferred even under KDE).

The script would communicate back only one thing - if the viewer or the
editor needs to be used in the output and possibly the options for the
viewer.  Of course, that would make it unnecessary to create temporary
files.  If we choose to use shell, we can use functions - all modern
shells support them.

Another purely technical suggestion for the future.  I think we need out
own popen() and pclose() that would capture stderr in the child and
optionally display it as a warning.  Let's replace every popen() with that
function - in extfs (very important), when running "file", in the viewer
(all those *_error_pipe functions should not be needed if we redirect
stderr in the child only).

Since fixing stderr in extfs is in TODO already, I may try it soon.

-- 
Regards,
Pavel Roskin




More information about the mc-devel mailing list