Có cd. có dùng không?

Một trong những hướng dẫn tôi đã theo dõi ngắn gọn tuyên bố rằng cd .không có sử dụng. Khi cố gắng sao chép vấn đề được hiển thị bởi OP trong đệ quy liên kết tượng trưng - điều gì làm cho nó thiết lập lại bản thân? , Tôi cũng đã thử cd ., cho thấy hiệu ứng tương tự mà OP mô tả ( $PWDbiến tăng trưởng ), có thể chống lại cd -P.

Điều này khiến tôi tự hỏi, có trường hợp nào người ta thực sự muốn sử dụng cd . không?

Tôi nghĩ rằng điều này là lật đổ vấn đề. cd .có thể không phải là thứ mà người ta sẽ tự chạy theo cách thông thường, nhưng nó chắc chắn là thứ có thể xảy ra khi thực hiện theo chương trình (nghĩ về bất kỳ tình huống nào bạn có thể cdđến thư mục chứa tệp, có đường dẫn được cung cấp bởi người dùng ). Do đó, nó không phải có một số cách sử dụng cụ thể: miễn là nó đáp ứng các ngữ nghĩa thông thường của cd <some-path>nó, nó rất hữu ích.

Đường dẫn của thư mục có thể đã thay đổi kể từ khi lệnh cuối cùng được thực thi và nếu không có cd .bash và ksh93 shell sẽ dựa vào thư mục làm việc logic được mô tả trong bài đăng được liên kết trong câu hỏi, do đó, việc gọi cd .ra vấn đề này getcwd()sẽ tạo ra vỏ sò sẽ đảm bảo đường dẫn hiện tại vẫn còn hiệu lực.

Các bước để sinh sản trong bash:

1. Trong một vấn đề tab thiết bị đầu cuối mkdir ./dir_no_1; cd ./dir_no_1
2. Trong một vấn đề tab thiết bị đầu cuối khác mv dir_no_1 dir_no_2
3. Trong vấn đề đầu cuối tab đầu tiên echo $PWDvà pwd. Lưu ý rằng thư mục đã được đổi tên bên ngoài; môi trường của shell chưa được cập nhật.
4. Vấn đề cd .; pwd; echo $PWD. Thông báo giá trị đã được cập nhật.

ksh93, tuy nhiên, không cập nhật thông tin môi trường, vì vậy cd .trong ksh93 trên thực tế có thể là vô dụng. Trong /bin/dashUbuntu và các hệ thống dựa trên Debian khác, cd .trả về dash: 3: cd: can't cd to .lỗi, tuy nhiên cd -P .hoạt động (không giống như trong ksh93).

Một trường hợp sử dụng khác cd .là khi thư mục bạn hiện đang bị xóa và sau đó được tạo lại. Cân nhắc thử những điều sau -

1. Tạo một thư mục temp
2. cd temp và sau đó làm một ls
3. Mở một thiết bị đầu cuối khác và xóa và sau đó tạo lại thư mục đó temp
4. Quay lại từ thiết bị đầu cuối đầu tiên, hãy thử làm một ls. Điều này sẽ dẫn đến một lỗi -ls: cannot open directory .: Stale file handle
5. cd . và sau đó làm một ls hoạt động tốt

Bạn có thể xóa $OLDPWDnhanh chóng cd ., nếu có trường hợp bạn không muốn nó chỉ ra bất cứ nơi nào "thú vị". Nó cũng sẽ ảnh hưởng cd -.

Về mặt lập trình, nó rất hữu ích khi không hoạt động. Hãy xem xét một đường dẫn được cung cấp từ đầu vào bên ngoài.

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

Với một đường dẫn như "fred.txt", thư mục sẽ trở thành ., dẫn đếncd .

Điều này là phổ biến nếu bạn phải làm việc với cáp USB xấu. Sau khi một thiết bị bị ngắt kết nối và kết nối lại, và tự động kết nối với cùng một thư mục, bạn phải sử dụng cd .để thiết bị hoạt động trở lại.

Lưu ý rằng "." là cách thích hợp để chỉ định tên của tệp được mở dưới dạng thư mục làm việc hiện tại của bất kỳ quy trình nào (bao gồm cả quy trình shell) và "." luôn luôn là một tên hợp lệ của một tập tin trong bất kỳ và tất cả các thư mục, bao gồm cả thư mục làm việc hiện tại. Tên .có thể không phải là tên hợp lệ cho một tệp cho một phiên bản đã cho của một quy trình nếu, giả sử, thư mục làm việc hiện tại nằm bên dưới đã bị xóa (hoặc biến thành "xấu", ví dụ: xử lý NFS cũ), nhưng đó là tên hợp lệ của một tập tin được đảm bảo tồn tại trong mọi thư mục hợp lệ.

Vì vậy, . phải là một đối số hợp lệ cho bất kỳ lệnh nào chấp nhận tên của một thư mục và do đó trong shell tiêu chuẩn cd .phải là một lệnh hợp lệ.

Có cd .hữu ích hay không phụ thuộc vào việc thực hiện shell. Như đã đề cập, nó có thể hữu ích nếu shell đặt lại ý tưởng bên trong của nó về tên đường dẫn đầy đủ của thư mục làm việc hiện tại sau khi gọi lệnh chdirhệ thống cơ bản , ví dụ như nếu thư mục bên dưới (hoặc một số cha mẹ của nó) đã được đổi tên.

Ít nhất một số shell mà tôi biết ( /bin/shtrên FreeBSD và NetBSD) sẽ chuyển đổi cd ""thành cd ., có thể được mô tả là một tính năng để hỗ trợ sử dụng lập trình trong tập lệnh shell trong đó một biến có thể được sử dụng làm tham số (nghĩa là chuyển đổi thay thế biến rỗng thành " không làm gì cả "kết quả), mặc dù lịch sử cam kết FreeBSD nói rằng sự thay đổi là trực tiếp do thêm hỗ trợ POSIX để ngăn chặn sự cố từ chdir("")đó, mà các nhiệm vụ POSIX phải thất bại.

Một số shell khác sẽ thay thế .bằng bất cứ thứ gì chúng đã lưu trữ dưới dạng tên đường dẫn đủ điều kiện vào thư mục làm việc hiện tại của chúng, và do đó, chúng có thể cho phép hành vi được đề cập trong câu trả lời của Sahil Agarwal .

Tôi đã sử dụng lệnh này ngay hôm nay khi tôi khởi động lại nhánh mà tôi đang làm việc trong Git, từ trong một thư mục lần đầu tiên được tạo trên cùng nhánh đó. Cuộc nổi loạn đã diễn ra tốt đẹp nhưng sau đó, git statusđã gây ra lỗi. Sau khi cd .mọi thứ đều bình thường.

(Tôi đang làm việc trong MobaXterm trên Windows, tình cờ. Chỉ trong trường hợp bạn đang cố gắng tái tạo điều này. Nó có thể không xảy ra trên các hệ thống khác.)

Tôi cũng đã sử dụng lệnh này trong các thư mục được làm mới bởi một quy trình tự động chuyển sang một thư mục cũ và thay thế nó bằng một thư mục mới (vì vậy nó càng gần với nguyên tử càng tốt). Không phải là một tình huống phổ biến nhưng cd .chính xác là những gì cần thiết.

Sau khi đọc câu trả lời tuyệt vời này từ Stephane Chazelas:

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

Bây giờ tôi hiểu rằng các trường hợp sử dụng của tôi ở trên chỉ hoạt động vì tôi đang sử dụng bash, trong đó cd .tương đương với cd "$PWD". Tôi rất khuyên bạn nên đọc câu trả lời liên kết.

Tôi sử dụng cd .để chạy lại những thứ tôi đã quá tải cdthông qua một bashchức năng.

Từ tôi ~/.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: Điều này đã được đề xuất bởi Sahil trước đây.

Điều này rất hữu ích nếu bạn đang ở trong một thư mục đã bị xóa và được tạo lại bởi một quy trình khác. Ví dụ: giả sử hai phiên cuối $1và $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

Tôi không chắc liệu chính xác (OS, SHELL, ...?) Nguyên nhân gốc rễ của hành vi này là ở đâu.

Không, nó không có ý nghĩa. Không phải trong kịch bản, nó chỉ không làm gì cả.