Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 277013 - python.eclass python_mod_cleanup() fails with bad path
Summary: python.eclass python_mod_cleanup() fails with bad path
Status: RESOLVED FIXED
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All IRIX
: High major (vote)
Assignee: Gentoo Prefix
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-08 10:19 UTC by Stuart Shelton
Modified: 2010-03-13 13:47 UTC (History)
1 user (show)

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


Attachments
Patch to fix broken 'find' invocations in python.eclass... (python.eclass.patch,2.28 KB, patch)
2009-08-17 13:23 UTC, Stuart Shelton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Shelton 2009-07-08 10:19:20 UTC
... this may be a problem with (the latest?) bash, but here goes:

I noticed recently that python packages were installing correctly, but the "Cleaning orphaned bytecode" einfo was immediately followed by a file not found error.

It turns out that bash seems to be treating asterisks in 'find "${path}"' literally, and reporting an invalid path, whereas 'find ${path}' works correctly.

This may be new app-shell/bash-4.0_p24 behaviour, or some IRIX-specific bug in bash.

If this problem is more wide-spread, then the patch I have is:

--- eclass/python.eclass.dist
+++ eclass/python.eclass
@@ -324,7 +324,7 @@ python_mod_optimize() {
        # set additional opts
        myopts+=(-q)

-       ebegin "Byte compiling python modules for python-${PYVER} .."
+       ebegin "Byte compiling python modules for python-${PYVER}"
        if ((${#mydirs[@]})); then
                python${PYVER} \
                        "${myroot}"/usr/$(get_libdir)/python${PYVER}/compileall.py \
@@ -370,8 +370,8 @@ python_mod_cleanup() {
        fi
       
        for path in "${SEARCH_PATH[@]}"; do
-               einfo "Cleaning orphaned Python bytecode from ${path} .."
-               find "${path}" -name '*.py[co]' -print0 | while read -rd ''; do
+               einfo "Cleaning orphaned Python bytecode from ${path} ..."
+               find ${path} -name '*.py[co]' -print0 | while read -rd ''; do
                        src_py="${REPLY%[co]}"
                        [[ -f "${src_py}" ]] && continue
                        einfo "Purging ${src_py}[co]"
Comment 1 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-07-21 21:20:33 UTC
Seems to be an IRIX specific bug, should bash-4.0_p24 be masked for IRIX?
Comment 2 Stuart Shelton 2009-07-21 22:49:40 UTC
Not just yet, I don't think... I'll do some further testing to determine whether this is a regression (in bash) and report back.

To confirm though, am I right in thinking that 'find "${path}" ' and 'find ${path} ' should be entirely equivalent in all circumstances where ${path} does not contain unescaped invalid characters for a path component?
Comment 3 Fabian Groffen gentoo-dev 2009-07-22 08:03:31 UTC
(In reply to comment #0)
> It turns out that bash seems to be treating asterisks in 'find "${path}"'
> literally, and reporting an invalid path, whereas 'find ${path}' works
> correctly.

Isn't that expected behaviour?
  find "bla/*/bla" vs find bla/*/bla
the real nastyness here is that bash silently ignores the pattern if it doesn't match, and just inserts the asterisk, something on which many people unfortunately rely.

But anyway, if it's quoted the asterisk no longer works.
Comment 4 Stuart Shelton 2009-07-22 08:20:29 UTC
In that case, then bash on IRIX is working correctly, and the bug still stands!
Comment 5 Stuart Shelton 2009-08-17 13:23:47 UTC
Created attachment 201531 [details, diff]
Patch to fix broken 'find' invocations in python.eclass...


I thought I saw that this was now fixed (perhaps not in Prefix?), but today I notice that the problem is now worse, with two quote-enclosed paths appearing in python.eclass!

(This patch also fixes some minor formatting, where lines are output with einfo/ebegin/etc. would appear as "Output text .. ...")
Comment 6 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2010-03-13 13:47:30 UTC
I think that I have fixed this bug some time ago.