Bug 151621

Summary: RPMs fail to install with spaces in the directory name
Product: [Fedora] Fedora Reporter: James Hall <rio>
Component: system-config-packagesAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: ejhuff, felipe.contreras, mporta, roessler
Target Milestone: ---Keywords: EasyFix
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-06 21:58:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Hall 2005-03-20 23:31:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
RPMs cannot be installed from a directory with a space in its name.

Version-Release number of selected component (if applicable):
rpm-4.3.2-21 nautilus-2.8.1-4

How reproducible:
Always

Steps to Reproduce:
1. Open nautilus
2. Make a new folder with a space in it, i.e. "My Downloads"
3. Move an RPM into the folder and double click it
  

Actual Results:  Produces the following error message:

Could Not Open Package

The file "/home/rio/My" could not be read.  Make sure that you have the proper permissions on it

Expected Results:  The package should have been loaded.

Additional info:

Comment 1 rudolf kastl 2005-03-22 01:39:04 UTC
tried it out and can confirm that.

Comment 2 James Hall 2005-04-25 17:43:18 UTC
Executing the following command as root user and non-privalidged user has the
following effect:

1. Open Terminal
2. type "system-install-packages /home/rio/My\
Downloads/AdobeReader_enu-7.0.0-1.i386.rpm"
3. Produces the error described above
4. su -
5. type "system-install-packages /home/rio/My\
Downloads/AdobeReader_enu-7.0.0-1.i386.rpm"
6. Behaves as expected

Therefore I imagine it could be a problem with the way system-auth passes
arguments. Will do more testing soon.


Comment 3 Miloslav Trmač 2005-06-12 19:40:08 UTC
*** Bug 76936 has been marked as a duplicate of this bug. ***

Comment 4 Felipe Contreras 2005-06-12 20:34:11 UTC
I can reproduce this bug.

The fix is to change /usr/sbin/system-install-packages, instead of sending $* we
should send "$@".

system-config-packages seems to have this problem too and probably some others.

However rpm still doesn't handle paths with spaces.



Comment 5 James Hall 2005-06-18 21:35:16 UTC
Problem still present in FC4

Comment 6 David Zeuthen 2005-06-22 17:56:56 UTC
Reassigning to package owner.

Comment 7 Jeremy Katz 2005-09-21 20:03:03 UTC
*** Bug 163416 has been marked as a duplicate of this bug. ***

Comment 8 Ignacio Vazquez-Abrams 2005-12-21 09:40:49 UTC
*** Bug 176311 has been marked as a duplicate of this bug. ***

Comment 9 Felipe Contreras 2005-12-21 16:10:47 UTC
I don't get it, I already told you the fix, why don't you fix it?

It is the right way to do it, if you don't believe me you can check the bash
manual; we want "$@".

*
Expands to the positional parameters, starting from one. When the expansion
occurs within double quotes, it expands to  a  single word  with  the value of
each parameter separated by the first character of the IFS special variable.
That is, "$*" is equivalent to "$1c$2c...", where c is the first character of
the value of the IFS variable. If IFS is unset, the parameters are separated by
spaces. If IFS is null, the parameters are joined without intervening separators.

@
Expands  to  the positional parameters, starting from one. When the expansion
occurs within double quotes, each parameter expands to a separate word. That is,
"$@" is equivalent to "$1" "$2" ... When there are no positional parameters,
"$@" and $@ expand  to nothing (i.e., they are removed).

Comment 10 James Hall 2005-12-21 17:09:07 UTC
Felipe Contreras,

Looks like the package owner doesn't have enough time to sort this out, so if
you could post a patch that would be great. I'd love to see this easily fixable
bug I reported 9 months ago get wrapped up.

Comment 11 Tejas Dinkar 2006-01-11 13:25:25 UTC
I really don't see why a patch is needed....

Here is what /usr/sbin/system-install-packages looks like:

exec python /usr/share/system-config-packages/SinglePackageWindow.py $*

Here is what it should look like:

exec python /usr/share/system-config-packages/SinglePackageWindow.py "$@"

There is only one line in the file

The Patch of: Felipe Contreras works in this case

Comment 12 Tejas Dinkar 2006-01-11 13:33:40 UTC
There is also one more thing I noted while trying this out:

RPM will not accept files with spaces in the path like so:
rpm -Uvh /home/tejas/My\ Downloads/gobby-0.2.2-6.fc4.i386.rpm

as other programs do.

However, rpm WILL accept the rpm if the \ is ALSO escaped. Hense, rpm WILL
install the package like this:
rpm -Uvh /home/tejas/My\\\ Downloads/gobby-0.2.2-6.fc4.i386.rpm

I don't think this should be patched here, however, and I'll post this up as an
RPM bug as well

Comment 13 Felipe Contreras 2006-01-11 17:26:02 UTC
Yes, there are two bugs, one is system-install-packages not handling spaces, and
another is rpm not handling spaces well.

I purposed a fix for system-install-packages, probably that is the way we should
be doing it, and the same thing happens for other scripts.

However the fix for rpm is something else.

Comment 14 Jeremy Katz 2006-02-06 21:58:39 UTC
This should be handled better in the system-install-packages from pirut.