Cactus: suppress interaction when using mv in make files

Issue #2154 closed
Roland Haas created an issue

POSIX requires (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html) that mv "hall write a prompt to standard error and read a line from standard input. If the response is not affirmative, mv shall do nothing more with the current source_file and go on to any remaining source_files." which is annoying if the operation is something like "mv foo.tmp foo".

Worse, some centers make "mv" behave as "mv -i" ie it asks about every single overwrite unless -f is also given.

Pull request is: https://bitbucket.org/cactuscode/cactus/pull-requests/48/cactus-suppress-interaction-when-using-mv/diff

Keyword: None

Comments (9)

  1. Erik Schnetter
    • removed comment

    POSIX does not requires this in general: This is only the case if either the "-i" option is given, or if the destination is not writable by the user.

    If a computing centre changes "mv" to "mv -i", then this is usually done via a shell alias. Those do not apply in a shell script.

    Is there a particular case where this is a problem? Almost every configure script uses "mv"; if "mv" was somehow broken, then most software would cease to function.

  2. Roland Haas reporter
    • removed comment

    I agree that in general this should not be an issue and also that in general this type of thing is done via an alias and does (or at least should) not affect the build system. I admit to being confused why this happens and had listed four things for the person to check:

    1. there is a non-standard version of mv on your system
    2. there is an alias for mv that (for some reason) bash is using
    3. you changed user accounts or similar so that the file /home/xu/Cactus/configs/sim/lib/LINKLIST.tmp has funny permissions / ownership
    4. there is a function mv() declared (same as alias)

    to be tested via:

    1. "which mv" and "mv --version" and let me know the result
    2. try "alias mv" and if that actually returns something please do "unalias mv" and compile again
    3. do ls -l ~/Cactus/configs/sim/lib/LINKLIST.tmp and ls -l ~/Cactus/configs/sim/lib/LINKLIST.tmp to check on the permissions
    4. check what "declare -f mv | grep mv" output and if there is a "mv ()" in the output please do "unset -f mv" to get rid of it then recompile

    and it seems as if:

    1.mv (GNU coreutils) 8.28 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. 2.nothing returned 3.The permission is -rw-r--r-- 4.The function exits.

    This was reported in private email to me. So there seems to be no alias and mv itself is "(GNU coreutils) 8.28". There may be a mv bash function though that is not quite clear to me from the email. The question shown by mv is:

    mv /home/xu/Cactus/configs/sim/lib/LINKLIST.tmp /home/xu/Cactus/configs/sim/lib/LINKLIST
    mv: replace '/home/xu/Cactus/configs/sim/lib/LINKLIST', overriding mode 0644 (rw-r--r--)?
    

    which is not a message that my mv (same coreutils version) would show (even with "-i").

    So one would have to ask which center / Linux distribution the person is using.

    Do you object to the patch on the basis that it does something wrong (or adds complexity and only fixes part of the issue) or are curious why this is happening? As far s I can tell, using "mv -f" is supported by POSIX and while it should never really be required, it also should never do harm.

    Addendum: I do get that message if the target file is owned by a different user than mine. I will ask to check once more for funny ownership (though the error about mv has already gone away so the file no longer exists).

  3. Erik Schnetter
    • removed comment

    I am concerned because we are using "mv" in many places. Logically, we either should use "mv -f" everywhere, or nowhere. Otherwise we're implementing a work-around for a poorly understood problem in one place. That means possibly that we'll never encounter the problem again, and the work-around wasn't necessary, or that we'll have to implement the same work-around in many other places.

    Cactus uses autoconf variables for many tools, including "ar", "ranlbi", "rm", "tar", etc. If you think that "mv -f" is beneficial, then I'd rather introduce a new configure variable "MV" that either can be set (on this system), or is set by default, to "mv -f".

    I would draw a parallel to "rm" and "rm -f" in implementing this.

  4. Steven R. Brandt
    • removed comment

    For what it's worth, here are all the places we use "mv":

    repos/flesh/lib/make/CCTK_Functions.sh
    repos/carpet/CarpetWeb/work-with-darcs.html
    repos/flesh/lib/make/known-architectures/linux
    repos/LORENE2/src/build.sh
    repos/flesh/lib/make/known-architectures/xt4-cray-linux
    repos/flesh/lib/make/make.configuration
    repos/flesh/lib/sbin/RunTestUtils.pl
    repos/CRL/py_components.py
    repos/flesh/lib/make/make.thornlib
    repos/flesh/lib/make/known-architectures/aix
    repos/simfactory2/bin/test-archive.sh
    repos/einsteinanalysis/WeylScal4/m/runmath.sh
    repos/ctthorns/m/runmath.sh
    repos/cactusutils/Formaline/src/make.configuration.deps
    repos/simfactory2/bin/distribute-gather
    repos/flesh/lib/make/known-architectures/bgl
    repos/EinsteinExact/m/Makefile
    repos/flesh/Makefile
    repos/mclachlan/doc/checkout.sh
    repos/flesh/doc/MaintGuide/Procedures.tex
    repos/flesh/lib/make/configure
    repos/CRL/GetComponents
    repos/mclachlan/m/runmath.sh
    repos/flesh/lib/make/install-sh
    repos/utils/Scripts/GetComponents
    repos/LORENE2/dist/makesystem.patch
    

    Do we want to change them all?

  5. anonymous
    • removed comment

    I did not check all those. The ones in flesh often (meaning all but the two lines that I changed) had a pattern:

    rm -f foo
    mv foo.tmp foo
    

    so not "mv -f" was required.

    Of he places you checked, do they use just "mv" or "mv -f" or the rm/mv combination?

  6. Roland Haas reporter
    • removed comment

    Please note that I am tending to agree with the general sentiment that this is likely not a rabbit hole we want to descend into. So rather than using "mv -f" everywhere (also in code we do not ourselves control) it seems better to expect a properly functioning mv and a code tree that is somewhat sane.

  7. Roland Haas reporter
    • changed status to resolved
    • removed comment

    Seems to be too exotic to worry about. Interaction attempts during parallel make seem to end up with a make failure which is fine and a serial make may even allow a user to press "y" to overwrite the file.

  8. Log in to comment