The UnlabeledValueArg arg type currently matches against arguments starting with a '-'. Could either a new class or an optional parameter be added to indicate an argument should not be allowed to start with an '-'? For instance,
namespace TCLAP{
template<typename T>
class UnlabeledStringValueArg : public UnlabeledValueArg<T>{
public:
using UnlabeledValueArg<T>::UnlabeledValueArg;
virtual bool processArg(int* i, std::vector<std::string>& args){
if(args[*i][0] == '-') return(false);
return(UnlabeledValueArg<T>::processArg(i, args));
}
};
}
Last edit: Sanford Freedman 2019-05-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A simple example would be any application expecting a filename. If a user accedentically had a '-' at the start of a filename argument, then they were probably attempting to use a flag instead. While an application can easily catch this, having the command line parser directly catch it is cleaner and results in a more sensible error/usage message. For instance, the error mesage when doing a 'ls -dummy' is:
instead of something similar to (the following is not real):
ls:cannotaccess'-dummy':Nosuchfileordirectory
While the option to allow a leading '-' must be available (for instance to support negative numbers), there are many situations where a leading '-' is not appropriate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The UnlabeledValueArg arg type currently matches against arguments starting with a '-'. Could either a new class or an optional parameter be added to indicate an argument should not be allowed to start with an '-'? For instance,
namespace TCLAP{ template<typename T> class UnlabeledStringValueArg : public UnlabeledValueArg<T>{ public: using UnlabeledValueArg<T>::UnlabeledValueArg; virtual bool processArg(int* i, std::vector<std::string>& args){ if(args[*i][0] == '-') return(false); return(UnlabeledValueArg<T>::processArg(i, args)); } }; }Last edit: Sanford Freedman 2019-05-31
Can you describe a use case where this would be useful? Perhaps there is a different way.
A simple example would be any application expecting a filename. If a user accedentically had a '-' at the start of a filename argument, then they were probably attempting to use a flag instead. While an application can easily catch this, having the command line parser directly catch it is cleaner and results in a more sensible error/usage message. For instance, the error mesage when doing a 'ls -dummy' is:
instead of something similar to (the following is not real):
While the option to allow a leading '-' must be available (for instance to support negative numbers), there are many situations where a leading '-' is not appropriate.