1. Re: walk_dir issue
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Nov 25, 2004
-
Last edited Nov 26, 2004
Me wrote:
> Robert Craig wrote:
>
>> Juergen Luethje wrote:
>
> <snip>
>
>>> It depends on what you actually want walk_dir() to do.
>>>
>>> a) According to the current documentation, the first parameter should be
>>> a path name. At least on DOS and Windows, something that contains a
>>> wildcard is not a valid path name.
>>> Yes, if the first parameter actually is supposed to be a path name,
>>> then I would expect that the user-defined routine would not be called
>>> at all because no such directory as "C:\\*.txt" exists, and that
>>> walk_dir() spits out an error message.
>>>
>>> b) On the other hand, if it is intended that the first parameter of
>>> walk_dir() may contain wildcards, then the documentation should be
>>> changed accordingly. And the walk_dir() function must be changed, so
>>> that -- regarding my previous example -- onyly "C:" is given to the
>>> user-defined function as the path name, rather than "C:\\*.txt",
>>> because "C:\\*.txt" is not a path name.
>>
>> I definitely intended and documented it as (a).
>>
>> The fact that walk_dir doesn't immediately crash and burn
>> when given wildcards, is just a fluke, based on the
>> fact that dir() accepts wildcards, which is also a fluke
>> (now documented). I didn't even know myself that
>> Euphoria's dir() worked with wildcards, until a user
>> pointed it out to me. By the way, dir() does
>> not work with wildcards on Linux/FreeBSD.
>>
>> To keep everyone happy, I'll add "the directory path must not
>> contain wildcards" to the docs. Sort of like "This machine
>> converts oranges into orange juice. Do not insert watermelons". 
>
>
> The main issue is not in the docs, but in the walk_dir() function itself.
> Here is the beginning (2.5 alpha -- I left out some comments):
> }}}
<eucode>
> global function walk_dir(sequence path_name, integer your_function,
> integer scan_subdirs)
> object d, abort_now
>
> -- get the full directory information
> if my_dir = DEFAULT then
> d = default_dir(path_name)
> else
> d = call_func(my_dir, {path_name})
> end if
> if atom(d) then
> return W_BAD_PATH
> end if
> </eucode>
{{{
>
> Why not add something like:
> }}}
<eucode>
> if platform() != LINUX and
> (find('*', path_name) or find('?', path_name)) then
> return W_BAD_PATH
> end if
> </eucode>
{{{
>
>
> Relying on the assumption that only proper arguments are passed to
> functions is, say "very optimistic".
> That's the reason why we also often use (built-in or user-defined) types
> for parameter checking, no?
... so the following is probably better:
type path(object x)
if atom(x)
or find('*', path_name)
or find('?', path_name) then
return 0
end if
return 1
end type
global function walk_dir(path path_name, integer your_function,
^^^^ integer scan_subdirs)
...
Besides using the new type, there's no need to change the walk_dir()
function, and there will be no speed loss at all, when "without type
check" is used.
Regards,
Juergen
--
Have you read a good program lately?
