Re: [Monotone-devel] new restrictions syntax proposal

[Derek Scherger]

Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Sun, 29 Aug 2004 22:14:39 -0600 (MDT), Derek Scherger 
> <address@hidden> said:
>
> derek>      Options generally take zero or one argument rather than several
> derek>      (say the result of a file glob). So for example, to exclude all c
> derek>      files rather than --exclude *.c you need something like --exclude
> derek>      "*.c" which prevents shell globbing and the restriction matching
> derek>      then essentially needs to do it's own globbing. While I think
> derek>      allowing for regexes in the restriction syntax might be good,
> derek>      effectively disabling shell globbing seems rather bad.
>
> The usual problem, which applies to all programs doing it this way.

I assume you mean the globbing stuff?

If the shell *does* do globbing though, --include *.c expands to something like  --include 
a.c b.c c.c d.c and from what I can see with the popt option library you can get either 
--include or --include a.c out of this, b.c, c.c and d.c will have nothing to do with the 
option. I don't see any way of saying "I want to use --include and --exclude but please 
don't treat them as normal options, just leave them in the argument list in order and 
untouched."

> However, if we want to be portable, we must be prepared for internal
> globbing anyway, since there are shells that don't do it for us (like
> the Windows command prompt, I believe...).

I've been wondering whether one of the portability libraries might slip in before 
main(argc, argv) and possibly do the globbing before main sees the arguments so that we 
don't need to worry about it explicitly.

> derek> The stuff I'm working on at the moment allows for the include/exclude
> derek> specifiers to be mixed in with FILE... lists. Since various shells
> derek> pretty much remove all hope of selecting clever operator characters
> derek> (like + and -) I've copped out and added a new lua hook
> derek> (get_restriction_ops) that returns two strings to use as the include
> derek> and exclude specifiers respectively. At the moment I have these set to
> derek> "/include" and "/exclude" although this feels somewhat DOS like and is
> derek> a bit verbose. The point of the hook is that it's easy to change them
> derek> to whatever you might like. If someone comes up with a particularly
> derek> good pair of names then we can drop the hook. The "/" prefix on the
> derek> names does seem somewhat good in that it looks like a pathname
> derek> (though, perhaps too much so) and monotone prohibits absolute
> derek> pathnames so they can't accidentally become file names.
>
> I like your idea, but I don't like the syntax.  I think that from a
> user point of view, having something looking that much like a usual
> directory spec is quite horrible.  For long expressions, they might

Agreed, and that's why I've set it up as a hook...
I don't expect that people will like what I have and I don't know what they 
will like.

Perhaps ==include and ==exclude would be a better initial choice?

> become more or less invisible.  Of course, this depends on the
> platform (on VMS, / is the normal option starting character, but then,
> there is no / anywhere in a directory spec).
>
> Why go away from the usual option syntax?  --include and --exclude
> should work without problems, and if someone has those as file names,
> it's always possible to do the usual ./--include trick.  This is a
> different problem, and all Unix folks should be use to it...

Only because from what I see getopt, popt, etc. treat the options as essentially out of 
band information and there is little or no correspondence between options and other 
command line arguments.

For example:

        --include *.c --exclude foo*.c

expands to

        --include a.c b.c c.c d.c foo.c foobar.c --exclude foo.c foobar.c

and you get notified that the --include and --exclude options exist with the remaining 
args being either

        a.c b.c c.c d.c foo.c foobar.c foo.c foobar.c

or
        b.c c.c d.c foo.c foobar.c foobar.c

depending on whether --include and --exclude are options with arguments or not.

Hopefully I'm missing something simple here and there is an easy way around 
this.
--
Cheers,
Derek