GNU bug report logs - #30907
mv return value.

Previous Next

Full log

View this message in rfc822 format

From: Jorgen Harmse <Jorgen.Harmse <at> samsclub.com>
To: Eric Blake <eblake <at> redhat.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "30907 <at> debbugs.gnu.org" <30907 <at> debbugs.gnu.org>
Subject: bug#30907: mv return value.
Date: Thu, 22 Mar 2018 22:47:32 +0000

I see Eric's point, but it seems to me that my use case is not unusual. (Rename a file unless the target exists, in which case check that they are the same before removing one.) Perhaps the documentation of mv could suggest a solution, e.g.

(ls b &> /dev/null && diff a b > /dev/null && rm a) || mv -n a b

Regards,
Jorgen Harmse
 
Sam’s Club Technology
Phone 512.633.2226 
jorgen.harmse <at> samsclub.com
 
 
This e-mail and any files transmitted with it are confidential and intended solely
for the individual or entity to whom they are addressed.  If you have received
this e-mail in error, destroy it immediately.  Wal-Mart Confidential.
 
On 3/22/18, 17:01, "Eric Blake" <eblake <at> redhat.com> wrote:

    On 03/22/2018 04:53 PM, Paul Eggert wrote:
    > On 03/22/2018 12:17 PM, Jorgen Harmse wrote:
    >> My preference is a non-zero exit status when mv does not move/rename 
    >> the file.
    > 
    > Hmm, this might be doable. POSIX says that the mv exit status is 0 if 
    > "All input files were moved successfully" and is >0 if "An error 
    > occurred". With mv -i, if the user declines a move and there is other 
    > file then neither case applies, so mv can yield either 0 or nonzero as 
    > an exit status. Of course someone would have to write the code and (more 
    > importantly) the documentation to do it that way, but I think your 
    > request is a reasonable one.
    
    I'd argue the opposite: 0 implies success ("I successfully moved all 0 
    files that you interactively approved for me to move"), while 1 implies 
    failure ("I failed to move a file, AND printed an error message why"). 
    When the user declines to move a file, we don't print an error message, 
    so that should NOT be treated as an error, but successfully skipping the 
    file.  We didn't fail to move the file, because we didn't even attempt 
    to move the file.  That is, interactive decisions can only reduce the 
    set of files to attempt to move, and not be treated as errors on t heir own.
    
    -- 
    Eric Blake, Principal Software Engineer
    Red Hat, Inc.           +1-919-301-3266
    Virtualization:  qemu.org | libvirt.org
    
    

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.