On Thursday, 24 January 2019 22:49:41 UTC, JJ  wrote:   
   > On Thu, 24 Jan 2019 12:25:58 -0800 (PST), JRS wrote:   
   > > I run a batch program (Windows 10 usually; could be earlier maybe)   
   > > which uses XCOPY (I cannot use COPY, as XCOPY's /D is needed).   
   > >   
   > > I use   
   > >   FOR /F "eol=; tokens=1*" %%J IN ... (   
   > >     ...   
   > >     XCOPY /D /Y %%J  %unto%%%J %%K | FIND /v " File(s) copied"   
   > >     )   
   > >   
   > > After various enhancements, it now sometimes asks whether the   
   > > name on the destination should be a file or a directory, but   
   > > without the (F = file, D = directory)? - I expect the FIND /v   
   > > eats that.   
   > >   
   > > Is there a good way to eliminate that question, and choose   
   > > file every time?  Nothing shown by FIND /? seems suitable,   
   > > but ICBW.  I can answer it "blind", but that's not nice.   
   > >   
   > > This is an example of what I mean, I think :-   
   > >     Prompt>xcopy pascal.htm e:fred.kk   
   > >     Does E:fred.kk specify a file name   
   > >     or directory name on the target   
   > >     (F = file, D = directory)?   
   >   
   > XCOPY will prompt you that if the destination doesn't exist. To always treat   
   > the destination as a file, make sure the destination exists as a file. So,   
   > create an empty file using the destination path, before executing XCOPY.   
   > e.g.   
   >   
   >   set src=pascal.htm   
   >   set dest=e:fred.kk   
   >   (rem.>%dest%)2>nul   
   >   xcopy /y %src% %dest%   
      
   That, as is, will not do; it will erase the old file %dest%, and   
   I want to copy only the few new files, leaving the many other old   
   ones untouched (especially as the destination might be a slow   
   device, and some files are vast).  So I can use 'if not exist   
   dest create a dest first'.   
      
   I'd rather not use both XCOPY and XCOPY /D, but instead of   
   your redirected REM I could copy over an ancient (and perhaps   
   empty) file.  DOS datestamps used a 16-bit unsigned integer   
   for days since 1980-01-01 = Day 0, but I see that imported   
   Touch32 in Win10 can go back to 1601-01-01.  But XCOPY is   
   ancient, and might not like that.  Going back to, say, 1981   
   should be safe.   
      
   H'mmm - I've used various ways to create a zero-length file   
   in the past, presumably because the obvious one did not then   
   work.   
      
   But (command line)   
           copy nul zzz      > nul   
           touch32 zzz 1981  > nul   
           dir zzz   
   shows   
           1981-01-01  00:00                 0 zzz   
      
   That looks promising.   
      
      
   P.S.  I don't mind using an already-imported tool, Touch32; but   
   I don't want to import and learn another tool for this.  Hence   
   - no RoboCopy.   
      
   Thanks.   
      
   --   
     (c) John Stockton, near London, UK.  Using Google Groups.           |   
    Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)