왜 쉘 스크립트에 "회사의 미래를 걸지" 말아야 합니까?[닫은]

https://stackoverflow.com/questions/17231

08-06-2019
|

문제

나는보고 있었다 http://tldp.org/LDP/abs/html/why-shell.html 그리고 충격을 받았습니다:

쉘 스크립트를 사용하지 말아야 할 경우

...

회사의 미래를 걸고 있는 미션 크리티컬 애플리케이션

왜 안 돼?

해결책

쉘 스크립트의 장점을 활용할 때는 쉘 스크립트를 사용하는 것이 좋습니다.우리 회사에는 클래스 5 소프트 스위치가 있고 통화 처리 코드와 프로비저닝 인터페이스가 Java로 작성되었습니다.그 밖의 모든 것은 KSH로 작성됩니다. 백업, 정리, 로그 파일 순환 및 모든 자동화된 보고를 위한 DB 덤프입니다.나는 이러한 모든 지원 기능이 비록 호출 경로와 직접적으로 관련되어 있지는 않지만 임무 수행에 매우 중요하다고 주장하고 싶습니다.특히 DB 상호 작용.DB 상호 작용 코드에 문제가 발생하여 통화 라우팅 테이블을 덤프하면 비즈니스가 중단될 수 있습니다.

그러나 쉘 스크립트는 이와 같은 작업에 완벽한 언어이기 때문에 아무 문제도 발생하지 않습니다.크기가 작고 이해하기 쉬우며 파일 조작이 강점이며 안정적입니다.누군가가 바이트 코드로 컴파일해야 한다고 생각하기 때문에 KSH09가 완전히 다시 작성될 것 같지는 않고 안정적인 인터페이스입니다.솔직히 말해서, Java로 작성된 프로비저닝 인터페이스는 꽤 자주 불안정하며 쉘 스크립트는 제가 기억하는 한 한 번도 엉망이 된 적이 없습니다.

다른 팁

나는 기사가 쉘 스크립트를 사용하지 않는 이유에 대한 정말 좋은 목록을 지적하고 있다고 생각합니다. 단일 임무 중요 항목을 사용하면 다른 모든 항목을 기반으로 한 결론에 더 가깝다고 지적합니다.

즉, 쉘 스크립트에서 미션 크리티컬 애플리케이션을 구축하고 싶지 않은 이유는 다른 중요 사항이 적용되지 않더라도 때문이라고 생각합니다. 오늘, 일정 기간 동안 유지 관리될 모든 애플리케이션은 진화하다 어느 시점에서 이러한 잠재적인 함정 중 적어도 하나에 의해 조금씩 문제가 발생할 정도로.....완전히 조치를 취하지 않으면 실제로 할 수 있는 일은 아무것도 없습니다. 수정 사항이 있습니다....처음부터 좀 더 산업적인 힘을 사용했으면 좋겠습니다.

분명히 이것은 내가 쓰러뜨리기에는 약간의 허수아비입니다.나는 사람들이 "임무에 중요한 응용 프로그램"에서 쉘 스크립트를 피해야 한다고 믿는 이유에 정말로 관심이 있지만 설득력 있는 이유는 생각나지 않습니다.

예를 들어, 저는 SQL*Plus를 사용하여 Oracle 데이터베이스와 상호 작용하는 일부 ksh 스크립트를 보고 작성했습니다.안타깝게도 쿼리에서 바인드 변수를 사용하지 않았기 때문에 시스템을 제대로 확장할 수 없었습니다.쉘 스크립트에 대해 한 번 공격해 보세요. 그렇죠?잘못된.문제는 쉘 스크립트가 아니라 SQL*Plus에 있었습니다.실제로 SQL*Plus를 데이터베이스에 연결하고 바인드 변수를 사용하는 Perl 스크립트로 교체하자 성능 문제가 사라졌습니다.

우주선 비행 소프트웨어에 쉘 스크립트를 넣는 것은 나쁜 생각이라고 쉽게 상상할 수 있습니다.그러나 Java나 C++도 마찬가지로 좋지 않은 선택일 수 있습니다.최선의 선택은 해당 목적에 일반적으로 사용되는 언어(어셈블리?)가 무엇이든 것입니다.

사실, Unix를 사용한다면 부팅이 중요하다고 생각하는 중요한 상황에서 쉘 스크립트를 사용하게 됩니다.스크립트가 쉘이 특별히 잘 하지 못하는 일을 해야 할 때, 그 부분을 하위 프로그램에 넣습니다.스크립트를 도매로 버리지 마십시오.

스크립트는 컴퓨터 프로그램 그 이상도 그 이하도 아닙니다.어떤 사람들은 스크립트가 덜 정교하다고 주장합니다.이러한 사람들은 일반적으로 스크립팅 언어로 정교한 코드를 작성할 수 있지만 이러한 스크립트는 실제로 더 이상 스크립트가 아니라 정의에 따라 본격적인 프로그램이라는 점을 인정합니다.

무엇이든.

내 생각에 정답은 "상황에 따라 다르다"이다.그건 그렇고, 이는 미션 크리티컬 애플리케이션을 위해 컴파일된 실행 파일을 신뢰해야 하는지에 대한 반대 질문에 대한 동일한 대답입니다.

좋은 코드는 좋고, 나쁜 코드는 나쁘다 - Bash 스크립트, Windows CMD 파일, Python, Ruby, Perl, Basic, Forth, Ada, Pascal, Common Lisp, Cobol 또는 컴파일된 C로 작성되었는지 여부.

어느 것이 ~ 아니다 언어 선택은 중요하지 않다고 말하는 거죠. 때로는 특정 언어를 선택하거나 컴파일 대 언어를 선택하는 데에는 매우 좋은 이유가 있습니다.해석(성능, 확장성, 기능, 보안 등).그러나 모든 것이 동일하다면 나는 일주일 내내 멍청이가 작성한 동등한 C++ 프로그램보다 훌륭한 프로그래머가 작성한 쉘 스크립트를 신뢰합니다.

아마도 회사를 운영하는 데 도움이 되는 쉘 스크립트일 것입니다. ~ 안으로 미래.나는 프로그래밍 관점에서 쉘 스크립트에 위임한 반복적인 작업을 수행하는 데 많은 시간을 낭비한다는 것을 알고 있습니다.예를 들어, 나는 명령줄에 대한 대부분의 Subversion 명령을 알고 있지만 모든 명령을 하나의 스크립트로 묶을 수 있다면 마음대로 실행할 수 있으므로 시간과 정신 에너지가 절약됩니다.

몇몇 다른 사람들이 말했듯이 언어가 하나의 요소입니다.기억하고 싶지 않은 짧은 단계와 글루 프로그램의 경우 나는 쉘 스크립트를 완전히 신뢰하고 이에 의존합니다.그렇다고 백엔드에서 bash를 실행하는 웹사이트를 구축하겠다는 뜻은 아니지만, 뼈대 프로젝트를 생성하고 패키징 및 배포를 관리하는 데 도움이 되는 bash/ksh/python/무엇이든 반드시 사용할 것입니다.

나는 이 인용문을 읽을 때 "라는 단어에 집중합니다.애플리케이션"미션 크리티컬" 부분이 아닌 "부분"입니다.

나는 bash가 애플리케이션 작성을 위한 것이 아니라 스크립팅을 위한 것이라고 읽었습니다.물론, 귀하의 애플리케이션에 일부 관리 스크립트가 있을 수 있지만 직접 작성하지는 마세요. critical-business-logic.sh 왜냐하면 그런 것에는 다른 언어가 더 나을 것이기 때문입니다.

나는 저자가 고품질 WRT 쉘 스크립팅의 특정 측면에 불편함을 보여주고 있다고 확신합니다.예를 들어 BASH 스크립트를 테스트하는 사람은 누구입니까?

또한 스크립트는 기본 운영 체제와 상당히 밀접하게 결합되어 있어 부정적인 측면이 있을 수 있습니다.

우리 모두는 OS와 상호 작용할 수 있는 유연한 도구가 필요합니다.이는 나사에 드라이버를 사용하는 것과 같이 우리가 사용하는 OS와의 사람이 읽을 수 있는 상호 작용입니다.명령줄은 항상 관리자, 프로그래머 또는 네트워크에 필요한 도구입니다.Powershell에서도 확장된 창을 보세요.

스크립트가 작동하려면 +r 및 +x 권한이 모두 있어야 하기 때문에 특정 업무상 중요한 기능을 구현하는 데는 적합하지 않습니다.실행 파일에는 +x만 있으면 됩니다.

스크립트에 +r이 있다는 사실은 사용자가 스크립트의 복사본을 만들고 편집/파괴하고 편집된 Cuckoo's-Egg 버전을 실행할 수 있음을 의미합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow