Page 1 of 1

yet another boundary in cmd (pipes)

Posted: 10 May 2015 05:20
by 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

Re: yet another boundary in cmd (pipes)

Posted: 10 May 2015 13:23
by penpen

Re: yet another boundary in cmd (pipes)

Posted: 10 May 2015 13:44
by npocmaka_
penpen wrote: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.

Re: yet another boundary in cmd (pipes)

Posted: 11 May 2015 02:36
by jeb
Even if the point of penpen is the real cause, the finding is quite interessant, but for a complete other reason :D

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 :)

Re: yet another boundary in cmd (pipes)

Posted: 11 May 2015 23:46
by foxidrive
jeb wrote:So the line limit of 8191 bytes is not always fix as thought it was.


I wonder if it is 8191 per pipe? :D

Re: yet another boundary in cmd (pipes)

Posted: 12 May 2015 05:06
by 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