Avoid enter key in cp -i

command linecp

I often need to selectively archive a long list of files using cp -iar, or similar, and to speed up the process I would like to press just one key instead of y or n followed by ENTER on every file. In other words I want to avoid having to press ENTER as well as y or n. Of course I would happily use different keys instead of y or n.

Is there a way to do this?

Best Answer

I think that what you need is a file manager, like midnight commander. In mc you can select several files with insert or + and realize operations on them, like deleting, moving or copying. A full set of instructions and tips can be found in the Tutorial.

If you give it a try to pure shell commands (no gui), suppose you have file0 to file10 but wants to copy only file1 and file3:

cp file1 file3 directory/

Of course, you can use the shell to help yourself:

cp file{1,3} directory/

but what about consecutive ones? file5 through file10?

cp file{5..10} directory/

You can also use find to help, if you want something more advanced, for example:

find Downloads -name "*.cfg" -exec cp {} directory \;

will do this:

copy Downloads/file(6).cfg to directory
copy Downloads/file(7).cfg to directory
copy Downloads/file(1).cfg to directory
copy Downloads/file.cfg to directory
copy Downloads/file(2).cfg to directory
copy Downloads/file(4).cfg to directory
copy Downloads/file(3).cfg to directory
copy Downloads/file(5).cfg to directory

you can verify the files to be copied removing the -exec ... part. You can also use -exec echo cp ... in case you want to know what find will do.

Related Solutions

How to type a command to execute when the current command completes

Well, according to some of your edits you've got CTRL+J bound to a bindkey macro command. That explains your bash issue considering readline's default behavior.

Generally readline reads input in something very like stty raw mode. Input chars are read in as soon as they are typed and the shell's line-editor handles its own buffering. readline sets the terminal to raw when it takes the foreground, and it restores it to whatever its state was beforehand when calling up another foreground process group.

CTRL+J is an ASCII newline. ABCDEFGHIJ is 10 bytes from NUL. Because you have configured readline to eat this character and subsequently to expand away what remains of any command-line on which it does with menu-completion, type-ahead won't work. The terminal is in a different state when the type-ahead is buffered by the kernel's line-discipline than it is when readline is in the foreground.

When readline is in the foreground it does its own translation for input carriage returns -> newlines and the terminal driver doesn't convert it at all. When you enter your type-ahead input, though, the terminal driver will typically translate returns to newlines as can be configured with stty [-]icrnl. And so your return key is sufficient for commands entered live, but the newlines sent by the terminal's line-discipline are being interpreted as menu-complete commands.

You might tell the terminal driver to stop this translation with stty -icrnl. This is likely to take at least a little bit of getting used to. Other commands that accept terminal input will usually expect newlines rather than returns, and so you'll either have to explicitly use CTRL+J when they control the foreground, or else teach them to handle the returns as bash does.

You've already mentioned that read doesn't work as expected when reading form the terminal. Again, it likely would if you explicitly used CTRL+J to end an input line. Or... you can teach it:

read()
    if    [ -t 0 ]
    then  command read -d $'\r' "$@"
    else  command read "$@"
    fi

It will probably be a lot less hassle in the long-run if you found a different key for menu-complete, though. Newlines are kind of a big deal for most terminal applications.

Bash – Command line method to find repeat-word typos, with line numbers

Edited: added install and demo

You need to take care of at least some edge cases, like

repeated words at the end (and beginning) of the line.
search should be case insensitive, because of frequent errors like The the apple.
probably you want to restrict search only to word constituent to not match something like ( ( a + b) + c ) (repeated opening parentheses.
only full words should match to eliminate the thesis
When it comes to human language Unicode characters inside words should properly interpreted

All in all I recommend pcregrep solution:

pcregrep -Min --color=auto '\b([^[:space:]]+)[[:space:]]+\1\b' file

Obviously color and line number (n option) is optional, but usually nice to have.

Install

On Debian-based distributions you can install via:

$ sudo apt-get install pcregrep

Example

Run the command on jefferson_typo.txt to see:

$ pcregrep -Min --color=auto '\b([^[:space:]]+)[[:space:]]+\1\b' jefferson_typo.txt
1:He has has refused his Assent to Laws, the most wholesome and necessary
3:He has forbidden his Governors to pass Laws of immediate and
and pressing importance, unless suspended in their operation till his
5:Assent should be be obtained; and when so suspended, he has utterly

The above is just a text capture, but on a color-supported terminal, matches are colorized:

has has
and
and
be be