This has always been a philosophical minefield. Unless you want to
convene a huge (and mortally contentious) Standards Committee to
resolve exactly what it means to "move" a file in all possible
filesystems, the only defensible solution is to make the function a
wrapper that simply punts the issue down to the underlying OS.
This was one of the major issues I had to deal with when writing the
CP/CMS-to-AIX Rexx program abstraction layer. None of the filesystem
operations worked exactly the same, or returned the same set of
errors. I remember COPYFILE being especially difficult to implement
in AIX.
IMHO, shell commands should be issued only as ADDRESSed commands. To
establish Rexx surrogates for them is just asking for trouble. I'd
deprecate whatever legacy behavior the functions have now and leave it
to the programmer to decide if, e.g., '-noclobber' is an option or the
default.
-Chip-
On 2/12/2019 7:47 AM, Rick McGuire wrote:
Starting to run my new unit tests on Linux and I've hit an interesting
difference between Windows and Linux. On Windows, the SysFileMove()
function fails if the target file exists, but on Linux, the rename()
function appears to work on the rename, which was unexpected. The docs
for the rename() function aren't really clear about that situation. Is
that expected?
Interestingly, the old rexxutil code had a test for the new and the
old files resolving to the same target, which the rename() docs
explicitly allow. So we have one situation where an error is expected
and another where an error is returned that would be allowed by the
system. Does anybody have thoughts on how this should work?
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
