Re: mutually exclusive group of options

> >     scan --init=/path/to/lib/to/load.so --dir1=... --dir2=... ; no
> error
> > 
> >     scan --dir1=... --dir2=... ; error because no --init is given
> > 
> > Unfortunately this latter one is the most common use-case with this
> application. :-(
> > I'm thinking about what default value I can define for --init to be
> compatible with previous versions.
> 
> from your original mail I seemd to understand that --dir options can 
> appear only if --init is given, isn't it so?  If not, then you can 
> simply make them independent from --init, can't you?

Yes, I think they are actually independent because the program now works only in one mode (standalone mode w/ optional --init) which means it can accept --init argument only and has no --attach at all. That's why --dir can be given now independently from the fact whether --init was given or not. In other words --init is an optional parameter with a very common default value.

1.)  scan --init --dir1 --dir2 ... ; standalone mode
2.)  scan --attach                 ; shared mode (attach to daemon)

Up to now the users have had to specify the initialization options in the standalone mode because the application was responsible to start and configure the daemon itself. (Most common ones have default values, so the users hadn't have to type too much ;)

But if I introduced the new mode ("attach to daemon" w/ --attach option) I'd had to disable (inhibit) some of the options which simply would make no sense in this new mode. (ie. do not give initialize an already initialized daemon) This is my first original problem.

My next concern is that I'd like that the application be compatible with previous versions so users can simply use it in the following way (like before), eg:

  scan --dir2  ...
  scan --dir1 -dir2 ... 

The common in both examples is that --init is omitted.