The SAS Output Delivery System and reporting techniques

Create file on unix, open it on windows

Accepted Solution Solved
Reply
Occasional Contributor
Posts: 5
Accepted Solution

Create file on unix, open it on windows

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
Solution
‎12-12-2014 05:20 AM
Occasional Contributor
Posts: 5

Re: Create file on unix, open it on windows

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.

View solution in original post


All Replies
Super User
Super User
Posts: 7,720

Re: Create file on unix, open it on windows

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.

Occasional Contributor
Posts: 5

Re: Create file on unix, open it on windows

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 Smiley Wink

Solution
‎12-12-2014 05:20 AM
Occasional Contributor
Posts: 5

Re: Create file on unix, open it on windows

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.

🔒 This topic is solved and locked.

Need further help from the community? Please ask a new question.

Discussion stats
  • 3 replies
  • 801 views
  • 0 likes
  • 2 in conversation