Re: FILE_EXPAND_PATH [message #35613 is a reply to message #35610] |
Thu, 03 July 2003 13:44  |
Mark Hadfield
Messages: 783 Registered: May 1995
|
Senior Member |
|
|
"Jonathan Joseph" <jj21@cornell.edu> wrote in message
news:3F0454DF.A3CFEDF7@cornell.edu...
>
> I have IDL 5.5 on Windows and 5.6 on Solaris. I am using the
> FILE_EXPAND_PATH function, but am not getting the behavior I would
> like on the Windows platform. It works well in all cases except if
> I pass the null string ''. On the unix version, I get back what I
> expect, which is the current working directory. On the Windows
> platform I get back garbage: a short string of meaningless
> characters.
>
> Does anyone know if this behavior is fixed in 5.6 for windows? Or
> is this function undefined for the null string?
I hope I'm not violating the beta agreement too badly by saying this, but
no, this behaviour has not changed in IDL 5.6 (beta) on Windows.
FILE_EXPAND_PATH calls on functions in the underlying OS, so it's not too
surprising that its behaviour is platform-dependent in an end case like
this. The function is probably passing an empty, null-terminated string (ie
a single NUL) to the OS's C library and returning whatever comes back. Is
NUL a valid file name on Unix? (Unix as an OS is very permissive about file
names, though Unix applications are less so. I am not convinced that this is
a sensible way of doing things, but let's not go there.)
You should report this to RSI. They may well choose to make the function's
behaviour on Windows more predictable.
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|