Closed perillo closed 5 months ago
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.
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.
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)
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.
@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.
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.
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
?
Tested on Linux, kcov 42
Thanks.