Khi nào nên sử dụng Bash và khi nào nên sử dụng Perl / Python / Ruby? [đóng cửa]

Chúng tôi đang thực hiện tất cả các kịch bản của chúng tôi với Bash cho đến nay, nhưng tôi bắt đầu cảm thấy hơi ngớ ngẩn về nó. Mặc dù tất nhiên chúng ta có thể làm mọi thứ chúng ta muốn với Bash (nó khá mạnh mẽ), tôi bắt đầu tự hỏi liệu chúng ta có nên sử dụng ngôn ngữ kịch bản phù hợp hay không (trong trường hợp của chúng ta rất có thể là Ruby).

Làm thế nào để bạn quyết định khi nào sử dụng Perl / Python / Ruby trên Bash cho một tập lệnh? Tôi không nghĩ rằng một tập lệnh init với Ruby có ý nghĩa, nhưng còn một tập lệnh dài hơn một chút có thêm tài khoản email thì sao?

Đưa ra một vấn đề mà cả hai có thể xử lý, bạn sẽ muốn sử dụng một vấn đề mà bạn cảm thấy thoải mái nhất. Cuối cùng, có rất nhiều chi tiết nhỏ, và chỉ có kinh nghiệm mới có thể dạy bạn nhìn thấy chúng.

Bash là một ngôn ngữ kịch bản có mục đích chung giống như Python, Ruby, Perl, nhưng mỗi ngôn ngữ có những điểm mạnh khác nhau so với phần còn lại. Perl xuất sắc trong phân tích văn bản, Python tuyên bố là người thanh lịch nhất trong nhóm, các tập lệnh Bash rất xuất sắc trong "công cụ đường ống xung quanh", nếu bạn hiểu ý tôi là gì, và Ruby ... tốt, Ruby có một chút đặc biệt cách

Tuy nhiên, sự khác biệt giữa chúng chỉ thực sự quan trọng khi bạn có một lượng kinh nghiệm kịch bản lành mạnh trong vành đai của mình. Tôi khuyên bạn nên chọn một ngôn ngữ và đẩy nó đến giới hạn của nó trước khi chuyển sang ngôn ngữ tiếp theo. Bạn có thể làm rất nhiều trong một kịch bản shell, nhiều hơn hầu hết mọi người sẽ thừa nhận. Bất kỳ ngôn ngữ nào cũng khó như bạn muốn làm. Sau khi bạn viết một vài điều trong đó, mọi ngôn ngữ đều "dễ dàng" với bạn.

Làm quen với trình bao trả nhanh chóng nếu bạn sống trong Linux, vì vậy có lẽ bạn muốn bắt đầu với điều đó. Nếu bạn tìm thấy một nhiệm vụ mà bạn không thể hoặc không thực tế để giải quyết trong tập lệnh shell, hãy sử dụng một cái gì đó khác.

Ngoài ra, hãy nhớ rằng học kịch bản shell rất đơn giản. Sức mạnh thực sự của nó nằm ở các chương trình khác, như awk, sed, tr, et al.

TL; DR - sử dụng bash chỉ để cài đặt một ngôn ngữ tốt hơn (nếu nó chưa có sẵn), nếu không bạn đang lãng phí không thể phục hồi, thời gian làm người quý báu. Nếu bạn không thể thực hiện nó trên dòng lệnh bằng tay mà không mắc lỗi, đừng viết kịch bản với bash / shell.

Đó là năm 2015, vì vậy tôi sẽ xem xét những điều sau:

1. bộ nhớ trên

   • Chi phí bộ nhớ thời gian chạy của Ruby / Python so với bash rất nhỏ (vì các thư viện dùng chung), trong khi người ta có thể không duy trì tập lệnh bash không tầm thường (ví dụ: một tập tin có> 100 dòng) - vì vậy việc sử dụng bộ nhớ không phải là một yếu tố

2. Thời gian khởi động

   • Khởi động Ruby / Python có thể chậm hơn một chút, nhưng rất có thể bạn sẽ không chạy nhiều quy trình Ruby / Python đầy đủ trong một vòng lặp chặt chẽ 100 lần mỗi giây (nếu bạn có những nhu cầu đó, bash / shell là quá nhiều chi phí dù sao và có lẽ bạn sẽ cần phải giảm xuống C / C ++)

3. hiệu suất

   • hầu như tất cả các crunching dữ liệu điển hình sẽ nhanh hơn trong Ruby / Python - hoặc ít nhất là có thể so sánh (hoặc, bạn cần C / C ++ / Haskel / OCaml / bất cứ điều gì nào)
   • hiệu năng thực sự / nút cổ chai trong thực thi (hoặc thậm chí năng suất) gần như sẽ không bao giờ là "thiếu sử dụng bash / shell" (ngay cả dấu gạch ngang chuyển đổi Ubuntu để khởi động cho thấy bash thực sự là vấn đề - và một hộp bận rộn có lẽ là trường hợp sử dụng duy nhất , bởi vì có là gì khác hơn là 'bash' và 'vi' để viết và chạy mã, và có thường không có cách nào để thêm / tải hoặc lưu trữ bất cứ điều gì khác)
   • chạy các tiến trình khác để thực hiện công việc (như sed / awk / grep) thực sự chậm hơn so với việc gọi một phương thức trên một đối tượng sống trong bộ nhớ

4. năng suất

   • quá dễ mắc lỗi Bash / shell so với việc sử dụng các phương thức, tham số, biến và ngoại lệ "thực" trong Ruby / Python
   • Agile là chủ đạo, trong khi Bash không hỗ trợ cho nó (thiếu khả năng kiểm tra đơn vị, thư viện, OO, mô đun hóa, linting, introspection, log, metaprograming; gần như không thể tái cấu trúc mà không phá vỡ một cái gì đó)
   • Cách quá nhiều sự không tương thích với các shell khác, các biến môi trường nhỏ có thể phá vỡ hoàn toàn một tập lệnh (và một số công cụ dev-op quan trọng như Puppet bỏ qua các dòng shebang và truyền hoặc viết lại các biến shell quan trọng), trong khi Ruby / Python có sự di chuyển tương đối trơn tru được xác định rõ đường dẫn ngay cả đối với các thay đổi phiên bản chính
   • học một ngôn ngữ mới mất một phần thời gian thay thế để gỡ lỗi các tập lệnh shell do các vấn đề cụ thể về vỏ (đáng chú ý - tên biến, không có booleans, không có ngoại lệ, v.v.)
   • ngay cả các tập lệnh khởi động là một mìn ( đặc biệt là vì chúng có thể bị lỗi trong quá trình khởi động hệ thống ) và với các lỗi bảo mật gần đây với bash, bạn có thể sử dụng C đơn giản (với các thư viện tốt) - vâng, C cần biên dịch, cấu hình, v.v. , nhưng ngay cả một tập lệnh shell đơn giản cũng có thể cần một kho lưu trữ, sau đó tạo phiên bản, sau đó đóng gói.
   • bất cứ thứ gì có sẵn với sed / awk / grep đều có khả năng đã được tích hợp vào Ruby / Python - mà không phải là phụ thuộc hoặc "sự khác biệt" giữa các phiên bản của các công cụ đó trên các nền tảng (vậy nếu nó hoạt động trên thiết lập của bạn )
5. bảo đảm công việc
   • quan điểm của việc đảm bảo một công việc bạn không thích là gì? (trừ khi bạn thích dành tất cả những giờ khó gỡ lỗi nhưng lỗi kịch bản shell để tạo ra)

Tôi thấy không có lý do gì để sử dụng Bash / Shell nếu bạn đã cài đặt Ruby / Python.

Và có lẽ việc cài đặt Ruby / Python thậm chí không cần tập lệnh bash ngay từ đầu (ngoại trừ busybox, một số công cụ hệ thống phụ thuộc vào Python / Perl dù sao cũng có mặt).

Và mỗi khi bạn viết một kịch bản shell, bạn sẽ "thực hành" làm chính xác điều đó - thay vì học một thứ gì đó mạnh mẽ / hiệu quả hơn.

Tại sao ngày nay mọi người sử dụng Bash? Bởi vì đó là một thói quen khủng khiếp, khó phá vỡ. Một kịch bản hiếm khi được "hoàn thành mãi mãi" sau vài phút đầu tiên - bất kể mọi người có xu hướng nghĩ như thế nào. Cùng với sai lầm "đó là lỗi cuối cùng trong kịch bản này".

Kết luận: chỉ sử dụng bash / shell khi bạn hoàn toàn bị ép buộc (như ~/.bashrc, busybox), vì ngày nay nó gần như không bao giờ là "công cụ phù hợp cho công việc".

Tôi sử dụng bash khi trọng tâm chính của tôi là xử lý tệp. Điều này có thể bao gồm di chuyển, sao chép và đổi tên tệp, cũng như sử dụng tệp làm đầu vào cho các chương trình khác hoặc lưu trữ đầu ra của chương trình khác trong tệp. Tôi hiếm khi viết mã bash thực sự kiểm tra nội dung của tệp hoặc tạo đầu ra để ghi vào tệp; Tôi để nó cho các chương trình khác (mà tôi có thể viết bằng Perl hoặc python) mà tôi khởi chạy qua bash.

Tôi sử dụng Perl và python khi trọng tâm chính của tôi là đọc dữ liệu từ các tệp, xử lý dữ liệu theo cách nào đó và ghi đầu ra vào tệp. Nếu tôi thấy mình sử dụng (trong Perl) systemlệnh, đánh dấu lại hoặc (bằng python) subprocessmô-đun quá rộng rãi, tôi xem xét việc viết tập lệnh trong bash. Mặt khác, đôi khi tôi bắt đầu thêm rất nhiều chức năng vào tập lệnh bash mà cuối cùng sẽ có ý nghĩa hơn khi viết lại nó trong Perl / python thay vì xử lý hỗ trợ giới hạn (bằng cách so sánh) của bash cho phạm vi biến, hàm, cấu trúc dữ liệu, v.v. .

Tôi thích các tiêu chí đặt ra trong bài viết trên blog này .

• Nếu không có bất kỳ đối số nào được đưa vào, đó có thể là tập lệnh shell.
• Nếu không có nhiều điều khiển logic (bên cạnh một vòng lặp hoặc nếu / khác) thì đó có thể là tập lệnh shell.
• Nếu tác vụ là tự động hóa các lệnh dòng lệnh thì nó gần như chắc chắn là một tập lệnh shell.

Tôi thấy phân tích Perl so với Bash này hữu ích ...

http://bloss.perl.org/users/buddy_burden/2012/04/perl-vs-shell-scripts.html

Để thuận tiện, tôi đang sao chép tóm tắt về 1) của tác giả đó khi bash là kết quả tốt hơn và 2) khi perl là kết luận tốt hơn ...

Khi Bash tốt hơn ...

• Thất bại trong công việc
• Các lệnh xuất cảnh
• Xử lý dòng đầu ra công việc
• Tài liệu ở đây
• Tương đương tệp
• So sánh dấu thời gian của tệp
• Mở rộng Tilde

Khi Perl tốt hơn ...

Perl vẫn đánh bại các crap ra khỏi bash cho hầu hết các ứng dụng. Những lý do tôi có thể thích Perl bao gồm (nhưng không giới hạn):

• Nó sẽ nhanh hơn. Chủ yếu là vì tôi thực sự không phải bắt đầu các quy trình mới cho nhiều thứ tôi muốn làm (tên cơ sở và dirname là ví dụ rõ ràng nhất, nhưng nói chung cũng có thể loại bỏ, grep, sort và wc).
• Xử lý chuỗi trong bash là thô sơ nhất, và toàn bộ điều $ IFS là siêu clunky.
• Các điều kiện trong các kịch bản shell có thể rất khó khăn.
• Trích dẫn trong các kịch bản shell có thể là một cơn ác mộng.
• tuyên bố trường hợp của bash để lại rất nhiều mong muốn ngoài các trường hợp đơn giản (NPI).
• Mảng trong bash hút. Băm trong bash (giả sử bash của bạn đủ mới để có tất cả) mút thậm chí còn khó hơn.
• Khi xử lý tệp hoặc đầu ra lệnh vượt ra ngoài trường hợp đơn giản mà tôi đã liệt kê ở trên, Perl bắt đầu thực sự hút bash.
• CPAN.

Vì vậy, nó không giống như bash sẽ tiếp quản Perl bất cứ lúc nào sớm. Nhưng tôi vẫn thấy, sau ngần ấy năm, nhiều lần một tập lệnh shell đơn giản đôi khi có thể đơn giản hơn một tập lệnh Perl đơn giản. Như tôi nói, tôi hoan nghênh mọi nỗ lực để thuyết phục tôi bằng cách khác. Nhưng, một lần nữa, không có gì sai khi có một vài công cụ khác nhau trong hộp công cụ của bạn.

Theo kinh nghiệm của tôi bash so với python là sự đánh đổi giữa thời gian phát triển và tính linh hoạt. Một giải pháp thô sơ cho một vấn đề thường có thể được thiết lập trong tập lệnh bash nhanh hơn so với tập lệnh python.

Python sẽ có xu hướng khiến bạn suy nghĩ nhiều hơn về cấu trúc của giải pháp của bạn hơn là tập lệnh bash tương đương. Python có sức mạnh biểu cảm hơn một tập lệnh bash và do đó nó có xu hướng mở rộng và sửa đổi tốt hơn theo thời gian. Nó cũng vẫn dễ đọc hơn nói chung.

Bash gần hơn với hệ thống tệp và có thể là tuyệt vời cho các giải pháp dự thảo đầu tiên cho các vấn đề KHÔNG được xác định rõ. Vì lý do này, một tập lệnh bash có thể là một lựa chọn đầu tiên tốt để tạo nguyên mẫu một cái gì đó với toàn bộ ý định chuyển nó sang python một khi vấn đề được hiểu rõ hơn.

Bash là một vỏ Unix nó bao gồm một ngôn ngữ kịch bản. Nó là bộ xử lý lệnh khá. bạn kiểm soát cách bạn chạy các lệnh, bạn thực sự chạy chúng.

Perl / Ruby / Python là ngôn ngữ có mục đích chung.

Khi bạn muốn một tập lệnh shell, bạn sử dụng Bash

Nếu bạn muốn nhiệm vụ phức tạp hơn hoặc không liên quan đến shell. Sử dụng Python, v.v.

Tôi sẽ không bao giờ so sánh các ngôn ngữ này thực sự. Python v.v ... là xách tay. Bạn có thể chạy chúng ở bất cứ đâu. Bash chỉ dành cho Unix.

Python v.v ... có hàng tấn thư viện có thể tái sử dụng giải quyết hàng triệu nhiệm vụ.

Nó gần như giống nhau nếu bạn hỏi. "Khi nào nên sử dụng Paint và khi nào nên sử dụng Photoshop"

Để xử lý email, tôi sẽ sử dụng lại Ruby, vì nó có rất nhiều thư viện có thể sử dụng lại.

Nhưng cách tốt nhất sẽ là kết hợp bash và ruby. Điều đó sẽ đúng. Giống như bạn tạo một tập lệnh xử lý email trong tập lệnh ruby ​​và bash sẽ gọi tập lệnh ruby ​​đó và chạy các lệnh commans khác.

Vì vậy, bất cứ khi nào bạn cần bộ xử lý lệnh, bạn sử dụng bash. Bạn chạy các lệnh unix và điều khiển chúng.

CẬP NHẬT sau 7 năm (tháng 3 năm 2019)

Trong khi phần chính của câu trả lời của tôi không thay đổi, tôi muốn chỉ ra điều đó.

Bash là một ngôn ngữ kịch bản mạnh mẽ quá. Để xử lý văn bản, nó có thể là một lựa chọn hợp pháp tuyệt đối.

Xin vui lòng đọc ý kiến ​​của mkaito dưới đây. Tất cả đều hoàn toàn đúng.

Các tập lệnh Shell như bash, ksh, zsh, sh và fish nổi tiếng là đáng ngạc nhiên, so với các ngôn ngữ có mục đích chung cấp cao như Ruby, Python hoặc Perl. Mặc dù tập lệnh shell có thể bắt đầu cuộc sống của nó dưới dạng tập tin ngắn hơn tập lệnh mục đích chung tương đương, nhưng điều ngạc nhiên dẫn đến rất nhiều mã gói phòng thủ, chẳng hạn như set -euo pipefailđể bật các chế độ nghiêm ngặt.

Đối với exampmle, hầu hết các ngôn ngữ shell tiếp tục thực thi các dòng trong tập lệnh shell, ngay cả khi một trong các lệnh bị lỗi. Ngược lại, một ngôn ngữ có mục đích chung thất bại ngay lập tức ở lỗi đầu tiên và thường tải, dẫn đến hành vi an toàn hơn, dễ dự đoán hơn trong các tập lệnh có độ phức tạp thậm chí nhẹ.

Bài viết thiên vị cao.

Tôi không thấy bash là quá khó để gỡ lỗi. Python thường quá cứng nhắc, trong khi bash cho phép bạn rất sáng tạo. Nếu bạn là người có tư duy tốt, bạn sẽ thích bash.

Tôi chạy các tập lệnh bash trên hàng triệu trình tự DNA đọc trong hàng ngàn tệp và nó phục vụ tốt cho tôi. Và trái với những gì mọi người nói, các phiên bản tương tự của các tập lệnh trong C ++ không thực sự chạy nhanh hơn nhiều (trong một vài phút tách chúng ra).

Tôi nghĩ bash, như perl, không thân thiện với người dùng / dễ đọc nhất. Điều đó làm mọi người sợ hãi vì hầu hết mọi người không phải là những nhà tư tưởng trừu tượng vĩ đại. Nhưng các lập trình viên sáng tạo hơn, sáng tạo hơn có xu hướng yêu thích nó và sử dụng nó thường xuyên. Nếu bạn biết chính mình và bạn biết bạn có bộ não, đừng sợ hãi vì bash. Nếu bạn là một người suy nghĩ cơ bản, có thể dính vào một cái gì đó như Python. Để mỗi người của họ.

Từ "Sách Llama"

• Randal L. Schwartz, Tom Phoenix và brian d foy, Learning Perl (Sebastopol, CA: O'Reilly, 2011), ch. 1.2 "Perl có nghĩa là gì?" , § § "Tại sao Larry không [người tạo ra Perl] chỉ sử dụng một số ngôn ngữ khác?", Tr. 5:

Perl cố gắng lấp đầy khoảng cách giữa lập trình cấp thấp (chẳng hạn như trong C hoặc C ++ hoặc lắp ráp) và lập trình cấp cao (chẳng hạn như lập trình shell shell [ví dụ, bash]). Lập trình cấp thấp thường khó viết và xấu, nhưng nhanh và không giới hạn; thật khó để vượt qua tốc độ của một chương trình cấp thấp được viết tốt trên một máy nhất định. Và không có nhiều bạn không thể làm ở đó. Lập trình cấp cao, ở một thái cực khác, có xu hướng chậm, khó, xấu và hạn chế; có rất nhiều điều bạn không thể làm với chương trình shell hoặc lập trình nếu không có lệnh nào trên hệ thống của bạn cung cấp chức năng cần thiết. Perl là dễ dàng, gần như không giới hạn, chủ yếu là nhanh chóng và loại xấu xí.

Theo nguyên tắc thông thường, hãy sử dụng ngôn ngữ đơn giản nhất có hiệu suất đủ tốt cho nhiệm vụ của bạn. Và đặc thù của nó chỉ để mở rộng chúng thực sự hữu ích.

Và về khả năng đọc, Bash là khủng khiếp nếu phong cách lập trình của bạn là khủng khiếp. Nếu bạn chỉ cần ném mã ở đó, nó sẽ trở nên tối nghĩa.

Nhưng nếu bạn chia mã thành các hàm ngắn nhất và đặt tên mọi thứ theo cách dễ hiểu, thì đó là ngôn ngữ rõ ràng nhất bạn có thể tìm thấy. Bởi vì nó rất ngắn gọn.

Như mẫu vật, đây là mã mới nhất của tôi ở Bash. Lưu ý cách dễ hiểu và gõ nó là:

#! /bin/bash


mainFunction () {
    file="${1}"

    checkFile "${file}"
    executeFile "${file}"
}


changeToThisProgramDir () {
    cd "$( dirname "${BASH_SOURCE[0]}" )"
}


checkFile () {
    file="${1}"

    checkFileNotEmpty "${file}"
    checkFileExist "${file}"
    checkFileIsExe "${file}"
}


checkFileExist () {
    file="${1}"

    if [ ! -f "${file}" ]; then
        echo "The file doesn't exist: ${file}" >&2
        echo "If the name was correct either type: exeCute \"pathToYourExeFile\""
        echo "Or just open with exeCute from the file manager"
        exit 1
    fi
}


checkFileIsExe () {
    file="${1}"
    mime=$(fileMime "${file}")

    if [ "${mime}" != "application/x-dosexec" ]; then
        echo "Not an exe: ${file}" >&2
        exit 1
    fi
}


checkFileNotEmpty () {
    file="${1}"

    if [ "${file}" == "" ]; then
        echo "No file specified" >&2
        echo "Either type this: exeCute \"pathToYourExeFile\""
        echo "Or just open with exeCute from the file manager"
        exit 1
    fi
}


execute () {
    function="${1}"
    command="${2}"
    error=$(eval "${command}" 2>&1 >"/dev/null")

    if [ ${?} -ne 0 ]; then
        echo "${function}: ${error}" >&2
        exit 1
    fi
}


executeFile () {
    file="${1}"
    type=$(fileType "${file}")

    if [ "${type}" == "MS-DOS executable" ]; then
        execute "executeFile" "dosbox \"${file}\" -forcescaler normal2x -exit -fullscreen"
    else
        execute "executeFile" "wine \"${file}\""
    fi
}


fileMime () {
    file="${1}"

    attributes=$(file --brief --mime "${file}")
    IFS=";" read -r -a attributes <<< "${attributes}"
    echo "${attributes[0]}"
}


fileType () {
    file="${1}"

    attributes=$(file --brief "${file}")
    IFS="," read -r -a attributes <<< "${attributes}"
    echo "${attributes[0]}"
}


changeToThisProgramDir
mainFunction "${@}"