| cd bug in IDL 5.5 [message #31068] |
Mon, 03 June 2002 08:29  |
Wolfgang.Dobler
Messages: 4
Registered: April 2002
|
Junior Member |
|
|
Has anybody encountered this one before:
idl> cd, '../../..'
only moves one directory up under IDL 5.5 (5.4 was OK).
The problem is that I have (and need) '../../../idl' in my !path; is there
a workaround to get this directory -- which may vary, depending on where I
currently am -- still included into !path ?
W o l f g a n g
--
------------------------------------------------------------ ----
| Wolfgang Dobler, Kiepenheuer Institute for Solar Physics |
| http://www.kis.uni-freiburg.de/~dobler/ |
------------------------------------------------------------ ----
|
|
|
|
| Re: cd bug in IDL 5.5 [message #31075 is a reply to message #31068] |
Tue, 18 June 2002 09:51  |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Ben wrote:
>
>> Dear Ben,
>>
>> it could be easier to use file_which
>>
>> x=file_which('mean.pro')
>> print,x
>> /usr/local/idl/idl/lib/mean.pro
>>
>> fpe=file_path_name_ext(x)
>>
>> print,fpe.path
>> /usr/local/idl/idl/lib/
>
>
> Reimar,
> You're right, if file_which worked correctly it would be easier (and faster)
> to use. Unfortunately, in win2k it doesn't seem to work right. Here are some
> examples.
>
> If you are in the IDL working directory it works fine.
> IDL> print, file_which('copyToClipboard.exe')
> C:\BEN_HILLDORE\KVI\KVI_PROGRAMS\Support Programs\copyToClipboard.exe
>
> Now i'll move that file to 'c:\gs'
>
> IDL> print, file_which('c:\', 'copyToClipboard.exe')
> It returns a null.
>
> If I specify the path directly to it, it works.
>
> IDL> print, file_which('c:\gs', 'copyToClipboard.exe')
> c:\gs\copyToClipboard.exe
>
> This routine seems to suffer from the same problem as expand_file_path.
Dear Ben,
this is correct, but I agree it's really bad described.
I will do a feature request for using an array of pathes
without concatination by strjoin.
I have this tested on unix and I hope I have transformed this right
for windows.
path=get_dir_tree('c:\',level=10)
path='c:\'+path
path=strjoin(path,';') ; it's : on unix
print,file_which(path,'copyToClipboard.exe')
c:\gs\copyToClipboard.exe
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/dbase/download/get_dir_tree.tar.gz
hope this helps.
Reimar
>
> Ben Hilldore
> Hope College Nuclear Research Group
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-I)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml
============================================================ =======
|
|
|
|
| Re: cd bug in IDL 5.5 [message #31079 is a reply to message #31068] |
Tue, 18 June 2002 08:22 |
crono15m
Messages: 9
Registered: June 2002
|
Junior Member |
|
|
> Dear Ben,
>
> it could be easier to use file_which
>
> x=file_which('mean.pro')
> print,x
> /usr/local/idl/idl/lib/mean.pro
>
> fpe=file_path_name_ext(x)
>
> print,fpe.path
> /usr/local/idl/idl/lib/
Reimar,
You're right, if file_which worked correctly it would be easier (and faster)
to use. Unfortunately, in win2k it doesn't seem to work right. Here are some
examples.
If you are in the IDL working directory it works fine.
IDL> print, file_which('copyToClipboard.exe')
C:\BEN_HILLDORE\KVI\KVI_PROGRAMS\Support Programs\copyToClipboard.exe
Now i'll move that file to 'c:\gs'
IDL> print, file_which('c:\', 'copyToClipboard.exe')
It returns a null.
If I specify the path directly to it, it works.
IDL> print, file_which('c:\gs', 'copyToClipboard.exe')
c:\gs\copyToClipboard.exe
This routine seems to suffer from the same problem as expand_file_path.
Ben Hilldore
Hope College Nuclear Research Group
|
|
|
|
| Re: cd bug in IDL 5.5 [message #31080 is a reply to message #31068] |
Tue, 18 June 2002 08:21 |
crono15m
Messages: 9
Registered: June 2002
|
Junior Member |
|
|
> Dear Ben,
>
> it could be easier to use file_which
>
> x=file_which('mean.pro')
> print,x
> /usr/local/idl/idl/lib/mean.pro
>
> fpe=file_path_name_ext(x)
>
> print,fpe.path
> /usr/local/idl/idl/lib/
Reimar,
You're right, if file_which worked correctly it would be easier (and faster)
to use. Unfortunately, in win2k it doesn't seem to work right. Here are some
examples.
If you are in the IDL working directory it works fine.
IDL> print, file_which('copyToClipboard.exe')
C:\BEN_HILLDORE\KVI\KVI_PROGRAMS\Support Programs\copyToClipboard.exe
Now i'll move that file to 'c:\gs'
IDL> print, file_which('c:\', 'copyToClipboard.exe')
It returns a null.
If I specify the path directly to it, it works.
IDL> print, file_which('c:\gs', 'copyToClipboard.exe')
c:\gs\copyToClipboard.exe
This routine seems to suffer from the same problem as expand_file_path.
Ben Hilldore
Hope College Nuclear Research Group
|
|
|
|
| Re: cd bug in IDL 5.5 [message #31087 is a reply to message #31068] |
Tue, 18 June 2002 00:02 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Ben wrote:
>
>> another, perhaps, bug i have discovered is that the file_expand_path
>> expands from the current working directory (not very handy :x ), not the
>> actual directory where the file might be. It should issue a warning if that
>> file does not exist in the current directory, something like:
>
> I too have noticed that file_expand_path doesn't work the way you
> would hope
> it would. As a solution I wrote my own "search" program that looks for
> a file
> and returns the full path to it. It will look outside of the working
> directory. It returns an array of all paths fitting 'filename'. It's
> probably not perfect but it works.
>
> Hope this helps,
>
> Ben Hilldore
> Hope College Nuclear Research Group
>
> function getFilePath, filename
> dirs = expand_path('+c:\', /all_dirs, /array)
> filenames = strarr(n_elements(dirs))
> for i = 0,n_elements(dirs)-1 do begin
> filenames[i] = findfile(dirs[i] + '\' + filename)
> endfor
> return, filenames[where(strlen(filenames) gt 1)]
> end
Dear Ben,
it could be easier to use file_which
x=file_which('mean.pro')
print,x
/usr/local/idl/idl/lib/mean.pro
fpe=file_path_name_ext(x)
print,fpe.path
/usr/local/idl/idl/lib/
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/dbase/download/file_path_name_ext.tar.gz
For further routines and licensing please have a look at
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
regards
Reimar
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-I)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
============================================================ =======
|
|
|
|
| Re: cd bug in IDL 5.5 [message #31091 is a reply to message #31068] |
Mon, 17 June 2002 10:47 |
crono15m
Messages: 9
Registered: June 2002
|
Junior Member |
|
|
> another, perhaps, bug i have discovered is that the file_expand_path
> expands from the current working directory (not very handy :x ), not the
> actual directory where the file might be. It should issue a warning if that
> file does not exist in the current directory, something like:
I too have noticed that file_expand_path doesn't work the way you
would hope
it would. As a solution I wrote my own "search" program that looks for
a file
and returns the full path to it. It will look outside of the working
directory. It returns an array of all paths fitting 'filename'. It's
probably not perfect but it works.
Hope this helps,
Ben Hilldore
Hope College Nuclear Research Group
function getFilePath, filename
dirs = expand_path('+c:\', /all_dirs, /array)
filenames = strarr(n_elements(dirs))
for i = 0,n_elements(dirs)-1 do begin
filenames[i] = findfile(dirs[i] + '\' + filename)
endfor
return, filenames[where(strlen(filenames) gt 1)]
end
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
