Dear Maintainer, I am writing to report a potential issue with the setcap command, where it does not properly support the end-of-options marker --. This behavior is inconsistent with the getcap command, which correctly recognizes -- as an indication that subsequent arguments are filenames or paths rather than options. Problem Description: In typical command-line usage, -- is used to signal the end of command options, allowing paths or filenames that start with a dash (-) to be handled correctly. However, setcap fails when -- is provided in the command syntax. For instance: setcap -r -- /bin/ping This command results in an error: Failed to set capabilities on file '--': No such file or directory It appears that setcap is treating -- as if it were a target filename, rather than recognizing it as an end-of-options marker. Expected Behavior setcap should accept -- to allow filenames or paths starting with - without misinterpreting them as options. This behavior is currently supported by getcap and aligns with standard POSIX conventions for command-line arguments. Steps to Reproduce Run the following command: setcap -r -- /bin/ping Observe that setcap fails with an error indicating -- is treated as a file rather than as an end-of-options marker. Workaround: To avoid the error, -- can be omitted when working with paths that do not start with - . However, the lack of end-of-options support may still lead to issues for paths or filenames beginning with -. Suggested Solution Implement -- as an end-of-options marker in setcap, consistent with the handling in getcap and other standard utilities. This change would improve usability and align setcap with common command-line conventions. Thank you for your attention to this issue. Best regards
You can always specify the file with a "./" prefix, such as ./-this . I'm reserving the libcap-2.72 release for a complete rewrite of libpsx. I'll address this request in libcap-2.73.
I've been looking at the setcap command and it doesn't work this way. The idea that it be used to set the same capabilities on more than one file at a time isn't how it was designed. The usage message: setcap ... (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) filenameN> ] makes it clear that the user is expected to supply "a capability" and a "filename" in pairs. Given this, conventional meaning for "--" doesn't apply to this utility. I won't be implementing support for it. As noted above, you can specify any filename you need by prefixing it with its path (relative or absolute).