kcov: error when out-dir is an executable

[perillo]

Tested on Linux, kcov 42

> kcov ls /bin/ls > /dev/null
kcov: error: Can't open directory /usr/bin/ls/

Thanks.

[SimonKagstrom]

I think you're just trying to store files in the wrong directory. It looks like you're in /usr/bin when you're executing the command, and that is not writable as a normal user. So ls here is the output directory, where the coverage is placed, and is in this case relative to the path you are currently in.

Also, /bin/ls probably does not contain debug symbols (and I guess the source code isn't available on your system), so kcov is unlikely to be able to collect anything from it.

[perillo]

I think you're just trying to store files in the wrong directory. It looks like you're in /usr/bin when you're executing the command, and that is not writable as a normal user. So ls here is the output directory, where the coverage is placed, and is in this case relative to the path you are currently in.

No. I'm executing the command from the /tmp directory.

Also, /bin/ls probably does not contain debug symbols (and I guess the source code isn't available on your system), so kcov is unlikely to be able to collect anything from it.

Yes, ls does not contain debug symbols, but I chose it to make it easy to reproduce. The problem is not ls but the fact that the out-dir directory is handled incorrectly in case it is an executable.

I found this bug when setting out-dir to coverage, unaware that it is the name of an executable. This is just a unfortunate case; coverage is a possible name an user can choice.

[SimonKagstrom]

Ah ok, but it still looks strange: This works for me (in /tmp):

Simons-iMac:tmp ska$ kcov ls ~/projects/build/kcov/src/kcov
Usage: kcov [OPTIONS] out-dir in-file [args...]
[...]

(using kcov, which has debug symbols)

[perillo]

When parsing the command line, the code expands all arguments. This means that an out-dir parameter having the same name of an executable is fully expanded, thus becoming an executable instead of a directory.

Also, I think that the

if (IParserManager::getInstance().matchParser(get_real_path(argv[lastArg])))
    break;

at the start of the loop is incorrect, since the first positional parameter is out-dir.

I'm trying to create a PR, but I have not used C++ for years, so I'm having a lot of errors when handling strings.

[perillo]

@SimonKagstrom I created a oatch that seems to work. I will try to create a PR as soon as possible so that you can review it.

[SimonKagstrom]

Yes, looks like you're right. Only the actual binary should be expanded. Not quite sure why I don't see it here though, although I'm on a mac.

[perillo]

For completeness, there is an additional issue; a confusing error message in case no executable is found:

> kcov a b --name value
kcov: unrecognized option '--name'
kcov: error: Unrecognized option: -

Usage: kcov [OPTIONS] out-dir in-file [args...]

Maybe in-file should be renamed to in-executable ?