Bugzilla Bug 184774

I was just writing a little ebuild for an ancient tool that's packed up as a
.lzh.

I installed lha-114i-r6 and tried letting portage's unpack function handle it. 
I was amazed that it tried, but it produced:

>>> Unpacking msbklin.lzh to /var/tmp/portage/app-arch/ntbkup-1.07/work
lha: invalid option -- q
usage: lha [-]<commands>[<options>] [-<options> ...] archive_file [file...]
  commands:  [axelvudmcpt]
  options:   [q[012]vnfto[567]dizg012e[w=<dir>|x=<pattern>]]
  long options: --system-kanji-code={euc,sjis,utf8,cap}
                --archive-kanji-code={euc,sjis,utf8,cap}
                --extract-broken-archive
                --help
                --version
 * 
 * ERROR: app-arch/ntbkup-1.07 failed.
 * Call stack:
 *   ebuild.sh, line 1647:   Called dyn_unpack
 *   ebuild.sh, line 768:   Called qa_call 'src_unpack'
 *   ebuild.sh, line 44:   Called src_unpack
 *   ebuild.sh, line 654:   Called unpack 'msbklin.lzh'
 *   ebuild.sh, line 461:   Called die
 * 
 * failure unpacking msbklin.lzh
 * If you need support, post the topmost build error, and the call stack if
relevant.
 * A complete build log is located at
'/var/tmp/portage/app-arch/ntbkup-1.07/temp/build.log'.
 * This ebuild is from an overlay: '/usr/local/overlays/shc-tools/'
 * 

which I then tracked down to the line in /usr/lib/portage/bin/ebuild.sh:

lha xqf "${srcdir}/${x}" || die "$myfail"

I tried several different variations, and it seems the q and f don't go so well
right next to each other.  I ended up with:

lha x -q -f "${srcdir}/${x}" || die "$myfail"

which seems to work fine.

See bug #159100, which has an ebuild for Debian's lha.

the lha command used to work (it did when i added it), so lha is broken here

*** This bug has been marked as a duplicate of bug 159100 ***

This does not appear to be a duplicate of bug #159100.  According to the
built-in help for lha, the q option takes an optional parameter, which seems to
be a "required" parameter if more options follow.  You can see it right in the
output from post #1.  The command line that works is:

    lha xq2f some_file_name

or even

    lha xfq some_file_name


Perhaps the command line parser needs to be made smarter, but this is
definitely not related to the "unable to extract quake files" bug.  Should this
bug be reopened as a "fix the command line parser" bug?  Or, should it just
left alone since it actually appears to be behaving as designed?

- John

I've changed it to xfq.

I'm not certain that will work as expected because the -f option will expect
the filename, rather than a q immediately after it...

I'd either explicitly specify a quiet level (like xq2f), or split the arguments
as in comment 1:

lha x -q -f "${srcdir}/${x}" || die "$myfail"

xfq works because according to --help f really means "force (over write at
extract)".  I chose xfq in hopes that it wouldn't trigger any backward
compatibility problems with older versions of lha that apparently accepted xqf
(probably not an issue since we only have one version in the tree now). 

You're entirely right, I'm sorry.  Serves me right for relying on my own
memory!  I do apologize...  5:(

This has been released in 2.1.3_rc9.

(In reply to comment #2)
> the lha command used to work (it did when i added it), so lha is broken here
> 
> *** This bug has been marked as a duplicate of bug 159100 ***
> 

SpanKY's right, by the way.  Between lha-114i-r5 and lha-114i-r6, the command
line parser became more strict.  It *did* used to work.

- John