Tài nguyên cho lập trình shell di động

Những tài nguyên tồn tại cho lập trình shell di động? Câu trả lời cuối cùng là thử nghiệm trên tất cả các nền tảng được nhắm mục tiêu, nhưng điều đó hiếm khi thực tế.

Đặc tả POSIX / Single UNIX là một sự khởi đầu, nhưng nó không cho bạn biết mức độ hỗ trợ của mỗi triển khai là gì, cũng như các phần mở rộng phổ biến tồn tại. Bạn có thể đọc tài liệu của từng cách thực hiện, nhưng điều đó rất tốn thời gian và không hoàn toàn chính xác.

Tôi dường như với tôi rằng một định dạng lý tưởng sẽ là một loại phiên bản được chú thích bởi cộng đồng của thông số POSIX, trong đó mỗi tính năng được chú thích bởi mức hỗ trợ của nó trong số các triển khai khác nhau. Có một điều như vậy? Hoặc có những tài nguyên hữu ích khác?

_{Ví dụ: có các trang tính di động shell của Sven Mascheck , nhưng đó chỉ là về các yếu tố cú pháp và một vài phần dựng sẵn, và chỉ bao gồm các shell cũ. Tôi đang tìm kiếm một nguồn tài nguyên toàn diện hơn.}

Hướng dẫn autoconf có một phần về lập trình shell di động .

Mặc dù đó không nhắm mục tiêu cụ thể vào POSIX, nhưng đây có lẽ là bộ sưu tập đầy đủ nhất về những việc cần làm và không nên làm khi cố gắng viết mã shell di động.

Ngoài dashvà posh, còn có bournesh(hoặc bsh), Vỏ Bourne gia truyền , có thể được sử dụng để phát hiện Bashism .

Dự án gia truyền cũng bao gồm "Công cụ gia truyền", một bộ sưu tập hơn 100 tiện ích Unix tiêu chuẩn (có thể đóng vai trò là điểm khởi đầu để so sánh các tùy chọn dòng lệnh).

Tương tự như câu trả lời này , hãy thử thực hiện kịch bản của bạn trong posh .

Ngoài ra, đừng quên đặt POSIXLY_CORRECTbiến môi trường thành true, vì điều này khiến nhiều chương trình (không chỉ vỏ) tuân thủ chặt chẽ hơn các tiêu chuẩn POSIX.

Viết kịch bản của bạn bằng cách sử dụng dấu gạch ngang có thể là một sự khởi đầu.

Để mở rộng hơn một chút, bạn có thể thử checkbashismstrong gói Debian / Ubuntu devscripts.

Nó không hoàn hảo, nhưng nó có lợi ích là một điểm khởi đầu hiện có. Ví dụ, nó không thấy các trục trặc cổ điển với sed/ findliên quan đến GNU so với BSD / các khác biệt khác.

Theo mặc định, đó là Debian + dash được định hướng, -pcờ có thể hữu ích trong trường hợp của bạn.

Ngày nay, bạn thường có thể tìm thấy trình bao POSIX trên một hệ thống và do đó, điều đó có nghĩa là bạn có thể viết tập lệnh bằng ngôn ngữ POSIX (modulo chạy theo các lỗi tuân thủ).

Vấn đề duy nhất /bin/shlà đôi khi không phải là vỏ POSIX. Và bạn phải mã hóa #!dòng thành các tập lệnh để hành xử như các tệp thực thi đẹp; bạn không thể yêu cầu người dùng nghiên cứu vấn đề và sau đó gọi tập lệnh của bạn như /path/to/posix/shell myscript.

Vì vậy, mẹo là sử dụng các tính năng POSIX trong tập lệnh của bạn, nhưng làm cho tập lệnh tự động tìm trình bao POSIX. Một cách để làm điều đó là như thế này:

#!/bin/sh

# At this point, we may be running under some old shell
# we have to tread carefully.

# note how we use test rather than [ ] syntax and avoid
# depending on test with no argument producing a failure;
# i.e. "test $posix_shell".

if ! test x$posix_shell = x ; then
  # the three possible shell paths are just an example;
  # please extend as necessary.

  for shell in /usr/xpg4/bin/sh /bin/bash /usr/bin/bash ; do
    if test -x $shell ; then
       posix_shell=$shell
    fi
  done
  if test x$posix_shell = x ; then
    echo "no POSIX shell found"
    exit 1
    # or we could avoid bailing here and just fall back on /bin/sh:
    # echo "falling back on /bin/sh: cross your fingers that it works"
    # posix_shell=/bin/sh
  fi
  export posix_shell

  # plain "$@" is broken in ancient shells! 
  # I seem to recall ${@+"$@"}: not sure if that's the right trick.

  exec $posix_shell $0 ${@+"$@"}  # can we count on exec in legacy shells? 
fi

# phew, at this point in the script we have been re-executed and are
# being interpreted by some reasonably modern shell. We can use $(...)
# command substitution, and other features.

Có những cách tiếp cận khác, chẳng hạn như tạo mã. Tăng cường các tập lệnh của bạn với một tập lệnh nhỏ chứa một tập tin tập lệnh mà không có #! và thêm một dòng.

Điều tồi tệ nhất bạn có thể làm là bắt đầu viết toàn bộ các đoạn script theo cách chúng chạy trên shell Bourne từ năm 1981. Điều này chỉ cần thiết nếu bạn phải viết cho một hệ thống không thực sự không có vỏ nào khác .