[Solved] find or findstr prompt issue

[bouchta]

is there a way to suppress the find or findstr prompt in case no input is detected by those application
as this will stop any further processing and leaving you in the prompt entering helpless key strokes.

if this prompt is suppressed thus this will help to continue the batch file processing or doing anything alternatively in case of no output


HELPLESS PROMPT

Code: Select all

find "string" &rem press enter
ghj
string
string
rgujp
...
...
...
keep entering keypresses or press CTRL+C to quit

any idea

[Ed Dyreen]

'
You mean ?

Code: Select all

echo.hello |2>&1 >nul find "hello" &&echo.yes ||echo.no

[bouchta]

'
You mean ?

Code: Select all

echo.hello |2>&1 >nul find "hello" &&echo.yes ||echo.no

no you have entered input with echo.hello

the find or findstr prompt appear when no input is supplied like this

Code: Select all

test this line and you will be prompted to enter useless search string
that will do nothing to you just preventing you from continuing 
 running your batch file or doing anything alternatively in case no input is supplied

find "hello" &&echo.yes ||echo.no

please i'm stuck, this nasty prompt make it impossible
to do anything if it occurs

[dbenham]

The answer seems simple - Don't write code like that

Why would it ever occur unless you, the developer, make it happen

I'm trying to imagine a scenario where your concern is valid.

The only thing I can come up with is if you are attempting FIND or FINDSTR on a file whose name is passed in as a function or script parameter like so:

Code: Select all

findstr "search string" %1

If the end user forgets to supply the file name argument then you get your nasty scenario.

But that is easy to guard against with a simple IF statement:

Code: Select all

if "%~1" neq "" findstr "search string" %1

Or if the file name is in a variable:

Code: Select all

if defined file findstr "search string" %file%

Dave Benham

[bouchta]

I'm trying to imagine a scenario where your concern is valid

simply the input source can be unkown :
input may come through the pipe or parameters or both

Example:

Code: Select all

echo 100 200|random.cmd
or
random.cmd 100 200
or even
echo 100 200|random.cmd outvar

surely testing for parameters is easy
no problem if the parameters were not specified,your code can deal with it
unfortunately when the input comes from the pipe your code can not deal with it at all

so i really need to test for any possible coming input before proceding

example:

Code: Select all

for /f %%G In ('find /v ""') do if not "%%~G"=="" ( call :random "%%G" "%%~H") else call :random %*

sometimes it work if there is input coming from the pipe,sometimes it doesn't if input only coming as parameters or no input
which will result in this unwanted useless unecessary prompt show prompt instead not useful and not smart.

strange the find or findstr itself test freely for input anywhere and if no input then it acts to shows you this prompt
but you can not do the same thing what a luck

or is there any other method to do it,this will be very appreciated

please help

cheer

[dbenham]

simply the input source can be unkown :
input may come through the pipe or parameters or both

Example:

Code: Select all

echo 100 200|random.cmd
or
random.cmd 100 200
or even
echo 100 200|random.cmd outvar

How does this relate to to your issue
I don't see where FIND or FINDSTR fits in to these examples.

unfortunately when the input comes from the pipe your code can not deal with it at all

so i really need to test for any possible coming input before proceding

example:

Code: Select all

for /f %%G In ('find /v ""') do if not "%%~G"=="" ( call :random "%%G" "%%~H") else call :random %*

sometimes it work if there is input coming from the pipe,sometimes it doesn't if input only coming as parameters or no input which will result in this unwanted useless unecessary prompt show prompt instead not useful and not smart.

This code can never work because you do not provide FIND any input. There is no pipe
I consider your code a bug. To use FIND or FINDSTR in a batch you must either provide a file argument or else pipe in some input. You have done neither.

Here is a proper (but silly) example of piping command output into the FIND command:

Code: Select all

for /f %%G in ('echo Hello world^|find "o"') do echo %%G

You can pipe absolutely any valid command output into FIND or FINDSTR and it will never hang on a prompt. This is true even if the command has no output

For example, the SETLOCAL command has no output. This is totally useless syntax that accomplishes nothing, but it does not hang:

Code: Select all

for /f %%G in ('setlocal^|find "o"') do echo %%G

Dave Benham

[jeb]

:? How does this relate to to your issue
I don't see where FIND or FINDSTR fits in to these examples.

This code can never work because you do not provide FIND any input. There is no pipe

bouchta describe his problem good enough with his sample.
I understand that he want to detect, if the batch is started with a pipe into it ... or not.

Therefore this can be valid and works like expected
echo Hello word | myBatch

Code: Select all

@echo off
for /F "delims=" %%A in ('find "e"') do echo #%%A

But without the pipe the find try to get the input from stdin and waits until it gets an EOF (CTRL-Z).

The question is, is it possible to detect if there is a pipe active into the current batch?

I didn't know the answer.
I suppose something like this could work, but it fails.

Code: Select all

@echo off
4< dummyFile.txt 0<&4 find "e"

This works also without a pipe, but it never reads from the pipe, as I hoped.

jeb

[bouchta]

Cheeeer up

[dbenham]

I understand that he want to detect, if the batch is started with a pipe into it ... or not.

Thank you jeb The question finally makes sense to me - a perfectly reasonable question at that.

But I'm with jeb, I don't see a good solution.

Some kind of input passthrough that accepted a timeout parameter might help. The passthrough would simply read stdin and echo it out to stdout. Passthrough would run continuously until either its input stream was exhausted, or until no input was detected for a specified time period. I don't know of such a command.

The only native batch solution I can think of is to pass the command string as an argument to your batch file instead of piping the output to your batch file. You could then execute the command within your FOR loop.

Here is a crude example:
test.bat

Code: Select all

@echo off
for /f %%g in ('%*^|find "o"') do echo %%g

This works

Code: Select all

test echo hello world

Calling with no arguments generates an error but doesn't hang:

Code: Select all

test

The code needs a lot of improvement though, since it doesn't properly escape characters that might be present in complex command strings. Of course you could eliminate the error message if no command line was given as well.

Dave Benham

[allal]

bouchta
if you are like jeb or dbenham who tries always to find solution native cmdly,then be prepared for a long journey where you will start
travelling to world forums till you have a looooooooooong white beard and walking on wooden stick,nice rides fill all over your face
following the misleader heart which sticks to what it loves and prevents from satisfying the god
that final day surprised by the angel of death dismantling your soul
no chance left but to be ignored,forgotten likewise


sorry the find or the findstr can not always help you because they are just buggy and disappointing
this faulty findstr which will not even succeed in doing its own job,i had a lot of trouble using it
yes it may fail

believe it or not the findstr.exe is worse than find.exe even find.exe don't support regex
throw this shit away and use something that always work for both your issue and regex and more


i use grep as it support more feature and has excellent regex engine
it never fail in doing its job and it is better than findstr say 1000 times
and bestows me with the tranquility of mind

download it from here

http://unxutils.sourceforge.net/UnxUpdates.zip

you will find a collection of unix utilities for windows and grep included
put grep in a jewel box and findstr in the recycle bin that is how i did
or if you like the name findstr,then rename grep findstr and it should work normally because it uses the %~n0 filename parameter


i tested it and it work

Code: Select all

del /f findstr.exe
ren grep.exe findstr.exe
for /f %%G In ('findstr ".*" 2^>nul ^|^|echo nein') do if not "%%~G"=="nein" ( call :random "%%~G" "%%~H") else call :random %*

enjoy

[bouchta]

bouchta
if you are like jeb or dbenham who tries always to find solution native cmdly,then be prepared for a long journey where you will start
travelling to world forums till you have a looooooooooong white beard and walking on wooden stick,nice rides fill all over your face
following the misleader heart which sticks to what it loves and prevents from satisfying the god
that final day surprised by the angel of death dismantling your soul
no chance left but to be ignored,forgotten likewise


sorry the find or the findstr can not always help you because they are just buggy and disappointing
this faulty findstr which will not even succeed in doing its own job,i had a lot of trouble using it
yes it may fail

believe it or not the findstr.exe is worse than find.exe even find.exe don't support regex
throw this shit away and use something that always work for both your issue and regex and more


i use grep as it support more feature and has excellent regex engine
it never fail in doing its job and it is better than findstr say 1000 times
and bestows me with the tranquility of mind

download it from here

http://unxutils.sourceforge.net/UnxUpdates.zip

you will find a collection of unix utilities for windows and grep included
put grep in a jewel box and findstr in the recycle bin that is how i did
or if you like the name findstr,then rename grep findstr and it should work normally because it uses the %~n0 filename parameter


i tested it and it work

Code: Select all

del /f findstr.exe
ren grep.exe findstr.exe
for /f %%G In ('findstr ".*" 2^>nul ^|^|echo nein') do if not "%%~G"=="nein" ( call :random "%%~G" "%%~H") else call :random %*

enjoy

WOW it really do it,i never thought to find solution

works great without problem

[Sponge Belly]

Hello All!

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
(call;)
set "line1=%tmp%\line1.tmp"

if /i "!cmdcmdline!" neq "!cmdcmdline:%ComSpec%  /s /d /c=!" (
type nul >"%line1%"
start "" /b find /n /v "" | find "[1]" >>"%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"

:end
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
piped file.txt | more
cd . | piped file.txt
cd . | piped file.txt | more

Whereas this will throw an error:

Code: Select all

type file1.txt | piped file2.txt

I haven’t tested this code to destruction, but it appears to be reasonably robust. I welcome your comments and suggestions.

- SB