Копирование содержимого одного каталога в другой

red	# 4 года, 8 месяцев назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	Natrio достаточно разрешить ей это: shopt -s dotglob тогда вместо одной это выливается в три команды: `$ shopt -s dotglob $ cp ... $ shopt -u dotglob` что не есть гуд Natrio `$ echo 1/{,.} 1/2 1/. 1/.. 1/.h 1/.hid` Natrio пример явно делает много лишнего. виноват, BASH не учёл, в ZSH такой ерунды не наблюдается, то есть . и .. скрывается при раскрытии * Natrio Что касается второго, копирующего 1/. , он действительно работает, хотя и очень неочевидным способом… ну а как по мне всё очевидно Natrio Кроме того, костыль внутри cp никаки не поможет с другими командами это как посмотреть если смотреть сверху стакана то это просто недоработки в некоторых командах в том числе и mv; в других, например, как ls и cd всё тип топ: `$ ls 1/./ $ cd 1/./` Natrio Команда scp воспримет "путь/". как… утилита scp из Community ну уж никак не тянет на базовые linux утилиты подобные cp, mv, ls, cd и др. из coreutils, поэтому как пример она здесь совсем не уместна, можно найти еще 1 миллион утилит где что-то будет работать неправильно п.с.1 посему выходит что наиболее универсальным способом в данном случае является копирование через точку, способ {,.} для баша(для zsh норм) работает некорректно п.с.2 по поводу dotfile, Роб Пайк считает что это глупость

# 4 года, 8 месяцев назад

Сообщения: 1517

Участник с: 31 августа 2011

Natrio
достаточно разрешить ей это: shopt -s dotglob

тогда вместо одной это выливается в три команды:

$ shopt -s dotglob
$ cp ...
$ shopt -u dotglob

что не есть гуд

Natrio

$ echo 1/{*,.*}
1/2 1/. 1/.. 1/.h 1/.hid

Natrio
пример явно делает много лишнего.

виноват, BASH не учёл, в ZSH такой ерунды не наблюдается, то есть . и .. скрывается при раскрытии *

Natrio
Что касается второго, копирующего 1/. , он действительно работает, хотя и очень неочевидным способом…

ну а как по мне всё очевидно

Natrio
Кроме того, костыль внутри cp никаки не поможет с другими командами

это как посмотреть
если смотреть сверху стакана то это просто недоработки в некоторых командах в том числе и mv; в других, например, как ls и cd всё тип топ:

$ ls 1/./
$ cd 1/./

Natrio
Команда scp воспримет "путь/". как…

утилита scp из Community ну уж никак не тянет на базовые linux утилиты подобные cp, mv, ls, cd и др. из coreutils, поэтому как пример она здесь совсем не уместна, можно найти еще 1 миллион утилит где что-то будет работать неправильно

п.с.1
посему выходит что наиболее универсальным способом в данном случае является копирование через точку, способ {*,.*} для баша(для zsh норм) работает некорректно

п.с.2
по поводу dotfile, Роб Пайк считает что это глупость

Natrio	# 4 года, 8 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	red как по мне всё очевидно "1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное. cd (оператор шелла, в bash и zsh ) воспринимает их все (1 и 1/.) как раз одинаково, но не о нём речь, поскольку он принимает только каталог как аргумент. Нас же интересуют только те команды, которые принимают как аргумент и файлы, и каталоги, а потому могут интерпретировать "/." в конце как указание на все файлы в каталоге, как это делает cp , в место самого каталога, Итак, мы уже выяснили, что команда mv (из того же пакета coreutils), в отличии от cp , вообще не может интерпретировать путь с "/.", и всегда выдаёт ошибку. Таким образом, mv не может переместить все файлы в другой каталог через обозначение "/." Команда rm -r , которая тоже принимает как файлы, так и каталоги, принципиально отказывается принимать пути с точкой (.) или двумя (..) на конце, из соображений безопасности. То есть, rm не может удалить все файлы в каталоге через это обозначение. Команда readlink -f (из coreutils), успешно удаляет из пути все лишние одинарные точки, и никакого специально значения им не придаёт, что от неё и ожидается. Команда ls тупо передаёт аргумент (или точку при отсутствии аргумента) ядру, а потому наличие или отсутствие лишних точек в конце пути не влияет на получаемый от ядра список (ядро выдает все файлы в каталоге, включая "скрытые", и включая виртуальные "." и ".."), но влияет на выводимый результат – ls так же тупо дописывает путь к каждому полученному от ядра имени. Другими словами, список файлов выводится независимо от точки в конце пути. Команда ln -s (жесткие ссылки на каталоги запрещены) аналогично mv , выдаёт ошибку, если в конце первого аргумента стоит точка, но только если каталог назначения существует. В противном случае работает так же, как и без точки. То есть, точка в конце пути и здесь не означает список файлов. Ладно, сдаюсь – мне не удалось припомнить в пакете coreutils ни одной команды, кроме cp, которая бы интерпретировала точку в конце пути таким специфическим (для меня) и таким очевидным (для вас) способом. Кстати, с scp я вчера что-то перепутал – она как раз работает аналогично cp Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]? При всём при этом, использование шаблона * в шелле работает со всеми командами безотказно. Отключение фильтрации "скрытых", работает одинаково и в баше ( shopt -s dotglob , включение shopt -u dotglob ), и в zsh ( setopt globdots , включение setopt noglobdots ). Шаблон *{,.}* работает только в zsh, который получая от ядра список имён для шаблона, выкидывает из него виртуальные, аналогично ls -A Было бы здорово, если бы все пользовались zsh, а не башем, да? :) По поводу мнения Роба Пайка о "дотфайлах" – можно сетовать на ошибки авторов UNIX сколько угодно, реальность от этого не изменится – они есть, и приходится как-то с ними жить. Ну, или может с ними побороться – например, прописать в rc-файле zsh перманентные команды `setopt globdots alias ls='ls --color=auto -A'` Вуаля, теперь все файлы в консоли равны!

Natrio

# 4 года, 8 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

red
как по мне всё очевидно

"1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное.

cd (оператор шелла, в bash и zsh ) воспринимает их все (1 и 1/.) как раз одинаково, но не о нём речь, поскольку он принимает только каталог как аргумент.

Нас же интересуют только те команды, которые принимают как аргумент и файлы, и каталоги, а потому могут интерпретировать "/." в конце как указание на все файлы в каталоге, как это делает cp , в место самого каталога,

Итак, мы уже выяснили, что команда mv (из того же пакета coreutils), в отличии от cp , вообще не может интерпретировать путь с "/.", и всегда выдаёт ошибку. Таким образом, mv не может переместить все файлы в другой каталог через обозначение "/."

Команда rm -r , которая тоже принимает как файлы, так и каталоги, принципиально отказывается принимать пути с точкой (.) или двумя (..) на конце, из соображений безопасности. То есть, rm не может удалить все файлы в каталоге через это обозначение.

Команда readlink -f (из coreutils), успешно удаляет из пути все лишние одинарные точки, и никакого специально значения им не придаёт, что от неё и ожидается.

Команда ls тупо передаёт аргумент (или точку при отсутствии аргумента) ядру, а потому наличие или отсутствие лишних точек в конце пути не влияет на получаемый от ядра список (ядро выдает все файлы в каталоге, включая "скрытые", и включая виртуальные "." и ".."), но влияет на выводимый результат – ls так же тупо дописывает путь к каждому полученному от ядра имени. Другими словами, список файлов выводится независимо от точки в конце пути.

Команда ln -s (жесткие ссылки на каталоги запрещены) аналогично mv , выдаёт ошибку, если в конце первого аргумента стоит точка, но только если каталог назначения существует. В противном случае работает так же, как и без точки. То есть, точка в конце пути и здесь не означает список файлов.

Ладно, сдаюсь – мне не удалось припомнить в пакете coreutils ни одной команды, кроме cp, которая бы интерпретировала точку в конце пути таким специфическим (для меня) и таким очевидным (для вас) способом. Кстати, с scp я вчера что-то перепутал – она как раз работает аналогично cp
Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]?

При всём при этом, использование шаблона * в шелле работает со всеми командами безотказно. Отключение фильтрации "скрытых", работает одинаково и в баше ( shopt -s dotglob , включение shopt -u dotglob ), и в zsh ( setopt globdots , включение setopt noglobdots ).
Шаблон {*,.*} работает только в zsh, который получая от ядра список имён для шаблона, выкидывает из него виртуальные, аналогично ls -A
Было бы здорово, если бы все пользовались zsh, а не башем, да? :)

По поводу мнения Роба Пайка о "дотфайлах" – можно сетовать на ошибки авторов UNIX сколько угодно, реальность от этого не изменится – они есть, и приходится как-то с ними жить. Ну, или может с ними побороться – например, прописать в rc-файле zsh перманентные команды

setopt globdots
alias ls='ls --color=auto -A'

Вуаля, теперь все файлы в консоли равны!

red	# 4 года, 8 месяцев назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	Natrio "1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное. ну да, ведь "точка" это жесткая ссылка на входной каталог большинство "проблем с поведением" проистекают из за наложенных в системе ограничений(даже для root) на создание жестких ссылок(одинаковый inode) на директорию, а также "наложенного запрета" на прямое создание/удаление/изменение имени двух подкаталогов с именами: "." - имеет inode входного каталога и ".." - имеет inode родительского каталога. Natrio Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]? оно ? Natrio Вуаля, теперь все файлы в консоли равны! процессору от этого не легче :)

red

# 4 года, 8 месяцев назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

Natrio
"1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное.

ну да, ведь "точка" это жесткая ссылка на входной каталог

большинство "проблем с поведением" проистекают из за наложенных в системе ограничений(даже для root) на создание жестких ссылок(одинаковый inode) на директорию, а также "наложенного запрета" на прямое создание/удаление/изменение имени двух подкаталогов с именами: "." - имеет inode входного каталога и ".." - имеет inode родительского каталога.

Natrio
Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]?

оно ?

Natrio
Вуаля, теперь все файлы в консоли равны!

процессору от этого не легче :)

Natrio	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	red оно ? Нет, конечно, там же написано: Base Package: dropbear Description: Lightweight SCP executable Upstream URL: https://matt.ucc.asn.au/dropbear/dropbear.html License(s): MIT Conflicts: openssh Если кто не в курсе, dropbear это "лёгкий" эрзац-SSH для систем с дефицитом ресурсов, вроде роутеров. Применяется там же, где busybox. А у нас, в Арче, используется нормальный, "взрослый" openssh, и scp всегда был его частью: `$ pacman -Ql openssh \| grep /bin/ openssh /usr/bin/ openssh /usr/bin/findssl.sh openssh /usr/bin/scp openssh /usr/bin/sftp openssh /usr/bin/ssh openssh /usr/bin/ssh-add openssh /usr/bin/ssh-agent openssh /usr/bin/ssh-copy-id openssh /usr/bin/ssh-keygen openssh /usr/bin/ssh-keyscan openssh /usr/bin/sshd $ pacman -Ss '^openssh$' core/openssh 7.6p1-1 [установлен] Free version of the SSH connectivity tools`

Natrio

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

red
оно ?

Нет, конечно, там же написано:

Base Package: dropbear
Description: Lightweight SCP executable
Upstream URL: https://matt.ucc.asn.au/dropbear/dropbear.html
License(s): MIT
Conflicts: openssh

Если кто не в курсе, dropbear это "лёгкий" эрзац-SSH для систем с дефицитом ресурсов, вроде роутеров. Применяется там же, где busybox.

А у нас, в Арче, используется нормальный, "взрослый" openssh, и scp всегда был его частью:

$ pacman -Ql openssh | grep /bin/
openssh /usr/bin/
openssh /usr/bin/findssl.sh
openssh /usr/bin/scp
openssh /usr/bin/sftp
openssh /usr/bin/ssh
openssh /usr/bin/ssh-add
openssh /usr/bin/ssh-agent
openssh /usr/bin/ssh-copy-id
openssh /usr/bin/ssh-keygen
openssh /usr/bin/ssh-keyscan
openssh /usr/bin/sshd
$ pacman -Ss '^openssh$'
core/openssh 7.6p1-1 [установлен]
    Free version of the SSH connectivity tools

red	# 4 года, 8 месяцев назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	а, ну так это походу тоже самое, только облегченная версия(или аналог) scp из openssh. `$ pacman -Fs scp core/openssh 7.6p1-1 usr/bin/scp extra/bash-completion 2.7-2 usr/share/bash-completion/completions/scp community/scp 2017.75-5 usr/bin/scp`