Dnia piątek, 4 lutego 2011 o 17:24:55 Eric Blake napisał(a): > On 02/04/2011 09:07 AM, Krzysztof Żelechowski wrote: > > I know exactly which implementation of mv will be used. > > Not necessarily. The point of open source is that someone can copy your > scripts into their setup, which might be different than yours.
I do not care, the script is distribution-specific anyway. > > > > >> Since POSIX already says you have to be > >> prepared for failure, the best you can do is to instead rewrite your > >> openSUSE scripts to not fail in the first place by doing a preparatory > >> check, and rewriting 'mv lib %{_lib}' into 'test %{_lib} != lib && mv > >> lib %{_lib}', so that you will work regardless of whether coreutils > >> changes behavior, or even whether you are using coreutils' mv. > >> > > > > I actually used code like > > [[ -d '%{_lib}' ]] || … > > but it is not 100% proof because it creates a race condition. > > Several things to think about: > 1. Is that race condition ever likely to be lost? That is, if someone > is simultaneously messing with /usr/lib (or /usr/lib64) while your > package is trying to install there, that system already has much more > serious problems. Not in this case, but I heard voices when I wrote it :-) > 2. That code snippet is bash-specific. It is not a configure script, it is a platform-specific installer script. > 3. What's wrong with textual comparison (as I suggested), which avoids > the race between probing the system and actually trying to perform a rename? Admitted, text is probably safer and I would use it if I seriously feared a race. To remember. > > At any rate, I don't see any reason for coreutils to change its > behavior; although I might be persuaded otherwise if someone writes up a > patch (including testsuite and documentation), Whereas I hoped to be persuaded that failing makes sense and is *not* counter-intuitive. Of course, changing something just because is harder than doing it right from the onset (example: Polish orthography). > and in particular, you > MUST ensure that coreutils does NOT regress on: > > ln a b > mv a b > > which uses behavior 3 permitted by POSIX (silently unlink a, reducing > the hard link count of b by 1). > > I have observed that in the case { mv a a; } mv does not call rename at all, as if trying to be smarter than the operating system. I am curious why it was implemented like this. Thanks, Chris