comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: file_lines and expand path
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: file_lines and expand path [message #49625 is a reply to message #49624] Fri, 04 August 2006 14:48 Go to previous messageGo to previous message
James Kuyper is currently offline  James Kuyper
Messages: 425
Registered: March 2000
Senior Member
Paul van Delst wrote:
...
> Hang on a minute.... in the IDL file_lines documentation it states:
>
>
> Return Value
> ------------
> Returns the number of lines of text contained within the specified file or files. If an
> array of file names is specified via the Path parameter, the return value is an array with

Note: "If an array of file names is specified ...".

> the same number of elements as Path, with each element containing the number of lines in
> the corresponding file.
>
> Arguments
> ---------
> Path
> A scalar string or string array containing the names of the text files for which the
> number of lines is desired.
>
>
> So, the IDL version of file_lines *should* return an array when multiple files are given.
> Does this mean IDL has a bug in file_lines() with regards to how it handles wildcard
> input? The words associated with the /NOEXPAND_PATH suggest that wildcard inputs are
> allowed (although it doesn't specifically say it).

I've tested it, and an array of strings works exactly as it should. I
suspect that the possibility of a string argument containing wildcards
that allow it to match multiple files was not even considered.

Issue: if the FL version returns an array when given a string argument
with wildcards that match multiple files, how should it handle an array
of string arguments, some or all of which have that same
characteristic? Personally, I think it should return an array of line
counts with the same length as the array of path names; anything else
would make it very complicated for the the calling routine to match up
inputs and outputs. I'd recommend using a total when multiple matches
to a wildcard occur, because I can actually imagine contexts where that
would be useful. I can't see anything useful about returning the length
of a randomly member of the matching set of files.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: nearest number
Next Topic: Re: CXFORM on WinXP

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 16:51:59 PDT 2025

Total time taken to generate the page: 0.00504 seconds