Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 515898 - =dev-libs/openssl-0.9.8z_p2-r2: shell quoting snafu
Summary: =dev-libs/openssl-0.9.8z_p2-r2: shell quoting snafu
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2014-07-01 00:47 UTC by Greg Turner
Modified: 2014-07-31 10:24 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
openssl-0.8.8z_p2-r2.ebuild_shell-quoting.patch (openssl-0.8.8z_p2-r2.ebuild_shell-quoting.patch,452 bytes, patch)
2014-07-01 00:47 UTC, Greg Turner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Turner 2014-07-01 00:47:11 UTC
Created attachment 380020 [details, diff]
openssl-0.8.8z_p2-r2.ebuild_shell-quoting.patch

For the longest time I've been stumped by the following behavior:

# ebuild /usr/portage/openssl-0.9.8z_p1-r2.ebuild digest 
>>> Downloading 'ftp://gg3.net/pub/linux/gentoo/distfiles/openssl-0.9.8z[.tar.gz'
--2014-06-30 17:32:08--  ftp://gg3.net/pub/linux/gentoo/distfiles/openssl-0.9.8z[.tar.gz
           => '.listing'
...

followed by the obvious results of trying to find openssl-0.9.8z[.tar.gz.

I knew the error happened somewhere in the "tr" statement at the top of the ebuild but was stumped as to why since at the terminal I couldn't reproduce the result:

# echo 1 | tr [1-9] [a-i]
a

Well it turns out this was the culprit:

# ls -l /usr/lib64/portage/pym
total 156
-rw-r--r-- 1 root root 109542 May 30 22:12 1
drwxr-xr-x 1 root root   2694 Jun 29 04:05 _emerge
-rw-r--r-- 1 root root  39996 Jun 25 12:51 no
drwxr-xr-x 1 root root    706 Jun 29 04:05 portage
drwxr-xr-x 1 root root    126 Jun 29 04:05 repoman
-rw-r--r-- 1 root root   7292 Sep 29  2013 yes

Somehow I got those crufty 1, no and yes files where PWD happened to be when tr was being executed, which was triggering some kind of bash quoting bullshit (I didn't bother trying to fathom the actual bash 'feature' at work, seeing as how the solution was obvious now).

The enclosed patch fixes the quoting of the tr command to work (even on my system with those weird crufty shell-code-vomit-files.
Comment 1 Alex Xu (Hello71) 2014-07-01 00:57:24 UTC
while it's still a good idea to patch this, why do you have !@#$ dumped in a core system component anyways?
Comment 2 Greg Turner 2014-07-01 02:45:13 UTC
(In reply to Alex Xu (Hello71) from comment #1)
> while it's still a good idea to patch this, why do you have !@#$ dumped in a
> core system component anyways?

It's most likely a result of some temporary coding error on my part.  I do a lot of ebuild hacking, and this directory is the default $PWD of portage.  I got rid of the files; if they return I'll need to think about where they may have come from but my guess is, they won't.

It is a bit weird though, that they got past sandbox somehow.  I usually have it enabled.
Comment 3 SpanKY gentoo-dev 2014-07-31 10:24:37 UTC
should be all set now in the tree; thanks for the report!

Commit message: Clean up bad code style for computing PLEVEL
http://sources.gentoo.org/dev-libs/openssl/openssl-0.9.8z_p1-r1.ebuild?r1=1.10&r2=1.11
http://sources.gentoo.org/dev-libs/openssl/openssl-0.9.8z_p1-r2.ebuild?r1=1.6&r2=1.7