Re: { mv test test; } should not fail

[Krzysztof Żelechowski]

Dnia piątek, 4 lutego 2011 o 01:10:54 Eric Blake napisał(a):
> On 02/03/2011 04:42 PM, Krzysztof Żelechowski wrote:
> > Dear all:
> > 
> > When I say { mv test test; }, I mean that the file currently named "test" 
> > should be named "test" in the future.  After { mv test test; } executes, my 
> > wish is successfully fulfilled, so why does the command fail?!
> > 
> > (This breaks scripts that rename "lib" to "%{_lib}" on openSUSE, where 
> > %{_lib} may be "lib" or "lib64", depending on context.)
> 
> Here's what POSIX requires on the matter:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
> 
> If the source_file operand and destination path name the same existing
> file, then the destination path shall not be removed, and one of the
> following shall occur:
> 
>    1.
> 
>       No change is made to source_file, no error occurs, and no
> diagnostic is issued.
>    2.
> 
>       No change is made to source_file, a diagnostic is issued to
> standard error identifying the two names, and the exit status is affected.
>    3.
> 
>       If the source_file operand and destination path name distinct
> directory entries, then the source_file operand is removed, no error
> occurs, and no diagnostic is issued.
> 
> 
> So you're asking us to change from behavior 2 to behavior 1.  Which will
> solve things for you if you used fixed coreutils, but not if you use
> some other POSIX-compliant mv.  

I know exactly which implementation of mv will be used.

> 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.

Chris