- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
hey there,
I ran into a problem I can´t seem to resolve on my own:
I´m creating output in a .txt file on a unix server. The file is then beeing archived (ODS PACKAGE) and sent to several people using the mail-engine.
When I open the file on unix directly, it is perfectly aligned, every record has it´s own line and the same values start in the same columns.
Opening the same file from the mail on an windows environment shows that there is a offset (7 characters, can´t find the reason for the number) which every line is offset from the next one.
Example:
Unix Output (correct):
values that are only on the first row
this is the first row 123 randomstring
this is the second row 472 anotherstring
this is the third row 555 laststringvalue
values that are only on the last row
Windows Output:
values that are only on the first row this is
the first row 123 randomstring
this is the second row 472 anothe
rstring this is the third row 555 laststring
value values that are only on the last row
It seems like there is a problem between the static first row and the first dynamic row generated from column values
The code looks something like this:
data WORK.OUT end=EOF;
file = "/bla/bla/out.txt";
if _N_ = 1 then put 'values that are only on the first row';
put STR1 $26.
STR2 $7.
STR3 $15.;
if EOF then put 'values that are only on the last row';
run;
I´d appreciate it, if someone could point me in the right direction.
Thank you.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
just a heads up:
I fixed the problem by manually inserting a CR/LF (carriage return/line feed) character ('0D0A'X) at the end of every line.
The plain file now has an empty row between every relevant row,
but the file inside the package is correctly formatted, which is what matters to me.
Explanation:
Unix uses LF or in hex '0A'x to indicate the end of a line.
Windows uses CR/LF or in hex '0D0A'x.
(Macintosh uses CR '0D'x)
It seems like windows just ignores the '0A'x.
I´m working on a cleaner solution that replaces all LF with CR/LF instead of adding a CR/LF to an existing LF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Does it do the same if you specify the position to put:
put @1 STR1 @26 STR2 @33 STR3;
Its likely to be the app you use to look at the data presenting spaces/tabs slightly differently - you get that between apps, for instance using tabs in SAS code, then opening them in Notepad really messes up alignment. The other thing I would suggest is using CSV (or maybe XML) - then it could be opened in Excel or Text quite easily.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
thanks for your suggestion, I´ll try the @ variant.
although I think the problem is, that the end-of-line value gets messed up between unix and windows.
I realized it looks like the line is filled until lrecl is reached instead of having a line for each put-statement.
changing the output format is no option, I´d never do it like I have to if I were given the choice
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
just a heads up:
I fixed the problem by manually inserting a CR/LF (carriage return/line feed) character ('0D0A'X) at the end of every line.
The plain file now has an empty row between every relevant row,
but the file inside the package is correctly formatted, which is what matters to me.
Explanation:
Unix uses LF or in hex '0A'x to indicate the end of a line.
Windows uses CR/LF or in hex '0D0A'x.
(Macintosh uses CR '0D'x)
It seems like windows just ignores the '0A'x.
I´m working on a cleaner solution that replaces all LF with CR/LF instead of adding a CR/LF to an existing LF.