hello,

findstr output has a problem when the search word happens to be on a last
line of the preceding file. The output will be garbled with the succeeding
file searched.
e.g here shows a sample command line session showing the problem with
file1.txt and file2.txt :

c:\ > type file1.txt
test
findstr
c:\ > type file2.txt
test
findstr
c:\ > findstr "findstr" file1.txt file2.txt
file1.txt:findstrfile2.txt:findstr


The desired output is :
file1.txt:findstr
file2.txt:findstr


The last line should not have a newline for file1.txt. Try using notepad and
make sure the last line does not have a newline. I also noticed that "edit"
also seems to insert a newline for the last line(but not notepad).

I also tested grep(a sort of findstr equivalent) and it does not have a this
problem when given the same file1.txt and file2.txt.

Will this problem be fixed? It could cause some subtle problems in scripts
when pipes are used.
This problem exists on Windows 2000 and Windows XP.

regards,
Cliff

I can confirm the behavior and would too consider it a bug. The
following syntax (when executed from within a script) will create
similar output to the native findstr command if that's what you really
need -

for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr" %%l&echo/

.... it is, however, less efficient on large numbers of files that
findstr alone. If this is not precisely what you're after, please post
back with an expanded definition of your goal.

Note, the FIND.EXE command does not exhibit this behavior but uses a
different output format.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

cliff wrote:
> hello,
>
> findstr output has a problem when the search word happens to be on a
> last line of the preceding file. The output will be garbled with the
> succeeding file searched.
> e.g here shows a sample command line session showing the problem with
> file1.txt and file2.txt :
>
> c:\ > type file1.txt
> test
> findstr
> c:\ > type file2.txt
> test
> findstr
> c:\ > findstr "findstr" file1.txt file2.txt
> file1.txt:findstrfile2.txt:findstr
>
>
> The desired output is :
> file1.txt:findstr
> file2.txt:findstr
>
>
> The last line should not have a newline for file1.txt. Try using
> notepad and make sure the last line does not have a newline. I also
> noticed that "edit" also seems to insert a newline for the last
> line(but not notepad).
> I also tested grep(a sort of findstr equivalent) and it does not have
> a this problem when given the same file1.txt and file2.txt.
>
> Will this problem be fixed? It could cause some subtle problems in
> scripts when pipes are used.
> This problem exists on Windows 2000 and Windows XP.
>
> regards,
> Cliff

hello,

My goal is to hope the problem will be fixed in the next release of findstr
so that it will be a better cmd environment.

regards,
Cliff

"Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
news:%23$TMrmttFHA.2912@TK2MSFTNGP09.phx.gbl...
>I can confirm the behavior and would too consider it a bug. The following
>syntax (when executed from within a script) will create similar output to
>the native findstr command if that's what you really need -
>
> for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr" %%l&echo/
>
> ... it is, however, less efficient on large numbers of files that findstr
> alone. If this is not precisely what you're after, please post back with
> an expanded definition of your goal.
>
> Note, the FIND.EXE command does not exhibit this behavior but uses a
> different output format.
>
> --
> Dean Wells [MVP / Directory Services]
> MSEtechnology
> [[ Please respond to the Newsgroup only regarding posts ]]
> R e m o v e t h e m a s k t o s e n d e m a i l
>
> cliff wrote:
>> hello,
>>
>> findstr output has a problem when the search word happens to be on a
>> last line of the preceding file. The output will be garbled with the
>> succeeding file searched.
>> e.g here shows a sample command line session showing the problem with
>> file1.txt and file2.txt :
>>
>> c:\ > type file1.txt
>> test
>> findstr
>> c:\ > type file2.txt
>> test
>> findstr
>> c:\ > findstr "findstr" file1.txt file2.txt
>> file1.txt:findstrfile2.txt:findstr
>>
>>
>> The desired output is :
>> file1.txt:findstr
>> file2.txt:findstr
>>
>>
>> The last line should not have a newline for file1.txt. Try using
>> notepad and make sure the last line does not have a newline. I also
>> noticed that "edit" also seems to insert a newline for the last
>> line(but not notepad).
>> I also tested grep(a sort of findstr equivalent) and it does not have
>> a this problem when given the same file1.txt and file2.txt.
>>
>> Will this problem be fixed? It could cause some subtle problems in
>> scripts when pipes are used.
>> This problem exists on Windows 2000 and Windows XP.
>>
>> regards,
>> Cliff
>
>

Microsoft may or may not fix that particular behavior, they are,
however, developing an entirely new command shell codenamed Monad
(AFAIK, its release date isn't yet certain).

I don't understand your response, surely you had a goal when using
FINDSTR in the manner you posted outside of finding fault with
Microsoft's CLI utilities? My comment was intended to try and find out
what that goal was to see if a workaround or an alternative approach
would be a better fit.

--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l

cliff wrote:
> hello,
>
> My goal is to hope the problem will be fixed in the next release of
> findstr so that it will be a better cmd environment.
>
> regards,
> Cliff
>
> "Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
> news:%23$TMrmttFHA.2912@TK2MSFTNGP09.phx.gbl...
>> I can confirm the behavior and would too consider it a bug. The
>> following syntax (when executed from within a script) will create
>> similar output to the native findstr command if that's what you
>> really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr
>> "findstr" %%l&echo/
>>
>> ... it is, however, less efficient on large numbers of files that
>> findstr alone. If this is not precisely what you're after, please
>> post back with an expanded definition of your goal.
>>
>> Note, the FIND.EXE command does not exhibit this behavior but uses a
>> different output format.
>>
>> --
>> Dean Wells [MVP / Directory Services]
>> MSEtechnology
>> [[ Please respond to the Newsgroup only regarding posts ]]
>> R e m o v e t h e m a s k t o s e n d e m a i l
>>
>> cliff wrote:
>>> hello,
>>>
>>> findstr output has a problem when the search word happens to be on a
>>> last line of the preceding file. The output will be garbled with the
>>> succeeding file searched.
>>> e.g here shows a sample command line session showing the problem
>>> with file1.txt and file2.txt :
>>>
>>> c:\ > type file1.txt
>>> test
>>> findstr
>>> c:\ > type file2.txt
>>> test
>>> findstr
>>> c:\ > findstr "findstr" file1.txt file2.txt
>>> file1.txt:findstrfile2.txt:findstr
>>>
>>>
>>> The desired output is :
>>> file1.txt:findstr
>>> file2.txt:findstr
>>>
>>>
>>> The last line should not have a newline for file1.txt. Try using
>>> notepad and make sure the last line does not have a newline. I also
>>> noticed that "edit" also seems to insert a newline for the last
>>> line(but not notepad).
>>> I also tested grep(a sort of findstr equivalent) and it does not
>>> have a this problem when given the same file1.txt and file2.txt.
>>>
>>> Will this problem be fixed? It could cause some subtle problems in
>>> scripts when pipes are used.
>>> This problem exists on Windows 2000 and Windows XP.
>>>
>>> regards,
>>> Cliff

hello,

Yes, I was actually using findstr to search some .js files for a function
and stumbled onto this problem. I was surprised to see the garbled output
and later determined that it was because I had placed the function call on
the last lines of some .js files. Actually I also wanted to pipe the output
from findstr to another findstr but saw I could not do that due to the fact
the output from the first findstr was garbled and it would have produced
incorrect results. Hence I thought Microsoft had better do something with
this and hence this posting.

I do not need any immediate solutions as I could easy use other solutons but
I just wanted the cmd environment to be more robust and friendly without
having to install more outside software and also the possible problems
others may also face unknowingly.

Thanks for the response. I hope Microsoft will do something for the sake of
correctness.
regards,
Cliff

"Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
news:erSJM0ttFHA.1284@tk2msftngp13.phx.gbl...
> Microsoft may or may not fix that particular behavior, they are, however,
> developing an entirely new command shell codenamed Monad (AFAIK, its
> release date isn't yet certain).
>
> I don't understand your response, surely you had a goal when using FINDSTR
> in the manner you posted outside of finding fault with Microsoft's CLI
> utilities? My comment was intended to try and find out what that goal was
> to see if a workaround or an alternative approach would be a better fit.
>
> --
> Dean Wells [MVP / Directory Services]
> MSEtechnology
> [[ Please respond to the Newsgroup only regarding posts ]]
> R e m o v e t h e m a s k t o s e n d e m a i l
>
> cliff wrote:
>> hello,
>>
>> My goal is to hope the problem will be fixed in the next release of
>> findstr so that it will be a better cmd environment.
>>
>> regards,
>> Cliff
>>
>> "Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
>> news:%23$TMrmttFHA.2912@TK2MSFTNGP09.phx.gbl...
>>> I can confirm the behavior and would too consider it a bug. The
>>> following syntax (when executed from within a script) will create
>>> similar output to the native findstr command if that's what you
>>> really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr "findstr"
>>> %%l&echo/
>>>
>>> ... it is, however, less efficient on large numbers of files that
>>> findstr alone. If this is not precisely what you're after, please
>>> post back with an expanded definition of your goal.
>>>
>>> Note, the FIND.EXE command does not exhibit this behavior but uses a
>>> different output format.
>>>
>>> --
>>> Dean Wells [MVP / Directory Services]
>>> MSEtechnology
>>> [[ Please respond to the Newsgroup only regarding posts ]]
>>> R e m o v e t h e m a s k t o s e n d e m a i l
>>>
>>> cliff wrote:
>>>> hello,
>>>>
>>>> findstr output has a problem when the search word happens to be on a
>>>> last line of the preceding file. The output will be garbled with the
>>>> succeeding file searched.
>>>> e.g here shows a sample command line session showing the problem
>>>> with file1.txt and file2.txt :
>>>>
>>>> c:\ > type file1.txt
>>>> test
>>>> findstr
>>>> c:\ > type file2.txt
>>>> test
>>>> findstr
>>>> c:\ > findstr "findstr" file1.txt file2.txt
>>>> file1.txt:findstrfile2.txt:findstr
>>>>
>>>>
>>>> The desired output is :
>>>> file1.txt:findstr
>>>> file2.txt:findstr
>>>>
>>>>
>>>> The last line should not have a newline for file1.txt. Try using
>>>> notepad and make sure the last line does not have a newline. I also
>>>> noticed that "edit" also seems to insert a newline for the last
>>>> line(but not notepad).
>>>> I also tested grep(a sort of findstr equivalent) and it does not
>>>> have a this problem when given the same file1.txt and file2.txt.
>>>>
>>>> Will this problem be fixed? It could cause some subtle problems in
>>>> scripts when pipes are used.
>>>> This problem exists on Windows 2000 and Windows XP.
>>>>
>>>> regards,
>>>> Cliff
>
>

"cliff" <null> wrote in message
news:e6AEwButFHA.3896@TK2MSFTNGP15.phx.gbl...
> hello,
>
> Yes, I was actually using findstr to search some .js files for a function
> and stumbled onto this problem. I was surprised to see the garbled output
> and later determined that it was because I had placed the function call on
> the last lines of some .js files. Actually I also wanted to pipe the
> output from findstr to another findstr but saw I could not do that due to
> the fact the output from the first findstr was garbled and it would have
> produced incorrect results. Hence I thought Microsoft had better do
> something with this and hence this posting.
>
> I do not need any immediate solutions as I could easy use other solutons
> but I just wanted the cmd environment to be more robust and friendly
> without having to install more outside software and also the possible
> problems others may also face unknowingly.
>
> Thanks for the response. I hope Microsoft will do something for the sake
> of correctness.

IMHO, there are a number of annoying little behaviours that we have found
workarounds for over the years, my favourite being the failure of [dim
arrayname(10)] and [const constname="constvalue"] in VBScript classes to
either work or throw a compile-time error.

You must realize, hoever, that, for the most part, the number of Microsoft
customers actually affected by these little aberations is quite small. And
further, people working with those technologies are typically those most
able to find workarounds.

Microsoft will probably not fix a problem mentioned in passing in their
public newsgroups -- unless they see a compelling reason to do so. They
certainly have not for some of the other annoyances that have seen even more
complaints in newsgroups.

/Al

> regards,
> Cliff
>
> "Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
> news:erSJM0ttFHA.1284@tk2msftngp13.phx.gbl...
>> Microsoft may or may not fix that particular behavior, they are, however,
>> developing an entirely new command shell codenamed Monad (AFAIK, its
>> release date isn't yet certain).
>>
>> I don't understand your response, surely you had a goal when using
>> FINDSTR in the manner you posted outside of finding fault with
>> Microsoft's CLI utilities? My comment was intended to try and find out
>> what that goal was to see if a workaround or an alternative approach
>> would be a better fit.
>>
>> --
>> Dean Wells [MVP / Directory Services]
>> MSEtechnology
>> [[ Please respond to the Newsgroup only regarding posts ]]
>> R e m o v e t h e m a s k t o s e n d e m a i l
>>
>> cliff wrote:
>>> hello,
>>>
>>> My goal is to hope the problem will be fixed in the next release of
>>> findstr so that it will be a better cmd environment.
>>>
>>> regards,
>>> Cliff
>>>
>>> "Dean Wells [MVP]" <dwells@mask.msetechnology.com> wrote in message
>>> news:%23$TMrmttFHA.2912@TK2MSFTNGP09.phx.gbl...
>>>> I can confirm the behavior and would too consider it a bug. The
>>>> following syntax (when executed from within a script) will create
>>>> similar output to the native findstr command if that's what you
>>>> really need - for %%l in (f1 f2) do @set /p =%%l:<nul&findstr
>>>> "findstr" %%l&echo/
>>>>
>>>> ... it is, however, less efficient on large numbers of files that
>>>> findstr alone. If this is not precisely what you're after, please
>>>> post back with an expanded definition of your goal.
>>>>
>>>> Note, the FIND.EXE command does not exhibit this behavior but uses a
>>>> different output format.
>>>>
>>>> --
>>>> Dean Wells [MVP / Directory Services]
>>>> MSEtechnology
>>>> [[ Please respond to the Newsgroup only regarding posts ]]
>>>> R e m o v e t h e m a s k t o s e n d e m a i l
>>>>
>>>> cliff wrote:
>>>>> hello,
>>>>>
>>>>> findstr output has a problem when the search word happens to be on a
>>>>> last line of the preceding file. The output will be garbled with the
>>>>> succeeding file searched.
>>>>> e.g here shows a sample command line session showing the problem
>>>>> with file1.txt and file2.txt :
>>>>>
>>>>> c:\ > type file1.txt
>>>>> test
>>>>> findstr
>>>>> c:\ > type file2.txt
>>>>> test
>>>>> findstr
>>>>> c:\ > findstr "findstr" file1.txt file2.txt
>>>>> file1.txt:findstrfile2.txt:findstr
>>>>>
>>>>>
>>>>> The desired output is :
>>>>> file1.txt:findstr
>>>>> file2.txt:findstr
>>>>>
>>>>>
>>>>> The last line should not have a newline for file1.txt. Try using
>>>>> notepad and make sure the last line does not have a newline. I also
>>>>> noticed that "edit" also seems to insert a newline for the last
>>>>> line(but not notepad).
>>>>> I also tested grep(a sort of findstr equivalent) and it does not
>>>>> have a this problem when given the same file1.txt and file2.txt.
>>>>>
>>>>> Will this problem be fixed? It could cause some subtle problems in
>>>>> scripts when pipes are used.
>>>>> This problem exists on Windows 2000 and Windows XP.
>>>>>
>>>>> regards,
>>>>> Cliff
>>
>>
>
>

Dean Wells [MVP] wrote:
About: findstr "findstr" file1.txt file2.txt

> I can confirm the behavior and would too consider it a bug. The

I, too, can confirm the outcome. However, I would rather consider it
naturally expected behavior. But, if and when it is a problem:

@echo off & setlocal enableextensions
type file1.txt > file1.tmp
echo.>>file1.tmp
findstr "findstr" file1.tmp file2.txt
del file1.tmp
endlocal & goto :EOF

C:\_M>cmdfaq
file1.tmp:findstr
file2.txt:findstr

All the best, Timo

--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:ts@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip