carriage returns

[Jim Sheffer]

Hi everyone. I mostly sit on the sidelines and try to soak up all the great posts but I need to clear something up.

I have a file that creates a .csv file from dynamic database information. At the end of each line, I have "\r\n" (without the quotes) to produce the end of line. I use \r\n because the file is being imported into a windows machine.

When I look at the file that is created, there are no spaces between each line.
I have been doing this for almost 15 year with no problems.

In BBEdit, with "Show Invisibles" I see the end on line character (or I assume that is what it is- a "sideways" L character.
To test, I added \r\n twice and as I expectedand in the final .csv file, BBedit shows me two of these characters.

Am I missing something? The reason I ask is the new .csv files do not import into the clients system and they are telling me that there are 2 carriage returns on each line.

I have been having problems with them already so I don't have much confidence in them to begin with. However, I don't want to tell them they are full of it until I am absolutely sure :-)

So am I right to assume the "L" character is indeed a carriage return and that with only one showing at the end of each line in the file and no spaces between the lines, there can only be one carriage return for each line?


James Sheffer,

The HigherPowered Team!

sup...@higherpowered.com sa...@higherpowered.com
Web Design & Development http://www.higherpowered.com
phone: 469-256-0268
"We help businesses succeed on the web!"
-------------------------------------------

[David Kelly]

On Aug 16, 2012, at 12:17 PM, Jim Sheffer wrote:

> So am I right to assume the "L" character is indeed a carriage return and that with only one showing at the end of each line in the file and no spaces between the lines, there can only be one carriage return for each line?

Just for curiosity open Terminal.app and look at the questioned file using "hexdump -C question.csv | more"

Of course that is very un-BBeditish so go to the bottom of the File menu where it says "Hex Dump" and use either Hex Dump File or Hex Dump Front Document to do the same as the above hexdump. This should answer your question as to what is where in no uncertain terms.

--
David Kelly N4HHE, dke...@HiWAAY.net
============================================================
Whom computers would destroy, they must first drive mad.

[Patrick Woolsey]

At 12:17 -0500 08/16/2012, Jim Sheffer wrote:
[...]

>I have a file that creates a .csv file from dynamic database information.
>At the end of each line, I have "\r\n" (without the quotes) to produce the
>end of line. I use \r\n because the file is being imported into a windows
>machine.
>

Two questions if I may:

a) Are you creating the original .csv file outside of BBEdit, or within it?

b) When you open the .csv file in BBEdit, what is its line ending format?

(By default, BBEdit will display this in the status bar at the bottom
of the editing window.)

>In BBEdit, with "Show Invisibles" I see the end on line character (or I
>assume that is what it is- a "sideways" L character.

That is the visible marker for a hard line break, which _within an open
document_ is always a carriage return (CR).

>To test, I added \r\n twice and as I expectedand in the final .csv file,
>BBedit shows me two of these characters.
>
>Am I missing something? The reason I ask is the new .csv files do not
>import into the clients system and they are telling me that there are 2
>carriage returns on each line.
>

In general, I recommend using BBEdit's automatic line ending support rather
than trying to adjust this manually.

If BBEdit shows the .csv file has "Windows" line endings, the file should
open normally on your client's system (or if not, something's likely
modifying the file in transit).

If instead BBEdit shows this file has "Classic Mac" or "Unix" line endings,
please change its line ending format to "Windows", then save it, and the
resulting file should open normally on your client's machine.



Regards,

Patrick Woolsey
==
Bare Bones Software, Inc. <http://www.barebones.com>
P.O. Box 1048, Bedford, MA 01730-1048

[Patrick Woolsey]

At 15:59 -0400 08/16/2012, Patrick Woolsey wrote:
>At 12:17 -0500 08/16/2012, Jim Sheffer wrote:
>[...]
>>I have a file that creates a .csv file from dynamic database information.
>>At the end of each line, I have "\r\n" (without the quotes) to produce the
>>end of line. I use \r\n because the file is being imported into a windows
>>machine.

and I said:
>In general, I recommend using BBEdit's automatic line ending support rather
>than trying to adjust this manually.
>

[... options elided ...]


PS: If for some reason the latter doesn't work, please send a note plus a
Zipped sample file to tech support <sup...@barebones.com> so we can take a
look.

[Jim Sheffer]

Patrick & David-

thanks for the help!

On Aug 16, 2012, at 2:59 PM, Patrick Woolsey <pwoo...@barebones.com> wrote:

> At 12:17 -0500 08/16/2012, Jim Sheffer wrote:
> [...]
>> I have a file that creates a .csv file from dynamic database information.
>> At the end of each line, I have "\r\n" (without the quotes) to produce the
>> end of line. I use \r\n because the file is being imported into a windows
>> machine.
>>
>

> Two questions if I may:
>
> a) Are you creating the original .csv file outside of BBEdit, or within it?

I create the file that creates the .cvs file within BBEdit using Lasso.

>
> b) When you open the .csv file in BBEdit, what is its line ending format?

Windows - which is what I need.

>
> (By default, BBEdit will display this in the status bar at the bottom
> of the editing window.)
>

I think I've found the problem. The file was actually sent to my client, then on to the company who created the system they are using.
I checked with my client and there file is also fine (no extra carriage returns. It seems the company they sent it to opened in up in note pad lite and somehow IT is creating the extra carriage returns.

Of course they are saying it is me, so I wanted to make sure absolutely before I tell my client that the company is full of it :-)
They have been a pain for both me and my client over this and it is quite annoying!

David- - I ran the file via terminal through hexdump with no problem. Can you tell me what I'm looking for?

Thanks for all the quick help!

James Sheffer

>
>> In BBEdit, with "Show Invisibles" I see the end on line character (or I
>> assume that is what it is- a "sideways" L character.
>
> That is the visible marker for a hard line break, which _within an open
> document_ is always a carriage return (CR).
>
>
>> To test, I added \r\n twice and as I expectedand in the final .csv file,
>> BBedit shows me two of these characters.
>>
>> Am I missing something? The reason I ask is the new .csv files do not
>> import into the clients system and they are telling me that there are 2
>> carriage returns on each line.
>>
>

> In general, I recommend using BBEdit's automatic line ending support rather
> than trying to adjust this manually.
>

> If BBEdit shows the .csv file has "Windows" line endings, the file should
> open normally on your client's system (or if not, something's likely
> modifying the file in transit).
>
> If instead BBEdit shows this file has "Classic Mac" or "Unix" line endings,
> please change its line ending format to "Windows", then save it, and the
> resulting file should open normally on your client's machine.
>
>
>

> Regards,
>
> Patrick Woolsey
> ==
> Bare Bones Software, Inc. <http://www.barebones.com>
> P.O. Box 1048, Bedford, MA 01730-1048
>

> --
> --
> You received this message because you are subscribed to the
> "BBEdit Talk" discussion group on Google Groups.
> To post to this group, send email to bbe...@googlegroups.com
> To unsubscribe from this group, send email to
> bbedit+un...@googlegroups.com
> For more options, visit this group at
> <http://groups.google.com/group/bbedit?hl=en>
> If you have a feature request or would like to report a problem,
> please email "sup...@barebones.com" rather than posting to the group.
> Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>

[Patrick Woolsey]

At 16:20 -0500 08/16/2012, Jim Sheffer wrote:
[...]

>> b) When you open the .csv file in BBEdit, what is its line ending format?
>
>Windows - which is what I need.

OK; that means the generated file is almost certainly correct.

>I think I've found the problem. The file was actually sent to my client,
>then on to the company who created the system they are using.
>I checked with my client and there file is also fine (no extra carriage
>returns. It seems the company they sent it to opened in up in note pad
>lite and somehow IT is creating the extra carriage returns.
>

Wups :-)

>Of course they are saying it is me, so I wanted to make sure absolutely
>before I tell my client that the company is full of it :-)
>They have been a pain for both me and my client over this and it is quite
>annoying!
>

Sounds like you're on solid ground here but understood.

>David- - I ran the file via terminal through hexdump with no problem. Can
>you tell me what I'm looking for?
>

I can give you a quick example as well.

First, for reference, "0D" is the hex value of a carriage return (CR, ASCII
13), and "0A" is the hex value of a line feed (LF, ASCII 10).

So, a CRLF pair would be "0D 0A", while two CRs in succession would be "0D
0D", etc. (The space in between is just for readability in the hex dump
output; it's not significant.)

Say you have a file with Windows line endings which contains this text:
====
the quick red fox
jumped over the lazy brown dog

====
and here's the resulting hex dump output:
====
0000: 74 68 65 20 71 75 69 63 6B 20 72 65 64 20 66 6F the quick red fo
0010: 78 0D 0A 6A 75 6D 70 65 64 20 6F 76 65 72 20 74 x..jumped over t
0020: 68 65 20 6C 61 7A 79 20 62 72 6F 77 6E 20 64 6F he lazy brown do
0030: 67 0D 0A g..
====

You can now look and/or search* within this output for the expected line
break characters or character pairs, e.g.

0000: 74 68 65 20 71 75 69 63 6B 20 72 65 64 20 66 6F the quick red fo
0010: 78 0D 0A 6A 75 6D 70 65 64 20 6F 76 65 72 20 74 x..jumped over t
***** **
here's the CRLF pair which ends the first line of text, and

0030: 67 0D 0A g..
***** **
here's the CRLF pair which comes at the end of the file.

[* Note that because of the output formatting, the CR could appear at the
end of one report line and its following LF at the start of the next report
line.]

[David Kelly]

On Aug 16, 2012, at 4:20 PM, Jim Sheffer wrote:

> David- - I ran the file via terminal through hexdump with no problem. Can you tell me what I'm looking for?

"What Patrick said." :-)

0x0d is CR and 0x0a is LF, and hexdump knows nothing of line endings so what it dumps is exactly what is there.

The Hex Dump utility built into BBedit under the File menu is essentially the same thing as "hexdump -C" but with easier knobs to turn in a GUI. The output is a BBedit text file which is a bit easier to search and move around in than piping it into /usr/bin/more.

On PC there is a freeware utility called HxD which I make a lot of use of. It can do binary compares and jump to the point the files differ. Also useful for trimming binary files.

--
David Kelly N4HHE, dke...@HiWAAY.net

========================================================================

[François Schiettecatte]

FWIW, I use 0xed on the Mac:

http://www.suavetech.com/0xed/0xed.html

F.

[Christopher Stone]

On Aug 17, 2012, at 05:04, François Schiettecatte <fschiet...@gmail.com> wrote:
> FWIW, I use 0xed on the Mac:

______________________________________________________________________

Synalyze It! (freebie) and Synalyze It! Pro (commercial) are good options as well.

http://www.macupdate.com/app/mac/35530/synalyze-it!

--
Best Regards,
Chris

[Jim Sheffer]

Thanks again to everyone!

I took some advice and downloaded "Synalyze" to check the file in Hex format. Having been over ten years since opening a file in Hex mode (and even then not knowing what I was doing!) I was pleasantly surprised at how quickly I was able to figure out how to do a search and understand the results (Thanks to Patrick for the in-depth "mini-tutorial" on what to look for!).

As strange as it sounds (and I don't have a clue yet as to how), the file was getting "changed" when either sent via email or opened on their end. They were indeed seeing duplicate carriage returns on their end (Even in a Hex editor) where on my end they were not there! Go figure!

Again, Thanks for all the great responses and help!

James Sheffer,

The HigherPowered Team!

[David Kelly]

On Aug 17, 2012, at 1:16 PM, Jim Sheffer wrote:

> I took some advice and downloaded "Synalyze" to check the file in Hex format. Having been over ten years since opening a file in Hex mode (and even then not knowing what I was doing!) I was pleasantly surprised at how quickly I was able to figure out how to do a search and understand the results (Thanks to Patrick for the in-depth "mini-tutorial" on what to look for!).

I suspect Patrick's mini-tutorial was created using the Hex Dump utility within BBedit. Synalyze is nice but not necessary.

> As strange as it sounds (and I don't have a clue yet as to how), the file was getting "changed" when either sent via email or opened on their end. They were indeed seeing duplicate carriage returns on their end (Even in a Hex editor) where on my end they were not there! Go figure!

How are you sending the file from here to there? Email attachment? Zipped email attachment?

Most zip utilities provide means for munging line endings. If for some reason one was used which automatically did what it thought was best then perhaps it wasn't best.

If MIME types were used in email that indicated a text file originated from Mac then once again auto manglers may have been invoked. Sometimes filename extensions can invoke this behavior.

--
David Kelly N4HHE, dke...@HiWAAY.net
============================================================

[Jim Sheffer]

On Aug 17, 2012, at 1:39 PM, David Kelly <dke...@hiwaay.net> wrote:

>
> On Aug 17, 2012, at 1:16 PM, Jim Sheffer wrote:
>
>> I took some advice and downloaded "Synalyze" to check the file in Hex format. Having been over ten years since opening a file in Hex mode (and even then not knowing what I was doing!) I was pleasantly surprised at how quickly I was able to figure out how to do a search and understand the results (Thanks to Patrick for the in-depth "mini-tutorial" on what to look for!).
>
> I suspect Patrick's mini-tutorial was created using the Hex Dump utility within BBedit. Synalyze is nice but not necessary.

I'm sure you were correct but it was quicker for me to learn for searching for what I needed :-)

>
>> As strange as it sounds (and I don't have a clue yet as to how), the file was getting "changed" when either sent via email or opened on their end. They were indeed seeing duplicate carriage returns on their end (Even in a Hex editor) where on my end they were not there! Go figure!
>
> How are you sending the file from here to there? Email attachment? Zipped email attachment?

Simple attachments.

>
> Most zip utilities provide means for munging line endings. If for some reason one was used which automatically did what it thought was best then perhaps it wasn't best.

LOL! I agree - sometimes software is written to be smarter than it really is!

>
> If MIME types were used in email that indicated a text file originated from Mac then once again auto manglers may have been invoked. Sometimes filename extensions can invoke this behavior.

Interesting. The strange part is, however, that ONLY the carriage returns were affected - everything else in the attachment is fine!

Again, thanks for everyone's help!

[David Kelly]

On Aug 17, 2012, at 2:22 PM, Jim Sheffer wrote:

>> If MIME types were used in email that indicated a text file originated from Mac then once again auto manglers may have been invoked. Sometimes filename extensions can invoke this behavior.
>
> Interesting. The strange part is, however, that ONLY the carriage returns were affected - everything else in the attachment is fine!

Well, traditionally thats all that differs between Mac, Windows, and Unix text files. It suggests that whatever was doing it was deliberately doing it.

I'd suggest using zip to compress the file before you send it and see what they get. Just right-click the file in Finder and about 1/3rd down in the popup is "Compress <yourfilename>" which make a .zip copy.

[Rod Buchanan]

On Aug 17, 2012, at 2:22 PM, Jim Sheffer wrote:

> On Aug 17, 2012, at 1:39 PM, David Kelly <dke...@hiwaay.net> wrote:
>
>>
>> On Aug 17, 2012, at 1:16 PM, Jim Sheffer wrote:
>>
>>> As strange as it sounds (and I don't have a clue yet as to how), the file was getting "changed" when either sent via email or opened on their end. They were indeed seeing duplicate carriage returns on their end (Even in a Hex editor) where on my end they were not there! Go figure!
>>
>> How are you sending the file from here to there? Email attachment? Zipped email attachment?
> Simple attachments.

Two questions:
1. Do you use Apple Mail?

2. Do you have "Always Send Windows-Friendly Attachments" checked (Edit > Attachments > "Always Send Windows-Friendly Attachments") ?

--
Rod Buchanan