comp.lang.idl-pvwave archive: archive » point

Home » Public Forums » archive » point_lun

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

point_lun [message #19032]

Wed, 23 February 2000 00:00

R.Bauer
Messages: 1424
Registered: November 1998

Senior Member

Hi,

I have recognized today point_lun makes differences between files
written on UNIX or DOS
for following idl version.

** Structure !VERSION, 5 tags, length=40:
ARCH STRING 'x86'
OS STRING 'Win32'
OS_FAMILY STRING 'Windows'
RELEASE STRING '5.3'
BUILD_DATE STRING 'Nov 11 1999'

My very old aix machine did not make a difference if the file is
written for DOS or for UNIX.

I have attached 2 example files and the testroutine.

The result of the test for windows is:

IDL> error_pointlun,'test.dos'
88 7777 AA xa xa
pointer is: 36
value: 11111.1
new position: 66
last position: 36
value: 11111.1

IDL> error_pointlun,'test.unix'
88 7777 AA xa xa
pointer is: 31
value: 11111.1
new position: 61
% READF: Input conversion error. Unit: 102, File: test.unix
% Execution halted at: ERROR_POINTLUN 24 error_pointlun.pro
% $MAIN$

On some data files I recognized a byte shift to right.

R.Bauer

88 7777
AA xa xa
11111.11 11.99 444.11
22222.22 21.99 555.11
33333.33 331.99 666.12

88 7777
AA xa xa
11111.11 11.99 444.11
22222.22 21.99 555.11
33333.33 331.99 666.12

PRO error_pointlun,file

OPENR, IUN, file, /GET_LUN

POINT_LUN, IUN, 0

s=STRARR(2)
READF,iun,s
PRINT,s

POINT_LUN,-iun,bpos
PRINT,'pointer is:',bpos

s=FLTARR(1)
READF,iun,s
PRINT,'value:',s

POINT_LUN,-iun,npos
PRINT,'new position:',npos

s=FLTARR(1)
POINT_LUN,iun,bpos
READF,iun,s
PRINT,'last position:',bpos
PRINT,'value:',s

FREE_LUN,iun

END

Attachment: test.unix
(Size: 0.12KB, Downloaded 83 times)
Attachment: test.dos
(Size: 0.12KB, Downloaded 78 times)
Attachment: error_pointlun.pro
(Size: 0.39KB, Downloaded 83 times)

Report message to a moderator

Re: point_lun [message #19080 is a reply to message #19032]

Fri, 25 February 2000 00:00

Martin Schultz
Messages: 515
Registered: August 1997

Senior Member

Hallo Reimar!

since I was looking at a similar issue yesterday night, I came across
some
statements about this in the online help. Look for "reading
files:Windows platform"
in the help index. It basically confirms what Craig said.

If nothing else helps and you *really* need to read these ASCII files
platform-
independently, you'll probably have to resort to reading it as binary
unformatted
into your own buffer, filter all CR's (13B) in case there are any, and
break the
lines at the line feeds (10B). This still leaves out the Mac World,
where they use only CR as far as I know...

Viele Gruesse,
Martin

"R.Bauer" wrote:
>
> Hi,
>
> I have recognized today point_lun makes differences between files
> written on UNIX or DOS
> for following idl version.
>
> ** Structure !VERSION, 5 tags, length=40:
> ARCH STRING 'x86'
> OS STRING 'Win32'
> OS_FAMILY STRING 'Windows'
> RELEASE STRING '5.3'
> BUILD_DATE STRING 'Nov 11 1999'
>
> My very old aix machine did not make a difference if the file is
> written for DOS or for UNIX.
>
> I have attached 2 example files and the testroutine.
>
> The result of the test for windows is:
>
> IDL> error_pointlun,'test.dos'
> 88 7777 AA xa xa
> pointer is: 36
> value: 11111.1
> new position: 66
> last position: 36
> value: 11111.1
>
> IDL> error_pointlun,'test.unix'
> 88 7777 AA xa xa
> pointer is: 31
> value: 11111.1
> new position: 61
> % READF: Input conversion error. Unit: 102, File: test.unix
> % Execution halted at: ERROR_POINTLUN 24 error_pointlun.pro
> % $MAIN$
>
> On some data files I recognized a byte shift to right.
>
> R.Bauer
>
> ------------------------------------------------------------ ------------
> 88 7777
> AA xa xa
> 11111.11 11.99 444.11
> 22222.22 21.99 555.11
> 33333.33 331.99 666.12
>
> ------------------------------------------------------------ ------------
> 88 7777
> AA xa xa
> 11111.11 11.99 444.11
> 22222.22 21.99 555.11
> 33333.33 331.99 666.12
>
> ------------------------------------------------------------ ------------
> PRO error_pointlun,file
>
> OPENR, IUN, file, /GET_LUN
>
> POINT_LUN, IUN, 0
>
> s=STRARR(2)
> READF,iun,s
> PRINT,s
>
> POINT_LUN,-iun,bpos
> PRINT,'pointer is:',bpos
>
> s=FLTARR(1)
> READF,iun,s
> PRINT,'value:',s
>
> POINT_LUN,-iun,npos
> PRINT,'new position:',npos
>
> s=FLTARR(1)
> POINT_LUN,iun,bpos
> READF,iun,s
> PRINT,'last position:',bpos
> PRINT,'value:',s
>
> FREE_LUN,iun
>
> END

--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[

Report message to a moderator

Re: point_lun [message #19122 is a reply to message #19032]

Wed, 23 February 2000 00:00

John-David T. Smith is currently offline

John-David T. Smith
Messages: 384
Registered: January 2000

Senior Member

Craig Markwardt wrote:
>
> "R.Bauer" <R.Bauer@fz-juelich.de> writes:
>>
>> I have recognized today point_lun makes differences between files
>> written on UNIX or DOS
>> for following idl version.
>
> This almost certainly has something to do with the difference between
> end-of-line conventions in Unix and Windows worlds. I believe that
> windows/DOS uses a CR/LF while Unix simply uses an LF.
>
> I don't understand *exactly* what is going wrong though, but it seems
> that Windows may be assuming that a CR/LF pair are present in your
> Unix file when only one of them is there. What's wierd is that it's
> using that information in the POINT_LUN call. This may not be a bug
> in IDL but rather in the Windows library that IDL uses. The Microsoft
> people probably don't even consider it a bug but a feature...
>
> There are converters that can do the Unix<->DOS conversion for you,
> but unfortunately it's an extra ugly step.
>

It depends on how it was written. Even DOS C programs will happily convert each
newline in your output to a carraige return/newline pair, unless told not to
with some kind of BINARY mode. All formatted windows/dos output will reflect
this conversion, unless it is somehow disabled. Many FTP programs will do this
to, for example (unless in binary mode).

JD

--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|

Report message to a moderator

Re: point_lun [message #19124 is a reply to message #19032]

Wed, 23 February 2000 00:00

Craig Markwardt
Messages: 1869
Registered: November 1996

Senior Member

"R.Bauer" <R.Bauer@fz-juelich.de> writes:
>
> I have recognized today point_lun makes differences between files
> written on UNIX or DOS
> for following idl version.

This almost certainly has something to do with the difference between
end-of-line conventions in Unix and Windows worlds. I believe that
windows/DOS uses a CR/LF while Unix simply uses an LF.

I don't understand *exactly* what is going wrong though, but it seems
that Windows may be assuming that a CR/LF pair are present in your
Unix file when only one of them is there. What's wierd is that it's
using that information in the POINT_LUN call. This may not be a bug
in IDL but rather in the Windows library that IDL uses. The Microsoft
people probably don't even consider it a bug but a feature...

There are converters that can do the Unix<->DOS conversion for you,
but unfortunately it's an extra ugly step.

Craig

--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------

Report message to a moderator

Re: point_lun [message #19252 is a reply to message #19032]

Tue, 29 February 2000 00:00

John-David T. Smith
Messages: 384
Registered: January 2000

Senior Member

Martin Schultz wrote:
>
> Hallo Reimar!
>
> since I was looking at a similar issue yesterday night, I came across
> some
> statements about this in the online help. Look for "reading
> files:Windows platform"
> in the help index. It basically confirms what Craig said.
>
> If nothing else helps and you *really* need to read these ASCII files
> platform-
> independently, you'll probably have to resort to reading it as binary
> unformatted
> into your own buffer, filter all CR's (13B) in case there are any, and
> break the
> lines at the line feeds (10B). This still leaves out the Mac World,
> where they use only CR as far as I know...

Or, just read a line at a time, which is platform independent, and how ascii
files are normally read. To skip to the nth line:

lin=''
for i=0,n-1 do readf,un,lin

JD

--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|

Report message to a moderator

Previous Topic:	passing functions as arguments in IDL?
Next Topic:	xmanager does not block

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Wed Oct 08 19:42:38 PDT 2025

Total time taken to generate the page: 0.00693 seconds