Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Paul Newsgroups: alt.comp.os.windows-11,alt.comp.os.windows-10 Subject: Re: what is the fastest command line copy? Date: Wed, 2 Apr 2025 04:15:57 -0400 Organization: A noiseless patient Spider Lines: 113 Message-ID: References: <050kujpf36f33i4hspur5jg286m5r7fvn3@4ax.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Date: Wed, 02 Apr 2025 10:16:04 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e621244b6d7ee4381bb9c48990f3e77a"; logging-data="1437170"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dJBZrgGXo2FvOH1XMDEG4EXuhemm3Qe4=" User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802) Cancel-Lock: sha1:3mrAkfpZNH6TSpsRUHxP5XKhSOs= Content-Language: en-US In-Reply-To: Xref: csiph.com alt.comp.os.windows-11:18177 alt.comp.os.windows-10:183158 On Wed, 4/2/2025 2:50 AM, Steve Hayes wrote: > On Tue, 1 Apr 2025 09:26:02 -0400, Newyana2 > wrote: > >> On 4/1/2025 1:00 AM, Steve Hayes wrote: >> >>> I've hitherto uased batch files, which are a form of scripting. >>> >>> Is there a better tool to use for this? >>> >> >> Big topic. I guess a lot of it depends on what you're used to. >> For people who started with DOS, commandline feels natural. >> And it can do some complex things. I try to avoid it because >> it's relatively limited and combines coding with doing, by which >> I mean, every time I want to do something I have to remember >> or look up the exact syntax I'll need. So I have to write the code >> every time, so to speak. The whole point of scripting for me is >> so that I only have to do something once. Next time I only have >> to double-click or drag-drop. > > I'm not sure what you're saying here. > > I have four batch files: > > dsk2flsh.bat > flsh2lap.bat > lap2flsh.bat > flsh2dsk.bat > > I only have to remember the exact syntax when I make the batch files, > and after that I I have to remember is the name of the batch file. > > When those .bat files copy things, do you check the "error number" to see if the copy was successful ? Scripting is "programming", and the same things I would have to check when writing a C language program, those are still issues when running a (so-called OS) copy program. Here, my personal copy program returns a value of "1", if the source file cannot be opened. This clause was written by an AI by the way. "It doesn't have to make sense", as the AI would tell you :-) What the AI didn't tell me, is there is a bug in one of the library routines I should know about. # part of paulcopy64.exe source code... Mostly written by an AI. # I only fix them up and make them work. The comment is written by the AI. // Open the source file in binary mode FILE *source = fopen64(argv[1], "rb"); if (!source) { perror("Error opening source file"); return 1; } Now, we test in a Command Prompt, and see if the returned integer error code, is arriving OK or not. It is. If each error has a different integer number, you can tell the error types apart, with numeric checks of %errorlevel% . D:\>paulcopy64 a b Error opening source file: No such file or directory D:\>echo %errorlevel% 1 # Om my! My copy did not proceed. Making a batch file is not "just making a laundry list". It needs conditional checks (somehow) of each stage of the operation. And in my C program snippet, you can see the AI is doing the same thing. The AI assumes I will be scripting calls to "paulcopy64.exe" and scripting needs the number, to check the program run went OK. In scripting, you have to be careful with "volatile" items like an %errorlevel% . They must be copied before they are lost, by the next utility program loading its success or failure status into that single variable in the shell. Look at the following and note my handling mistake. The error result from the "dir" command, has overwritten the "1" left in the %errorlevel% . There was no error in the "dir" run and the result from it is "0". D:\>paulcopy64 a b Error opening source file: No such file or directory D:\>dir Volume in drive D Directory of D:\ Tue, 03/18/2025 09:56 AM 252,122 paulcopy64.exe D:\>echo %errorlevel% 0 # Oops! I lost my copy failure code. The paulcopy64.exe was actually compiled on Ubuntu 23.04 as a cross compile, as I have not managed to get a good mingw64 for Windows set up here. So I just cross-compiled it, and that is why the program is 252,122 bytes, when it should be a lot smaller for a dumb copy program. # Asking Ubuntu to make a 64-bit version of a Windows EXE (a PE32+ EXE file). # The FILE_OFFSET_BITS is to enable 64 bit long length fields and stuff. # The compiler package (effectively a script) must be installed for the executable # of the compiler, to be found. "x86_64-w64-mingw32-gcc" does not exist by default. # This allows my program to have "gobs" of RAM, compiling it this way :-) /usr/bin/x86_64-w64-mingw32-gcc -D_FILE_OFFSET_BITS=64 -I/usr/x86_64-w64-mingw32/include -o paulcopy64.exe paulcopy64.c Paul