Làm thế nào để Linux xử lý nhiều dấu tách đường dẫn liên tiếp (tập tin / home //// tên người dùng ///)?

Tôi đang làm việc với một kịch bản python chuyển các vị trí tệp đến một quy trình con scp. Điều đó không sao, nhưng tôi đang ở trong một tình huống mà cuối cùng tôi có thể nối một đường dẫn với một tên tệp sao cho có một dấu hai ' /trong đường dẫn. Tôi biết rằng bash không quan tâm nếu bạn có nhiều trình phân tách tệp, nhưng tôi tự hỏi làm thế nào chính xác điều đó được khắc phục. Là bash mà dải thêm /s hoặc nó thực sự không quan trọng bao giờ?

Tôi yêu cầu bởi vì nó sẽ tiết kiệm cho tôi một vài dòng mã để kiểm tra thêm /s trong khi nối. Tôi biết đó không phải là một vấn đề lớn, nhưng tôi cũng tò mò. Tôi có một tập lệnh bash có dòng cd //usr(thay vì cd /usr), dường như ngụ ý có thể có một ý nghĩa đối với việc sử dụng nhiều /s trong một đường dẫn

Nhiều dấu gạch chéo được phép và tương đương với một dấu gạch chéo. Từ đặc tả Unix đơn (phiên bản 3) , các định nghĩa cơ sở §3.266 tên đường dẫn : Triệu Nhiều dấu gạch chéo liên tiếp được coi là giống như một dấu gạch chéo.

Có một ngoại lệ: nếu một tên đường dẫn bắt đầu bằng chính xác hai dấu gạch chéo, nó có thể được xử lý khác nhau (ref: định nghĩa cơ sở §4.11 độ phân giải tên đường dẫn ). Bản thân Linux không làm điều này, mặc dù một số ứng dụng có thể và các hệ thống unix-ish khác làm (ví dụ Cygwin).

Một dấu /ở cuối tên đường dẫn buộc tên đường dẫn phải tham chiếu đến một thư mục. Trong ( POSIX định nghĩa 1.003,1-2001 (Single Unix v3) cơ sở giải quyết §4.11 tên đường dẫn , một dấu /tương đương với một dấu /.. POSIX 1.003,1-2008 (Single Unix định nghĩa v4) cơ sở §4.12 loại bỏ các yêu cầu để làm cho nó tương đương với /., để để đối phó với các thư mục không tồn tại (ví dụ: mkdir foo/bắt buộc phải hoạt động, trong khi mkdir foo/.sẽ không - xem cơ sở lý luận cho sự thay đổi).

Đối với các chương trình hoạt động trên một mục nhập thư mục, nếu foolà một liên kết tượng trưng đến một thư mục, thì việc truyền foo/là một cách để làm cho chương trình hoạt động trên thư mục thay vì liên kết tượng trưng.

¹ _{Lưu ý rằng đây áp dụng cho chỉ có độ phân giải tên đường dẫn, tức là khi truy cập vào tập tin. Thao tác tên tệp có thể hoạt động khác nhau. Ví dụ basenamevà dirnamebỏ qua dấu gạch chéo.}

Hệ điều hành dường như cũng không quan tâm đến nó, khi vừa thử một chương trình C với một tòa nhà trực tiếp để mở bằng // trong đường dẫn.

Bạn có thể sử dụng chức năng thư viện python os.path.normpath để bình thường hóa nó, điều này giúp bạn tiết kiệm được việc quét qua chuỗi tìm kiếm các tính năng bổ sung. Các ngôn ngữ khác có chức năng tương tự.

http://docs.python.org/l Library / os.path.html # os.path.normpath

Trên tất cả các hệ thống Unix mà tôi đã thấy nó giống như một /, nhưng tiêu chuẩn Unix chỉ định rằng

Một tên đường dẫn bắt đầu bằng hai dấu gạch chéo liên tiếp có thể được diễn giải theo cách được xác định theo cách thực hiện, mặc dù nhiều hơn hai dấu gạch chéo hàng đầu sẽ được coi là một dấu gạch chéo.

vì vậy nó có thể được xử lý đặc biệt, tùy thuộc vào hệ thống của bạn. (Một số phiên bản Unix cũ hơn đã sử dụng một đầu kép /để truy cập hệ thống tệp từ xa và vẫn có thể có một số phiên bản khác .)

Sử dụng os.path.jointrong Python và bạn sẽ không nhận được nhiều dấu gạch chéo. Tự xây dựng tên tập tin bằng cách nối các chuỗi được coi là kiểu Python kém.

Không có sự khác biệt.

Nhiều dấu gạch chéo bị bỏ qua (không có hiệu lực), ví dụ:

ls -al //usr///////bin/sed

Tất nhiên bạn có thể bình thường hóa một đường dẫn có nhiều / (dấu gạch chéo) có thể trong đó bằng cách chuyển qua tr -s

NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)

... và sau đó sử dụng $NORMALIZED

Tuy nhiên, nó là cần thiết. Như tôi biết, bất kỳ hạt nhân UNIX đúng nào cũng nên bỏ qua các dấu tách đường dẫn đồng thời --- hoặc về mặt khái niệm coi chúng là ... /./...