[Toybox] Pending fiddliness

[Rob Landley]

I've been holding off on "mv" forever, even though it's a commonly used  
command that I've got the infrastructure for (it's a simpler version of  
cp), because I haven't figured out how to get the code sharing quite  
right yet.

I want to share infrastructure between "mv" an option of "cp". The  
main() function is mostly the same, for example. And if mv is used  
across partitions, it falls back to a combination of cp and rm.

I could move cp code out into lib/ but that gets built for every  
command, and makes reading the logic of "cp" itself more convoluted. If  
only two commands are sharing it, having the logic way out of line is  
not ideal. The other way of doing this is to add an OLDTOY() macro to  
cp.c adding mv as an alias with different behavior. The problem here is  
option flags.

The option flag infrastructure defines FLAGS_X for the current command.  
That's the main reason #define FOR_mv is needed up at the top, I could  
never work out how to autoselect that from __FILE__ or similar.  
(There's no strcmp in #if tests.)

So commands that share a .c file can't have their own FLAG_ macros. I  
could do the flag math by hand (the flags run right to left to make  
that easier, the same order as the binary bits when written out, abcd  
a=8 b=4 c=2 d=1), but I've removed the need for that from the rest of  
the code and doing it here seems ugly. (And brittle if I change the  
flags and have to redo them by hand...)

Maybe I'll do them by hand for right now and try to come up with a  
cleaner way later...

Or I could be _really_ subtle and only use a subset of the flags that  
mv alreay does (POSIX only specifies -f and -i, the rest are optional),  
and keep them in the same order so the FLAG macros work out right. But  
I _really_ shouldn't name the variable that indicates we were called as  
move instead of cp TT.fezzig.

   http://www.girlgeniusonline.com/comic.php?date=20100609

(Hy iz not done mit tryink de sottle!)

Rob
 1371689475.0