Is there an interactive 'mv' command?

11 views
Skip to first unread message

pH

unread,
Oct 18, 2021, 1:43:13 PM10/18/21
to
I want to move selected files from a working directory to a sub-directory.
Rather than tediously doing it one file or similar groups of files at a time
I tried: "mv -i * backup_dir"
and it ended up just moving everything.

-i turns out to be just confirm before overwriting, so of course everything
got moved since it did not already exist in the destination. Dang.

I'm looking for a command that'll do the mv with a y/n query before each
move. Do there be such a thing?

I went down into "backup_dir" and did a "mv * .."
to put everything back again.

Pureheart in Aptos, CA

Rich

unread,
Oct 18, 2021, 1:57:57 PM10/18/21
to
pH <wNOS...@gmail.org> wrote:
> I'm looking for a command that'll do the mv with a y/n query before
> each move. Do there be such a thing?

You can create one on the fly in Bash:

for name in files* files* files* ; do
read -p "Move $name?: " ANS
if [ "$ANS" == "Y" -o "$ANS" == "y" ] ; then
mv "$name" destination/
fi
done

For typing at the CLI, you would normally make it all one line like so:

for name in files* files* files* ; do read -p "Move $name?: " ANS ; if [ "$ANS" == "Y" -o "$ANS" == "y" ] ; then mv "$name" destination/ ; fi ; done


pH

unread,
Oct 18, 2021, 2:15:35 PM10/18/21
to
Wow! Perfect! This worked wonderfully.

I think I'll make a function out of this and put it in my bashrc or
whereever it's supposed to be.

I could not find a man page for read except the 'C' file descriptor read.

thank-you again.
pH

David W. Hodgins

unread,
Oct 18, 2021, 2:52:22 PM10/18/21
to
On Mon, 18 Oct 2021 14:15:31 -0400, pH <wNOS...@gmail.org> wrote:
> I could not find a man page for read except the 'C' file descriptor read.

It's described in "man bash". To find it quickly, search in the man page output by
entering a slash (/) followed by "nchars" (without the quotes).

I picked nchars to search for, as it's a string unique to the read command.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

Lew Pitcher

unread,
Oct 18, 2021, 3:08:25 PM10/18/21
to
On Mon, 18 Oct 2021 14:52:08 -0400, David W. Hodgins wrote:

> On Mon, 18 Oct 2021 14:15:31 -0400, pH <wNOS...@gmail.org> wrote:
>> I could not find a man page for read except the 'C' file descriptor
>> read.
>
> It's described in "man bash". To find it quickly, search in the man page
> output by entering a slash (/) followed by "nchars" (without the
> quotes).

The OP might find it interesting to read up on all the builtin commands in
bash. Same procedure, but substitute "^SHELL BUILTIN" for "nchars", as in
/^SHELL BUILTIN


HTH
--
Lew Pitcher
"In Skills, We Trust"

Rich

unread,
Oct 18, 2021, 3:26:51 PM10/18/21
to
pH <wNOS...@gmail.org> wrote:
> I could not find a man page for read except the 'C' file descriptor
> read.

It is a Bash built-in. man bash (or "help read" at the Bash CLI).

Eli the Bearded

unread,
Oct 18, 2021, 7:43:07 PM10/18/21
to
In comp.os.linux.misc, Rich <ri...@example.invalid> wrote:
> You can create one on the fly in Bash:
>
> for name in files* files* files* ; do
> read -p "Move $name?: " ANS
> if [ "$ANS" == "Y" -o "$ANS" == "y" ] ; then
> mv "$name" destination/
> fi
> done

(This works in more than just bash, but Rich knows that.)

> For typing at the CLI, you would normally make it all one line like so:

What? Why? Multiple lines commands at the prompt have all the "easy to
read and see your mistakes" advantages of multiple line commands in
scripts.

For _further_ readability, I set PS2 to be a tab, so that all my
additional lines are indented.

Just for variety, here's how I'd do that sort of thing (ksh for me):

for name in files* files* files; do
printf "Move %s ?\n" "$name"
read ans
case "$ans" in
[yY]*) mv "$name" destination/ ;;
esac
done

That's "no" as default. If I wanted "yes" to be default case,
I'd write it like this:

case "$ans" in
[nN]*) : do nothing ;;
*) mv "$name" destination/ ;;
esac

I'm a big user of case instead of OR conditions in test or
if-else pairs. And using the : no-op command.

Elijah
------
uses PS1 in the form ": ... ; " with changing ... info

Rich

unread,
Oct 18, 2021, 8:38:59 PM10/18/21
to
Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.os.linux.misc, Rich <ri...@example.invalid> wrote:
>> For typing at the CLI, you would normally make it all one line like so:
>
> What? Why? Multiple lines commands at the prompt have all the "easy to
> read and see your mistakes" advantages of multiple line commands in
> scripts.

Besides invoking an editor on the current CLI being entered, is there a
way to return to a previous line to fix a mistake after one's gone on
to a subsequent line? I enter these single line because then if I do
need to edit something near the front, at least I can run back in the
readline buffer and edit the front.

But if there's a way to jump back and edit a previous line, please
enlighten me.

> I'm a big user of case instead of OR conditions in test or if-else
> pairs. And using the : no-op command.

Yes, and I've done the same myself for my scripts. I simply didn't
think about using 'case' when writing up my response.

Eli the Bearded

unread,
Oct 19, 2021, 4:58:12 PM10/19/21
to
In comp.os.linux.misc, Rich <ri...@example.invalid> wrote:
> Besides invoking an editor on the current CLI being entered, is there a
> way to return to a previous line to fix a mistake after one's gone on
> to a subsequent line? I enter these single line because then if I do
> need to edit something near the front, at least I can run back in the
> readline buffer and edit the front.

I guess that's a valid reason. I control-c out and cut-paste to repeat
and fix (or invoke an editor with 'escape-v' because I live in
"set -o vi" world.)

> But if there's a way to jump back and edit a previous line, please
> enlighten me.

"fc -e ed for" not your style then? :^)

Elijah
------
uses "fc" commands via one character aliases

pH

unread,
Oct 20, 2021, 12:09:11 AM10/20/21
to
On 2021-10-18, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
> On Mon, 18 Oct 2021 14:15:31 -0400, pH <wNOS...@gmail.org> wrote:
>> I could not find a man page for read except the 'C' file descriptor read.
>
> It's described in "man bash". To find it quickly, search in the man page output by
> entering a slash (/) followed by "nchars" (without the quotes).
>
> I picked nchars to search for, as it's a string unique to the read command.
>
> Regards, Dave Hodgins
>

Ah! It's a bash built-in. Thank-you for the tip.

pH

pH

unread,
Oct 20, 2021, 12:10:58 AM10/20/21
to
I've jotted this down as my next learning task--if only I can retain it
all--thanks!
pH

Eric Pozharski

unread,
Oct 20, 2021, 5:33:11 AM10/20/21
to
with <eli$21101...@qaz.wtf> Eli the Bearded wrote:
> In comp.os.linux.misc, Rich <ri...@example.invalid> wrote:

>> Besides invoking an editor on the current CLI being entered, is there
>> a way to return to a previous line to fix a mistake after one's gone
>> on to a subsequent line? I enter these single line because then if I
>> do need to edit something near the front, at least I can run back in
>> the readline buffer and edit the front.
> I guess that's a valid reason. I control-c out and cut-paste to repeat
> and fix (or invoke an editor with 'escape-v' because I live in "set -o
> vi" world.)

Or (vi-speak here) "<Esc>o" or "<Esc>O" (because I live in zsh world,
just checked bash doesn't (or I'm missing something here) (also, no idea
how to do it with emacs-mode)).

>> But if there's a way to jump back and edit a previous line, please
>> enlighten me.
> "fc -e ed for" not your style then? :^)

(zsh again, no idea how to do it in bash or emacs-mode) "-" recalls
previos *command*, "k" goes to previous *line* (in multi-line), then to
last line command-wise. Just have to keep in mind (and constantly) --
"<Enter>" executes command right now ("r<Enter>" is fine though).

*CUT*

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Bit Twister

unread,
Oct 20, 2021, 7:19:17 AM10/20/21
to
On Tue, 19 Oct 2021 00:38:54 -0000 (UTC), Rich wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> In comp.os.linux.misc, Rich <ri...@example.invalid> wrote:
>>> For typing at the CLI, you would normally make it all one line like so:
>>
>> What? Why? Multiple lines commands at the prompt have all the "easy to
>> read and see your mistakes" advantages of multiple line commands in
>> scripts.
>
> Besides invoking an editor on the current CLI being entered, is there a
> way to return to a previous line to fix a mistake after one's gone on
> to a subsequent line? I enter these single line because then if I do
> need to edit something near the front, at least I can run back in the
> readline buffer and edit the front.

As I miss-understand it setting the VISUAL environment variable to the
desired editor of choice allows you to use that editor commands for editing.

Example: ]$ echo $EDITOR
EMACS
allows me to use emacs commands at the prompt.



Eli the Bearded

unread,
Oct 20, 2021, 3:14:24 PM10/20/21
to
In comp.os.linux.misc, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Tue, 19 Oct 2021 00:38:54 -0000 (UTC), Rich wrote:
> > Besides invoking an editor on the current CLI being entered, is there a
> > way to return to a previous line to fix a mistake after one's gone on
> As I miss-understand it setting the VISUAL environment variable to the
> desired editor of choice allows you to use that editor commands for editing.

What if you don't want to invoke the editor? "Besides invoking an
editor" was the question.

> Example: ]$ echo $EDITOR
> EMACS
> allows me to use emacs commands at the prompt.

What shell? The bash I have installed here will use VISUAL, EDITOR, and
then emacs in that order according to the manpage. Unless you use the fc
command to manipulate history, then it's FCEDIT, EDITOR or vi. In ksh93,
VISUAL, EDITOR, vi to edit history when "set +vi" is on, otherwise (I
think) HISTEDIT, FCEDIR, or ed.

I don't know what zsh, et al., do.

Elijah
------
is fine with ed, and prefers it to (some) linux using nano as default editor
Reply all
Reply to author
Forward
0 new messages