String Handling in GrADS1.9.0-rc1 win32

Stephen R McMillan smcmillan at PLANALYTICS.COM
Fri Mar 7 01:18:28 EST 2008

Arlindo, looks like the string-handling problem has been resolved. See my 
comments ("SMc: ....") below. Thanks!
Stephen Mc 

Arlindo da Silva <dasilva at ALUM.MIT.EDU> 
03/06/2008 08:47 AM
Please respond to


Re: String Handling in GrADS1.9.0-rc1 win32

2008/3/6 Stephen R McMillan <smcmillan at>:

I have been unable to figure out why the V1.9.0-rc1 win32 superpack 
appears to handle strings differently than v1.8SL11 does.  So far, I have 
encountered this problem only when reading text data files, but it is 
keeping me from applying many of my data scripts in the newer version. I 
submitted something similar before, but I'm sending another example to see 
if someone in the user community may have an "aha!" answer. I've attached 
four text files, respectively from left, (1) test script, (2) data file, 
(3) screen-dump output from v1.9, and (4) output from v1.8. Both sessions 
were done on the same pc with MS Windows XP Pro (SP2). I've also included 
text of script here for convenience.

I've a similar script you sent me before on my installation and it worked 
just fine.


Try using POSIX fiile names: d:/temp/apr06.txt. Is the file apr06.txt 
MS-DOS or Unix-style text files?
SMc: Although I tried after changing it, the file name style was not the 
issue, as it recognized, opened, and read the file just fine either way. 
The issue was how 1.9 treated the data strings within. As for the data 
file apr06.txt, it was a Windows-style plain-text (ANSI) file, the 
standard text output or "save as" option in MS Word, Excel, Notepad, 
Wordpad (okay, I prefer the plain-vanilla editors with few bells and 
whistles). I'm not aware of any ANSI-to-unix or "save as" unix options in 
these applications (I mostly use Excel VB to generate the data text 
The test19 script itself serves no useful purpose other than to illustrate 
the differences. The v1.8 output is what I expected from running it--no 
problem there. However, running the same script in v1.9 produces a 
different result. It appears to handle the variables differently than v1.8 
does, e.g., numeric versus non-numeric. Any ideas? Do we have to declare 
variables as strings, integers, etc. in v1.9?

I don't think so. I believe we are hitting same MS-DOS/Unix text file 
issue you encountered. I added some info to the wiki:
SMc: I reviewed the "dos2unix" instructions on the wiki. It didn't work at 
first because a needed file (cygpopt-0.dll) was missing in my 
grads19/win32. See attached screen-dump image file. I got the required dll 
through a link on the cygwin site and added to /win32. After doing the 
dos2unix conversion on the data file, my script ran correctly. Thanks! 
But...see my comments at the end.

I am away this week and I do not have access to Windows. I'll look into 
this issue next week. The idea is to have it all working transparently. 
SMc: Perhaps it's a minor inconvenience to add the extra steps of creating 
an additional copy and doing the dos2unix conversion. In my case, that can 
be several hundred data files at a time. My suggestion would be to have 
1.9.0-rc1 win32 handle Windows/Dos-style text files just as transparently 
and effortlessly as 1.8sl11 does now.


Arlindo da Silva
dasilva at 

The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain information that is privileged, confidential, and/or proprietary.  If you are not the intended recipient, you may not review, copy or distribute this message.  If you have received this communication in error, please notify the sender immediately by e-mail, and delete the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dos2unix error 3-6-08.png
Type: application/octet-stream
Size: 24443 bytes
Desc: not available
Url : 

More information about the gradsusr mailing list