[I was hoping that someone with more coreutils history was jumping in here - adding Jim for that matter.]
On 11/05/2013 01:01 AM, Gian Piero Carrubba wrote: >> On 11/04/2013 12:48 AM, Bernhard Voelker wrote: > [...] >>> BUT I'm not happy at all with the following case: >>> >>> $ : > file >>> $ ln -s file filelink >>> $ src/cp --link filelink dst--link >>> $ src/cp --link -R filelink dst--link-R >>> $ ls -ldogi file filelink dst--link dst--link-R >>> 537364 -rw-r--r-- 2 0 Nov 4 01:30 dst--link >>> 537365 lrwxrwxrwx 2 4 Nov 4 01:30 dst--link-R -> file >>> 537364 -rw-r--r-- 2 0 Nov 4 01:30 file >>> 537365 lrwxrwxrwx 2 4 Nov 4 01:30 filelink -> file >>> >>> That's exactly what Gian was worried about in a different case >>> of my solution: it *matters* whether the rather unrelated -R option >>> is specified or not. ;-( > > Exactly. But this is a problem with the implementation of '-R', and as > such I think it should be fixed there. Please see the just-opened bug > #15806 [0]. Imho, modifying it here would mean special-casing a > special-case. Add we wouldn't gain a lot in terms of consistency ( `cp` > dereferences, `cp -R` doesn't, `cp -lR` does ). > > [0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15806 Okay, so we're leaving the ground of the GNU extension --link here. cp's dereferencing vs. non-dereferencing behavior with -r seems to be a longer story, e.g. there have been several commits between Dec 2001 and Mar 2002. I don't know why and I can't tell a reason, but I have the impression that the current behavior is the best choice for almost all situations. On the other side, many scripts I've seen (including mine) are using the -a option (which is "-dR --preserve=all" with in turn -d as "--no-dereference --preserve=links") for copying whole directory tree ... that may be an indication that the default for -r alone is not that much used. Anyway, I belief that doing a change aside from this --link patch would be quite delicate. Have a nice day, Berny
