Default verbose output is un-Unixey

[chungy]

It is a little annoying to have the terminal spammed by a list of file names and os while testing and extracting. There is an option to quieten the output, but in more typical Unix fashion, I think quiet output should be default: only print anything if an error occurs.

I also realize that perhaps this choice was intentional to preserve compatibility with LHA scripts, so maybe this request is invalid.

[fragglet]

I also realize that perhaps this choice was intentional to preserve compatibility with LHA scripts, so maybe this request is invalid.

Right - I don't particularly like the overly-verbose output either, but the goal is to be compatible with existing tools and to be a drop-in replacement.

[drawkula]

Could an environment variable be a compromise? GZIP, BZIP2, XZ and probably many more other programs allow setting default options this way.

The defaults as coded in could stay unaltered and every user can set that variable in some per user startup scripts or global for the whole system elsewhere.

[fragglet]

Sorry, I'm very opposed to adding mostly-useless options to the program. In particular it could add some nasty interactions with tools that expect a particular output format. For example suppose you're a user who sets this "special" environment variable. Suddenly your GUI compression tool stops working properly because it expects the normal lha output.

For this reason, I don't find the GZIP environment variable to be a good analogy (that's supposed to be used to control things like compression level, not program output). Even then, the gzip manual strongly implies that adding it was a bad idea:

The obsolescent environment variable GZIP can hold a set of default options for gzip. These options are interpreted first and can be overwritten by explicit command line parameters. As this can cause problems when using scripts, this feature is supported only for options that are reasonably likely to not cause too much harm, and gzip warns if it is used. This feature will be removed in a future release of gzip.

It seems to me that doing something like this in your shell:

alias lhasa="lhasa -q"

ought to have the desired effect. However, it looks like at the moment it doesn't. I'd maybe be open to tweaking the command line parsing to make that workable.

[chungy]

It seems like the best option is to use an entirely new program that behaves in a typically Unix fashion, including being quiet by default. libarchive and its associated bsdtar/bsdcpio programs seems to be just that program (with their interfaces matching the traditional tar/cpio programs, of course).

They seem to use their own implementation of LHA. I don't know how complete it is compared to lhasa, but it does appear to work with the few LHA archives I have around.

[fragglet]

That's probably sensible, although Lhasa supports a lot of obscure details of the format (compression formats, platform-specific quirks) that I doubt other tools handle them all correctly.

But, it would be nice to provide a workaround to point people at who dislike the un-unixey behavior of the tool. So I'll reopen and retitle.

[fragglet]

So I think it seems like an acceptable solution if we can (1) make the alias hack described in my comment above work as intended; (2) add a note in the manpage explaining how to do this, if the default output is too verbose. Relying on alias should ensure that this will only ever take effect for human interactions.

[chungy]

Looks like the command line processing doesn't allow multiple dash options. They must all be smooshed together on the same string. This is why the alias doesn't work.

[drawkula]

Don't start this journey... Everyone with a different shell then expects to find the alias for his shell in the manpage too. While bourne shell and csh siblings behave similar enough not to be a problem here, there are lots of newcomers (cmd.exe and friends, es, rc, fish and others...) in the shell universe and some or all of them may behave different. That's not worth it.

An example sh script managing that stuff probably would be easier to maintain, because that could run whatever shell the user is using and so only would be a single item to keep uptodate. sh without leading ba, because that's still the standard.

[fragglet]

Looks like the command line processing doesn't allow multiple dash options. They must all be smooshed together on the same string. This is why the alias doesn't work.

Right - another weird behavior of the original lha command that lhasa preserves (can't really be broken up because, for example, 'v' is both a command and an option). Seems to me that it should be possible to allow a special-case check for a '-q' preceding all other command line options. So for example these need to work:

lhasa -q x foo.lzh
lhasa -q -x foo.lzh
lhasa -q -xq foo.lzh

It probably shouldn't / doesn't need to support other options, although that could potentially be a future enhancement.

Don't start this journey...

I don't think it's a big deal. A quick check shows that almost (?) all popular Unix shells support aliases: aside from bash there's csh and derivatives, ksh, zsh and fish. There only seem to be a couple of syntaxes so we shouldn't need an extensive list of different syntaxes for each shell.

The only other one you mention is cmd.exe and that doesn't need to be Unixey :)