Bug 31444

Summary: spurious capture of which in KMIMETYPEFINDER
Product: Portland Reporter: Christopher Yeleighton <giecrilj>
Component: xdg-utilsAssignee: Portland Bugs <portland-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium CC: rdieter
Version: 1.0   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Christopher Yeleighton 2010-11-07 06:19:57 UTC
I wonder what the purpose of the following lines in xdg-mime would be:

        KMIMETYPEFINDER=`which kmimetypefinder 2>/dev/null`
        $KMIMETYPEFINDER "$1" 2>/dev/null | head -n 1

Since the variable KMIMETYPEFINDER is not used anywhere else, the following equivalent form would be more efficient:

        kmimetypefinder "$1" 2>/dev/null | head -n 1

Of course, there is a subtle difference when kmimetypefinder cannot be found (that means, of course, that the PATH is set to a weird value or the system is damaged).  In this case,  the error message is forcibly silenced and the argument $1 gets SILENTLY EXECUTED, which is why I set severity to Major.
Comment 1 Rex Dieter 2010-11-18 14:38:59 UTC
This seems odd to me at first glance too.

Unless I hear any cries to keep or justify this code in the next few days, I'll amend it as suggested.
Comment 2 Fathi Boudra 2010-12-31 02:37:25 UTC
I guess it's a copy/paste from the KDE3 support code, adapted for KDE4 support:

if [ x"$KDE_SESSION_VERSION" = x"4" ]; then
    DEBUG 1 "Running kmimetypefinder \"$1\""
    KMIMETYPEFINDER=`which kmimetypefinder 2>/dev/null`
    $KMIMETYPEFINDER "$1" 2>/dev/null | head -n 1
else
    DEBUG 1 "Running kfile \"$1\""
    KFILE=`which kfile 2>/dev/null`
    $KFILE "$1" 2> /dev/null | head -n 1 | cut -d "(" -f 2 | cut -d ")" -f 1
fi

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.