coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request: "mv --relative" or "mv -r"


From: Bob Proulx
Subject: Re: Feature request: "mv --relative" or "mv -r"
Date: Sat, 24 Nov 2018 01:02:47 -0700
User-agent: Mutt/1.10.1 (2018-07-13)

Daniel Böhmer wrote:
> I want to propose a new parameter to the "mv" command which
> helps when working with nested directory structures from the
> structure's root dir as $PWD.

New options require a strong rationale for addition.

> Similar to the "ln" command's "--relative" parameter "mv"
> could accept this and either chdir to the moved files
> location beforehand or (maybe better) calculate the
> target location from the given path as relative path
> from the file's original location.

By my reading of the description it doesn't seem to be similar to ln's
--relative option.  The proposal above seems to be proposing a way to
operate within a subdirectory, which is different.  That seems to be
simply a change directory first operation.  Like make's -C option.

> Examples with the "-v" switch for illustration:
> 
> $ mv -rv foo/bar.txt baz.txt
> 'foo/bar.txt' -> 'foo/baz.txt'

I know this is the trivial command:

  mv -v foo/bar.txt foo/baz.txt

But I know you were wanting to avoid typing in the "foo" part more
than once.  Therefore this seems like the right short expression for it.

  (cd foo && mv -v bar.txt baz.txt)

> $ mv -rv foo/*.txt subfolder/
> 'foo/bar.txt' -> 'foo/subfolder/bar.txt'
> 'foo/baz.txt' -> 'foo/subfolder/baz.txt'

Same thing here:

  (cd foo && mv -v ./*.txt subfolder/)

  (cd foo && mv -v -t subfolder ./*.txt)

[[Note I always use ./* instead of * to avoid any possibility of one
of the files starting with a '-' and being interpreted as an option.]]

> I often miss this switch for these use cases:
> - simply rename a file in a [sub*]directory
> - move a bunch of files around in a lower part of the directory structure

Additionally one can also easily create a custom script that changes
directory first and then performs the operation.  For example:

  #!/bin/sh
  dir=$1
  shift
  cd $dir && mv "$@"

And then call it like:

  mycdmv very/long/path a.txt b.txt

The joy of the Unix philosophy is small utilities that can be joined
together to perform larger tasks.

> I find the alternatives
> - mv very/long/path/{a.txt,b.txt}
> - rename 's/a\.txt/b.txt/' very/long/path/a.txt
> rather cumbersome to type.

I personally find this to be very easy to type and the very long path
gets completion making that easy.

  (cd very/long/path && mv a.txt b.txt)

Using (cd directory && ...) is an idiom that just rolls off the
fingers very easily.  At least for me.  Been using it for a very long
time.  If one typos the directory then the cd will fail and produce an
error message appropriately to stderr.  If the cd fails then the &&
fails and the right hand side is not invoked.  The entire thing is in
a (...) subshell and therefore the directory change evaporates after
that process exits.

> For the source location
> I want to use bash completion and for the target
> location I'd like to type only the new information,
> i.e. the subfolder or the new filename.

The cd can make use of bash completion.  The rest seems not to be
automatically completable anyway.

> Do you know of any easier existing ways to achieve
> the desired behavior?

I personally would use the above techique of changing directory in a
subshell before running the command.  It is also portable across
systems.  But there is also the -t --target-directory option too.  It
can be very useful depending upon the situation too.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]