Làm cách nào tôi có thể làm cứng các tập lệnh bash chống lại tác hại khi thay đổi trong tương lai?

Vì vậy, tôi đã xóa thư mục nhà của mình (hoặc chính xác hơn là tất cả các tệp tôi có quyền truy cập ghi). Điều gì đã xảy ra là tôi đã có

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

trong một tập lệnh bash và sau khi không còn cần thiết nữa $build, hãy xóa phần khai báo và tất cả các công dụng của nó - nhưng rm. Bash vui vẻ mở rộng ra rm -rf /*. Vâng

Tôi cảm thấy ngu ngốc, cài đặt bản sao lưu, làm lại công việc tôi đã mất. Cố gắng vượt qua sự xấu hổ.

Bây giờ, tôi tự hỏi: các kỹ thuật để viết các tập lệnh bash là gì để những lỗi như vậy không thể xảy ra, hoặc ít nhất là ít có khả năng? Chẳng hạn, tôi đã viết

FileUtils.rm_rf("#{build}/*")

trong một kịch bản Ruby, thông dịch viên sẽ phàn nàn về việc buildkhông được khai báo, vì vậy có ngôn ngữ bảo vệ tôi.

Những gì tôi đã xem xét trong bash, bên cạnh corraling rm(mà, như nhiều câu trả lời trong các câu hỏi liên quan đề cập, không phải là không có vấn đề):

1. rm -rf "./${build}/"*
   Điều đó sẽ giết chết công việc hiện tại của tôi (một repo Git) nhưng không có gì khác.
2. Một biến thể / tham số hóa rmyêu cầu tương tác khi hoạt động bên ngoài thư mục hiện tại. (Không thể tìm thấy bất kỳ.) Hiệu ứng tương tự.

Là nó, hoặc có những cách khác để viết các tập lệnh bash "mạnh mẽ" theo nghĩa này?

set -u

hoặc là

set -o nounset

Điều này sẽ làm cho trình bao hiện tại xử lý việc mở rộng các biến không đặt là lỗi:

$ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

set -uvà set -o nounsetlà các tùy chọn vỏ POSIX .

Một giá trị trống sẽ không gây ra lỗi mặc dù.

Cho rằng, sử dụng

$ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

Việc mở rộng ${variable:?word}sẽ mở rộng thành giá trị variabletrừ khi nó trống hoặc không được đặt. Nếu nó trống hoặc không được đặt, phần tử wordsẽ được hiển thị trên lỗi tiêu chuẩn và trình bao sẽ coi việc mở rộng là một lỗi (lệnh sẽ không được thực thi và nếu chạy trong trình bao không tương tác, điều này sẽ chấm dứt). Rời :khỏi sẽ chỉ gây ra lỗi cho một giá trị chưa được đặt, giống như dưới set -u.

${variable:?word}là một mở rộng tham số POSIX .

Cả hai điều này sẽ khiến một lớp vỏ tương tác chấm dứt trừ khi set -e(hoặc set -o errexit) cũng có hiệu lực. ${variable:?word}làm cho các script thoát ra nếu biến trống hoặc không được đặt. set -usẽ khiến một đoạn script thoát ra nếu được sử dụng cùng với set -e.

Đối với câu hỏi thứ hai của bạn. Không có cách nào để giới hạn rmkhông hoạt động bên ngoài thư mục hiện tại.

Việc triển khai GNU rmcó một --one-file-systemtùy chọn ngăn không cho đệ quy xóa các hệ thống tệp được gắn kết, nhưng nó gần như tôi tin rằng chúng ta có thể nhận được mà không cần thực hiện rmcuộc gọi trong một hàm thực sự kiểm tra các đối số.

Như một lưu ý phụ: ${build}hoàn toàn tương đương với $buildtrừ khi việc mở rộng xảy ra như một phần của chuỗi trong đó ký tự ngay sau là ký tự hợp lệ trong tên biến, chẳng hạn như trong "${build}x".

Tôi sẽ đề nghị kiểm tra xác thực bình thường bằng cách sử dụng test/[ ]

Bạn sẽ an toàn nếu bạn viết kịch bản của mình như vậy:

build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

Các [ -n "${build}" ]kiểm tra đó "${build}"là một chuỗi có độ dài khác không .

Các ||là toán tử logic OR trong bash. Nó khiến một lệnh khác được chạy nếu lệnh đầu tiên thất bại.

Theo cách này, đã ${build}trống / không xác định / vv. tập lệnh sẽ thoát (với mã trả về là 1, đây là lỗi chung).

Điều này cũng sẽ bảo vệ bạn trong trường hợp bạn loại bỏ tất cả các sử dụng ${build}vì [ -n "" ]sẽ luôn sai.

Ưu điểm của việc sử dụng test/ [ ]là có nhiều kiểm tra có ý nghĩa khác mà nó cũng có thể sử dụng.

Ví dụ:

[ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.

Trong trường hợp cụ thể của bạn, trước đây tôi đã làm lại 'xóa' để di chuyển tệp / thư mục (giả sử / tmp nằm trên cùng phân vùng với thư mục của bạn):

# mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

Đằng sau hậu trường, điều này di chuyển các tham chiếu tệp / thư mục toplevel từ nguồn sang $trashdircấu trúc thư mục đích trên cùng một phân vùng và không mất thời gian đi bộ cấu trúc thư mục và giải phóng các khối đĩa trên mỗi tệp ngay lúc đó. Điều này tạo ra việc dọn dẹp nhanh hơn nhiều trong khi hệ thống đang hoạt động, đổi lại việc khởi động lại chậm hơn một chút (/ tmp được làm sạch khi khởi động lại).

Ngoài ra, một mục cron để dọn dẹp định kỳ /tmp/.trash-$USER sẽ giữ / tmp không bị đầy, đối với các quy trình (ví dụ: bản dựng) tiêu tốn nhiều dung lượng đĩa. Nếu thư mục của bạn nằm trên một phân vùng khác là / tmp, bạn có thể tạo một thư mục tương tự / tmp trên phân vùng của mình và thay vào đó là cron dọn dẹp.

Mặc dù vậy, quan trọng nhất, nếu bạn làm hỏng các biến theo bất kỳ cách nào, bạn có thể khôi phục nội dung trước khi dọn dẹp xảy ra.

Sử dụng thay thế paramater bash để gán mặc định khi biến không được khởi tạo, ví dụ:

rm -rf $ {biến: - "/ nonexistent"}

Tôi luôn cố gắng bắt đầu các tập lệnh Bash của mình bằng một dòng #!/bin/bash -ue.

-ecó nghĩa là "thất bại trên e rror đầu tiên ";

-ucó nghĩa là "thất bại trong lần sử dụng đầu tiên của biến u ndeclared".

Tìm thêm chi tiết trong bài viết tuyệt vời Sử dụng Chế độ nghiêm ngặt Bash không chính thức (Trừ khi bạn gỡ lỗi) . Ngoài ra tác giả khuyên bạn nên sử dụng set -o pipefail; IFS=$'\n\t'nhưng với mục đích của tôi thì điều này là quá mức cần thiết.

Lời khuyên chung để kiểm tra xem biến của bạn có được đặt hay không, là một công cụ hữu ích để ngăn chặn loại vấn đề này. Nhưng trong trường hợp này đã có một giải pháp đơn giản hơn.

Rất có thể không cần phải toàn cầu hóa nội dung của $buildthư mục để xóa chúng mà không phải là $buildthư mục thực sự . Vì vậy, nếu bạn bỏ qua phần không liên quan *thì một giá trị unset sẽ biến thành rm -rf /mặc định, hầu hết các triển khai rm trong thập kỷ trước sẽ từ chối thực hiện (trừ khi bạn vô hiệu hóa bảo vệ này với --no-preserve-roottùy chọn của GNU rm ).

Bỏ qua dấu vết /cũng sẽ dẫn đến rm ''thông báo lỗi:

rm: can't remove '': No such file or directory

Điều này hoạt động ngay cả khi lệnh rm của bạn không thực hiện bảo vệ cho /.

Bạn đang suy nghĩ về các thuật ngữ ngôn ngữ lập trình, nhưng bash là một ngôn ngữ kịch bản :-) Vì vậy, hãy sử dụng một mô hình hướng dẫn hoàn toàn khác nhau cho một mô hình ngôn ngữ hoàn toàn khác .

Trong trường hợp này:

rmdir ${build}

Vì rmdirsẽ từ chối xóa một thư mục không trống, trước tiên bạn cần xóa các thành viên. Bạn biết những thành viên đó là gì, phải không? Chúng có thể là các tham số cho tập lệnh của bạn hoặc xuất phát từ một tham số, vì vậy:

rm -rf ${build}/${parameter}
rmdir ${build}

Bây giờ, nếu bạn đặt một số tệp hoặc thư mục khác vào đó như tệp tạm thời hoặc thứ gì đó mà bạn không nên có, rmdirsẽ gây ra lỗi. Xử lý nó đúng cách, sau đó:

rmdir ${build} || build_dir_not_empty "${build}"

Cách suy nghĩ này đã phục vụ tôi rất tốt bởi vì ... vâng, đã ở đó, đã làm điều đó.