>> 1) modify .m files to perform element-wise copy/move through a for loop:
>> quite slow, but should work; easy to implement
>> 2) do not rely on underlying cp/mv tools and implement it completely with
>> octave tools: lot of work; portable; should probably be done in C++ for
>> speed, using file_ops, file_stat and dir_entry
>> 3) include cp.exe and mv.exe in octave distribution (MSVC): I'm not really
>> in favor of that
>
> Hey you answered your own question -> 2) ....
Well, I biased the things a little bit... :-)
I'm indeed in favor of 2, because of portability. OTOH, this also means
somehow re-inventing the wheel, which some people might mot agree
upon.
> Seriously, is it that much work?
Not for only basic support. But if you want to support all "cp" features,
then it might be cumbersome. With the abstraction layer that octave
provides, you can already do a good job.
> It seems to me that it would be a good
> idea in general to removethese external dependencies when possible,
> and in that case things like pack, zip, etc should also be considered as
> candidates to have native implementations.
Actually, I already tried to implement "untar" in pure M-code, which
is possible, because octave can have native support for compressed
files (with zlib). This was quite easy indeed (at least for basic support).