RPi3 вопрос по монтированию nfs

Совсем не обязательно запоминать в отдельной переменной текущую директорию (_pwd=$PWD), если нужно перейти в другую директорию и когда-то вернуться обратно в текущую
Достаточно запушить её и указать куда идем дальше.
Создаю какую-то тестовую директорию

Код (Bash):

alex@orangepizero:~$ mkdir test-dir && cd test-dir/

Пушу текущую директорию и ухожу в /tmp, выполняю какие-то команды и гуляю по директориям, в конце возвращаюсь в текущую директорию.

Код (Bash):

alex@orangepizero:~/test-dir$ pushd /tmp && echo $PWD >test.pwd && cd /etc && cat os-release && popd && cat /tmp/test.pwd
/tmp ~/test-dir
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
~/test-dir
/tmp
alex@orangepizero:~/test-dir$

Малинки включенной не было, тренировался на апельсинке.

П.С.
Не понятно для чего менять директорию, чтоб выполнить в ней скрипт myroot.sh
Если в скрипте нужно знать в какой директории этот скрипт расположен (например скрипте используется относительный путь для создания доп.директории), то проще получить имя директории из имени скрипта.
Строю скрипт в /tmp/myroot.sh в котором создаю директорию share1

Код (Bash):

#!/bin/bash
if ! [ -d $(dirname $0)/share1 ]; then
  mkdir $(dirname $0)/share1
  chmod 777 $(dirname $0)/share1
fi

 

Верно! Перенёс сие в скрипт запуска и там так же не важно запоминать PWD если сам скрипт с "&". Но если в rc.local надо что-то ещё с текущим (для rc.local) то и надо делать возврат.
Ранее моей ошибкой было то что запускаемый из rc.local скрипт "хотел" для своей работы тот каталог в котором он сам.
Можно конечно и start-stop-daemon с параметрами... но это уж с лишком по моему... да и в процессе работы сам рабочий скрипт будет запускать и останавливать много чего. Он же цикл с ориентированием на содержимое ряда файлов в примонтированной NFS. Да и контролировать ему много чего надо:
- по списку из файла проверять/запускать ряд других скриптов/программ
- проверять версию прорамм и по списку из файла (новая версия) останавливать, компилировать и запускать. При редактировании кода на удалённой машине надо только указать в файле новую версию и дату.
- вести в директории ID каждого запущенного процесса
- вести логи
Весь смысл (в начале говорил) в том, что малин будет несколько и каждая будет иметь свою директорию (NFS) на одной удалённой машине. При добавлении/изменении проекта не надо заходить в каждую малину и перезапускать что-то. На одной машине делать что-то удобнее чем на каждой в отдельности. Пока не пришёл к форме контроля (формат файла описания)

 

Вот теперь подключена вторая малина (pi02) обе при перезапуске имеют примонтированную свою NFS и на кажой запущен свой mywork.sh, который должен контролировать работу по собственному списку. сам скрипт (mywork.sh) идентичен
pi02 (список будет заточен)
- сонар по i2c
- поворот камеры и сонара сеовомашинами (шилд через ардуину по USB-SERIAL)
- движение (шилд через ардуину по USB-SERIAL)
- код на OpenCV и web-камера по USB
- сервер связи (данные с камеры,сонара, команды управления) серез /dev/shm между процессами и сервером
Будь это моя работа, давно бы сделал и далее двигался...

pi01 (список пока не заточен)
- будем учиться строить карту пространства (опыт)
- управлять движением по связи с pi02
- ...

У каждой малины хоть и идентичный скрипт контроля, но свой список задач. Теперь отработка скрипта контроля (надо пилить)