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 <stok...@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 <stok...@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 <g...@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
--
Sergey Ponomarev <https://linkedin.com/in/stokito>,
stokito.com
--
Sergey Ponomarev <https://linkedin.com/in/stokito>,
stokito.com
