Your examples seem flawed to me. The first one ...
set /p inp=Requesting user input...
doesn't work because the scope of the redirection is the batch file,
not just the first statement in the file that accepts input. This
behavior seems consistent to me. If you want subsequent statements to
accept input from the keyboard rather than the redirected StdIn, use a
new CON redirection. Again, it seems like a consistent behavior to
me.
The second problem you cite is like unto the first. The PAUSE
statement is tied to the redirected StdIn. It is again redirectable
to the keyboard like this ...
pause < con
As far as the issue with Control-C, I have often find that unreliable
in breaking a batch file and generally resort to Control-Break,
instead.
All together, I think this accomplishes what you seem to say it can't
do ...
@echo off
for /f "tokens=*" %%I in ('more') do echo.[%%I]
set /p inp=Requesting user input... < con
echo Did batch wait for user input? - yes
echo inp=[%inp%] - {changed as expected}
pause < con
echo Did batch pause? - yes
echo Make sure to pipe in a long DIR output...
echo Can you [Control]+[C] to abort the batch? - no
echo Use Control-Break instead.
echo done.
Having said that, I fully accept your 'right' to disagree. I offer
that building a batch procedure to accepted piped and redirected input
is useful, but thankfully, you are free to use it or not, as YOU see
fit.
________________________________
Tom Lavedas