"Craig A. Berry" <[EMAIL PROTECTED]> wrote on 02/12/2004 11:24:54 PM:
> At 4:47 AM -0500 2/7/04, IvorW wrote:
> >
> >This thread has set me thinking, and I am reminded of something that VMS
> >handles rather better than Unix. VMS uses the ellipsis [...] to stand
for
> >"and any directory path below". This renders redundant, the need for
> >the find utility, or equivalent.
>
> Are you sure there are no ellipsis capabilities in Unix shells? I'm
> almost positive I've seen syntax like foo/.../bar but have been
> unsuccessful in finding documentation about the rules for pathname
> expansion.
I had hoped to find time to reply to this post as well but did not
do so in a timely fashion. At any rate one of the tools that you are
likely
to have encountered that does use ... to glob through directory separators
even on platforms as wide as Windows, Mac OS (Classic and X), VMS, and Unix
is Perforce; that is the p4(.exe) command line client. That said
p4 does place restrictions on file names as mentioned in
http://www.perforce.com/perforce/technotes/note041.html
(by the way perforce's recommended foreign symbol for their client
for VMS is along the lines of:
$ p4 :== $disk:[dir]p4.exe
I recommend that folks use instead:
$ perf*orce :== $disk:[dir]p4.exe
so as to not interfere with VMS things that do not distinguish
between the GLOBAL p4 symbol and the LOCAL P4 procedure/subroutine
parameter).
It has been quite a while since I've looked at the comparisons between
various Unix shells. I do recall that a bit more than 3 years ago when
the move to consolidate on File::Glob as perl's internal
"cross-platform [t]csh independent" glob (that was in turn based upon
a rewrite of Guido van Rossum's FreeBSD glob implementation as later
interpreted as Nate Torkington's Glob::BSD
type glob extension then later still as Greg Bacon's
http://search.cpan.org/~gbacon/File-BSDGlob-0.94/. One irony I knew
of for the OS/390 port we could not rely on a dynamically loaded extension
in OS/390 perl and there perl's glob() is the older call into C lib
call.) option was being discussed that advocates of the zsh shell argued
strongly for a move to their style with directory recursion being cited
as a big feature well worth having. In fact on the zsh FAQ it is still
cited near the top of the list of features (op cit
http://zsh.sunsite.dk/FAQ/zshfaq01.html#l4 ).
> > one of the facilities I
> >built in was elliptic globbing. This meant that a command line file spec
could
> >contain the equivalent of [...], and my shell would recursively expand
this.
> >I got the idea because this was a facility I had got used to on VMS
(then version 2.7).
> >
> >For example:
> >
> >rm /home/~me///core
> >
> >The /// reads as "blah blah blah", as does "..." in a VMS directory path
spec.
> >
> >Now, many years later, I realise that nobody in the Unix world has
thought of doing
> >this, mainly because few of them have been exposed to VMS's elliptic
wildcards.
> >I know that the POSIX standard does not include this, but my syntax is
consistent
> >with it. Could we provide this facility in Perl for all platforms, thus
making
> File::Find
> >redundant?
> >
> >We could also allow version number syntax ";*" and ";-1" etc. which
would be
> >ignored by (most) operating systems that don't support multiversions. I
gather that
> >some Unixen have a file multiversioning facility (AIX for instance), but
this needs
> >to be specially enabled by the sysadmins, and there are also multiple
caveats
> >as most standard Unix utilities and scripts don't expect to see multiple
fileversions.
> >
> >I've also seen a nightmarish scenario when VMS is serving NFS. to Unix
boxes,
> >and clients see a directory containing foo.pl.1, foo.pl.2 and foo.pl for
a
> VMS directory
> >containing 3 versions of foo.pl. There could also be applications
relating to version
> >control systems, where the FS has no versioning, but the concept still
exists.
> >
> >Anyway, rather than attacking the perl core to shoehorn something in
that is esoteric
> >and arcane to most Perl people, I'm thinking of proposing a module:
> >
> >use File::EllipticGlob;
> >
> >This overrides glob in your current namespace, providing a function
which does what
> >I am suggesting.
> >
> >Thoughts please.
>
> I'm all for it unless we already have it or can implement some
> standard syntax for doing the same thing.
Writing a File::EllipticGlob and uploading to CPAN would be very useful.
I might be able to help test it on a couple of platforms beyond VMS.
You might want to see either Greg Bacon's extension or the File::Glob
as shipper with the perl source for packaging and coding hints and tips.
Peter Prymmer
