Чи cd. є використання?

Один із навчальних посібників, які я дотримувався, коротко заявив, що cd .не має користі. Коли ви намагаєтесь повторити проблему, показану ОП у символічній рекурсії посилання - що робить її “скиданням”? , Я також спробував cd ., який показав той же ефект, що описаний OP (зростаюча $PWDзмінна), з якою можна протистояти cd -P.

Це змушує мене замислитися, чи є випадок, коли хтось насправді хотів би використати cd . ?

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

Шлях до каталогу міг змінитись з часу останньої команди команди, і без cd .оболонок bash та ksh93 буде покладатися на логічний робочий каталог, описаний у публікації, пов’язаній у запитанні, тому виклик, cd .який робить оболонку, видає getcwd()syscall, забезпечить ваш поточний шлях досі діє.

Кроки до відтворення в баші:

1. У випуску вкладки терміналу mkdir ./dir_no_1; cd ./dir_no_1
2. У іншому випуску терміналу mv dir_no_1 dir_no_2
3. У першій випуску вкладки терміналу echo $PWDі pwd. Зауважте, що каталог було перейменовано зовні; середовище оболонки не оновлено.
4. Випуск 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
}

EDIT: Це вже було запропоновано Сахілом .

Це корисно, якщо ви знаходитесь у папці, яку видалили та відтворили іншим процесом. Наприклад, якщо припустити два термінальні сеанси $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, ...?) Першопричина такої поведінки.

Ні, це не має сенсу. Ні в сценаріях, це просто нічого не робить.