Apologies for my late arrival to this topic. I hope it goes better than the last time I tried to revive an old thread!
Anyways, Allal makes a valid point. However, there is
a Batch solution to Bouchta’s problem. The following little program accepts a filename as argument and runs findstr /n "^" "%~1" over the file contents.
The interesting bit is that the program will die if it’s in a pipeline and
downstream of flowing data.
Code: Select all
:: -- piped.cmd
@echo off & setlocal enableextensions enabledelayedexpansion
if /i "!cmdcmdline!" neq "!cmdcmdline:%ComSpec% /s /d /c=!" (
type nul >"%line1%"
start "" /b find /n /v "" | find "" >>"%line1%"
tasklist | findstr find\.exe >nul && taskkill /f /im find.exe >nul
for %%f in ("%line1%") do (del "%line1%"
if %%~zf gtr 0 (>&2 echo(piped input not supported
(call) & goto end)))
findstr /n "^" "%~1"
endlocal & goto :EOF
:: -- end program
First, check the CmdCmdLine dynamic variable to see if the program is in a pipeline. If it is, create the temp file. Next, execute the two find commands. The first one is launched asynchronously using start. The second one doesn’t require the same treatment. Not sure why. The temp file is appended to rather than created by the second find to avoid a potential race condition. But that’s just me. I’ve no evidence to back up my suspicion.
Then taskkill forcefully terminates all instances of find. Not very subtle, I know…
Lastly, a for loop tests the size of the temp file. If it’s greater than zero, an attempt was made to pipe data into the program, and the program exits with an error message.
These commands will work:
Code: Select all
piped file.txt | more
cd . | piped file.txt
cd . | piped file.txt | more
Whereas this will throw an error:
I haven’t tested this code to destruction, but it appears to be reasonably robust. I welcome your comments and suggestions. - SB