Классический подход — использовать sed:
cp "${filename}" "$(realpath ${filename} | sed s:/:__:g)"
Преимущество в первую очередь заключается в переносимости между оболочками, если вы не всегда будете использовать bash.
Конечно, это также позволяет вам отказаться от скрипта и просто сделать это с помощью find:
find /base/path -type f -exec cp \{\} `realpath \{\} | sed s:/:__:g` \;
В программе «Найти» есть параметры сортировки и фильтрации, которые можно использовать, если они нужны только для копирования определенных файлов.
изменить :Эта настройка работает на одной из моих систем, но не на другой. Вместо того, чтобы разбираться в различиях, я просто сделал его более портативным :
.find /base/path -type f | sed -e "p; s:/:__:g" | xargs -n2 cp
Я изучил, как диагностировать проблемы.
Я установил tcpdump
на Raspberry Pi и отслеживал eth1
. Я видел запросы ARP с запросом «у кого есть локальный хост».
Я отредактировал /etc/dhcp/dhcpd.conf
и нашел строку option routers localhost;
. Я предполагаю, что это недопустимый вариант, хотя journalctl -xe
об этом не сообщил. (По крайней мере, я так не думаю, я не заметил никаких ошибок при загрузке.)
Я изменил это на option routers 192.168.2.254
. Мне это "кажется" неправильным. Я бы подумал, что это должно быть localhost
или 127.0.0.1
... Потому что Pi является одновременно DHCP-сервером для сети 192.168.2.0
и маршрутизатором для этой сети.
Перезагрузился, снова очистил iptables
, и теперь я могу пропинговать маршрутизатор (Pi ).
Хорошо, сейчас я не могу пинговать, но минуту назад мог...
На моей рабочей станции я теперь вижу это как свою таблицу маршрутизации
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
127.0.0.1 dev enx0050b668976b proto dhcp scope link metric 100
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
Это больше похоже на то, что я ожидал увидеть.
После перезагрузки у меня просто
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
192.168.2.0/24 enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
Перезагрузил оба устройства.
Вот результатiptables --list -v
sudo iptables --list -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
185 21142 ACCEPT all -- lo any anywhere anywhere
124 11380 ACCEPT tcp -- eth1 any anywhere anywhere tcp dpt:ssh
107 16316 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
34 2936 DROP all -- eth0 any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Таблица маршрутизации:
default via 192.168.1.254 dev eth0 proto dhcp src 192.168.1.201 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.201 metric 202
192.168.2.0/24 dev eth1 proto dhcp scope link src 192.168.2.254 metric 203
Таблица маршрутизации рабочей станции:
default via 192.168.2.254 dev enx0050b668976b proto dhcp metric 100
10.0.0.0/8 dev enp7s0 proto kernel scope link src 10.0.0.1
192.168.2.0/24 dev enx0050b668976b proto kernel scope link src 192.168.2.10 metric 100
Кажется, default
вернулся. Я действительно не уверен, почему это произошло, кроме неправильной конфигурации где-то.
Вот мое определение подсети в `/etc/dhcp/dhcpd.conf
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.10 192.168.2.120;
option routers 192.168.2.254;
option broadcast-address 192.168.2.255;
}
Опять же, немного странно, что здесь используется 192.168.2.254
, а не что-то вроде 127.0.0.1
, но я думаю, сработает ли это?