스크립트 언어(Perl, Python, Ruby 등)가 셸 언어로 적합하지 않은 이유는 무엇입니까?
Bash 등의 셸 언어에는 어떤 차이가 있습니까?bash, Z 쉘 ( )zsh물고기 ( )fish위의 스크립트 언어를 사용하여 셸에 적합하게 할 수 있습니까?
명령줄 사용 시 셸 언어가 훨씬 쉬워 보입니다.예를 들어 IPython에서 셸 프로파일을 사용하는 것보다 bash를 사용하는 것이 훨씬 더 원활하게 느껴집니다.Python에서는 Bash보다 중대형 프로그래밍의 많은 부분이 더 쉽다는 것에 대해서는 대부분 동의할 것이라고 생각합니다.가장 친숙한 언어로 Python을 사용하고 있습니다.Perl과 Ruby도 마찬가지입니다.
이유를 설명하려고 노력했지만, 양쪽에서 현의 취급이 다르다는 것을 전제로 하는 것 이외에는 할 수 없습니다.
이 질문의 이유는 양쪽에서 사용할 수 있는 언어를 개발하고 싶기 때문입니다.그런 언어를 아시는 분들은 올려주세요.
S.Lott의 설명에 따르면, 이 문제는 어느 정도 해명이 필요합니다.셸 언어의 특징과 스크립트 언어의 특징을 묻고 있습니다.따라서 비교는 이력이나 명령줄 치환 등 다양한 인터랙티브(REPL) 환경의 특성에 관한 것이 아닙니다.질문의 다른 표현은 다음과 같습니다.
복잡한 시스템 설계에 적합한 프로그래밍 언어가 파일 시스템에 액세스하거나 작업을 제어할 수 있는 유용한 단일 행을 동시에 표현할 수 있습니까?프로그래밍 언어가 스케일업과 스케일다운을 유용하게 할 수 있을까요?
몇 가지 차이점을 생각할 수 있습니다.여기서는 특별한 순서 없이 생각만 하면 됩니다.
Python & Co.는 스크립트 작성에 능하도록 설계되어 있습니다.Bash & Co.는 스크립트 작성에만 능하고 타협은 전혀 없습니다.IOW: Python은 스크립트 작성과 비스크립트 작성에 모두 적합하도록 설계되었으며, Bash는 스크립트 작성에만 관심이 있습니다.
& 되어 있지 & 는 타이프 있지 에, Bash & Co.라는 .Python & Co.는 타이프 되어 있지 않기 때문에, 그 숫자는 다음과 같습니다.
123, ""123" " " 입니다.123많이 달라요.그러나, 그것들은 정적으로 입력되어 있지 않습니다.그것은, 그것들을 떼어놓기 위해서, 다른 리터럴을 가질 필요가 있다는 것을 의미합니다.
§:| Ruby | Bash ----------------------------------------- number | 123 | 123 string | '123' | 123 regexp | /123/ | 123 file | File.open('123') | 123 file descriptor | IO.open('123') | 123 URI | URI.parse('123') | 123 command | `123` | 123Python & Co.는 10000, 100000, 어쩌면 10000 라인 프로그램까지 확장할 수 있도록 설계되었으며, Bash & Co.는 10 문자 프로그램까지 확장할 수 있도록 설계되어 있습니다.
Bash & Co에서는 파일, 디렉토리, 파일 기술자, 프로세스가 모두 퍼스트 클래스 객체이며 Python에서는 Python 객체만 퍼스트 클래스이므로 파일, 디렉토리 등을 조작하려면 먼저 Python 객체로 랩해야 합니다.
셸 프로그래밍은 기본적으로 데이터 흐름 프로그래밍입니다.조개껍데기를 쓰는 사람조차 잘 모르는데조개껍데기는 꽤 잘 쓰이고 범용 언어는 잘 쓰이지 않는 것으로 나타났습니다.범용 프로그래밍 세계에서 데이터 흐름은 대부분 프로그래밍 패러다임보다는 동시성 모델로 간주됩니다.
기능이나 DSL을 범용 프로그래밍 언어에 포함시킴으로써 이러한 점에 대처하려고 해도 효과가 없는 것 같습니다.적어도, 나는 아직 그것에 대한 설득력 있는 실행을 보지 못했다.Ruby에서 셸을 구현하려는 RuSH(Ruby Shell)가 있고, Ruby에서 셸 프로그래밍을 위한 내부 DSL인 Rush(러시), Python 쉘인 Hotwire가 있지만 IMO는 Bash, Zsh, fish, friends와 경쟁할 만한 것이 없다.
사실 IMHO, 현재 최고의 쉘은 Microsoft PowerShell입니다. 마이크로소프트가 수십 년 동안 계속해서 최악의 쉘을 가지고 있었다는 것을 고려하면 매우 놀라운 일입니다.제 말은.COMMAND.COM정말요? (불행하게도 아직 단말기가 엉망이에요.그 이후로도 "명령 프롬프트"가 계속 이어지고 있습니다.Windows 3.0?)
해 온 것을 (PowerShell 기 、 Microsoft ） 。COMMAND.COM,CMD.EXE, VBScript, JScript를 사용하여 Unix 쉘에서 시작하는 대신 모든 하위 호환성 크러프트(명령어 대체용 백틱 등)를 제거하고 Windows를 보다 쉽게 하기 위해 약간 마사지합니다(Windows의 경로 컴포넌트 구분 문자인 백슬래시 대신 사용되지 않은 백틱을 이스케이프 문자로 사용).후 이 일어날입니다.s) 그 after after after
Python과 비교하여 기본적으로 반대되는 선택을 함으로써 위에서 문제 1과 3에 대처합니다.Python은 큰 프로그램을 먼저 생각하고 스크립팅을 합니다.Bash는 스크립트 작성에만 관심이 있습니다.PowerShell은 스크립트 작성과 대규모 프로그램 작성에 신경을 씁니다.저에게 결정적인 순간은 Jeffrey Snover(PowerShell의 수석 디자이너)와의 인터뷰 영상을 본 것입니다. 인터뷰 진행자가 그에게 PowerShell로 쓸 수 있는 프로그램의 크기를 물었을 때, Snover는 "80자"라고 한 마디도 놓치지 않고 대답했습니다.그 순간, 이 사람이 드디어 셸 프로그래밍을 "구입"한 사람이라는 것을 깨달았습니다(아마 PowerShell이 Microsoft의 프로그래밍 언어 그룹(즉, lambda-calculus math nerds)이나 OS 그룹(커널 너드)에 의해 개발된 것이 아니라 셸과 THA를 실제로 사용하는 서버 그룹(즉, sysadmin)에 의해 개발된 것과 관련이 있을 것입니다).PowerShell에 대해 진지하게 검토해야 할 것 같습니다.
숫자 2는 인수를 정적으로 입력함으로써 해결됩니다.그래서 그냥 쓰시면 됩니다.123또한 PowerShell에서는 cmdlet(PowerShell에서 셸 명령이라고 함)이 해당 인수 유형을 셸에 선언하기 때문에 문자열인지 숫자인지 파일인지도 알 수 있습니다.여기에는 상당한 영향이 있습니다.각 명령어가 자체 인수를 해석하는 UNIX와 달리(기본적으로 셸은 인수를 문자열 배열로 전달합니다), PowerShell의 인수 해석은 셸에 의해 수행됩니다.cmdlet은 모든 옵션, 플래그 및 인수, 셸에 대한 유형 및 이름 및 문서(!)를 지정합니다.이러한 형식에서는 인수 해석, 탭 완료, IntelliSense, 인라인 문서 팝업 등을 한 곳에서 수행할 수 있습니다.(이는 혁신적이지 않으며 PowerShell 설계자들은 디지털 명령어(DCL) 및 IBM OS/400 명령어(CL)와 같은 셸을 선행 기술로 인정하고 있습니다.AS/400을 사용해 본 적이 있는 유저라면, 이것은 친숙하게 들릴 것입니다.OS/400에서는 셸 명령어를 쓸 수 있습니다.특정 인수의 구문을 모르면 생략하고 를 누르면 라벨이 붙은 필드, 드롭다운, 도움말 텍스트 등이 있는 메뉴(HTML 형식과 유사)가 나타납니다.이것이 가능한 것은 OS가 가능한 모든 인수와 그 유형을 알고 있기 때문입니다.)Unix 쉘에서는 이 정보가 3회 복제되는 경우가 많습니다.명령어 자체의 인수 해석 코드에서는bash-completion탭 표시 스크립트 및 manpage에 표시됩니다.
4번 문제는 PowerShell이 파일, 프로세스, 폴더 등을 포함하는 강력한 유형의 개체에서 작동한다는 사실로 해결됩니다.
특히 흥미로운 것은 PowerShell이 제가 아는 유일한 셸이기 때문입니다. PowerShell을 작성한 사람들은 쉘이 본질적으로 데이터 플로우 엔진이라는 사실을 알고 의도적으로 데이터 플로우 엔진으로 구현했습니다.
PowerShell의 또 다른 장점은 명명 규칙입니다. 모든 cmdlet에는 이름이 지정됩니다.Action-Object또, 특정의 액션이나 특정의 오브젝트의 표준화된 이름도 있습니다.(이것도 OS/400 유저에게는 친숙한 것으로 들릴 것입니다.)예를 들어, 어떤 정보를 받는 것과 관련된 모든 것을 불려요.Get-Foo(하위) 오브젝트에서 동작하는 모든 것을 호출됩니다.Bar-ChildItem그럼, 그 대가는ls이Get-ChildItem(단, PowerShell은 빌트인 에일리어스도 제공합니다).ls그리고.dir– 실제로 적절한 경우에는 Unix와CMD.EXE에일리어스 및 약어(gci(이 경우는)를 참조해 주세요).
하지만 IMO의 킬러 기능은 강력한 유형의 객체 파이프라인입니다.PowerShell은 Unix 쉘에서 파생되었지만 매우 중요한 차이점이 하나 있습니다. Unix에서는 모든 통신(파이프와 리디렉션을 통한 통신 및 명령 인수를 통한 통신)은 정형화되지 않은 문자열로 이루어집니다.PowerShell에서는 모두 강력한 유형의 구조화된 객체입니다.왜 아무도 생각해내지 못했는지 정말 궁금할 정도입니다. (그건 생각해봤지만, 인기를 끌지는 못했습니다.)셸 스크립트에서는 명령어 중 최대 3분의 1이 공통 텍스트 형식에 일치하지 않는 다른 두 명령어 간의 어댑터 역할을 하기 위해 존재하는 것으로 추정됩니다.cmdlet이 구조화되지 않은 텍스트 대신 구조화 개체를 교환하기 때문에 이러한 어댑터의 대부분은 PowerShell에서 사라집니다.명령어 내부를 보면 텍스트 입력을 내부 객체 표현으로 해석하고 오브젝트를 조작하여 텍스트로 변환하는 세 단계로 구성됩니다.1단계와 3단계는 기본적으로 사라집니다. 데이터가 이미 개체로 입력되어 있기 때문입니다.
그러나 설계자들은 적응형 시스템이라고 불리는 시스템을 통해 셸 스크립팅의 역동성과 유연성을 보존하기 위해 많은 주의를 기울였습니다.
어쨌든, 저는 이것을 PowerShell 광고로 만들고 싶지 않습니다.PowerShell에는 많은 장점이 있지만 대부분은 Windows 또는 특정 구현과 관련이 있으며 개념과는 관련이 없습니다(예: 에서 구현된 사실).NET은, 을 최초로 기동했을 경우에, 셸을 최초로 기동했을 때에, 최대 몇 초가 걸리는 것을 의미합니다.NET 프레임워크가 필요한 다른 응용 프로그램 때문에 파일 시스템 캐시에 아직 없습니다.셸을 사용하는 시간이 1초 미만인 경우가 많은 것을 고려하면 이는 전혀 받아들일 수 없습니다.)
제가 하고 싶은 가장 중요한 점은 스크립팅 언어와 셸로 된 기존 작업을 보고 싶다면 Unix와 Ruby/Python/Perl/PHP 패밀리에서 그치지 말아야 한다는 것입니다.예를 들어 TCL은 이미 언급되어 있습니다.Rexx는 다른 스크립트 언어입니다.Emacs Lisp는 또 다른 사람이 될 것이다.셸 영역에는 OS/400 명령줄 및 DCL과 같은 이미 언급된 메인프레임/미드레인지 셸이 있습니다.그리고 플랜9의 rc.
문화적이죠.Bourne 쉘은 거의 25년 전의 것으로 최초의 스크립트 언어 중 하나이며 Unix 관리자의 중앙 요구에 대한 최초의 훌륭한 솔루션입니다(즉, 다른 모든 유틸리티를 하나로 묶어 매번 빌어먹을 C 프로그램을 컴파일하지 않고 일반적인 Unix 태스크를 수행할 수 있는 '글루').
현대적 기준으로 볼 때, 그 구문은 형편없고, 이상한 규칙과 문장부호 스타일(모든 바이트가 계산되던 1970년대에 유용)은 비관리자들이 그것을 이해하기 어렵게 만든다.하지만 성공했어그 결함과 단점은 그 뒤에 있는 아이디어를 재인식할 필요 없이 그 후손(ksh, bash, zsh)의 진화적 개선을 통해 해결되었다.관리자가 핵심 구문을 고수하는 이유는 이상하게도 심플한 작업을 방해하는 일 없이 잘 처리할 수 있는 것은 없기 때문입니다.
복잡한 것에 관해서는 Perl이 등장하여 반은 관리자, 반은 애플리케이션 언어로 변형되었습니다.그러나 복잡해질수록 관리 작업이 아닌 애플리케이션으로 인식되기 때문에 비즈니스 담당자는 둘 다 적절한 괴짜라는 사실에도 불구하고 이를 수행하기 위해 "관리자"가 아닌 "프로그래머"를 찾는 경향이 있습니다.그래서 이 점에 초점을 맞추고, Perl의 애플리케이션 기능에 대한 진화적 개선은...Python과 Ruby입니다.(그건 너무 단순하지만 Perl은 두 언어 모두에 영감을 준 몇 가지 언어 중 하나였습니다.)
결과? 전문화.관리자는 현대의 통역 언어가 일상 업무에는 너무 무겁다고 생각하는 경향이 있습니다.그리고 전반적으로, 그들이 옳다.그들은 물건이 필요 없다.데이터 구조에는 관심이 없습니다.그들은 명령어가 필요합니다.접착제가 필요해요.Bourne 쉘의 개념보다 명령어를 더 잘 실행하려고 하는 것은 없습니다(여기서 이미 언급한 TCL을 제외하고). Bourne은 충분히 훌륭합니다.
요즘 점점 더 개발에 대해 배워야 하는 프로그래머들은 본 셸의 한계를 보고 어떻게 누군가가 그것을 견딜 수 있는지 궁금해 한다.그러나 고객이 알고 있는 툴은 확실히 Unix 스타일의 I/O 및 파일 조작에 치우쳐 있지만 목적에 맞는 툴은 아닙니다.백업 스크립트나 파일 이름 변경은 Ruby로 작성했습니다.왜냐하면 저는 bash를 아는 것보다 더 잘 알고 있기 때문입니다.그러나 아마 전문 관리자라면 bash에서도 같은 작업을 할 수 있을 것입니다.아마도 적은 행과 적은 오버헤드로 할 수 있을 것입니다만, 어느 쪽이든 마찬가지로 동작합니다.
"Z가 더 낫는데 왜 다들 Y를 사용하는가?"라고 묻는 것이 일반적이지만 테크놀로지의 진화는 다른 모든 것의 진화와 마찬가지로 충분히 좋은 것으로 멈추는 경향이 있습니다.그 차이를 거래를 깨는 좌절로 보지 않는 한, '더 나은' 솔루션은 승리할 수 없습니다.Bourne 타입의 스크립팅은 당신에게는 짜증날 수 있지만, 그것을 항상 사용하는 사람들과 그것이 의도한 일에 대해서는 항상 효과가 있습니다.
셸 언어는 사용하기 쉬워야 합니다.작은 프로그램이 아닌 일회성 폐기 명령을 입력하려고 합니다.예를 들어, 입력하려는 경우
ls -laR /usr
것은 아니다.
shell.ls("/usr", long=True, all=True, recursive=True)
즉, 셸 언어는 인수가 옵션인지 문자열인지 숫자인지 다른지에 대해 별로 신경 쓰지 않습니다.
또한 셸에 포함된 프로그래밍 구성 요소는 추가 기능이며, 항상 빌트인되는 것은 아닙니다.즉, Bash 또는 Bourne 쉘에서 if와 [의 조합을 고려합니다.sh시퀀스 생성 등을 위한 seq
마지막으로 셸에는 프로그래밍에서 덜 필요하거나 다르게 필요한 특정 요구사항이 있습니다.예를 들어 파이프, 파일 리디렉션, 프로세스/작업 제어 등입니다.
그런 언어를 아시는 분들은 올려주세요.
TCL도 그런 언어 중 하나입니다.주로 CAD 프로그램의 셸 인터프리터가 되도록 설계되어 있기 때문입니다.여기 Tcl이 왜 원래대로 설계되었는지 깨달은 한 하드코어 Python 프로그래머의 경험이 있습니다.Tcl을 칭찬하다니 믿을 수 없습니다.
저는 Tcl 쉘(물론 Tcl로 작성)을 홈브루드 라우터의 Linux 로그인 셸로 사용하고 개선했습니다.순수 Tcl 리드라인
일반적으로 Tcl을 좋아하는 이유 중 일부는 기존 셸과의 구문 유사성과 관련이 있습니다.
기본적으로 TCL 구문은 다음과 같습니다.
command argument argument...다른 건 없어요이것은 Bash, C 쉘 또는 DOS 쉘과 동일합니다.맨말은 문자열로 간주됩니다.이는 기존 셸과 마찬가지로 다음과 같은 내용을 기술할 수 있습니다.
open myfile.txt w+대신open "myfile.txt" "w+".Tcl은 1과 2의 기초이기 때문에 관련 구문이 거의 없습니다.구두점이 적은 코드를 작성합니다.
puts Hello대신printf("Hello");프로그램을 쓸 때는 무엇을 쓸지 고민하는 시간이 많기 때문에 큰 상처를 느끼지 않는다.셸을 사용하여 파일을 복사할 때 단순히 입력만 하고 입력할 필요는 없다고 생각합니다.(그리고."그리고.,그리고.)그리고.;몇 번이고 몇 번이고 금방 짜증나죠.
*주의: 저는 하드코어 TCL 프로그래머입니다.
누가 아니라고 하던가요?를 참조하십시오.모든 명령어가 구문적으로 정확해야 하며 프로그램 실행이 다음에서 끝나기 때문에 Reples(Read Eval Print Loops)는 crappy 쉘을 참조하십시오.
foo arg1 arg2 arg3
로.
system "foo", "arg1", "arg2", "arg3"
그리고 리다이렉트 할 생각도 하지 마세요.
따라서 명령어와 리다이렉트, 명령어를 함께 바인드하기 위해 사용하는 언어를 이해하는 커스텀셸(REP가 아닌)이 필요합니다.생각합니다zoid(Zoidberg 껍데기)가 꽤 잘합니다.
이러한 답변은 제가 Perl 기반의 Shell Zoidberg의 유지보수를 맡도록 영감을 주었습니다.몇 가지 수정 후 다시 사용할 수 있습니다!
유저즈 가이드를 참조하거나, 마음에 드는 CPAN 클라이언트를 사용해 인스톨 합니다.
아니요.
아니요, 스크립트 언어는 셸에 적합하지 않을 수 있습니다.
문제는 거시 언어와 다른 모든 것 사이의 이분법이다.
셸은 nroff 및 m4와 같은 다른 레거시 매크로 언어와의 범주에 있습니다.이러한 프로세서에서는 모든 것이 문자열이며 프로세서는 입력 문자열에서 출력 문자열로의 매핑을 정의합니다.
어떤 경계는 모든 언어에서 양방향으로 교차되지만, 일반적으로 시스템의 범주가 매크로인지, 아니면 음, 공식적인 용어가 무엇인지 잘 알지 못합니다.'진짜 언어'라고 하겠습니다.
Ruby와 같은 언어로 모든 명령어를 입력할 수 있습니다.또한 실제 셸에 비해 차선책일 수도 있지만 매크로 언어는 아닙니다.존중해야 할 구문이 너무 많다.인용문이 너무 많아요.
그러나 매크로 언어는 프로그래밍을 시작할 때 그 자체의 문제가 있습니다. 왜냐하면 너무 많은 타협이 필요했기 때문입니다.문자열은 따옴표 없이 입력됩니다.누락된 구문을 주입하려면 다양한 양의 마법을 다시 도입해야 합니다.그냥 좀 달라지려고 한 번 해봤어요.그것은 꽤 이상했다.매크로 언어의 대규모 구현의 소스 코드는 무섭습니다.
둘 다 정식 프로그래밍 언어이기 때문에 한쪽에서 할 수 있는 것은 다른 쪽에서도 할 수 있습니다.사실 이것은 디자인에 중점을 둔 문제입니다.셸 언어는 인터랙티브하게 사용하도록 설계되어 있지만 스크립트 언어는 그렇지 않습니다.
설계의 기본적인 차이는 명령과 변수의 범위 간의 데이터 저장입니다.Bash 등에서는 값을 저장하기 위해 홉을 건너뛰어야 합니다(예를 들어 다음과 같은 명령).set a='something'Python과 같은 언어에서는 단순히 assignment 스테이트먼트( )를 사용합니다.a = 'something'셸 언어에서 값을 사용할 경우 변수 값을 원하는 언어를 지정해야 합니다.스크립트 언어에서는 문자열의 즉시 값을 원하는 언어를 지정해야 합니다.이것은 대화식으로 사용할 때 효과가 있습니다.
에서는, 「」는 다음과 같습니다.ls되었습니다.
a = some_value
ls a*b
을 하는가)a★★★★★★★★★★★★★★★★★? "some_value * (b)" "some_value * (b)" "some_value" 。a'anystring'b는요?스크립트 언어에서는 디폴트는의 메모리에 격납되어 있습니다.
ls 'a*b' Now means what the Unix ls a*b means.
바쉬어 같은 말투로
set a=some_value
ls a*b means what the Unix ls a*b means.
ls $a*b uses an explicit recall of the value of a.
스크립트 언어를 사용하면 값을 쉽게 저장 및 호출할 수 있으며 값에 대한 일시적인 범위를 갖기 어렵습니다.셸 언어를 사용하면 값을 저장 및 호출할 수 있지만 명령별로 3가지로 일시적인 스코프가 있습니다.
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★로 통상적인 됩니다.$ xxxcommand는 실행할 명령어를 의미합니다.Python과 Ruby에서는 system("command") 등을 수행해야 합니다.
그들이 적합하지 않다는 것이 아니라, 단지 아무도 아직 그렇게 하지 않았다는 것이다. 적어도 나는 그렇게 생각한다.Rush는 Ruby의 예시이며, Python은 IPython 같은 것을 가지고 있습니다.
당신이 질문을 하세요.모든 사람이 셸 언어가 우월하다는 것에 동의하는 것은 아니다.하나는, _왜 안 되는가?
얼마 전 친구가 PHP 스크립트를 재귀적으로 검색하여 문자열을 찾는 방법을 물었습니다.그 디렉토리에는 큰 바이너리 파일과 템플릿이 많이 들어있었기 때문에 보통 GREP에 빠질 수도 있었습니다.GREP를 사용하는 방법이 생각나지 않아 Find와 GREP를 함께 사용하는 것이 최선이라고 생각했습니다.
find . -name "*.php" -exec grep 'search_string' {} \; -print다음은 Ruby에서 재작업한 위의 파일 검색입니다.
Dir['**/*.php'].each do |path| File.open( path ) do |f| f.grep( /search_string/ ) do |line| puts path, ':', line end end end당신의 첫 반응은 "글쎄요, 원래보다 꽤 말이 많네요."일 것이다.그리고 난 그냥 어깨를 으쓱하고 그냥 내버려 둬야 해."연장이 훨씬 더 쉽습니다."라고 저는 말합니다.플랫폼 전체에서 동작합니다.
확장성과 확장성Common Lisp(CLISP 및 기타 구현을 Unix 환경에서 로그인 셸로 실행할 수도 있습니다).
Windows 사용자의 경우 JP Software의 4NT(지금은 Take Command Console)를 사용하고 있기 때문에 PowerShell의 필요성을 느끼지 못했습니다.이것은 프로그래밍 능력이 풍부한 매우 좋은 껍데기입니다.그래서 이 두 세계의 장점을 결합한 것입니다.
예를 들어 IRB(Ruby Interpreter)를 살펴보면, 더 많은 한 줄로 확장하여 매일 스크립트 파일 관리 또는 대량 파일 관리 및 세부적인 작업을 수행할 수 있어야 합니다.
언급URL : https://stackoverflow.com/questions/3637668/why-are-scripting-languages-e-g-perl-python-and-ruby-not-suitable-as-shell
'programing' 카테고리의 다른 글
| MySQL 문자열에서 영숫자가 아닌 모든 문자를 제거하려면 어떻게 해야 합니까? (0) | 2023.01.21 |
|---|---|
| PHP | define() vs. const. (0) | 2023.01.21 |
| 마리아답:WHERE 절에서 창 함수 LAG 결과 사용 (0) | 2023.01.15 |
| PHP에서 닫힘...정확히 무엇을 언제 사용할 필요가 있는가? (0) | 2023.01.15 |
| 줄을 서야 한다." 결과 UnicodeDecodeError: 'utf-8' 코덱이 바이트를 디코딩할 수 없습니다. (0) | 2023.01.15 |