Re: reading long ascii records [message #1370] |
Sat, 30 October 1993 06:40 |
wolff
Messages: 3 Registered: November 1993
|
Junior Member |
|
|
In Article <1993Oct27.203017.14297@ncar.ucar.edu>, rob@hao.ucar.edu (Rob
Montgomery) wrote:
> In article <GEOMAGIC.93Oct23123353@moe.seismo.do.usbr.gov>
geomagic@seismo.do.usbr.gov (Dan O-Connell) writes:
>> In article <2a9cdr$5p8@skates.gsfc.nasa.gov> fisher@echo.gsfc.nasa.gov (Brad
L. Fisher) writes:
>>> I am trying to read an ascii file in idl which has some 1428+ words
>>> (4 bytes/word) per record. When I do this with readf I receive an error:
>>> Input line is too long for input buffer of 2048 characters. Is there any
>>> simple way to read this file in IDL without reformatting it.
>
> It is often painless and sufficient to reformat with the Unix 'fold'
> command, which you may do in a SPAWN, if desired. (I don't know if
> you are using Unix...)
>
>> What version of IDL are you using? This ones been around a long time.
>> This has to be just about the most stupid limitation I've ever
>> encountered in IDL and PV-WAVE. I can't believe they wouldn't [have]
>> fixed it by now.
>
> I am surprised the limitation exists, considering how easy it might be
> to "fix"; however, I consider that to be one of the *most reasonable*
> limitations. In our environment there is generally no reason to create
> such files: we are not forced into using ASCII for compatibility reasons
> (e.g., can use IEEE f.p., "BYTEORDER", "SAVE [,/XDR]", etc.), thus the
> main reason to choose ASCII is to be able to use tools like text editors
> on the files, and for that use it's best to have reasonably short lines
> (i.e., optimally 79 characters or less if you want to be nice to all
> terminal emulators). Only twice have I seen cases here where people
> needed to fold their data.
>
> Environments and needs vary, of course... :-)
>
> -Rob
>
I have to disagree with your statement that there is generally no reason
to create such files. In the field, the data is often kept on
IBMs (ugggh) a
David B. Wolff
NASA/GSFC/910.1
Greenbelt, MD 20771 USA
wolff@echo.gsfc.nasa.gov
|
|
|
Re: reading long ascii records [message #1371 is a reply to message #1370] |
Sat, 30 October 1993 06:40  |
wolff
Messages: 3 Registered: November 1993
|
Junior Member |
|
|
In Article <1993Oct27.203017.14297@ncar.ucar.edu>, rob@hao.ucar.edu (Rob
Montgomery) wrote:
> In article <GEOMAGIC.93Oct23123353@moe.seismo.do.usbr.gov>
geomagic@seismo.do.usbr.gov (Dan O-Connell) writes:
>> In article <2a9cdr$5p8@skates.gsfc.nasa.gov> fisher@echo.gsfc.nasa.gov (Brad
L. Fisher) writes:
>>> I am trying to read an ascii file in idl which has some 1428+ words
>>> (4 bytes/word) per record. When I do this with readf I receive an error:
>>> Input line is too long for input buffer of 2048 characters. Is there any
>>> simple way to read this file in IDL without reformatting it.
>
> It is often painless and sufficient to reformat with the Unix 'fold'
> command, which you may do in a SPAWN, if desired. (I don't know if
> you are using Unix...)
>
>> What version of IDL are you using? This ones been around a long time.
>> This has to be just about the most stupid limitation I've ever
>> encountered in IDL and PV-WAVE. I can't believe they wouldn't [have]
>> fixed it by now.
>
> I am surprised the limitation exists, considering how easy it might be
> to "fix"; however, I consider that to be one of the *most reasonable*
> limitations. In our environment there is generally no reason to create
> such files: we are not forced into using ASCII for compatibility reasons
> (e.g., can use IEEE f.p., "BYTEORDER", "SAVE [,/XDR]", etc.), thus the
> main reason to choose ASCII is to be able to use tools like text editors
> on the files, and for that use it's best to have reasonably short lines
> (i.e., optimally 79 characters or less if you want to be nice to all
> terminal emulators). Only twice have I seen cases here where people
> needed to fold their data.
>
> Environments and needs vary, of course... :-)
>
> -Rob
>
David B. Wolff
NASA/GSFC/910.1
Greenbelt, MD 20771 USA
wolff@echo.gsfc.nasa.gov
|
|
|