kdb ls produces additional keys

[kodebach]

Steps to Reproduce the Problem

Have the spec plugin (global-)mounted and run:

kdb ls spec/tests/example

Expected Result

Only keys below spec/tests/example should be listed.

Actual Result

Cascading keys below /tests/example are also listed.

Further Comments

IMO kdb ls should never produce cascading keys, even if it is called with a cascading parent key. If I call kdb ls, I want to know about the actual keys present.

[markus2330]

Thank you for reporting this problem. I fully agree!

Only with -v these keys should be part of the output.

[DaHopeman]

I would like to do this as my first issue @markus2330

[markus2330]

Good choice, this should be very easy. I assigned you.

[DaHopeman]

@markus2330
I just want to make sure I understood the problem correctly:
using kdb ls should just list those keys that are directly in the given path and not "deeper down", right?
like this:

[markus2330]

No, "deeper down" is a separate feature using -m and -M switches (man kdb ls). You should only filter out the keys which start with / and not filter the correct keys.

You get such keys by setting defaults:

kdb setmeta spec/tests/example default something
kdb ls spec/tests
#> spec/tests/example

Wanted output:

spec/tests/example

Current output:

/tests/example

Or also (maybe a different bug?):

kdb setmeta spec/tests/example default something
kdb ls spec/tests/example
#> spec/tests/example

Please also add test cases (the code above is already a shell recorder test, see tests/shell/shell_recorder/tutorial_wrapper/README.md)

[DaHopeman]

I have modified the printResults method in my fork to filter out the keys which start with /.
I did not create a pull request however, because I am not sure if this is really the problem for this bug.

Using the input you mentioned above:

kdb setmeta spec/tests/example default something
kdb ls spec/tests

I get the following output:

/tests/example
spec/tests/example

I get both versions every time. Is this intentional or could there be a problem in the cut function, which is used to provide the Keyset for printResults?

[kodebach]

could there be a problem in the cut function

Considering #2550 and that cur is also used in kdb rm, I agree that there probably is a bug in ksCut (the function underlying cut).

[markus2330]

@kodebach is this resolved now?

[kodebach]

As far as I can tell, yes.