File spec wildcard match test?
Steven M. Schweda
which had a kind of "/EXCLUDE = (file1 [, file2 [...]])" option, where
the /EXCLUDE file list could include wildcard file specs.
Is there an easy way (RMS service, or something else already extant
in VMS V5.4, say) to test a particular file spec against a given
wildcard file spec? That is, for example:
wild_match( "[.a.b.c]fred.dat", "[...b...]fred.*") /* (true) */
wild_match( "[.a.b.c]fred.dat", "[...b]fred.*") /* (false) */
This would be something like $SEARCH with a wildcard file spec, but
testing a particular file spec string against the wildcard file spec,
instead of testing real files against the wildcard file spec.
One could write code for this, but it seems that with commands like
BACKUP and DIRECTORY, which have /EXCLUDE options, there should be
something lying around already.
What's true?
------------------------------------------------------------------------
Steven M. Schweda (+1) 651-699-9818
382 South Warwick Street sms@antinode-org
Saint Paul MN 55105-2547
dbsn...@bigpond.com
in the OpenVMS Utility Routines Manual.
I don't think they are available as far back as V5.4 though.
Dave
JF Mezei
> Is there an easy way (RMS service, or something else already extant
> in VMS V5.4, say) to test a particular file spec against a given
> wildcard file spec? That is, for example:
HELP RTL STR STR$MATCH_WILD
Peter Weaver
news:1131606186.8...@g14g2000cwa.googlegroups.com...
UTIL$CQUAL* to be a bit more specific, IIRC they were released with V7.
Peter Weaver
news:JjIcf.17035$EK.3...@news20.bellglobal.com...
Sorry, I was distracted there, what I meant to type before posting was that
I recall being told that the routines were in prior versions of VMS but not
documented. You might want to run a few tests and see if they were in V5.4.
Steven M. Schweda
> > UTIL$CQUAL* to be a bit more specific, IIRC they were released with V7.
Thanks. The first glance suggests more fanciness than I need, but
I'll see if I can make some use of them.
From: JF Mezei <jfmezei...@teksavvy.com>
> > wildcard file spec? That is, for example:
>
> HELP RTL STR STR$MATCH_WILD
Good for "%" and "*", but not a general file-spec wildcard, as, for
example, in the example you omitted ("...").
Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
with "..." in a directory spec?
Larry Kilgallen
> From: "Peter Weaver" <news...@weaverconsulting.ca>
>
>> > UTIL$CQUAL* to be a bit more specific, IIRC they were released with V7.
>
> Thanks. The first glance suggests more fanciness than I need, but
> I'll see if I can make some use of them.
>
>
> From: JF Mezei <jfmezei...@teksavvy.com>
>
>> > wildcard file spec? That is, for example:
>>
>> HELP RTL STR STR$MATCH_WILD
>
> Good for "%" and "*", but not a general file-spec wildcard, as, for
> example, in the example you omitted ("...").
STR$MATCH_WILD is a matching algorithm that knows only syntax.
To find all files in a directory tree properly, one needs to call RMS.
> Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
> with "..." in a directory spec?
I thought there were multiple implementations of Zip for VMS.
The one you are using was probably written in C, and C programmers
have a habit of thinking that all file systems are like Unix and
should be handled by calling CRTL.
Steven M. Schweda
> To find all files in a directory tree properly, one needs to call RMS.
Which is not what I'm trying to do.
> > Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
> > with "..." in a directory spec?
>
> I thought there were multiple implementations of Zip for VMS.
I refer to the Info-ZIP Zip. You have in mind which other ones?
(GNU zip, which lacks "-i" and "-x", perhaps?)
> The one you are using was probably written in C, and C programmers
> have a habit of thinking that all file systems are like Unix and
> should be handled by calling CRTL.
Please let me know when you can supply a superior replacement. Feel
free to write it in any language you wish.
JF Mezei
> > HELP RTL STR STR$MATCH_WILD
>
> Good for "%" and "*", but not a general file-spec wildcard, as, for
> example, in the example you omitted ("...").
You might be able to do some magic with F$PARSE. It will tell you
whether there is wildcarding in any of the fields.
Larry Kilgallen
> From: Kilg...@SpamCop.net (Larry Kilgallen)
>
>> To find all files in a directory tree properly, one needs to call RMS.
>
> Which is not what I'm trying to do.
I did not notice an English language description of what you were
trying to do. Please elaborate.
>> > Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
>> > with "..." in a directory spec?
>>
>> I thought there were multiple implementations of Zip for VMS.
>
> I refer to the Info-ZIP Zip. You have in mind which other ones?
> (GNU zip, which lacks "-i" and "-x", perhaps?)
I am not a Zip user.
>> The one you are using was probably written in C, and C programmers
>> have a habit of thinking that all file systems are like Unix and
>> should be handled by calling CRTL.
>
> Please let me know when you can supply a superior replacement. Feel
> free to write it in any language you wish.
It is more likely to be done by someone who uses Zip.
If they want to be able to sell their implementation, they need to
distinguish it in some fashion, such as quality.
What price are you willing to pay for such a quality implementation ?
I am sure that will affect whether people jump into the fray.
Steven M. Schweda
> >> To find all files in a directory tree properly, one needs to call RMS.
> >
> > Which is not what I'm trying to do.
>
> I did not notice an English language description of what you were
> trying to do. Please elaborate.
At the risk of boring those who were paying attention, as I recall, I
wrote (10-NOV-2005 00:31:47.24):
> Is there an easy way (RMS service, or something else already extant
> in VMS V5.4, say) to test a particular file spec against a given
> wildcard file spec? That is, for example:
>
> wild_match( "[.a.b.c]fred.dat", "[...b...]fred.*") /* (true) */
> wild_match( "[.a.b.c]fred.dat", "[...b]fred.*") /* (false) */
> >> > Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
> >> > with "..." in a directory spec?
> >>
> >> I thought there were multiple implementations of Zip for VMS.
> >
> > I refer to the Info-ZIP Zip. You have in mind which other ones?
> > (GNU zip, which lacks "-i" and "-x", perhaps?)
>
> I am not a Zip user.
Is there something about me personally which attracts useless advice
from people who admit not knowing anything about the subject on which
they offer advice? Or is it something about Zip? If I knew, then
perhaps I could take appropriate steps.
On the bright side, it's getting harder not to be an UnZip user, as
many patch kits are now being distributed as self-extracting UnZip
archives. (Using an obsolete UnZip version, of course.)
> [... blather ...]
> What price are you willing to pay for such a quality implementation ?
> I am sure that will affect whether people jump into the fray.
Never mind. I'll just keep working on it myself. You can work on
whatever you want when and as you feel the need.
JF Mezei
> > wild_match( "[.a.b.c]fred.dat", "[...b...]fred.*") /* (true) */
> > wild_match( "[.a.b.c]fred.dat", "[...b]fred.*") /* (false) */
If you did a quick parse of the string to replace
"[..." with "[*."
and "...]" with ".*]"
then the str$match_wild would work as you wish.
Hein RMS van den Heuvel
Larry Kilgallen wrote:
> In article <05111019182...@antinode.org>, s...@antinode.org (Steven M. Schweda) writes:
> > From: Kilg...@SpamCop.net (Larry Kilgallen)
> >
> >> To find all files in a directory tree properly, one needs to call RMS.
> >
> > Which is not what I'm trying to do.
>
> I did not notice an English language description of what you were
> trying to do. Please elaborate.
Hmmm, odd... the base topic seems to consist of just that.
I thought is was an imminently readable description of a non trivial
problem.
As par as that base problem goes, I think that SYS$PARSE with
NAM$V_SYNCHK is as close as you are going to get with system services
to help you normalize & parse a user provided filespec.
The suggested STR$MATCH_WILD has no special understanding of filename
structure.
It does know * for multi-char match and % for single char, which is
handy.
You would likely need to pre-parse and provide 'anchors' in the form of
[].;
While dabling in this space, maybe you spot some ''easy' regular
expression code allowing your end user more elaborate selection
criteria?
fwiw,
Hein.
Steven M. Schweda
And "[*.m]" would match "[a.b.c.d.e.f.g.h.i.j.k.l.m]" as well as it
would "[a.m]". My idea of "as I wish" and yours appear to differ.
SMS.
JF Mezei
SYS$PARSE has the ability for you to provide default file specs, related
file specs and the actual file spec.
I haven't thought this through but...
lets say you want to COOK [...]*.CHOCOLATE /exclude=[...]MOUSSE.*
so cook uses sys$Parse and sys$search to get the *.CHOCOLATE list.
For each file, you might be able to build some sys$parse that uses the
$SEARCH result and the /exclude with proper use of defeault, related and
actual specs to test if the $SEARCH result would result in $PARSE
finding the file (hence telling you to exclude that file).
Again, this is just brainstorming.
Dave Froble
> In article <05111019182...@antinode.org>, s...@antinode.org (Steven M. Schweda) writes:
>
>>From: Kilg...@SpamCop.net (Larry Kilgallen)
>>
>>
>>>To find all files in a directory tree properly, one needs to call RMS.
>>
>> Which is not what I'm trying to do.
>
>
> I did not notice an English language description of what you were
> trying to do. Please elaborate.
Since ZIP is a utility for moving files, activity would include taking a
copy of data from disk, and placing a copy of data on disk. In either
case, one or more file specifications would be involved. It seems to me
that being able to fully parse and understand a file specification is
the issue.
>>>> Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
>>>>with "..." in a directory spec?
>>>
>>>I thought there were multiple implementations of Zip for VMS.
>>
>> I refer to the Info-ZIP Zip. You have in mind which other ones?
>>(GNU zip, which lacks "-i" and "-x", perhaps?)
>
>
> I am not a Zip user.
I'm an infrequent user, but at times it's quite valuable.
>>>The one you are using was probably written in C, and C programmers
>>>have a habit of thinking that all file systems are like Unix and
>>>should be handled by calling CRTL.
Ah, my daily anti-C 'fix'.
>> Please let me know when you can supply a superior replacement. Feel
>>free to write it in any language you wish.
>
>
> It is more likely to be done by someone who uses Zip.
> If they want to be able to sell their implementation, they need to
> distinguish it in some fashion, such as quality.
>
> What price are you willing to pay for such a quality implementation ?
> I am sure that will affect whether people jump into the fray.
The various versions of ZIP for VMS are, to the best I know, basically
free. A service to the VMS community. To ask an entity who is
providing a free service to the VMS community to pay for providing such
a service is, ah, less than appropriate.
To put it into perspective, would you pay me for the priviledge of
coming here and working for me?
Back to the issue. I'm thinking that 1) HP is the #1 beneficiary of
such VMS freeware, because it supports an HP product, and 2) VMS BACKUP
and probably other utilities already have all the required
functionality, that it sure would be appropriate for some form of
colaboration including VMS engineering. Perhaps an inquiry on the issue
could be made?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
Larry Kilgallen
>
> Larry Kilgallen wrote:
>> In article <05111019182...@antinode.org>, s...@antinode.org (Steven M. Schweda) writes:
>> > From: Kilg...@SpamCop.net (Larry Kilgallen)
>> >
>> >> To find all files in a directory tree properly, one needs to call RMS.
>> >
>> > Which is not what I'm trying to do.
>>
>> I did not notice an English language description of what you were
>> trying to do. Please elaborate.
>
> Hmmm, odd... the base topic seems to consist of just that.
> I thought is was an imminently readable description of a non trivial
> problem.
It was not in the post to which I responded, and ANUNEWS has no backward
threading.
Bob Koehler
Until some user enters <... or <* .
Larry Kilgallen
> From: JF Mezei <jfmezei...@teksavvy.com>
>
>> > > wild_match( "[.a.b.c]fred.dat", "[...b...]fred.*") /* (true) */
>> > > wild_match( "[.a.b.c]fred.dat", "[...b]fred.*") /* (false) */
>>
>> If you did a quick parse of the string to replace
>> "[..." with "[*."
>> and "...]" with ".*]"
>>
>> then the str$match_wild would work as you wish.
>
> And "[*.m]" would match "[a.b.c.d.e.f.g.h.i.j.k.l.m]" as well as it
> would "[a.m]".
In normal VMS usage [...m] will match both of those.
> My idea of "as I wish" and yours appear to differ.
I think you need to describe the matching semantics you want.
Larry Kilgallen
> Larry Kilgallen wrote:
>> What price are you willing to pay for such a quality implementation ?
>> I am sure that will affect whether people jump into the fray.
>
> The various versions of ZIP for VMS are, to the best I know, basically
> free. A service to the VMS community. To ask an entity who is
> providing a free service to the VMS community to pay for providing such
> a service is, ah, less than appropriate.
>
> To put it into perspective, would you pay me for the priviledge of
> coming here and working for me?
>
> Back to the issue. I'm thinking that 1) HP is the #1 beneficiary of
> such VMS freeware, because it supports an HP product, and 2) VMS BACKUP
> and probably other utilities already have all the required
> functionality, that it sure would be appropriate for some form of
> colaboration including VMS engineering.
And that is the nub of the problem. I believe HP's efforts should be
concentrated on supported software. If people wanted a BACKUP/ZIP
capability that certainly has been delayed by presence of the "free"
version (that is "free" only for those who value their own time at
zero).
Steven M. Schweda
> As par as that base problem goes, I think that SYS$PARSE with
> NAM$V_SYNCHK is as close as you are going to get with system services
> to help you normalize & parse a user provided filespec.
I'm starting to lean that way. More thought required.
> While dabling in this space, maybe you spot some ''easy' regular
> expression code allowing your end user more elaborate selection
> criteria?
Maybe not. Just trying to match the current non-VMS functionality in
Zip with normal VMS user expectations (mine). The ODS5 extended file
name escape syntax ("^") causes trouble for the existing code, too, as
it tends to think one character at a time. Everything's complicated.
From: JF Mezei <jfmezei...@teksavvy.com>
> For each file, you might be able to build some sys$parse that uses the
> $SEARCH result and the /exclude with proper use of defeault, related and
> actual specs to test if the $SEARCH result would result in $PARSE
> finding the file (hence telling you to exclude that file).
I don't want to do a $SEARCH here, just check an already searched
name. The goal is to make it work better, not to re-write the whole
program.
> Again, this is just brainstorming.
Call off the cloud seeding.
From: Kilg...@SpamCop.net (Larry Kilgallen)
> > And "[*.m]" would match "[a.b.c.d.e.f.g.h.i.j.k.l.m]" as well as it
> > would "[a.m]".
>
> In normal VMS usage [...m] will match both of those.
And "[*.m]" wouldn't. I think that that was my point. Or did I
misunderstand me?
> I think you need to describe the matching semantics you want.
I think "[n]ormal VMS usage" covers it pretty well. Which news group
is this? Am I lost?
Dave Froble
> In article <11n8p36...@corp.supernews.com>, Dave Froble <da...@tsoft-inc.com> writes:
>
>>Larry Kilgallen wrote:
>
>
>>>What price are you willing to pay for such a quality implementation ?
>>>I am sure that will affect whether people jump into the fray.
>>
>>The various versions of ZIP for VMS are, to the best I know, basically
>>free. A service to the VMS community. To ask an entity who is
>>providing a free service to the VMS community to pay for providing such
>>a service is, ah, less than appropriate.
>>
>>To put it into perspective, would you pay me for the priviledge of
>>coming here and working for me?
>>
>>Back to the issue. I'm thinking that 1) HP is the #1 beneficiary of
>>such VMS freeware, because it supports an HP product, and 2) VMS BACKUP
>>and probably other utilities already have all the required
>>functionality, that it sure would be appropriate for some form of
>>colaboration including VMS engineering.
>
>
> And that is the nub of the problem.
Ok, I'm going to try to understand this.
> I believe HP's efforts should be
> concentrated on supported software.
For the most part, yes. However, to totally ignore all other activity
will at times not be good customer relations.
> If people wanted a BACKUP/ZIP
> capability that certainly has been delayed by presence of the "free"
> version
I don't think that's what's being discussed, nor have I personally heard
any requests for BACKUP to be involved.
ZIP does two things.
1) it compresses data.
2) it encapsulates data inside a structure with known characteristics.
The 'archive' can be treated as binary data and transmitted as such
while retaining the capability of successfully extracting the data once
it reaches it's destination.
While BACKUP does a similar task, it depends upon file characteristics
outside the 'container', thus rendering it more complex to move outside
VMS environments.
Therefore ZIP does offer a useful capability to VMS users. I've read
that 'official' 'supported' ECOs are moved over the internet in ZIP
archives.
> (that is "free" only for those who value their own time at
> zero).
Here's where understanding breaks down.
There are not charges for the product.
As for obtaining the product, installing the product, and using the
product, what difference is there between the 'free' product and any
'official' 'supported' product from HP for which you will incur a cost
above that of the freeware product?
If the issue you're raising is that an entity will produce a product
without compensation, well, there may be many valid reasons such is
done, but that has no bearing upon anyone else using the product.
If the issue is that you cannot 'trust' the product without reviewing
the sources and building executables from reviewed sources, well then
consider that the cost of the product. Note that 'trust' isn't a given
with 'supported' software.
Still not sure I've understood the issue.
Larry Kilgallen
> Larry Kilgallen wrote:
>> I believe HP's efforts should be
>> concentrated on supported software.
>
> For the most part, yes. However, to totally ignore all other activity
> will at times not be good customer relations.
They should not ignore other activities. They should consider what
features drive people to use unsupported software and consider doing
the equivalent in supported software.
>> If people wanted a BACKUP/ZIP
>> capability that certainly has been delayed by presence of the "free"
>> version
>
> I don't think that's what's being discussed, nor have I personally heard
> any requests for BACKUP to be involved.
>
> ZIP does two things.
>
> 1) it compresses data.
That is what Backup currently does not do.
> 2) it encapsulates data inside a structure with known characteristics.
>
> The 'archive' can be treated as binary data and transmitted as such
> while retaining the capability of successfully extracting the data once
> it reaches it's destination.
That is what Backup does.
> While BACKUP does a similar task, it depends upon file characteristics
> outside the 'container', thus rendering it more complex to move outside
> VMS environments.
If you use a transmission method that destroys the metadata, then
of course things will fail. There have been command sequences to
work around such errors ever since there has been Backup.
>> (that is "free" only for those who value their own time at
>> zero).
>
> Here's where understanding breaks down.
>
> There are not charges for the product.
And there is no support, so you end up supporting it yourself.
Thus it is not "free" unless you value your own labor at zero.
> As for obtaining the product, installing the product, and using the
> product, what difference is there between the 'free' product and any
> 'official' 'supported' product from HP for which you will incur a cost
> above that of the freeware product?
Submit a trouble report to HP on the unsupported product.
Let us know when they fix it.
Or let us know when you figure out how to fix it without any effort.
(But the figuring out counts as effort.)
Dave Froble
> In article <11n9igs...@corp.supernews.com>, Dave Froble <da...@tsoft-inc.com> writes:
>
>>Larry Kilgallen wrote:
>
>
>>>I believe HP's efforts should be
>>>concentrated on supported software.
>>
>>For the most part, yes. However, to totally ignore all other activity
>>will at times not be good customer relations.
>
>
> They should not ignore other activities. They should consider what
> features drive people to use unsupported software and consider doing
> the equivalent in supported software.
The sad facts are, customers don't support vendor activity in the same
manner we're used to from the 70s and 80s. VMS engineering cannot
command the budget to do everything every customer wants/needs. Even in
the past everything wasn't available. Just not possible. Got to choose
your fights carefully these days.
Surely you don't think that VMS engineering can produce and support
every capability that VMS customers want? There are limits. But those
limits should not limit what's available to people. Thus the freeware,
and some of it quite good and useful. I see people commenting favorably
on such, even the people in VMS engineering. Just look at the
acceptance of the DFU (or is it DFO) disk utility. Freeware. Happens
that the author worked at DEC, I believe. Not supported.
>>>If people wanted a BACKUP/ZIP
>>>capability that certainly has been delayed by presence of the "free"
>>>version
>>
>>I don't think that's what's being discussed, nor have I personally heard
>>any requests for BACKUP to be involved.
>>
>>ZIP does two things.
>>
>>1) it compresses data.
>
>
>
> That is what Backup currently does not do.
>
>
>>2) it encapsulates data inside a structure with known characteristics.
>>
>>The 'archive' can be treated as binary data and transmitted as such
>>while retaining the capability of successfully extracting the data once
>>it reaches it's destination.
>
>
> That is what Backup does.
>
>
>>While BACKUP does a similar task, it depends upon file characteristics
>>outside the 'container', thus rendering it more complex to move outside
>>VMS environments.
>
>
> If you use a transmission method that destroys the metadata, then
> of course things will fail. There have been command sequences to
> work around such errors ever since there has been Backup.
Yep, got some myself. Short little (unsupported) program that reads the
blocksize of any save set. But a ZIP archive, transmitted as binary
data, has no metadata to lose, and needs no workarounds.
>>>(that is "free" only for those who value their own time at
>>>zero).
>>
>>Here's where understanding breaks down.
>>
>>There are not charges for the product.
>
>
> And there is no support, so you end up supporting it yourself.
> Thus it is not "free" unless you value your own labor at zero.
>
>
>>As for obtaining the product, installing the product, and using the
>>product, what difference is there between the 'free' product and any
>>'official' 'supported' product from HP for which you will incur a cost
>>above that of the freeware product?
>
>
> Submit a trouble report to HP on the unsupported product.
> Let us know when they fix it.
>
> Or let us know when you figure out how to fix it without any effort.
> (But the figuring out counts as effort.)
Ok, comprehension hits me over the head. Your concern is having to
support the freeware. It seems that the normal response to that issue
is, if it works, use it, if it doesn't work, don't use it, and in that
case you aren't out any purchase price. The only downside is if you
'really' need it to work, and it doesn't.
Submitting a trouble report to HP takes no effort? If you're told it
will be fixed in the next release of the product, how much good does
that do you today? You work around the problem, not using the product,
pretty much like freeware that doesn't work.
Just to state my perspective, I'm not a fan of free software. Someone
has put effort into the product, and not too many of us can afford to
work for free. Unfortunately, too many times people just will not buy
smaller software products. Had this conversation with Glenn Everhart,
who also has written some nice things, and people just wouldn't cough up
the bucks. So, sometimes, just to support the community, you make the
software available without charging for it.
Larry Kilgallen
> Surely you don't think that VMS engineering can produce and support
> every capability that VMS customers want? There are limits. But those
Only those with wide appeal.
> limits should not limit what's available to people. Thus the freeware,
> and some of it quite good and useful.
Certainly. But for those with a mission-critical need, freeware is
not going to be "cheap". It may be _necessary_ if there is no
supported product to do the same thing. Freeware is only "cheap"
for those with the freedom to abandon their project if the freeware
does not immediately do what they want.
> Larry Kilgallen wrote:
>> If you use a transmission method that destroys the metadata, then
>> of course things will fail. There have been command sequences to
>> work around such errors ever since there has been Backup.
>
> Yep, got some myself. Short little (unsupported) program that reads the
> blocksize of any save set.
I have always used BACKUP followed by COPY/OVERLAY, avoiding the
need to carry a command procedure.
> But a ZIP archive, transmitted as binary
> data, has no metadata to lose, and needs no workarounds.
But one cannot count on the required software being present on
every VMS system.
> Ok, comprehension hits me over the head. Your concern is having to
> support the freeware. It seems that the normal response to that issue
> is, if it works, use it, if it doesn't work, don't use it, and in that
> case you aren't out any purchase price. The only downside is if you
> 'really' need it to work, and it doesn't.
Yes, mission-critical computing cannot be based on "hope it works".
> Just to state my perspective, I'm not a fan of free software. Someone
> has put effort into the product, and not too many of us can afford to
> work for free. Unfortunately, too many times people just will not buy
> smaller software products. Had this conversation with Glenn Everhart,
> who also has written some nice things, and people just wouldn't cough up
> the bucks. So, sometimes, just to support the community, you make the
> software available without charging for it.
I have no quarrel with donors making their software available.
I am biased against recipients counting on it to meet their needs.
AEF
> From: Kilg...@SpamCop.net (Larry Kilgallen)
>
> > >> To find all files in a directory tree properly, one needs to call RMS.
> > >
> > > Which is not what I'm trying to do.
> >
> > I did not notice an English language description of what you were
> > trying to do. Please elaborate.
>
> At the risk of boring those who were paying attention, as I recall, I
> wrote (10-NOV-2005 00:31:47.24):
LOL!
>
> > Is there an easy way (RMS service, or something else already extant
> > in VMS V5.4, say) to test a particular file spec against a given
> > wildcard file spec? That is, for example:
> >
> > wild_match( "[.a.b.c]fred.dat", "[...b...]fred.*") /* (true) */
> > wild_match( "[.a.b.c]fred.dat", "[...b]fred.*") /* (false) */
>
>
> > >> > Has anyone else noticed that "Zip -x" (or "-i") doesn't deal properly
> > >> > with "..." in a directory spec?
> > >>
> > >> I thought there were multiple implementations of Zip for VMS.
> > >
> > > I refer to the Info-ZIP Zip. You have in mind which other ones?
> > > (GNU zip, which lacks "-i" and "-x", perhaps?)
> >
> > I am not a Zip user.
>
> Is there something about me personally which attracts useless advice
> from people who admit not knowing anything about the subject on which
> they offer advice? Or is it something about Zip? If I knew, then
> perhaps I could take appropriate steps.
I hear you! I have gotten the full range of understanding to my posts.
Sometimes I get exactly the answer I need. Other times people
completely misunderstand me and post stuff that is of no help. Still
other times I get nothing.
E.g., I recently posted a question about why I can't get my DECnet
configurators to work. No response at all. Is it really true that no
one who reads cov can answer this question? Have all the configurator
experts put me in their kill file? Oh well. Maybe the configurator is
just a joke: It doesn't really work, but simply pads the manual a
little. ;-) (Just kidding.) Maybe I'll try ITRC or Ask the Wizard.
Perhaps people aren't responding because of another misunderstanding:
my question about a node dropping itself. I asked: what does that mean?
Instead, I get people trying to diagnose my whole network. Not meaning
to be ungrateful, I was trying to steer things back to just what it
means for a node to drop itself. To me, it's like someone standing up
and shouting "I am not going to talk or listen to myself anymore so
everyone take notice!" (!) I guess the meaning of a node dropping
itself is so obvious to most they think I must be asking for a
diagnosis. The other problem is my network is part of a much larger
network and I don't know all the details of everything in the network
and no one at work in the network group is going to take the time to
answer such questions for me. I tried to answer people's questions but
I guess I came up short and everyone just sort of gave up at some
point. Networks is my weak suit (making my answering their questions
more difficult) and I am trying to catch up. OK.
I also once asked about the mysterious default input/output streams
table for SPAWN/INPUT and SPAWN/OUTPUT. No one seems to know about
this. Maybe this table is the same as that weird thing in older ON
documentation saying something like "to specify a control/y interrupt
specify CRTL/Y". Just something mysterious that somehow wanderred into
the documentation. Well, the mysterious CTRL/Y statement is gone from
at least 6.2 and later but the spawn tables are still there. The SPAWN
question involves this:
"Note that when NRO PPFs are used as implicit input (that is, the
/INPUT qualifier is not specified and SYS$INPUT is a NRO PPF), the
SPAWN command can succeed, as shown in the following table: "
What NRO PPF's. SYS$INPUT? SH DEV shows that "TT" is a record-oriented
thing. What does it mean? When is SYS$INPUT a NRO PPF?
In another thread I started someone insisted I reveal who I was. Now
how is THAT going to help solve the problem???!!! :-)
Now I'm reading this post and I can "feel your pain". Some are equating
'*' with '...'. Others are looking for actual matching files when all
you want is to see if a given non-wildcard file-spec matches a given
wildcard file-spec or not. Again, an answer from someone who can't help
you !!! but at least I understand (or think I do) the problem posed! I
think you're trying to fix the zip equivalent of /EXCLUDE. And then
there's the free vs. pay sidebar.
I also find out that Google Groups actually has something that another
newsreader doesn't (I mean beside the years-long archive and stupid
bugs and stupid features.)
Then there's the 'infamous' am/pm thread which I never intended to
start or nourish but people kept posting posts that showed gross
misunderstanding of what I was trying to say or claimed I was dead
wrong. Maybe I was unclear. Maybe some couldn't read. I don't know. But
I couldn't just let everyone misunderstand me! And I felt I had to
defend myself against accusations of being dead wrong. (Maybe those who
killfiled me for the am/pm bit are exactly the configurator experts!)
Anyway, good luck with your problem. Sorry, but I can't help you!!!
>
> On the bright side, it's getting harder not to be an UnZip user, as
> many patch kits are now being distributed as self-extracting UnZip
> archives. (Using an obsolete UnZip version, of course.)
>
> > [... blather ...]
> > What price are you willing to pay for such a quality implementation ?
> > I am sure that will affect whether people jump into the fray.
>
> Never mind. I'll just keep working on it myself. You can work on
> whatever you want when and as you feel the need.
I'll give 10 quatloos. (Sorry, can't resists a chance to bring Star
Trek into the discussion!) And thanks for the great laugh session.
>
> ------------------------------------------------------------------------
>
> Steven M. Schweda (+1) 651-699-9818
> 382 South Warwick Street sms@antinode-org
> Saint Paul MN 55105-2547
AEF
AEF
Steven M. Schweda wrote:
> From: "Hein RMS van den Heuvel" <heinvand...@gmail.com>
>
> > As par as that base problem goes, I think that SYS$PARSE with
> > NAM$V_SYNCHK is as close as you are going to get with system services
> > to help you normalize & parse a user provided filespec.
>
> I'm starting to lean that way. More thought required.
>
> > While dabling in this space, maybe you spot some ''easy' regular
> > expression code allowing your end user more elaborate selection
> > criteria?
>
> Maybe not. Just trying to match the current non-VMS functionality in
> Zip with normal VMS user expectations (mine). The ODS5 extended file
> name escape syntax ("^") causes trouble for the existing code, too, as
> it tends to think one character at a time. Everything's complicated.
OK, good. Your request should really be clear now.
> From: JF Mezei <jfmezei...@teksavvy.com>
>
> > For each file, you might be able to build some sys$parse that uses the
> > $SEARCH result and the /exclude with proper use of defeault, related and
> > actual specs to test if the $SEARCH result would result in $PARSE
> > finding the file (hence telling you to exclude that file).
>
> I don't want to do a $SEARCH here, just check an already searched
> name. The goal is to make it work better, not to re-write the whole
> program.
>
> > Again, this is just brainstorming.
>
> Call off the cloud seeding.
LOL, I love it!
> From: Kilg...@SpamCop.net (Larry Kilgallen)
>
> > > And "[*.m]" would match "[a.b.c.d.e.f.g.h.i.j.k.l.m]" as well as it
> > > would "[a.m]".
> >
> > In normal VMS usage [...m] will match both of those.
>
> And "[*.m]" wouldn't. I think that that was my point. Or did I
> misunderstand me?
Good.
Well, you did miss a question mark or a ;-) right after "[a.m]".
> > I think you need to describe the matching semantics you want.
>
> I think "[n]ormal VMS usage" covers it pretty well. Which news group
> is this? Am I lost?
Creme de la creme. It doesn't get any better!
Thank you so much. But please, do give some warning next time. I almost
stopped breathing I was laughing so hard!
Brilliant delivery, thank you.
"Am I lost?" you ask.
Meet Mr. Steven M. Schweda. A VMS programmer in St. Paul, Minnesota,
working on making the exclude qualifier of zip finally work correctly
for the ellipsis wildcard string. Doing a great service for the VMS
community. But he comes to a stumbling block. Goes to c.o.v. to try to
get some answers, but finds, instead, ...do-do-do-do do-do-do-do... A
signpost on the road ahead. Your next stop: The Twilight Zone.
Hey, that's the best I can do after being laugh-deprived of oxygen. ;-)
>
> ------------------------------------------------------------------------
>
> Steven M. Schweda (+1) 651-699-9818
> 382 South Warwick Street sms@antinode-org
> Saint Paul MN 55105-2547
AEF