DosTips.com

This is very simple to perform with JREPL.BAT :D Assuming the input file is indeed UTF-16 LE, and you want your output to be the same, then: jrepl "^(\d+) DIALOG" "$txt=$0; openOutput($1+'.rc',false,true);" /jq /utf /f dialog.rc The /jq option instructs that the 2nd argument is JScript code. The /ut...

Thanks sst. Your explanation of how the child processes inherit the file handles is really helpful, and steps 1 and 2 of the pipe setup makes enough sense that I can envision how your technique could work. But the details after step 2 confuse me. :? I can't tell if there is a problem with your write...

The simplest way to quickly see the underlying code is to modify the script as follows: 1) Add ECHO ON after the @ECHO OFF line. 2) On all of the subsequent lines, prefix each line with REM<space>. The <space> represents a single space character. Now simply run the modified script, and all of the RE...

Hi Dave, in your script at this line cmd /v:on /c "<nul set /p "=!str:~0,%1!"" 0>&3 4>&0 | break There is no need to use /v:on because !str:~0,%1! will be expanded in batch context. Delayed expansion will not be affected by pipe. You are correct, but only because I had accidentally dropped parenthe...

Cool So you mostly confirm my finding, but there is one thing that surprises me. My script shows that the buffer is 4096 bytes long. But your script shows that if the writer performs an operation that exactly fills the buffer, then subsequent writer commands are blocked until the reader reads the bu...

I had gotten the ~1000 byte buffer limit from jeb at the bottom of this StackOverflow answer about pipe behavior . But I am seeing something different. I did some testing on my Windows 10 machine, and I see a pipe buffer of exactly 4096 bytes. I used the following script to probe the buffer size. Ea...

:shock: Fascinating :!: 8) I need to think more about this when I get free time. I'd like to trace the technique to better understand the underlying mechanics, and I'm curious if this might be of some practical use. The first thing that comes to mind is it functions somewhat like a temporary file, w...

The body of the question asks for a result of 'D:\\foo\\bar\\aaa\\bbb.txt' , but the title implies he is looking for ' "D:\\foo\\bar\\aaa\\bbb.txt" ' . (Note extra space added to differentiate between the single and double quotes) To strip the double quotes, just modify Aacini's answer by one additi...

All the code-page changes and UTF-8, UTF-16, etc. file encodings stuff is used when a program wants to display a non-Ascii character on the screen. Just to be clear: an Ascii character is one in the 0-255 range that is correctly displayed in all code pages (although some code pages show some charac...

I'm pretty sure this is a planned feature of the new Windows 10 console, but I don't understand the rationale. It appears that certain code pages are incompatible with raster fonts within the new console unless you force the console into "legacy" mode. I reported this at https://www.dostips.com/foru...

Bad news about use of FINDSTR to output the remainder after the last substitution - it is unreliable because FINDSTR cannot process lines greater than 8191 bytes long when the input is piped or redirected. I've got a pair of patchBin scripts based on CERTUTIL that work very well, and are reasonably ...

Oops, I spoke too soon. I didn't read your code carefully enough to realize you rely on the offset address to identify the lines to modify. Also, those offsets don't work for my version of cmd.exe (Windows 10) When I ran your posted code it successfully made the changes at your offsets, but who know...

I like it :D Once I saw your idea to use CERTUTIL, I began thinking of all the optimizations that could be done, and you hit all that I could think of, especially the use of SET /P to read through all the changes, and FINDSTR to read/write the remainder. I'm not sure this makes a substantive differe...

Here is how JREPL could do your example task, assuming your offsets are 0 based: Dave Benham

No, that is not possible.