Hi all, I'm not satisfied with a behavior of osc ls in project/package dir - instead of listing of a project list on a server, I expect it will list a content of a current project/package instead. So I wrote patch changing it. Simple example: user@host:~/Base\:System/ed> osc ls _link ed-1.4.tar.gz ed.changes ed.spec ready There is one problem prevents me to push this commit - with this patch is impossible to list a content of an another project/package inside this directory. The root of the problem comes from a current command syntax, which I considered weird - let see how it looks osc ls [PROJECT [PACKAGE [FILE]]]] osc ls -b [PROJECT [PACKAGE [REPOSITORY [ARCH]]]] The first thing I don't understand is a FILE argument - don't see a reason why it's necessary. The test of existence of a file in repository is straightforward osc ls PRJ PKG | grep file # in shell file in meta_get_filelist(...) # in python ... and this syntax don't allow to test more than one file per call, which is not really useful. The second problem is with REPOSITORY and ARCH arguments in binary listing - it produces a some of mess in code, because it's duplicated by -r/-a options. And those two positional but optional arguments produces an ambiguity while parsing a command line - what's the expected result of user@host:package> osc ls ARG1 user expects the osc ls PROJECT or osc ls FILE? user@host:package> osc ls -b ARG1 ARG2 In this case what user wants? osc ls -b PROJECT PACKAGE, or osc ls -b REPOSITORY ARCH? My proposal and solution is to use the second option, which disallows the listing of an another project/package inside project/package dir, but it should be more convenient. Comments are welcome Michal Vyskocil