The help for darcs query contents claims:

 Outputs a specific version of a file.

This would seem to imply that there *must* be a filename argument, else what is
it doing? However, darcs does not require a filename argument and will exit
successfully:

[10:50 AM] 0Mb$ darcs query contents --match='hash
"20090820015315-823f1-5364754c6be3b162b9d0e60d1211725932995f9d.gz"' && echo foo
foo

(This is on the darcs-wikirepo)

[10:50 AM] 0Mb$ darcs --version
2.2.98.4 (beta 4)

Worse, darcs query contents will happily process an entire repo even when no
filename argument, a sometimes tedious process:

[10:51 AM] 0Mb$ time darcs query contents --match='hash
"20040519123446-9bed5-5a1d5f9b10dac5cfdc3d43c56c510e252a06ce85.gz"' 

real	0m5.470s
user	0m3.624s
sys	0m1.788s

This should be fairly straightforward to fix.  It may be worth also considering
the interactions with the bit of code that filters out non-repo-paths

> Usage: darcs show contents [OPTION]... [FILE]...

The problem is that these are meaningful:

    darcs show contents f
    darcs show contents f1 f2 ... fn

but this is not:

    darcs show contents

I am not sure if "one-or-more" can be expressed by the current
command_extra_args setup.  Perhaps the bodge of using -1 to mean "zero
or more" could be extended such that -2 means "one or more".

We could work around it by simply removing the ability to "cat"
multiple files at once, but it means that the (uncommon?) case of

    darcs show contents f1 f2 ... fn

will be O(n) instead of O(1), which could be very slow if you are
fetching a very old repository state.

All this aside, I suppose the command_extra_args = -1 could be left
as-is, and simply case have

    show_contents_cmd opts [] = <throw an error here>

I'll try that presently.

The following patch updated the status of issue1548 to be resolved:

* Resolve issue1548: show contents requires at least one argument. 
Ignore-this: c15286919e827a5e7fdad01c75acccfe