Bug 249150 - grip freezes on non-full path executables
grip freezes on non-full path executables
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: grip (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Adrian Reber
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-21 10:59 EDT by Ken Dreyer
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-25 20:34:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ken Dreyer 2007-07-21 10:59:42 EDT
Description of problem:
Unless given an absolute pathname for the lame encoder, grip freezes

Version-Release number of selected component (if applicable):
grip-3.2.0-16.fc7

How reproducible:
Every time

Steps to Reproduce:
1. open Grip
2. in the menu, go to "Config" > "Encode" > "Encoder"
3. in the "encoder executable" field, specify anything other than the full path
of the lame executable; i.e., don't put "/usr/bin/lame" 
4. in the menu go to "Rip"
5. click "Rip+Encode"
  
Actual results:
Grip freezes

Expected results:
Grip should rip the CD to mp3 format as usual

Additional info:
In Fedora's Grip, the default path is just "lame" instead of "/usr/bin/lame".
This triggers this bug.
Comment 1 Ken Dreyer 2007-07-21 11:55:37 EDT
Looks like an Ubuntu user filed a report upstream on 2006-12-03:

http://sourceforge.net/tracker/index.php?func=detail&aid=1608041&group_id=3714&atid=103714
Comment 2 Adrian Reber 2007-07-23 03:22:12 EDT
I can confirm the bug report from the ubuntu user but I cannot confirm your
report that it freezes. I just get a simple box telling me it cannot find the
executable.

I am not 100% sure this needs to be fixed because the text entry is supposed to
hold the "Encoder executable" and it could be argued that this has to include
the full path. It is not too much effort to write a small patch to fix this
behaviour but I am not yet sure that it should do it.

If I start grip without any existing configuration files it defaults to
/usr/bin/lame for lame and not to just lame like you said. If you change it once
it will stay that way.
Comment 3 Ken Dreyer 2007-07-25 20:34:48 EDT
(In reply to comment #2)
> I can confirm the bug report from the ubuntu user but I cannot confirm your
> report that it freezes. I just get a simple box telling me it cannot find the
> executable.

Odd, it still freezes on me. I've tried the --verbose flag, but it doesn't give
me anything out of the ordinary. If this freeze is non-reproducible, I'll try to
troubleshoot this elsewhere.

> I am not 100% sure this needs to be fixed because the text entry is supposed to
> hold the "Encoder executable" and it could be argued that this has to include
> the full path. It is not too much effort to write a small patch to fix this
> behaviour but I am not yet sure that it should do it.
> 
> If I start grip without any existing configuration files it defaults to
> /usr/bin/lame for lame and not to just lame like you said. If you change it once
> it will stay that way.

I've tracked down the problem; I installed and ran grip before I installed lame.
 gripcfg.c's FindExeInPath() function couldn't find lame, so it defaulted to
just exename. I guess this is the safest option, particularly when lame RPM is
not in the official repos. Thanks for the help Adrian.
Comment 4 Adrian Reber 2007-07-26 03:28:10 EDT
Even if you closed the bug I will release a new version with a patch the finds
the executable. I have just put FindExeInPath() in the function that does the
actual ripping and it will find any executable if it is in $PATH.

Note You need to log in before you can comment on or make changes to this bug.