On 2023-07-09 14:41, Sergey Ponomarev wrote:
Hi again,
So will you accept a patch with adding the * as a basename
replacement
for
DEST in cp and mv?
FWIW, quite frankly, I don't think that would be a good idea.
Repurposing the asterisk would only lead to various issues down the
road. Using "cd" to get into the destination directory and do the
intended copy operation, as already discussed, is a perfectly usual
thing to do.
And speaking about the second usability problem about creation of
a non
existing DEST directory.
There is install command which makes exactly this but also support
setting
owner:
-D create all leading components of DEST except the
last,
or
all
components of --target-directory, then copy SOURCE
to
DEST
-g, --group=GROUP
set group ownership, instead of process' current
group
-m, --mode=MODE
set permission mode (as in chmod), instead of
rwxr-xr-x
-o, --owner=OWNER
set ownership (super-user only)
It's great and actually looks like this command is just an
extension of
cp.
But while the cp is well known the install command is used rarely.
I
never
looked into it and never saw its man. I guess many users too.
What if we just merge these two commands? That will simplify
things.
It looks like there are two conflicting options -d -s so we can't
just
make a
symlink to cp but anyway it's easy to just wrap the cp.
I also don't think that would be a good idea. See, "cp" does one
thing,
while "install" does another thing, and the primary philosophy of
Unix
is to do one thing and do it right.
Will you consider a patch with the change?
This two additions while being relatively small will make more
effective
interacting with command line and writing scripts.
On Sat, Jul 1, 2023 at 8:19 PM Sergey Ponomarev
<stokito@gmail.com>
wrote:
Workaround: use Brace Expansion:
mv /tmp/{file1,.bak}
or
mv /tmp/{file1,.bak}
It wasn't intuitive, that's why I didn't figure it out in the
first
place.
Autocomplete doesn't work, but this is a bash issue.
Still, the placeholder would be kind of more clear but it's an
additional
feature so you probably WONTFIX it.
On Sat, Jul 1, 2023 at 7:23 PM Sergey Ponomarev
<stokito@gmail.com>
wrote:
Thank you for the fast response. Nice tricks, didn't know about
the
direxpand. Probably most regular users don't know either :(
As you may see, even with a workaround this usability can be
improved.
So what about having the simple solution in place?
1. Use placeholder like asterisk to refer the source dir inside
of
the
dest dir
2. Use -F arg to create directory if not exists
Have a nice weekend
On Sat, Jul 1, 2023 at 6:44 PM Glenn Golden <gdg@zplane.com>
wrote:
On Sat, Jul 1, 2023, at 09:03, Bernhard Voelker wrote:
On 7/1/23 14:12, Sergey Ponomarev wrote:
> To rename a file a user need to use mv command and specify
the DEST
dir:
>
> mv /some/very/long/path/file /some/very/long/path/
>
> This makes it not so easy to use when typing a command but
also
makes a
> script line longer.
Assuming you meant
$ mv /some/very/long/path/file /some/very/long/path/file2
as in the other example - this could be done with:
$ cd /some/very/long/path && mv file file2
or (with GNU coreutils' env):
$ env -C /some/very/long/path mv file file2
Have a nice day,
Berny
If you use bash and if your long paths are consistent (i.e.
often
referring
to the same source or destination each time) then another
approach
is to
just
enable the bash 'direxpand' option, define some short envars in
your
.bash_profile or .bashrc, and use those to facilitate
commandline
(and
script) operations, e.g.
export p1=/long/path/to/some/frequently/accessed/directory
export
p2=/another/long/path/to/a/frequently/accessed/directory
Then, for cmdline ops, just typing
$ mv $a/<tab>
immediately expands $a (inline on the commandline) to
$ mv /long/path/to/some/frequently/accessed/directory/
and you can then tack on "$b" (or any other destination).
The 'direxpand' option provides nice immediate feedback that
the
envar
you
selected is the correct one (among, presumably, several
1-letter
envars
you've defined like this for various long paths of interest.)
I use this approach frequently in my own workflow when dealing
with
annoyingly long but consistent paths.
Glenn