----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Craig A. Berry" <[EMAIL PROTECTED]> Cc: "IvorW" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: 13 February 2004 16:51 Subject: Re: Using File::Find to find all versions > > > > "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. > > > 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.
Although this was a few months ago, I've done it. However I decided that the name File::Wildcard was more suitable. It also has the ability to construct new file names (something that I found useful with RMS $NAM blocks). A given file spec is turned into a regexp, and all the wildcards are available as captures $1, $2, etc. to build new filenames from. Unfortunately, it only works with POSIX style filenames t/foo.t, lib/My/Module.pm, etc. and the tests for absolute files t/03_absolute.t is skipped on VMS. I've found it very handy for some windoze scripts. Enjoy :) Ivor.
