thanks for improving you MR with tests!
actually, I did (should have done it before, sorry) some tests on windows. it's even more wicked than I could imagine
``` C:\Users\epo>erase echo.bat Could Not Find C:\Users\epo\echo.bat C:\Users\epo>echo @echo foo > echo.bat C:\Users\epo>echo.bat bar foo @rem so far so good C:\Users\epo>erase echo.bat C:\Users\epo>echo.bat bar bat bar @rem looks like if echo.bat is present as file, then it's executed, otherwise the '.' is treated @rem as separator C:\Users\epo>echo @echo foo > echo+.bat C:\Users\epo>echo+ bar bar C:\Users\epo>echo+.bat bar .bat bar @rem '+' is considered as a delimiter for keyword recognition C:\Users\epo>echo @echo foo > echo_.bat C:\Users\epo>echo_ bar bar C:\Users\epo>echo_.bat bar foo @rem while '_' isn't used as a keyword delimiter ```
so I'm afraid it'll require some more tests to distinguish between keyword delimiter ('+' above) and executable delimiter ('_' in the example above).
This looks like a nice can of worms <g>
note: in your proposal you test for `count > 0` (not to cover `.bat` as a filename), but I get this:
``` C:\Users\epo>echo @echo foo > .bat C:\Users\epo>more .bat @echo foo C:\Users\epo>.bat bar foo ```
which doesn't comply with the `count>0` case.
All tests made on Win10 only.