Возвращает ли команда pwd в сценарии оболочки каталог, в котором находится сценарий оболочки?
Нет.
Во-первых, по определению, ни один сценарий оболочки или команда оболочки не возвращает ничего, кроме числового статуса выхода в диапазоне от 0 до 255. Это аксиоматика, но обычно не то, что люди имеют в виду, когда задают вопросы такого типа.
Во-вторых, pwd
является как встроенной оболочкой Борна , так и стандартным системным двоичным кодом.Либо один печатает логический или физический текущий рабочий каталог , который обычно:
Если вам нужен каталог текущего сценария, используйте утилиту dirname
, как описано в последнем разделе ниже.
pwd
В качестве быстрой проверки, чтобы увидеть, что действительно печатает pwd , вы можете выполнить следующее:
# Create a shell script containing pwd.
cat <<-EOF > /tmp/test_pwd.sh
#!/bin/sh
pwd
EOF
# Make the script executable.
chmod 755 /tmp/test_pwd.sh
# Go somewhere on the filesystem, and call the test script.
cd /etc
/tmp/test_pwd.sh
Будет напечатано / etc
а не / tmp
, потому что ваш текущий рабочий каталог - / etc
. Это ожидаемое поведение.
Вероятно, вы задаете этот вопрос, потому что хотите найти каталог текущего сценария. В общем случае это быстрое и грязное решение:
#!/usr/bin/env bash
echo $(dirname "$0")
Это работает, потому что $ 0
обычно содержит путь, используемый для вызова выполняемого скрипта, а расширение оболочки использует dirname
, возвращающая путь без имени файла. Вы можете сделать нечто подобное, но с меньшей переносимостью, с помощью расширения параметра Bash «$ {0% / *}»
.
Все это, конечно, чрезмерное упрощение.Пожалуйста, прочтите руководство Bash (особенно разделы о позиционных параметрах, специальных параметрах и BASH_SOURCE ) и страницы руководства для readlink
и realpath
], чтобы получить более полное представление о крайних случаях, которых несколько.
Однако в повседневном написании сценариев компонента каталога $ 0
достаточно, чтобы сообщить вам то, что вы хотите знать. Если вы делаете что-то достаточно сложное, где $ 0
не содержит информации, которая вам действительно нужна, и вам требуются более сложные конструкции, такие как:
echo $(dirname "$(realpath "$0")")
, то вы, вероятно, усложняете себе жизнь, чем нужно. быть.
Вы не можете повторно -создать файл сокета Unix, который был удален.
На самом деле, вы можете создать еще один файл сокета с тем же путем (, попытавшись снова привязать ()дескриптор файла сокета к тому же адресу ), но любой клиент, пытающийся подключиться к нему, получит «Отказано в соединении» вместо подключения к сокету, который был привязан к нему в первую очередь.
Это связано с тем, что сокеты Unix в основном привязаны к инодам , а не к путям. Вы можете легко проверить это, если ваш netcat поддерживает сокеты Unix:
nc -lU /tmp/old_sock &
[1] 19241
ln -f /tmp/old_sock /tmp/new_sock; rm /tmp/old_sock
# or mv /tmp/old_sock /tmp/new_sock
echo yup | nc -U /tmp/new_sock
yup
Все, что может сделать ваша программа, это закрыть старый сокет, создать новый и привязать его к тому же адресу. Чтобы получить уведомление об удалении файла, вы можете использовать inotify(7)
в Linux, kqueue(2)
в BSD или просто периодически выполнять stat(2)
по пути (, как и для любого другого файла )..
Обратите внимание, что в Linux также есть «абстрактные» сокеты Unix --, которые привязаны к последовательности байтов[1] вместо какого-либо системного объекта файла -и не подчиняются никакому файловому -стилю. права доступа и не могут быть «удалены» или перемещены на другой адрес.
[1] вы можете назвать его «строкой», но имейте в виду, что он также может содержать байты NUL, в отличие от системного пути к файлу -.