Команды Bash усекаются при вставке нескольких команд в терминал
Попробуйте сделать следующее:
rename -n 's/\d+/sprintf("%.03d", $&)/e' *jpg
(удалите переключатель -n, когда ваши тесты в порядке)
Есть другие инструменты с тем же именем, которые могут или может быть не в состоянии сделать это, поэтому будьте осторожны.
Если вы запустите следующую команду ( GNU )
$ file "$(readlink -f "$(type -p rename)")"
и получите результат вроде
.../rename: Perl script, ASCII text executable
, но не содержащий:
ELF
, то это правильный инструмент =)
Если нет, сделать его по умолчанию (обычно уже так) в Debian и производном, например Ubuntu :
$ sudo update-alternatives --set rename /path/to/rename
(замените / путь / на / переименовать на путь к вашей команде perl rename .
Если у вас нет этой команды, выполните поиск в диспетчере пакетов, чтобы установить ее, или сделайте это вручную
И последнее, но не менее важное, это Первоначально инструмент был написан Ларри Уоллом, отцом Перла.
Кажется, вы столкнулись с этой ошибкой:
https://lkml.org/lkml/2013/7/25/205
readline() inadvertently triggers an error recovery path when pastes larger than 4k overrun the line discipline buffer. The error recovery path discards input when the line discipline buffer is full and operating in canonical mode and no newline has been received. Because readline() changes the termios to non-canonical mode to read the line char-by-char, the line discipline buffer can become full, and then when readline() restores termios back to canonical mode for the caller, the now-full line discipline buffer triggers the error recovery.
When changing termios from non-canon to canon mode and the read buffer contains data, simulate an EOF push without the DISABLED_CHAR in the read buffer.
Importantly for the readline() problem, the termios can be changed back to non-canonical mode without changes to the read buffer occurring; ie., as if the previous termios change had not happened (as long as no intervening read took place).
Это было применено к ядру 10 декабря 2013 года, то есть ядру Linux версии 3.14. Вы используете более ранний дистрибутив Linux? Какой у тебя дистрибутив? Вы, вероятно, заменили свой реальный путь к файлу, поэтому я не могу считать символы. Не могли бы вы сделать:
for ((a=1; a<20; a++)); do echo "mv /long/path/to/file$a /longer/path/to/file$a"; done|wc -c
с вашими реальными путями -будет ли это что-то действительно близкое к 4k? Если это так, ошибка выше, вероятно, ваша.
Если да, то ответы на ваши вопросы:
- это проблема, связанная с терминалом -(Xterm в моем случае )?
нет
- копирование/вставка происходит через ssh :создает ли это проблему или усугубляет ее?
нет
- это проблема, связанная с bash -на сервере?
Нет и да -это не ошибка в bash или какой-либо библиотеке, используемой bash. Ошибка в ядре.
- Может быть, с другой оболочкой этого не произойдет?
Может быть, если оболочка не использует readline. Вроде зш.
Что касается связанных вопросов «как вставить несколько…», похоже, они не связаны с вашей проблемой. -Причина в том, что некоторые приложения могут читать вставленные вами команды. Наиболее известным примером этого является ssh, если вы запускаете команду ssh на удаленном сервере. Но, учитывая, что вы теряете только части строк, в вашем случае это маловероятно.
Второй вопрос 'Команды вставлены в терминал...' задан 25 сентября 2013 года, в то время патча не существовало, и это определенно выглядит как ошибка, которая у вас есть, и я подозреваю, что это ошибка ядра.
Как проверить наверняка? вставьте вывод uname -здесь.
Я предлагаю использовать gzip и base64 для копирования команд с одного терминала на другой. Если проблема возникает из-за метасимвола или расширения табуляции, вы должны решить ее таким образом.
Пример:
[root@server-one ~]# cat << __EOF__ | gzip | base64
mv /long/path/to/file23 /longer/p
mv /long/path/to/file24 /longer/path
mv /long/path/to/file25 /longer/p
<other commands>
__EOF__
Затем скопируйте закодированный результат в
[root@server-two ~]$ base64 -di | gunzip | bash
<insert your base64-encoded and send with control-d>