-
Simon McVittie authored
The reason we originally did this is that older versions of bwrap didn't support the GNU-style "--" argument separator, used to disambiguate between non-option arguments and strangely-named executables that happened to start with a minus. However, we now wrap our user-controlled "payload" command with pressure-vessel-adverb(1) in all cases, which means we don't need this. bwrap's first non-option argument is the absolute path to pressure-vessel-adverb, which definitely does not start with "-" and so cannot be confused with an option; and all of our own commands, notably pressure-vessel-adverb, use GOptionContext and therefore support the "--" option-separator correctly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
Simon McVittie authoredThe reason we originally did this is that older versions of bwrap didn't support the GNU-style "--" argument separator, used to disambiguate between non-option arguments and strangely-named executables that happened to start with a minus. However, we now wrap our user-controlled "payload" command with pressure-vessel-adverb(1) in all cases, which means we don't need this. bwrap's first non-option argument is the absolute path to pressure-vessel-adverb, which definitely does not start with "-" and so cannot be confused with an option; and all of our own commands, notably pressure-vessel-adverb, use GOptionContext and therefore support the "--" option-separator correctly. Signed-off-by:
Simon McVittie <smcv@collabora.com>