kịch bản một lớp

Tôi đã nhận thấy rất nhiều câu hỏi và câu trả lời và bình luận thể hiện thái độ khinh bỉ (và đôi khi thậm chí là sợ) viết kịch bản thay vì một dòng. Vì vậy, tôi muốn biết:

• Khi nào và tại sao tôi nên viết một kịch bản độc lập chứ không phải là "một lớp"? Hoặc ngược lại?

• Các trường hợp sử dụng và ưu và nhược điểm của cả hai là gì?

• Có một số ngôn ngữ (ví dụ awk hoặc perl) phù hợp hơn với một lớp so với các ngôn ngữ khác (ví dụ: python)? Nếu vậy, tại sao?

• Đây chỉ là vấn đề sở thích cá nhân hay có lý do chính đáng (nghĩa là khách quan) để viết cái này hay cái khác trong hoàn cảnh cụ thể? Những lý do đó là gì?

Định nghĩa

• one-liner: bất kỳ chuỗi lệnh nào được gõ hoặc dán trực tiếp vào dòng lệnh shell . Thường liên quan đến đường ống và / hoặc sử dụng ngôn ngữ như sed, awk, perl, và / hoặc các công cụ như grephoặc cuthoặc sort.

  Đó là việc thực hiện trực tiếp trên dòng lệnh là đặc tính xác định - độ dài và định dạng không liên quan. Một "lớp lót" có thể là tất cả trên một dòng hoặc nó có thể có nhiều dòng (ví dụ: sh for loop, hoặc mã awk hoặc mã nhúng, với nguồn cấp dữ liệu và thụt dòng để cải thiện khả năng đọc).

• script: bất kỳ chuỗi lệnh nào trong bất kỳ ngôn ngữ được giải thích nào được lưu vào một tệp và sau đó được thực thi. Một tập lệnh có thể được viết hoàn toàn bằng một ngôn ngữ hoặc nó có thể là một trình bao bọc kịch bản lệnh shell xung quanh nhiều "lớp lót" sử dụng các ngôn ngữ khác.

Tôi có câu trả lời của riêng mình (mà tôi sẽ đăng sau), nhưng tôi muốn điều này trở thành một câu hỏi và trả lời kinh điển về chủ đề này, không chỉ là ý kiến ​​cá nhân của tôi.

Một phản ứng khác dựa trên kinh nghiệm thực tế.

Tôi sẽ sử dụng một lớp lót nếu đó là mã "vứt đi" mà tôi có thể viết thẳng vào dấu nhắc. Ví dụ: tôi có thể sử dụng điều này:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Tôi sẽ sử dụng một tập lệnh nếu tôi quyết định rằng mã đó đáng để lưu. Tại thời điểm này tôi sẽ thêm một mô tả ở đầu tệp, có thể thêm một số kiểm tra lỗi và thậm chí có thể kiểm tra nó vào một kho lưu trữ mã để tạo phiên bản. Ví dụ: nếu tôi quyết định rằng việc kiểm tra thời gian hoạt động của một bộ máy chủ là một chức năng hữu ích mà tôi sẽ sử dụng nhiều lần, thì một lớp lót ở trên có thể được mở rộng sang đây:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Tổng quát hóa, người ta có thể nói

• Lót

  • Mã đơn giản (tức là chỉ một vài câu lệnh), được viết cho mục đích một lần cụ thể
  • Mã có thể được viết nhanh chóng và dễ dàng bất cứ khi nào cần thiết
  • Mã dùng một lần

• Kịch bản

  • Mã sẽ (có thể) được sử dụng nhiều hơn một hoặc hai lần
  • Mã phức tạp đòi hỏi nhiều hơn "một vài" câu lệnh
  • Mã sẽ cần được duy trì bởi những người khác
  • Mã được người khác hiểu
  • Mã được chạy không giám sát (ví dụ: từ cron)

Tôi thấy một số lượng lớn các câu hỏi ở đây trên unix. Tôi yêu cầu một lớp lót để thực hiện một nhiệm vụ cụ thể. Sử dụng các ví dụ của tôi ở trên, tôi nghĩ rằng cái thứ hai dễ hiểu hơn cái thứ nhất, và do đó độc giả có thể học hỏi nhiều hơn từ nó. Một giải pháp có thể dễ dàng bắt nguồn từ giải pháp khác vì vậy vì lợi ích của khả năng đọc (đối với người đọc trong tương lai), có lẽ chúng ta nên tránh cung cấp mã được nén thành một dòng cho bất kỳ giải pháp nào khác ngoài các giải pháp tầm thường nhất.

Viết kịch bản khi:

• cần thêm mã
• bạn coi trọng khả năng đọc
• nó là cần thiết / hữu ích để thêm ý kiến, để hiển thị những gì mã làm
• bạn cần truyền tham số
• bạn muốn tập lệnh chạy trong môi trường riêng của nó (các biến, v.v.)
• bạn có thể sẽ sử dụng lại / điều chỉnh mã cho một số mục đích phức tạp hơn

Viết một lớp lót khi:

• chỉ một lượng nhỏ mã là cần thiết
• bạn muốn truy cập các biến được xác định trong trình bao hiện tại
• bạn cần một giải pháp nhanh chóng và bẩn thỉu

Khi một chuỗi lệnh được yêu cầu khá ngắn và / hoặc tạo ra kết quả có thể sử dụng được như một phần của đường ống lớn hơn hoặc bí danh lệnh, nó có thể là một lớp lót tốt.

Về cơ bản, tôi nghĩ rằng một lớp lót thường là những thứ mà một quản trị viên hệ thống dày dạn quen thuộc với cả vấn đề và các lệnh được sử dụng có thể viết ngay tại chỗ, mà không cần suy nghĩ quá nhiều.

Khi một lớp lót trở nên quá dài hoặc liên quan đến nhiều hơn các điều kiện hoặc vòng lặp rất đơn giản, tốt hơn là viết chúng dưới dạng tập lệnh nhiều dòng hoặc hàm shell, để dễ đọc. Ngoài ra, nếu đó là thứ bạn viết để sử dụng lặp đi lặp lại hoặc thứ gì đó sẽ được người khác sử dụng (và có thể gây rắc rối), bạn nên sẵn sàng dành thời gian để viết giải pháp thành một (rõ ràng), nhận xét, hình thức kịch bản.

Trong Python, thụt lề là một phần của cú pháp, do đó bạn hoàn toàn không thể sử dụng các tính năng của ngôn ngữ trong phạm vi của chúng nếu bạn viết một lớp lót.

Perl và awk one-liners thường là về việc sử dụng sức mạnh thô của các biểu thức thông thường. Nhưng một số người gọi các biểu thức thông thường là Ngôn ngữ chỉ viết, không hoàn toàn không có lý do. Viết một kịch bản nhiều dòng cho phép bạn viết bình luận để mô tả những gì một biểu thức thông thường cụ thể được thực hiện, sẽ rất hữu ích khi bạn xem lại kịch bản, sau khi thực hiện các thao tác khác trong sáu tháng.

Đây thực sự là một câu hỏi dựa trên quan điểm, vì nó liên quan đến việc đo lường mức độ phức tạp có thể chấp nhận được và sự đánh đổi giữa khả năng đọc và tính gọn nhẹ; tất cả những điều này là rất nhiều vấn đề đánh giá cá nhân. Ngay cả việc lựa chọn ngôn ngữ cũng có thể phụ thuộc vào các vấn đề cá nhân: nếu một ngôn ngữ cụ thể về mặt lý thuyết sẽ tối ưu cho một vấn đề cụ thể, nhưng bạn không quen với nó và đã biết cách giải quyết vấn đề với một số ngôn ngữ khác, bạn có thể chọn ngôn ngữ quen thuộc để hoàn thành công việc nhanh chóng và với nỗ lực tối thiểu, mặc dù giải pháp về mặt kỹ thuật có thể hơi kém hiệu quả.

Tốt nhất thường là kẻ thù của đủ tốt , và điều này áp dụng rất nhiều ở đây.

Và nếu bạn đã quen thuộc với Perl, bạn có thể đã nghe nói về TMTOWTDI: Có nhiều cách để làm điều đó.

Xin lưu ý rằng đây là một ý kiến ​​cá nhân; Mang nó theo một hạt muối.

1. Nếu lệnh phù hợp bên trong, giả sử, 80 ký tự, hãy sử dụng một lớp lót. Dòng lệnh dài là khó để làm việc với. Cũng có vấn đề tái phát, xem # 2

2. Nếu bạn cần chạy (các) lệnh nhiều lần, hãy sử dụng tập lệnh. Khác, sử dụng một lớp lót, với điều kiện # 1 được đáp ứng.

3. Điều này rất chủ quan, nhưng vâng, tôi thấy shell, Perl hoặc awk là công cụ tiếp theo của tôi cho một lớp lót.
4. Xem # 1, # 2, # 3.

Tôi xem và sử dụng một lớp lót như một công cụ phát triển tạm thời để chỉnh sửa lặp đi lặp lại cho đến khi nó thực hiện những gì tôi muốn hoặc tôi hiểu làm thế nào một số tinh tế của một lệnh phụ hoạt động.

Sau đó, nó sẽ được ghi chú (và chú thích) trong một tệp văn bản về chủ đề tôi đang nghiên cứu hoặc được làm sạch thành một tập lệnh được đưa vào bin PATH cá nhân của tôi, có thể để sàng lọc thêm, tham số hóa, v.v. Thông thường, một dòng sẽ được chia thành dễ đọc hơn, ngay cả khi không có thay đổi nào khác được thực hiện hoặc tôi không bao giờ sử dụng tập lệnh nữa.

Tôi đặt lịch sử shell của mình là hơn 5000 dòng, với một lịch sử riêng cho mỗi thiết bị đầu cuối và mỗi lần đăng nhập trên một điều khiển từ xa, v.v. Tôi ghét không thể tìm thấy trong các lịch sử này một lệnh một dòng tôi đã phát triển vài tuần trước và không nghĩ rằng tôi sẽ cần một lần nữa, do đó chiến lược của tôi.

Đôi khi, cả một nhóm lệnh cần phải làm một cái gì đó, như cấu hình một số phần cứng; Cuối cùng, tôi sao chép tất cả chúng ra khỏi lịch sử, dọn dẹp chúng tối thiểu và thêm chúng vào tập lệnh shell RUNMEgiống như ghi chú về những gì tôi đã làm, nhưng cũng để chúng gần như sẵn sàng được sử dụng lại bởi người khác. (Đây là lý do tại sao tôi tìm thấy các công cụ chỉ cung cấp GUI để cấu hình chúng một cách đau đớn như vậy.) Tôi thấy đây là một hiệu quả đáng kinh ngạc, vì thường thì một điều gì đó bạn chỉ muốn làm một lần, sau đó phải thực hiện thêm 5 lần nữa .. .

Tôi muốn những người trong nhóm của tôi viết kịch bản cho bất kỳ thao tác nào có thể được yêu cầu thực hiện nhiều lần (nghĩa là "quy trình công việc" hoặc "đường ống") và cho bất kỳ nhiệm vụ một lần nào được yêu cầu phải ghi lại (thông thường những thứ như "sửa đổi một số thứ trong một số tập dữ liệu để sửa dữ liệu được cung cấp không chính xác" trong trường hợp của chúng tôi). Ngoài ra, "một lớp lót" hoặc tập lệnh không quá quan trọng.

Không ghi chép đúng quy trình công việc (dưới dạng tập lệnh hoặc tương đương) khiến việc giới thiệu nhân viên mới trong dự án trở nên khó khăn hơn và cũng khiến việc chuyển mọi người ra khỏi dự án khó khăn hơn. Nó cũng làm cho bất kỳ loại kiểm toán nào trở nên khó khăn và việc theo dõi các lỗi có thể là không thể.

Điều này là bất kể ngôn ngữ nào được sử dụng để lập trình.

Nơi làm việc khác có thể có phong tục hoặc kỳ vọng tương tự / khác nhau, thậm chí có thể được viết ra.

Ở nhà, bạn làm bất cứ điều gì bạn cảm thấy thích.

Ví dụ: tôi viết các tập lệnh ngay khi tôi làm một cái gì đó không tầm thường trong vỏ, như trước khi gửi câu trả lời cho câu hỏi U & L hoặc bất cứ khi nào tôi cần kiểm tra các thành phần riêng lẻ của một lệnh hoặc bộ lệnh trước khi chạy nó " thực".

Tôi cũng viết kịch bản cho các nhiệm vụ lặp đi lặp lại mà tôi thực sự muốn làm theo cách tương tự mọi lúc, ngay cả khi chúng đơn giản, như

• cập nhật hệ thống OpenBSD của tôi và tất cả các gói đã cài đặt (điều này có ba lệnh ngắn và một số lệnh khác để dọn phòng, được thu thập trong một tập lệnh ngắn), hoặc
• sao lưu hệ thống của tôi vào bộ lưu trữ ngoài trang web (về cơ bản là một lệnh duy nhất , nhưng một lần nữa với khá nhiều công việc dọn phòng và tập lệnh cũng cho phép tôi thực hiện các khác biệt giữa các ảnh chụp nhanh, v.v. và nó cần phải hoạt động khác nhau trên các hệ thống khác nhau và Tôi chạy nó từ một công việc định kỳ), hoặc
• tìm nạp thư (một lần nữa, về cơ bản là một lệnh đơn lẻ, nhưng tôi muốn nó hoạt động khác đi khi được gọi là công việc định kỳ và khi tôi sử dụng nó từ dòng lệnh, và nó không nên cố gắng tìm nạp thư trong một số trường hợp và nó viết thông điệp tường trình ngắn vào một tập tin).

Tôi sử dụng chức năng vỏ (rất hiếm khi bí danh) cho thuận tiện trong vỏ tương tác, ví dụ như để thêm tùy chọn để lệnh nhất định theo mặc định ( -Fcho ls) hoặc để tạo biến thể chuyên về một số lệnh ( pmanđây là một manlệnh mà chỉ có vẻ bề ngoài tại hướng dẫn sử dụng POSIX, ví dụ) .

Có vẻ như tôi giữ một quan điểm thiểu số về điều này.

Thuật ngữ "kịch bản" là cố ý gây nhầm lẫn, loại bỏ nó. Đây là phần mềm bạn đang viết ở đó, ngay cả khi bạn chỉ sử dụng bashvà awk.

Trong một nhóm, tôi thích viết phần mềm với quy trình xem xét mã được thi hành bởi một công cụ (github / gitlab / gerrit). Điều này cho phép kiểm soát phiên bản như một phần thưởng. Nếu bạn có nhiều hệ thống, hãy thêm các công cụ triển khai liên tục. Và một số bộ thử nghiệm, nếu các hệ thống mục tiêu là quan trọng. Tôi không tôn giáo về những điều này, nhưng cân nhắc lợi ích và chi phí.

Nếu bạn có một nhóm quản trị viên, đơn giản nhất vim /root/bin/x.shchủ yếu là một thảm họa về giao tiếp liên quan đến thay đổi, khả năng đọc mã và phân phối hệ thống chéo. Thông thường, một trục trặc nghiêm trọng sẽ tốn nhiều thời gian / tiền bạc hơn so với quy trình được cho là "nặng".

Tôi thực sự thích một lớp lót cho bất cứ thứ gì không xứng đáng với quy trình "nặng" đó. Chúng có thể được sử dụng lại nhanh chóng, với một vài lần nhấn phím, nếu bạn biết cách sử dụng lịch sử vỏ của mình một cách hiệu quả; dễ dàng dán giữa các hệ thống không liên quan (ví dụ khách hàng khác nhau).

Sự khác biệt quan trọng giữa (một phần chưa được xem xét!) Và phần mềm được xem xét ("tập lệnh"): trách nhiệm hoàn toàn thuộc về bạn khi bạn thực hiện một lớp lót. Bạn không bao giờ có thể tự nói với mình "Tôi chỉ tìm thấy cái này ở đâu đó, tôi đã chạy nó mà không hiểu, cái gì không phải là lỗi của tôi" - bạn biết rằng bạn đang chạy phần mềm không được xem xét và chưa được kiểm tra, vì vậy đó là lỗi của bạn. Hãy chắc chắn rằng nó đủ nhỏ để bạn có thể thấy trước kết quả - bị nguyền rủa nếu bạn không.

Đôi khi bạn cần cách tiếp cận đơn giản này và đặt thanh ở khoảng một dòng văn bản hoạt động tốt trong thực tế (nghĩa là ranh giới giữa mã được xem xét và mã không được xem xét). Một số lớp lót của tôi trông dài khủng khiếp, nhưng chúng hoạt động hiệu quả với tôi. Miễn là tôi mò mẫm họ và tôi không đưa nó cho nhiều đồng nghiệp cấp dưới, tất cả đều ổn. Thời điểm tôi cần chia sẻ chúng - tôi trải qua quá trình phát triển phần mềm tiêu chuẩn.

Tôi phải nói rằng tôi hơi kinh hoàng bởi những hàm ý của những phần đầu tiên của câu hỏi. Các ngôn ngữ kịch bản Unix là ngôn ngữ lập trình chính thức và ngôn ngữ lập trình là ngôn ngữ , nghĩa là chúng có thể dễ uốn và linh hoạt như ngôn ngữ của con người. Và một trong những đặc điểm nổi bật của "tính linh hoạt và tính linh hoạt vô hạn" là hầu như không bao giờ "một cách đúng" để diễn đạt một cái gì đó - có nhiều cách khác nhau, và đây là một điều tốt! Vì vậy, vâng, tất nhiên đó là vấn đề sở thích cá nhân, và không có gì sai với điều đó. Bất cứ ai nói rằng chỉ có một cách để làm một cái gì đó,

Ngày xửa ngày xưa, riêng tôi ~/bincó đầy những kịch bản nhỏ "hữu ích" tôi đã viết. Nhưng tôi nhận ra rằng hầu hết trong số họ đã sử dụng vào ngày tôi viết chúng, và không bao giờ trở lại. Vì vậy, thời gian càng trôi qua, binthư mục của tôi càng nhỏ .

Tôi không nghĩ có gì sai khi viết kịch bản. Nếu bạn tưởng tượng rằng bạn hoặc người khác có thể sử dụng lại nó, bằng mọi cách, hãy viết một kịch bản. Nếu bạn muốn "thiết kế đúng" một kịch bản có thể hỗ trợ vì lợi ích của nó, bằng mọi cách, hãy làm như vậy. (Ngay cả khi không ai từng sử dụng nó, viết nó là một thực hành tốt.)

Những lý do tôi không viết kịch bản nhiều nữa (và, tôi đoán là ủng hộ "một lớp lót"):

• binthư mục lộn xộn không có một chi phí. Tôi không đặt mọi thứ ở đó nữa trừ khi chúng thực sự thuộc về nơi đó.
• Các ngôn ngữ kịch bản tôi sử dụng là ngôn ngữ mà tôi sử dụng ; Bây giờ tôi thực sự rất thân với họ. Thử lại một lớp lót bất cứ khi nào tôi cần nó không cảm thấy như công việc; Tôi không cảm thấy bắt buộc phải giữ và lưu và sử dụng một tập lệnh chỉ để giảm bớt gánh nặng gõ lại. (Trong số những thứ khác, tại một số điểm, gánh nặng gõ lại trở nên ít hơn gánh nặng bộ nhớ của việc ghi nhớ kịch bản là gì.)
• Một lý do khác để gõ lại những thứ không cảm thấy như một gánh nặng là: lịch sử chỉ huy. Có rất nhiều lớp lót mà tôi không được coi là tập lệnh, mặc dù tôi sử dụng chúng hàng ngày - nhưng tôi không phải gõ lại chúng; Tôi chỉ nhớ lại chúng từ lịch sử. Theo cách đó, chúng là loại kịch bản hoặc bí danh của người nghèo.

Tôi tin rằng hầu hết thời gian yêu cầu "một lót" trên thực tế là một yêu cầu cho "âm thanh cắn", đó là:

Trong bối cảnh báo chí, một âm thanh cắn được đặc trưng bởi một cụm từ hoặc câu ngắn ghi lại bản chất của những gì người nói đang cố gắng nói, và được sử dụng để tóm tắt thông tin ...

Mọi người muốn và yêu cầu mã ngắn nhất thể hiện một giải pháp cho câu hỏi được hỏi.

Đôi khi, không có cách nào để giảm lời nói thành "cắn âm thanh" cũng như có thể không thể giảm kịch bản thành "một đoạn" ngắn. Trong những trường hợp như vậy, câu trả lời duy nhất có thể là một kịch bản.

Và, nói chung, một "âm thanh cắn" không bao giờ là một thay thế tốt cho toàn bộ bài phát biểu. Vì vậy, "một lớp lót" nói chung chỉ tốt để truyền đạt một ý tưởng hoặc đưa ra một ví dụ thực tế về ý tưởng đó. Sau đó, sau khi ý tưởng được hiểu, nó nên được mở rộng (áp dụng) trong một kịch bản.

Vì vậy, hãy viết một "một lớp lót" để truyền đạt một ý tưởng hoặc khái niệm.

Viết mã chung của bạn dưới dạng các tập lệnh đầy đủ không phải là một lớp.

Bạn hỏi về "nỗi sợ và coi thường kịch bản". Điều này là do tình huống Q + A, trong đó thường có câu trả lời: Nó cần bước này và bước này, nhưng tôi cũng có thể đặt nó trong một dòng (vì vậy bạn có thể sao chép dán nó và sử dụng như một lệnh đơn giản dài).

Đôi khi bạn chỉ có thể đoán xem Q được phục vụ tốt hơn bằng giải pháp dán sao chép nhanh và bẩn hay nếu một tập lệnh "đẹp" chính xác là những gì Q cần hiểu.

Rất nhiều ưu và nhược điểm ở đây là đúng, nhưng vẫn còn thiếu điểm. Tôi thậm chí sẽ nói các định nghĩa trong Q không hữu ích.

Các tập tin lịch sử shell là "một liners", nhưng chúng vẫn được lưu. Hàm bash operate-and-get-next (C-o)thậm chí cho phép bạn lặp lại chúng bán tự động.

Tôi hầu như không thấy chức năng từ được đề cập. Đó là cách để lưu trữ cả "tập lệnh" và "một lớp lót". Và với một vài lần nhấn phím, bạn có thể chuyển đổi giữa cả hai định dạng. Một lệnh ghép thường có thể phù hợp với cả hai.

history -r filelà cách để đọc một hoặc nhiều dòng lệnh (và nhận xét) từ bất kỳ tệp nào, không chỉ từ tệp lịch sử mặc định. Nó chỉ mất một số tổ chức tối thiểu. Bạn không nên dựa vào kích thước tệp lịch sử lớn và tìm kiếm lịch sử để truy xuất (một số) phiên bản của dòng lệnh.

Các chức năng nên được xác định theo cách tương tự. Để bắt đầu, hãy đặt thisfunc() {...}một tệp "hàm" trong thư mục nhà của bạn và lấy nguồn đó. Vâng, đây là một số chi phí, nhưng nó là giải pháp chung.

Nếu bạn lưu trữ mọi dòng lệnh và mọi biến thể tập lệnh trong một tệp riêng biệt, thì đó là sự lãng phí (lý thuyết, nhưng khách quan) của các khối hệ thống tệp.

Một lớp lót không có gì nhanh và bẩn. Đó là phần sao chép dán hơi nhíu mày và cách chúng ta chỉ dựa vào lịch sử lệnh để lưu nó cho chúng ta.

@sitaram: một lớp lót của bạn thực sự có các tính năng không phổ biến: dòng shebang, dòng mới, bốn cuộc gọi tiện ích - hai trong số đó là "chương trình" sed. Tôi nghĩ rằng tập lệnh perl ban đầu trông đẹp hơn và chạy nhanh hơn và không lãng phí bất kỳ byte nào bằng cách trải rộng trên 60 dòng. Và perl cũng cho phép bạn bóp khá nhiều.

Đối với tôi, đó chính xác là loại lót cần tránh. Bạn có muốn có (dán) trên dòng lệnh của bạn? Không, và sau đó, nếu bạn lưu trữ nó trong một tệp dù thế nào (bất kể tập lệnh hay hàm), bạn có thể sẽ đầu tư hai hoặc ba byte dòng mới để làm cho nó trông --- đẹp.

10 phút. sau: Tôi chỉ muốn kiểm tra xem tôi có thể nói "hai chương trình sed" hay là "hai thay thế / cuộc gọi sed". Nhưng câu trả lời của sitaram đã biến mất. Trả lời của tôi vẫn có ý nghĩa tôi hy vọng.