Re: [Monotone-devel] new restrictions syntax proposal

[Richard Levitte - VMS Whacker]

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.
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...).

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
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...

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis