휴대용 쉘 프로그래밍을위한 리소스


65

이식 가능한 쉘 프로그래밍에 어떤 리소스가 있습니까? 궁극적 인 대답은 모든 대상 플랫폼에서 테스트하는 것이지만 거의 실용적이지 않습니다.

POSIX / 단일 UNIX 사양은 시작이지만, 각 구현의 지원 수준이 무엇인지 당신도 알 않으며, 일반적인 무엇을 확장 존재한다. 각 구현에 대한 문서를 읽을 수 있지만 시간이 많이 걸리고 완전히 정확하지는 않습니다.

이상적인 형식은 POSIX 사양의 일종의 커뮤니티 주석 버전이며 각 기능은 다른 구현 중 지원 수준으로 주석이 달린 것 같습니다. 그런 것이 있습니까? 아니면 다른 유용한 자료가 있습니까?

예를 들어, Sven Mascheck의 쉘 이식성 페이지 는 있지만 구문 요소와 내장 기능에 관한 것이며 오래된 쉘만 포함합니다. 더 포괄적 인 리소스를 찾고 있습니다.


2
NB 특정 구현의 적합성 문서를 인용하기 위해 여기에 대답하지 마십시오. 그중 하나가 있다면, 해당 태그 위키가 좋은 장소가 될 것입니다.
Gilles

1
누군가는 autoconfand Metaconfig(Perl, rn)에 대한 개정 이력을 채굴하고 모든 트릭과 설명 주석을 한곳에 수집해야합니다.
geekosaur

@geekosaur : 좋은 제안. 나는 autoconf의 내부를 본 적이 없다. 자신의 스크립트를 작성할 때 가이드로 사용할 수있는 것이 있습니까? 그렇다면 결정적인 질문이 아니더라도 내 질문에 대한 좋은 대답이 될 것입니다.
Gilles

5
두 사람 모두 쉽게 찾을 수 있다고 확신하지만이 스레드를 따르는 다른 사람들의 이익을 위해 autoconf 매뉴얼의 관련 페이지에 대한 링크는 다음과 같습니다 .gnu.org / software / hello /
J. Taylor

답변:


32

autoconf 매뉴얼에는 이식 가능한 쉘 프로그래밍 섹션이 있습니다.

POSIX를 겨냥한 것은 아니지만 이식 가능한 쉘 코드를 작성할 때 수행해야 할 작업과 수행하지 않는 작업 중 가장 완벽한 컬렉션 일 것입니다.


3
그것은 최고의 리소스 중 하나이며 가능한 많은 쉘에서 이식 가능한 쉘 코드를 생성 해야하는 M4로 코드를 작성하는 동안 작성되었습니다.
Tim Post

6

이외에 dash하고 posh, 거기에 bournesh(나 bsh)에 가보 Bourne 쉘 감지하는 데 사용할 수있는 Bashisms을 .

Heirloom 프로젝트에는 100 가지가 넘는 표준 Unix 유틸리티 모음 인 "The Heirloom Toolchest"도 포함되어 있습니다 (이는 명령 줄 옵션을 비교하기위한 시작점으로 사용할 수 있음).


2
Bourne 쉘은 POSIX 쉘이 아니므로 스크립트를 Bourne 쉘로 이식 가능하게 만들면 스크립트의 구문이 표준 POSIX sh 언어에서 그와 Bourne 쉘의 구문 사이의 공통 분모로 다운 그레이드됩니다. 고대 시스템 (또는 Solaris 10 이하에서 / usr / xpg4 / bin에있는 표준 sh를 사용할 수있는 선택권이 없음)을 이식 할 수 없다면 의견의 가치는 없습니다.
Stéphane Chazelas

5

이 답변 과 유사하게 posh 에서 스크립트를 실행하십시오 .

또한 POSIXLY_CORRECT환경 변수를 true 로 설정하는 것을 잊지 마십시오 . 쉘뿐만 아니라 많은 프로그램이 POSIX 표준을보다 엄격하게 준수하기 때문입니다.


4

대시 를 사용하여 스크립트를 작성 하는 것이 시작일 수 있습니다.


3
ksh / bash 기능에 우연히 의존하는 것을 피하기 위해 대시로 테스트하는 것은 최소한이지만, 그 이후에는 다른 쉘 (예 : zsh의 불량한 트랩 처리) 및 쉘 유틸리티 (예 : OpenBSD의 find여전히 결함)에 대한 지식 )을 구현하지 않았습니다 -exec +.
Gilles

FWIW, 오늘날 OpenBSD는 find그렇게 -exec utility {} +합니다.
Kusalananda

2

조금만 확장하면 checkbashisms데비안 / 우분투 devscripts패키지를 사용해 볼 수 있습니다 .

완벽하지는 않지만 기존 시작점이되는 이점이 있습니다. 예를 들어, GNU와 BSD / 다른 차이점에 관한 sed/ find와 관련된 고전적인 결함은 보이지 않습니다 .

기본적으로 데비안 + 대시 중심이며 -p플래그는 귀하의 경우에 유용 할 수 있습니다.


2

오늘날에는 일반적으로 시스템에서 POSIX 셸을 찾을 수 있으므로 일반적으로 POSIX 언어 (규정 준수 버그로 실행되는 모듈)로 스크립트를 작성할 수 있습니다.

유일한 문제점은 /bin/sh때때로 POSIX 쉘이 아니라는 것입니다. 그리고 #!훌륭한 실행 파일처럼 동작하도록 스크립트에 줄을 하드 코딩해야합니다 . 사용자에게 문제를 조사한 다음로 스크립트를 호출하도록 요청할 수는 없습니다 /path/to/posix/shell myscript.

따라서 트릭은 스크립트에서 POSIX 기능을 사용하는 것이지만 스크립트가 POSIX 셸을 자동으로 찾도록합니다. 한 가지 방법은 다음과 같습니다.

#!/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.

코드 생성과 같은 다른 접근 방법이 있습니다. #없이 스크립트 파일의 본문을 취하는 작은 스크립트로 스크립트를 강화하십시오! 한 줄을 추가합니다.

최악의 방법은 1981 년부터 Bourne 쉘에서 실행되는 방식으로 전체 스크립트 작성을 시작하는 것입니다. 실제로 다른 쉘이없는 시스템에 대해 작성해야하는 경우에만 필요합니다. .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.