Делает кд. есть использование?

В одном из кратких руководств, за которым я следовал, cd .он бесполезен. При попытке воспроизвести проблему, показанную OP в рекурсии символьной ссылки, что делает ее «перезагрузкой»? Я также попробовал cd ., который показал тот же эффект, который описал OP (растущая $PWDпеременная), с которым можно бороться cd -P.

Это заставляет меня задуматься, есть ли случай, когда кто-то действительно хотел бы использовать cd . ?

Я думаю, что это переосмысление проблемы. cd .может быть не то, что можно было бы запустить вручную в обычном порядке, но это определенно то, что может возникнуть при программном выполнении (подумайте о любой ситуации, когда вы можете cdобратиться к каталогу, содержащему файл, путь которого указан пользователем ). Следовательно, он не должен иметь какое-то конкретное применение: пока он выполняет обычную семантику cd <some-path>, он полезен.

Путь к каталогу мог измениться с тех пор, как была выполнена последняя команда, и без cd .оболочек bash и ksh93 будет полагаться на логический рабочий каталог, описанный в сообщении, связанном с вопросом, поэтому вызов, вызывающий cd .проблему с getcwd()оболочкой, обеспечит системный вызов. текущий путь все еще действителен.

Шаги для воспроизведения в Bash:

1. В терминальной вкладке вопрос mkdir ./dir_no_1; cd ./dir_no_1
2. В другом терминале проблема с вкладкой mv dir_no_1 dir_no_2
3. В первой вкладке терминала выдают echo $PWDи pwd. Обратите внимание, что каталог был переименован извне; среда оболочки не была обновлена.
4. Issue cd .; pwd; echo $PWD. Обратите внимание, что значение было обновлено.

ksh93, однако, не обновляет информацию об окружающей среде, поэтому cd .в ksh93 может фактически оказаться бесполезным. В /bin/dashUbuntu и других системах на основе Debian cd .возвращает dash: 3: cd: can't cd to .ошибку, однако cd -P .работает (в отличие от ksh93).

Другой вариант cd .использования: когда каталог, в котором вы сейчас находитесь, был удален, а затем снова создан. Попробуйте попробовать следующее -

1. Создать каталог temp
2. cd temp а затем сделать ls
3. Откройте другой терминал и удалите, а затем заново создайте этот каталог temp
4. Вернитесь из первого терминала, попробуйте выполнить команду ls. Это приведет к ошибке -ls: cannot open directory .: Stale file handle
5. cd . а затем делает ls работает нормально

Вы можете $OLDPWDбыстро очистить cd ., если должен быть случай, когда вы не хотите, чтобы это указывало на что-то «интересное». Это также повлияет cd -.

Программно это полезно как неоперативный. Рассмотрим путь, предоставленный внешним вводом.

read -p "Path to file: " p
dirn=$(dirname "$p")
file=$(basename "$p")
echo "dirn=$dirn, file=$file"
cd "$dirn"
ls -ld "$file"

С путем , такими как «fred.txt» каталог будет ., что приведет кcd .

Это часто случается, если вам приходилось работать с плохим USB-кабелем. После того, как устройство будет отключено и снова подключено и автоматически подключено к тому же каталогу, вы должны будете снова использовать cd .его для работы.

Обратите внимание, что "." это правильный способ указать имя файла, который открыт как текущий рабочий каталог любого процесса (включая, конечно, процесс оболочки), и "." всегда является допустимым именем файла во всех без исключения каталогах, включая текущий рабочий каталог. Имя .может не являться допустимым именем для файла для данного экземпляра процесса, если, скажем, текущий текущий рабочий каталог был удален (или стал «плохим», например устаревший дескриптор NFS), но это допустимое имя файла, который гарантированно существует в каждом допустимом каталоге.

Таким образом, . должен быть действительный аргумент для любой команды, которая принимает имя каталога, и, следовательно, в стандартной оболочке cd .должна быть допустимая команда.

Является ли cd .это полезно или нет , зависит от реализации оболочки. Как уже упоминалось, это может быть полезно, если оболочка сбрасывает свое внутреннее представление о полном пути к текущему рабочему каталогу после вызова базового chdirсистемного вызова, например, если базовый каталог (или некоторый его родитель) был переименован.

По крайней мере , некоторые оболочки которых я знаю ( /bin/shна FreeBSD и NetBSD) будет конвертировать cd ""в cd ., который , возможно , может быть описана функцией поддержки программного использования в сценарии оболочки , где переменный может быть использован в качестве параметра (т.е. преобразование пустой подстановки переменной в " «ничего не делать»), хотя история коммитов FreeBSD гласит, что изменение было напрямую связано с добавлением поддержки POSIX для предотвращения сбоя chdir(""), который должен произойти из-за мандатов POSIX.

Некоторые другие оболочки заменят .все, что они сохранили, как полное имя пути к своему текущему рабочему каталогу, и, таким образом, для них это может позволить поведение, упомянутое в ответе Сахила Агарвала .

Я использовал эту команду только сегодня, когда перебазировал ветку, над которой я работал, в Git из каталога, который был сначала создан в этой же ветке. Ребаз прошел нормально но потом git statusвыкинул ошибку. После cd .все было нормально.

(Кстати, я работал в MobaXterm на Windows. На всякий случай, если вы пытаетесь воспроизвести это. Это может не произойти в других системах.)

Я также использовал эту команду в каталогах, которые обновляются автоматическим процессом, который перемещает в сторону старый каталог и заменяет его новым (поэтому он максимально приближен к атомарному). Не обычная ситуация, но cd .это именно то, что нужно.

Прочитав этот отличный ответ от Стефана Шазеля:

• https://unix.stackexchange.com/a/79621/135943

Теперь я понимаю, что приведенные выше варианты использования работают только потому, что я использую bash, что cd .эквивалентно cd "$PWD". Я настоятельно рекомендую прочитать связанный ответ.

Я использую, cd .чтобы перезапустить материал, которым я перегружен cdчерез bashфункцию.

Из моего ~/.bashrc:

# from the "xttitle(1)" man page - put info in window title
update_title()
{
    [[ $TERM = xterm ]] || [[ $TERM = xterm-color ]]  && xttitle "[$$] ${USER}@${HOSTNAME}:$PWD"
}

cd()
{
    [[ -z "$*" ]] && builtin cd $HOME
    [[ -n "$*" ]] && builtin cd "$*"
    update_title
}

РЕДАКТИРОВАТЬ: Это уже было предложено Sahil ранее.

Это полезно, если вы находитесь в папке, которая была удалена и воссоздана другим процессом. Например, предполагая два терминальных сеанса $1и $2:

$1 mkdir d
$1 cd d
$1 touch f

$2 rm -rf /path/to/d # delete the folder where $1 is in ...
$2 mkdir /path/to/d # ... and recreate it

$1 touch g # cannot create file g because current dir doesn't exist anymore
touch: cannot touch ‘g’: Stale file handle
$1 cd . # go to the newly created dir (same path)
$1 touch g # works fine now

Я не уверен, где именно (OS, SHELL, ...?) Коренная причина этого поведения.

Нет, это не имеет смысла. Ни в сценарии, он просто ничего не делает.