Summary: | SRC_URI: spaces not supported | ||
---|---|---|---|
Product: | Portage Development | Reporter: | kalium |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to support spaces in SRC_URI |
Description
kalium
2005-08-15 06:46:56 UTC
Maybe we can simply add some double quotes around \${URI}. FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P \${DISTDIR} \"\${URI}\"" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P \${DISTDIR} \"\${URI}\"" that doesnt fix internal handling of SRC_URI/A in portage ... personally i dont think it's really worth the time; dont use spaces in your URLs :p i'm pretty sure this has been covered before, just cant seem to find the bug spaces won't play nice in the digests either... Just run wget like wget -O 'filename' '$SRC_URI' and all is fine because it does not replace the %20 with spaces in that case. So spaces are no problem in the URL if you use URL encoding... btw: couldn't you allow real spaces by considering escape characters, ie. in the form "these\ are\ spaces"? As far as I remember, digest files should not have problems with spaces. At least not if handled correctly: if there is only one file name per line and all other fields on the same line have predefined lengths or adjacent separators, the parsing of such a line should be no problem. your sanest bet is what you suggested in Comment #4 Created attachment 69314 [details] Patch to support spaces in SRC_URI Example: SRC_URI="http://www.site.com/foo%20bar%20here.tar.gz" really shouldnt hardcode that kind of stuff find an html decoder function which translates encoded URL's to the proper format This was discussed on the portage-dev ml and decided on: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2054/focus=2054 Short summary: NOTABUG |