using echo to enter text in a file and carriage return

[chr15b]

Hi, i've noticed an anomily.. if i use the following:

echo test >> test.txt
echo blah >> test.txt

results in a text file formatted as:

test
blah

however if i echo out to a file, then run an external program and then echo out they appear on the same line.. ie:

echo test >> test.txt
someexe.exe
echo blah >> test.txt

Results in:

testblah

as an example this happens when using findstr in place of someexe.exe

any ideas why and how i can work around, the only way i have so far is to add an echo. >> test.txt in between, but this isnt always what i want.

Thanks

[jeb]

Hi chr15,

I can not reproduce your results, and I can't believe that this can even occour.
The first line
echo test >> test.txt
Will append the line "test" with an carriage return.

So the next command can't remove this from file.

I suppose you made a mistake in your test case.

jeb

[chr15b]

i've found a few instances of it so far.

three programs i'm using, findstr, ftps.exe (from moveit) and sleep.exe

as an example,

starting ftp >> output.log
ftp 192.168.1.1 -u:user -p:pass
ending ftp >> output.log

always gives me the resule

starting ftp ending ftp

the same happens with findstr

echo checking log for sample data >> output.log
findstr /m test sample.log
if %errorlevel%==0 (
ECHO success >> output.log
) else (
echo fail >> output.log
)

this will result in:
checking log for sample data success
or
checking log for sample data fail

depending on the result.

could be my mistake, but i struggle to see how i've messed that up.

[dbenham]

I can't reproduce your results either. I agree with jeb, it doesn't make sense, or seem possible.

I tested your FINDSTR example on Vista.

You can get concatenated lines if you capture the output of FINDSTR when the last line is not terminated with <CR><LF> (EOL). But that is because FINDSTR simply prints out the binary image of the matching line. If the line does not contain EOL then neither will the FINDSTR output.


Dave Benham

[chr15b]

Hi, thanks for this. I think i'm getting to what the problem is.

if i do the commands above in a batch file and view the txt file in notepad its formatted correctly.

However i'm using the text file with a program called bmail.exe - it takes the content of the file as the body of an email. upon sending the email the text wraps rather than on a new line. it only does this with text redirected to the file after an executable. its a bit wierd and i dont think i'm going to find a way round it other thn echo a blank line.

Thanks anyway

[chr15b]

This is still driving me up the wall!! but i've found a difference using a hex editor.

Sample text from the file during normal echo

4A 61 6E 20 31 30 20 30 36 3A 33 32 3A 33 37 20 Jan 10 06:32:37
32 30 30 30 0D 0A 43 6F 6E 6E 65 63 74 65 64 20 2000..Connected


Sample text from the file after using findstr

63 74 20 72 65 63 6F 72 64 3A 20 50 61 73 73 65 ct record: Passe
64 20 0D 0A 4C 4F 47 20 41 4E 41 4C 59 53 49 53 d ..LOG ANALYSIS

Text sent to a file during normal "Echo" has ".." or "0D 0A" (CR/LF)

Text sent directly after using findstr has " .." or "20 0D 0A" (space CR/LF)

In Notepad, the display is as you'd expect, new line for each 'echo' but in outlook you see all the text as one line

Echo. breaks the cycle, however this adds a blank line which looks messy.

Any ideas how to stop this?

Cheers
Chris

[Liviu]

Text sent to a file during normal "Echo" has ".." or "0D 0A" (CR/LF)

Text sent directly after using findstr has " .." or "20 0D 0A" (space CR/LF)

Can't relate this to your previous code directly. But in case it matters, note that the 'echo' line carries everything up to the '>>' redirection part, including any trailing spaces.

echo Passed>>output.log
echo Passed >>output.log

In other words, the second 'echo' above will save a <space>-CR-LF at the end, while the first one will have no extra space.

Liviu

[chr15b]

After much trawling the net before and after my previous post i happened upon a forum that suggested putting spaces in front of the data would break this habit..

findstr somethig....
Echo test >> myfile.txt
Echo test >> myfile.txt

results is:

test
test

Which is better than

test test

[chr15b]

Text sent to a file during normal "Echo" has ".." or "0D 0A" (CR/LF)

Text sent directly after using findstr has " .." or "20 0D 0A" (space CR/LF)

Can't relate this to your previous code directly. But in case it matters, note that the 'echo' line carries everything up to the '>>' redirection part, including any trailing spaces.

echo Passed>>output.log
echo Passed >>output.log

In other words, the second 'echo' above will save a <space>-CR-LF at the end, while the first one will have no extra space.

Liviu

Thanks, tried doing echo test>>myfile.txt without success.

To put it into context.
----

If i use the following it results in a text file and email of:

@echo off
text exists>>myfile.txt
checks complete>>myfile.txt


Text file when viewed in notepad:

text exists
checks complete

When emailed it views as:
text exists
checks complete

---------
findstr /C:"something" somefile.log
if %errorlevel%==0 (
Echo text exists>>myfile.txt
) else (
Echo text does not exist>>myfile.txt
)
echo checks complete>>myfile.txt

Text file when viewed in notepad:

text exists
checks complete

when the same file is emailed it reads as:

text exists checks complete

--------------

The only difference i can find is when viewed using a hex editor, the standard echos have 0D 0A (cr/lf) the ones after using findstr have 20 0D 0A (space cr/lf)

it gets worse, but an 'echo.' breaks the cycle - for example:
-----------
findstr /C:"something" somefile.log
if %errorlevel%==0 (
Echo text exists>>myfile.txt
) else (
Echo text does not exist>>myfile.txt
)
echo checked for something>>myfile.txt
echo in file somefile.log>>myfile.txt
echo.>>myfile.txt
echo checks complete>>myfile.txt
echo file complete>>myfile.txt

would read in notepad as:

text exists
checked for something
in file somefile.log

checks complete
file complete

however when the text file is emailed outlook would display it as:

text exists checked for something in file somefile.log

checks complete
file complete

[Liviu]

Sorry, but I don't see it happening here.

---------
findstr /C:"something" somefile.log
if %errorlevel%==0 (
Echo text exists>>myfile.txt
) else (
Echo text does not exist>>myfile.txt
)
echo checks complete>>myfile.txt

Text file when viewed in notepad:

text exists
checks complete

when the same file is emailed it reads as:

text exists checks complete
--------------

The only difference i can find is when viewed using a hex editor, the standard echos have 0D 0A (cr/lf) the ones after using findstr have 20 0D 0A (space cr/lf)

I ran your code as quoted above (with a somefile.log which did contain 'something'). Then I replaced the 'findstr' line with 'verify >nul' (just to make sure the errorlevel is 0). The two saved files (myfile.txt) are bit-identical, and neither has any spaces before CR-LF. So, I am not sure what's going on, but I can't really help since I am not able to duplicate it.

Liviu

[foxidrive]

It would seem to be a problem when processing text in his email utility.


@OP Have you tried using BLAT?

[Liviu]

It would seem to be a problem when processing text in his email utility.

Right. Looks to me like some "clever" attempt on the part of the email utility to un-wrap lines based on a (rather arbitrary) rule of if-previous-line-ends-with-a-space-then-consider-this-line-a-continuation. Besides your suggestion to try a different utility, it's also possible that the one he uses may have some option/switch to turn off the "clever" behavior.

That said, and back to batch matters, the OP insisted in his previous post that simply running findstr causes subsequent echoed lines to append a trailing space. He gave a code snippet which I copied and ran here, but failed to duplicate his results. Quoting from Jeb's first reply to the OP "I suppose you made a mistake in your test case".

Liviu

[alan_b]

Started off as an unidentified wild goose chase.

Finished up with a turkey called bmail.exe

[chr15b]

blat has the same end scenario.

the issue i believe is outlook and something called 'extra line breaks'

doubtful i'll ever get to the bottom of the issue, but i stick by what i posted yesterday. I have a text file thats been ouput, it contains about 40 lines. the first 30 format 100% correct in the eventual email, the point where it 'goes wrong' is when text is echo'd to the file within () and continues until an echo. is sent to the file.
it may be a red herring, but the first 30 lines up to this point have no trailing space, the lines echo'd within the () have a trailing space before the crlf - outlook for some reason reads these as 'extra' line breaks and ignores them, resulting in that part of the email appearing as one line.

thanks to those who assisted me in getting to the root cause, sometimes its not always obvious where the problem lies. I'm going to live with the workaround of adding extra leading spaces.

[Squashman]

What would this have to do with Outlook when you were using Bmail and Blat?