Problem with except
Robert
except (*.exe *.tmp *.bak) copy /u *.* f: /s
I would expect that any file form the current drive and directory (and all
its subdirectories), that did not meet the "except" criteria, would be
copied to the F: drive (provided that it was a new file, or a newer version
of a file already on F:).
Well, it works as if I never specified the "except" command. What am I
doing wrong?
Steve Fabian
news:e5491$418a81f8$42a70da1$15...@msgid.meganewsservers.com...
You mention neither the TC version, nor the OS.so it is difficult to
reproduce your problem.
Is COPY by any chance an alias?
Regardless, a much simpler approach in JPsoft command processors is to use
the EXCLUSION RANGE feature, which works regardless of attributes or alias
definition:
copy /u /s /[!*.exe *.tmp *.bak] *.* f:
--
Steve
Robert
--
"Steve Fabian" <ESFa...@BellAtlantic.net> wrote in message
news:m_SdnRkAqfX...@comcast.com...
Sorry about that :-(.
Take Command/32 2.01A Windows NT 5.01 (XP Pro)
Copy is not a alias, and no attributes are set (other than archive), so...
I will give a try to the approach you recommended, as well.
Steve Fabian
> ...
> Take Command/32 2.01A Windows NT 5.01 (XP Pro)
>
> Copy is not a alias, and no attributes are set (other than archive), so...
>
> I will give a try to the approach you recommended, as well.
You are using a really old version. It just might not work with NTFS5 file
system properly. Current release is 6.00, and 6.01 (with some features added
to 6.00) is in public beta. For anybody using a recent version of an MS OS
it has many features worth getting. Free trial is available at
http://jpsoft.com.
--
Steve
Charles Dye
Nitpick: The range must always immediately follow the command.
(Exception: DO.)
copy /[!*.exe *.tmp *.bak] /u /s *.* f:
Steve, I see that the help files for both 4NT/Take Command and 4DOS
suggest that EXCEPT would be useful with COPY /S. I haven't had time
to play with it, but I suspect that such is not the case -- that some
of the examples given in the help files are misleading if not flat-out
wrong. It seems unlikely that EXCEPT would know to hide matching
files in subdirectories....
Robert, think of EXCEPT as a crock implemented for the benefit of
*external* commands. As Steve points out, exclusion ranges are a
far cleaner approach when using internal commands. Even with
externals, EXCEPT may not be the best way to go. You can usually wrap
an external program in a DO loop or FOR loop instead, and get the
full benefit of the JP extended file selection features: exclusion
ranges, extended wildcards, recursion into subdirectories, @file
lists, selection by attributes or file descriptions, etcetera. EXCEPT
is a little simpler to use, but that's almost its only benefit.
--
Charles Dye ras...@highfiber.com
Steve Fábián
"Charles Dye" <cd...@unm.edu> wrote in message
news:5b5lo09nn628g1o11...@4ax.com...
>
> Steve, I see that the help files for both 4NT/Take Command and 4DOS
> suggest that EXCEPT would be useful with COPY /S. I haven't had time
> to play with it, but I suspect that such is not the case -- that some
> of the examples given in the help files are misleading if not flat-out
> wrong. It seems unlikely that EXCEPT would know to hide matching
> files in subdirectories....
I never tried, I'll repost this in jpsoft_support for Rex to answer.
--
Steve
Mike Bessy
requested pattern and it will not recurse directories. It's been a very
long time since that command has had any actual use, and it's definitely
not a wise choice for directory tree scanning. I'm sure JP Software can
give you all the details (probably blaming me for any inaccuracy in the
help files)... :-).
>> From Charles Dye on 11/4/2004 3:10 PM:
>
> Nitpick: The range must always immediately follow the command.
> (Exception: DO.)
>
> copy /[!*.exe *.tmp *.bak] /u /s *.* f:
>
> Steve, I see that the help files for both 4NT/Take Command and 4DOS
> suggest that EXCEPT would be useful with COPY /S. I haven't had time
> to play with it, but I suspect that such is not the case -- that
> some of the examples given in the help files are misleading if not
> flat-out wrong. It seems unlikely that EXCEPT would know to hide
> matching files in subdirectories....
>
> Robert, think of EXCEPT as a crock implemented for the benefit of
> *external* commands. As Steve points out, exclusion ranges are a far
> cleaner approach when using internal commands. Even with externals,
> EXCEPT may not be the best way to go. You can usually wrap an
> external program in a DO loop or FOR loop instead, and get the full
> benefit of the JP extended file selection features: exclusion
> ranges, extended wildcards, recursion into subdirectories, @file
> lists, selection by attributes or file descriptions, etcetera.
> EXCEPT is a little simpler to use, but that's almost its only
> benefit.
>
--
-----------------
Mike Bessy
bi...@starband.net
Mike....@gmail.com
http://mike.computermdonline.com/
_________________
Steve Fábián
"Mike Bessy" <bi...@starband.net> wrote in message
news:XpEid.35$Vl...@fe25.usenetserver.com...
> EXCEPT merely turns on the "hidden" attributes for files matching the
> requested pattern and it will not recurse directories. It's been a very
> long time since that command has had any actual use, and it's definitely
> not a wise choice for directory tree scanning. I'm sure JP Software can
> give you all the details (probably blaming me for any inaccuracy in the
> help files)... :-).
I can't blame you, since the sentence below has been in the topic "HELP
EXCEPT" for years:
EXCEPT will assume that the files to be excluded are in the current
directory, unless another directory is specified explicitly.
For me the above would indicate that recursion by the target command is
independent of EXCEPT, and EXCEPT does NOT support recursion.
--
Steve
Mike Bessy
publicly for so many things and only got away with it because I can't
afford an attorney... :-)
>> From Steve Fábián on 11/5/2004 6:04 AM:
>
> I can't blame you, since the sentence below has been in the topic
> "HELP EXCEPT" for years:
>
> EXCEPT will assume that the files to be excluded are in the current
> directory, unless another directory is specified explicitly.
>
> For me the above would indicate that recursion by the target command
> is independent of EXCEPT, and EXCEPT does NOT support recursion.
--
Robert
involvement in the various JPSOFT fora, over the years, I always associated
your name with the person to go to when "nobody else" could help. Are you
saying people at JPSOFT turned on you? That's a shame :-( And, who would
that be? Since you said it was done publicly, there is no harm in telling
us!
"Mike Bessy" <bi...@starband.net> wrote in message
news:IJMid.590$Vl5...@fe25.usenetserver.com...
Charles Dye
>Steve, I see that the help files for both 4NT/Take Command and 4DOS
>suggest that EXCEPT would be useful with COPY /S. I haven't had time
>to play with it, but I suspect that such is not the case -- that some
>of the examples given in the help files are misleading if not flat-out
>wrong. It seems unlikely that EXCEPT would know to hide matching
>files in subdirectories....
After a closer look, the examples in the help file are not wrong at
all. They work as intended, and are in fact rather clever. EXCEPT is
used to set the hidden attribute of *subdirectories* before executing
the COPY /S -- neatly preventing COPY from recursing into those
particular subdirectories. So EXCEPT *is* useful with COPY /S, but
only to exclude subdirectories; attempting to use wildcards to hide
*files* from COPY /S would be less successful. Not immediately
obvious from the help text, but it makes sense if you think about how
EXCEPT works.
--
Charles Dye ras...@highfiber.com
Mike Bessy
"dumped". Rex Conn (who bought out founder Tom Rawson a couple of years
ago) suddenly decided to dispense with my services in a swift and wholly
unexpected move. It was all done in 48 hours around 05-August without
any warning, or explanation. Rex bought my few useless shares of JP
Software for next to nothing. I've been unemployed ever since.
>> From Robert on 11/5/2004 12:35 PM:
> I am not a 4DOS power user, or anything, but from my *very* little
> involvement in the various JPSOFT fora, over the years, I always
> associated your name with the person to go to when "nobody else"
> could help. Are you saying people at JPSOFT turned on you? That's a
> shame :-( And, who would that be? Since you said it was done
> publicly, there is no harm in telling us!
--
Bill Stewart
> ... representing JP Software, ...
This might have been part of the problem. Based on some simple Google
Usenet queries, it wasn't just me that felt your treatment of JP
Software customers was, shall we say, less than optimal.
> ... wholly unexpected move ...
I'm genuinely surprised at this statement, and I think it's really
unfortunate. I hope you will take your situation to heart and realize
the implications of your actions.
Regards,
Bill
Mike Bessy
from the JP Software Forum, your opinion doesn't come as a total shock.
Like it or not, the customer is *not* always right, and only companies
whose only concern is selling more copies will abide by that silly
philosophy. If Rex were to share publicly some of his comments about
"valued customers" (and even recent associates), you might be surprised.
I personally prefer truth and honesty, and specifically never took more
than very minimal income from JP Software on purpose to avoid the
temptation of letting greed guide me.
Rest assured that I have no regrets about anything I did or said during
my long tenure with JP Software. Tom Rawson was guided by a nice set of
personal values. Unfortunately, he no longer controls the company.
>> From Bill Stewart on 11/5/2004 4:51 PM:
>...
> This might have been part of the problem. Based on some simple Google
> Usenet queries, it wasn't just me that felt your treatment of JP
> Software customers was, shall we say, less than optimal.
>
>> ... wholly unexpected move ...
>
>
> I'm genuinely surprised at this statement, and I think it's really
> unfortunate. I hope you will take your situation to heart and realize
> the implications of your actions.
>
> Regards,
>
> Bill
--
Bill Stewart
> Since I believe you were either banned or had your access restricted
> from the JP Software Forum, your opinion doesn't come as a total
> shock.
Lest readers misunderstand, the reason for this "banning" was that I
corrected some of your inaccurate technical statements. The truth of the
matter was that you had no way of justifying your statements, and the
only way to avoid having to retract anything was to censor me.
> Like it or not, the customer is *not* always right, ...
True, but it's also possible that the person making this statement is
not always right either. It goes both ways.
> Rest assured that I have no regrets about anything I did or said
> during my long tenure with JP Software.
This is unfortunate. A person that refuses to own their behavior and
learn from their mistakes; a person that blames everyone else for their
problems -- such a person is a liability to any company.
Regards,
Bill
Robert
here. Based on the messages posted, I guess there is some bad blood here.
All I was saying, was that your name was the one heard when it came to tech
help. I have had no personal experience, or have heard anything regarding
"attitude" or whatever. So, I'll stay out of this, and sorry to have
re-opened what appear to be old wounds :-(
"Mike Bessy" <bi...@starband.net> wrote in message
news:ugRid.595$Vl5...@fe25.usenetserver.com...
Mike Bessy
*still* have no interest in pursuing this non-conversation or in
rewriting your personal history with JP Software. Whether you're Rex's
valued customer or his recurrent headache nowadays is not my problem... :-)
>> From Bill Stewart on 11/8/2004 9:49 AM:
>...
>
> Lest readers misunderstand, the reason for this "banning" was that I
> corrected some of your inaccurate technical statements. The truth of
> the matter was that you had no way of justifying your statements, and
> the only way to avoid having to retract anything was to censor me.
>
>> Like it or not, the customer is *not* always right, ...
>
>
> True, but it's also possible that the person making this statement is
> not always right either. It goes both ways.
>
>> Rest assured that I have no regrets about anything I did or said
>> during my long tenure with JP Software.
>
>
> This is unfortunate. A person that refuses to own their behavior and
> learn from their mistakes; a person that blames everyone else for
> their problems -- such a person is a liability to any company.
>
> Regards,
>
> Bill
--
Bill Stewart
> Whether you're Rex's valued customer or his recurrent headache
> nowadays is not my problem... :-)
Hmm. Based on your situation, who, exactly, was a headache?
Bill
Mike Bessy
has its share of unhappy users and every support representative has
irked a number of people. There can be countless satisfied customers
but what always stands out is the handful of chronic complainers. It
comes with the territory and it's part of the price one has to pay for
being somewhat of a "public figure" for so long. I won't lose any sleep
over it and I hope you don't either... :-)
>> From Robert on 11/8/2004 11:38 AM:
> Oops... My intent was NOT to start a war-of-words, or anything like
> that here. Based on the messages posted, I guess there is some bad
> blood here. All I was saying, was that your name was the one heard
> when it came to tech help. I have had no personal experience, or
> have heard anything regarding "attitude" or whatever. So, I'll stay
> out of this, and sorry to have re-opened what appear to be old wounds
> :-(
--
Stan Brown
comp.os.msdos.4dos:
>Mike Bessy wrote:
>
>> Since I believe you were either banned or had your access restricted
>> from the JP Software Forum, your opinion doesn't come as a total
>> shock.
>
>Lest readers misunderstand, the reason for this "banning" was that I
>corrected some of your inaccurate technical statements. The truth of the
>matter was that you had no way of justifying your statements, and the
>only way to avoid having to retract anything was to censor me.
Which is _precisely_ why any controlled in-house forum is a bad
thing for users.
(All the technical problems and server failures were just icing on
the cake.)
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
"And if you're afraid of butter, which many people are nowa-
days, (long pause) you just put in cream." --Julia Child
Bill Stewart
> Which is _precisely_ why any controlled in-house forum is a bad thing
> for users.
I don't begrudge the company for wanting an official support venue. I do
take exception to being bullied. Several people have told me that they
had to "Mike-proof" their comments, lest they be perceived as an attack
on his ego.
> (All the technical problems and server failures were just icing on
> the cake.)
Indeed. Your post below is a humorous reminder:
Regards,
Bill