Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

>>> 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.