>>> Unpacking source... >>> Unpacking AdobeReader_enu-7.0.9-1.i386.tar.gz to /var/tmp/portage/app-text/acroread-7.0.9/work mv: cannot stat `/var/tmp/portage/app-text/acroread-7.0.9/work/AdobeReader/bin/acroread.': No such file or directory !!! ERROR: app-text/acroread-7.0.9 failed. Call stack: ebuild.sh, line 1611: Called dyn_unpack ebuild.sh, line 751: Called qa_call 'src_unpack' environment, line 2961: Called src_unpack acroread-7.0.9.ebuild, line 126: Called die !!! Failed to put acroread. back to acroread; please report nelchael ~ # ll /var/tmp/portage/app-text/acroread-7.0.9/work/AdobeReader/ total 111M 6.6M -rw-r--r-- 1 root root 6.6M Jan 5 20:57 COMMON.TAR 104M -rw-r--r-- 1 root root 104M Jan 5 20:57 ILINXR.TAR 36K -rwxr-xr-x 1 root root 34K Jan 5 20:56 INSTALL 32K -rw-r--r-- 1 root root 29K Feb 23 2005 LICREAD.TXT 80K -rw-r--r-- 1 root root 78K May 5 2006 ReadMe.htm nelchael ~ #
in french AdobeReader_fra-7.0.9-1.i386.tar.gz unpack to AdobeReader and no more in AdobeReader_fra so reming off two lines solve th pb, like this: # if [[ ${pkg} =~ "^AdobeReader_" ]]; then cd ${S} tar xf ILINXR.TAR || die "Failed to unpack ILINXR.TAR; is distfile co rrupt?" tar xf COMMON.TAR || die "Failed to unpack COMMON.TAR; is distfile co rrupt?" epatch ${FILESDIR}/acroread-scim.patch epatch ${FILESDIR}/acroread-low-startup-fontissue.patch epatch ${FILESDIR}/acroread-expr.patch ll=$(acroread_get_ll ${pkg}) mv bin/acroread bin/acroread.${ll} if [[ -z ${fl} ]]; then fl=${ll} linguas="${ll}" else linguas="${linguas} ${ll}" fi # fi
This problem occurs if you are using bash version >=3.2. The syntax of the [[ .. =~ .. ]] construct has changed: # pre 3.2 # if [[ ${pkg} =~ "^AdobeReader_" ]]; then # new syntax if [[ ${pkg} =~ ^AdobeReader_ ]]; then Maybe we need a test here like [ ${BASH_VERSINFO[0]} == 3 ] && [ ${BASH_VERSINFO[1]} -gt 1 ] && ...
(In reply to comment #2) > Maybe we need a test here like > [ ${BASH_VERSINFO[0]} == 3 ] && [ ${BASH_VERSINFO[1]} -gt 1 ] && ... Hm, wouldn't it be better to replace this with a standard compliant syntax? Like: [ AdobeReader_${pkg#AdobeReader_} ] && echo String in pkg \"$pkg\" begins with AdobeReader_ IMO it's bad style to rely on non-standard compliant code, if there are easy alternatives available.
(In reply to comment #3) > [ AdobeReader_${pkg#AdobeReader_} ] && echo String in pkg \"$pkg\" begins with > AdobeReader_ Darn. Copy'n'paste error :( Make that: [ "AdobeReader_${pkg#AdobeReader_}" = "${pkg}" ]
The code in the ebuild is currently: if [[ "${pkg}" =~ "^AdobeReader_" ]]; then I put the quotes around the lhs thinking this would satisfy bash 3.2. Does it not? Looks like a bug in bash if this fails.
(In reply to comment #2) > This problem occurs if you are using bash version >=3.2. The syntax of the [[ > .. =~ .. ]] construct has changed: > > # pre 3.2 > # if [[ ${pkg} =~ "^AdobeReader_" ]]; then > > # new syntax > if [[ ${pkg} =~ ^AdobeReader_ ]]; then FI this syntax works with bash pre-3.2 as well. However I don't like having literal strings unquoted. Could you try the following on bash 3.2, and report the results back? [[ ${pkg} =~ "^AdobeReader_" ]] && echo ok [[ "${pkg}" =~ "^AdobeReader_" ]] && echo ok [[ ${pkg} =~ '^AdobeReader_' ]] && echo ok All report "ok" for bash 3.1. Thanks.
er, and of course do: pkg="AdobeReader_blah" first...
(In reply to comment #6) > [[ ${pkg} =~ "^AdobeReader_" ]] && echo ok > [[ "${pkg}" =~ "^AdobeReader_" ]] && echo ok > [[ ${pkg} =~ '^AdobeReader_' ]] && echo ok askwar@hetzner ~ $ pkg="AdobeReader_blah" askwar@hetzner ~ $ [[ ${pkg} =~ "^AdobeReader_" ]] && echo ok askwar@hetzner ~ $ [[ "${pkg}" =~ "^AdobeReader_" ]] && echo ok askwar@hetzner ~ $ [[ ${pkg} =~ '^AdobeReader_' ]] && echo ok askwar@hetzner ~ $ bash --version GNU bash, version 3.2.9(1)-release (i686-pc-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. None report ok for 3.2.9. However, the standard compliant syntax I posted works just fine. Why not simply use that? Why rely on some non-standard, bash-only feature?
(In reply to comment #8) > None report ok for 3.2.9. Thanks. > However, the standard compliant syntax I posted works just fine. Why not simply > use that? Why rely on some non-standard, bash-only feature? All ebuilds are bash scripts, not sh. '[[' is bash-only, for a start. It seems odd to me that '[[ ${pkg} =~ "^AdobeReader_" ]]' fails - and I need convincing it's not a bug in gcc-3.2. What does bash-3.2 do if other match operators are used - for example: pkg="AdobeReader" [[ ${pkg} == "AdobeReader" ]] && echo ok etc?
actually - don't bother - I've built 3.2_p9 locally so I can test myself. I've emailed the bash mailing list, see what the maintainers say.
*** Bug 162075 has been marked as a duplicate of this bug. ***
The problem exists also with acroread-7.0.8-r1.
oh; and in the meantime I'm committing the no-quotes version for now, as it works on both bash-3.1 and 3.2 (with a comment about the inconsistent behaviour to prevent someone 'fixing' it again).
(In reply to comment #9) > (In reply to comment #8) > > > None report ok for 3.2.9. > > Thanks. > > > However, the standard compliant syntax I posted works just fine. Why not simply > > use that? Why rely on some non-standard, bash-only feature? > > All ebuilds are bash scripts, not sh. Yep, bad. > '[[' is bash-only, for a start. Yep. As you might have noticed, I did not use [[, as it's a bash'ism and not standards compliant. Anyway, good luck with your non-standard code. Guess you'll run into problems soon, when they change behaviour again.
(In reply to comment #14) > > All ebuilds are bash scripts, not sh. > > Yep, bad. Nope, good; it makes our code tidier and easier to read and maintain. Bash is standard on all Gentoo systems, so there's no need to restrict ourselves unnecessarily to sh syntax.
(In reply to comment #15) > (In reply to comment #14) > > > All ebuilds are bash scripts, not sh. > > > > Yep, bad. > > Nope, good; it makes our code tidier and easier to read and maintain. As we just saw, right? ;) > Bash is > standard on all Gentoo systems, so there's no need to restrict ourselves > unnecessarily to sh syntax. Other than that POSIX compliant code will always work. Why use non-standard compliant code, when there's no reason to do so? Like it was in the case of this bug (which would not have existed, if standard compliant code would have been used)? Or like it is with the unnceccessary use of [[ instead of [ (yes, I know about the advantages of [[ over [, but the code in question doesn't make use of this). BTW: I wouldn't say that [[ "${pkg}" =~ "^AdobeReader_" ]] really is easier to read, compared to eg. [ "AdobeReader_${pkg#AdobeReader_}" = "${pkg}" ]. I'm also not saying that [ "AdobeReader_${pkg#AdobeReader_}" = "${pkg}" ] is easier to read, though. Oh well, you'll run into another problem like this soon again, I suppose. But that's not an issue, as bash is "standard" (as in: MS Word is standard) and there's no need to use standard-compliant code, right?
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > > All ebuilds are bash scripts, not sh. > > > > > > Yep, bad. > > > > Nope, good; it makes our code tidier and easier to read and maintain. > > As we just saw, right? ;) Compare and contrast: if [[ ${pkg} =~ ^AdobeReader_ ]]; then if [ "AdobeReader_${pkg#AdobeReader_}" = "${pkg}" ]; then I know which I find easiest to read. > > > Bash is > > standard on all Gentoo systems, so there's no need to restrict ourselves > > unnecessarily to sh syntax. > > Other than that POSIX compliant code will always work. Why use non-standard > compliant code, when there's no reason to do so? Because the bash code has several advantages. If we follow your argument to the logical conclusion, we'd remove bash completely, along with all the other GNU extensions in sed (no '-i', which we use everywhere), diff (no '-u') etc - and that's patently silly. Gentoo is a GNU system, not a pure POSIX system (if such a thing exists).
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > > All ebuilds are bash scripts, not sh. > > > > > > > > Yep, bad. > > > > > > Nope, good; it makes our code tidier and easier to read and maintain. > > > > As we just saw, right? ;) > > Compare and contrast: > > if [[ ${pkg} =~ ^AdobeReader_ ]]; then > > if [ "AdobeReader_${pkg#AdobeReader_}" = "${pkg}" ]; then > > I know which I find easiest to read. Yep, the 2nd one, correct? ;) > > Other than that POSIX compliant code will always work. Why use non-standard > > compliant code, when there's no reason to do so? > > Because the bash code has several advantages. Not in the way it's used HERE. Another example: [[ -z ${fl} ]] Why use [[ here and not [? Why use GNUisms, even if they don't provide an advantage? > If we follow your argument to > the logical conclusion, we'd remove bash completely, You'd remove bash completely, because you'd use bash only where it's necessary? Hm. > Gentoo is a GNU system, not a pure POSIX system (if > such a thing exists). And why would it be bad to use GNUisms only where necessary? Why is it bad to try to use standard compliant code whereever possible and refrain to use GNUisms?
(In reply to comment #18) > Not in the way it's used HERE. Another example: > > [[ -z ${fl} ]] > > Why use [[ here and not [? Why use GNUisms, even if they don't provide an > advantage? '[[' is internal bash syntax, whereas '[' is a separate executable. Thus using '[' costs a new process, '[[' doesn't. Do some timing comparisons, you'll see the difference - it's significant when it accumulates; especially when used in global scope. > > If we follow your argument to > > the logical conclusion, we'd remove bash completely, > > You'd remove bash completely, because you'd use bash only where it's necessary? Well, none of the bash syntax is strictly necessary - you can always find a way of writing stuff using only POSIX code, it's just that it can be messy. > > Gentoo is a GNU system, not a pure POSIX system (if > > such a thing exists). > > And why would it be bad to use GNUisms only where necessary? Why is it bad to > try to use standard compliant code whereever possible and refrain to use > GNUisms? I would argue that a restriction to POSIX code should be just for code that is expected to be used on non-GNU systems. Anyway, this is not a discussion forum, so I won't discuss it further here. Take it up on one of the mailing lists if you really think we should stop using '[[' in ebuilds.
(In reply to comment #19) > (In reply to comment #18) > > Not in the way it's used HERE. Another example: > > > > [[ -z ${fl} ]] > > > > Why use [[ here and not [? Why use GNUisms, even if they don't provide an > > advantage? > > '[[' is internal bash syntax, whereas '[' is a separate executable. Thus using > '[' costs a new process, '[[' doesn't. You're wrong. At least in bash, [ is also a builtin. askwar@winds06 ~ $ type [ [ is a shell builtin askwar@winds06 ~ $ echo $BASH_VERSION 3.00.16(1)-release Granted, that's not a Gentoo bash - but for sure, you haven't patched out [ out of the Gentoo bash, have you? > Do some timing comparisons, you'll see > the difference - it's significant when it accumulates; especially when used in > global scope. Well, in that case - use standard compliant code and use a faster shell (eg. dash). If you're after speed, then you should stop using bash. It's simply too slow. The "problem" with dash is, that it "only" supports POSIX; but that's good enough. Also, in how far is speed relevant regarding THIS bug? > Well, none of the bash syntax is strictly necessary - you can always find a way > of writing stuff using only POSIX code, it's just that it can be messy. Yes, you're right. POSIX code can be messier. But that's also true wrt. bash code. > I would argue that a restriction to POSIX code should be just for code that is > expected to be used on non-GNU systems. Fine. I'd argue, that non-POSIX code should not be used, if there are easy alternatives available. As is with [[ compared to [ (as long as the advantages aren't used); as is now with the code that broke because of bash 3.2, which caused this bug.
(In reply to comment #20) > You're wrong. At least in bash, [ is also a builtin. You're right. However '[' is still 50% more expensive than '[[', on timing tests I have run. re. bash 3.2 (which is still ~, btw) - I'm waiting to hear what upstream say about the change in behaviour from 3.1 to 3.2.
