yet another boundary in cmd (pipes)

[npocmaka_]

max sequence of pipes is 2042 .The 2043th produces "The handle could not be duplicated during a pipe operation." (tested on Win8x64 and WinXPx32.Not tested with conditional operators or cyclic stream redirections .):

https://gist.github.com/npocmaka/ee9ed4bf3a83b0910ff5

[penpen]

Sounds somehow like this:
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx.

penpen

[npocmaka_]

Sounds somehow like this:
http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx.

penpen

Aahh.Most probably as each pipe starts subprocess of cmd.Thanks for the link.

[jeb]

Even if the point of penpen is the real cause, the finding is quite interessant, but for a complete other reason

You bring me to another idea to be tested.

Code: Select all

@echo off
setlocal
set "var=12345678901234567890"
(
    echo @echo off
    <nul set /p  ".=echo %var%"
    for /L %%n in (1 1 2000) DO (
        <nul set /p  ".= | find "%var%" "
    )
    echo(
) > longLine.bat
call longLine.bat
for %%a in ("longLine.bat") DO echo It works, %%a is %%~za bytes long

This creates a batch with the second line looks like

Code: Select all

echo 12345678901234567890 | find "12345678901234567890" | find "12345678901234567890" | find .... | find "12345678901234567890" " 

The line is about 60.000 characters long and it still works

So the line limit of 8191 bytes is not always fix as thought it was.

Perhaps it can be useful for things like macros or something else

[foxidrive]

So the line limit of 8191 bytes is not always fix as thought it was.

I wonder if it is 8191 per pipe?

[dbenham]

Very cool jeb.

Can you fix your output? It does not match your posted script.

I don't remember the details, but I do remember you demonstrated that FOR /F has a limited ability to read lines longer than 8191 bytes long. Can you think of a way to usefully combine the FOR /F capability with this new discovery?


Dave Benham