Hi folks,
I was just playing around with Ladislav's fix of SPLIT-PATH. I was
wondering why he converted the argument values to strings, since this
has the disadvantage that if the argument is a URL the result will
eventually get changed to a file.
Then I noticed something really weird:
>> path: file: %dir/file.ext
== %dir/file.ext
>> parse path [any [#"/" file: | skip]]
== true
>> file
== "file.ext"
>> insert path "parent/"
== %dir/file.ext
>> path
== %parent/dir/file.ext
>> head file
== "parent/dir/file.ext"
Even though we're parsing a file! , any pointer set within the parse
rule becomes a string! , and yet it's still pointing to the same
underlying data. It can't, however, be used as an index with COPY/PARSE:
>> parse path [any [#"/" file: | skip]]
== true
>> copy/part path file
** Script Error: Invalid /part count: file.ext.
** Where: copy/part path file
I never realized that you could view the same data with two different
datatypes. Is this intended? I think it would be much better to have
get-words in parse rules use the type of the data being parsed.
BTW, I agree with Andrew that this behavior of SPLIT-PATH is better
than Ladislav's fix (unless READ is also fixed to read the current
directory for %""):
>> split-path %file.ext
== [%./ "file.ext"]
>> read first split-path %file.ext
== [%USER.R %TALK.R %rebol.r %REBOL.exe ...
>> sp %file.ext ; Ladislav's version
== [% %file.ext]
>> read first sp %file.ext
** Access Error: Cannot open /C/prog/rebol/.
** Where: read first sp %file.ext
See you,
Eric
