Piped input and output to a batch file

[Squashman]

I must have typed CTRL+C thinking it was hanging.

I reran it again and it did work but it took 9 minutes 20 seconds on a file with 6,947 lines in it. File is actually just under 7MB in size.

So I ran it with Dave's Code.

Code: Select all

@echo off
echo %TIME%>davelog.log
setlocal
set "suffix1=%~n1                    ."
set suffix=%suffix1:~0,20%
for /f "delims=" %%A in ('findstr /n . %1') do (
  set "ln="
  set "ln=%%A"
  setlocal enableDelayedExpansion
  if defined ln set "ln=!ln:*:=!"
  echo(!ln!!suffix!>>DaveAppend.txt
  endlocal
)
echo %TIME%>>davelog.log

On this same file Dave's code took 3 minutes 13 seconds.

For some reason I was thinking Aacini's code would be faster.

[jeb]

I prefer the solution of dbenham with findstr, more or find, as it's nearly a pure batch solution.

It could also be useful to know if there is input from a pipe or a input redirection anyway.

How to detect if input comes from pipe or redirected file

jeb

[Squashman]

I have of course gotten off the main topic of this thread which was piping to another command.
But just throwing this last one out there.
This code from Orange Batch on the same file took all of 16 seconds.

Code: Select all

@echo off
echo %time%>oblog.log
type nul>"OBtemp.txt"
set "suffix1=%~n1                    ."
set suffix=%suffix1:~0,20%
for /f "usebackq tokens=* delims=" %%a in ("%~1") do echo(%%a%suffix%>>OBtemp.txt
echo %time%>>oblog.log
exit/b

Not sure why this one was so much faster than Dave's. I thought using FINDSTR was always the faster option.

[Liviu]

My PIPE.COM program is only 69 bytes in size, so it is a very good replacement of FINDSTR to be used in these cases. If you are worried about where to get my program from, here it is; just copy the 69 bytes below to a file named PIPE.COM and it is ready to run:

ë2´)€ì!Í!ŠÐŠà€Ä!€ü.u.€þ+u)R²A€ê!´#€ì!Í!Z´#€ì!Í!Šò€Æ!´,€ì!Í!"ÀuôLÍ!ëã

Not going to argue the merits of "inline executables", but I'd like to point that the line you quote is useless and even dangerous if you don't specify the active codepage you saved it under, and make it abundantly clear to the reader that they must 'chcp' to same codepage before pasting the text.

Issue here is that batch files are 8-bit text and, as such, they are affected by the active codepage. When one copies the line above from this page, which is Unicode-enabled, and pastes it into 8-bit text, the extended characters are converted/mapped based on the codepage being active at the time of pasting.

For example, the following generates 3 different text files on my (us-en) XP.

Code: Select all

C:\>chcp 437
Active code page: 437

C:\>echo copyright - ©©© >437.txt

C:\>chcp 850
Active code page: 850

C:\>echo copyright - ©©© >850.txt

C:\>chcp 1252
Active code page: 1252

C:\>echo copyright - ©©© >1252.txt

Liviu