누셸 방식으로 생각하기

누셸은 다릅니다! 새로운 사용자가 다른 셸이나 언어에서 온 기존의 "습관"이나 정신 모델을 가지고 있는 것은 일반적이며 예상되는 일입니다!

새로운 사용자의 가장 일반적인 질문은 일반적으로 다음 주제 중 하나에 해당합니다.

누셸은 Bash가 아닙니다

때로는 Bash처럼 보일 수 있습니다

누셸은 프로그래밍 언어이자 셸입니다. 이 때문에 파일, 디렉터리, 웹사이트 등을 다루는 고유한 방식이 있습니다. 누셸의 일부 기능은 다른 셸에서 익숙한 기능과 유사하게 작동한다는 것을 알게 될 것입니다. 예를 들어, 파이프라인은 다른 셸과 마찬가지로 두 개 이상의 명령을 함께 결합하여 작동합니다.

예를 들어, 다음 명령줄은 유닉스/리눅스 플랫폼의 Bash와 누셸 모두에서 동일하게 작동합니다.

curl -s https://api.github.com/repos/nushell/nushell/contributors | jq -c '.[] | {login,contributions}'
# => 누셸에 대한 기여자를 기여 횟수 순으로 반환합니다.

누셸은 Bash(및 다른 셸)와 많은 유사점을 가지고 있으며 공통된 명령도 많습니다.

http get https://api.github.com/repos/nushell/nushell/contributors | select login contributions

하지만 Bash는 아닙니다

그러나 이 때문에 Bash(및 일반적으로 POSIX) 스타일 구문 중 일부는 누셸에서 작동하지 않는다는 것을 잊기 쉽습니다. 예를 들어, Bash에서는 다음과 같이 작성하는 것이 일반적입니다.

# >를 사용하여 리디렉션
echo "hello" > output.txt
# 그러나 test 명령을 사용하여 비교(보다 큼)
test 4 -gt 7
echo $?
# => 1

그러나 누셸에서는 >가 비교를 위한 보다 큼 연산자로 사용됩니다. 이것은 현대 프로그래밍 기대치와 더 일치합니다.

4 > 10
# => false

>가 연산자이므로 누셸에서 파일로의 리디렉션은 콘텐츠 저장 전용 파이프라인 명령인 save를 통해 처리됩니다.

"hello" | save output.txt

암시적 반환

다른 셸에서 온 사용자는 echo 명령에 매우 익숙할 것입니다. 누셸의 echo는 처음에는 동일하게 보일 수 있지만 매우 다릅니다.

먼저, 다음 출력이 Bash와 누셸(심지어 PowerShell과 Fish에서도)에서 어떻게 동일하게 보이는지 확인하십시오.

echo "Hello, World"
# => Hello, World

그러나 다른 셸이 Hello, World를 _표준 출력_으로 직접 보내는 반면, 누셸의 echo는 단순히 _값을 반환_합니다. 그런 다음 누셸은 명령 또는 더 기술적으로는 _표현식_의 반환 값을 _렌더링_합니다.

더 중요한 것은 누셸이 표현식의 값을 _암시적으로 반환_한다는 것입니다. 이것은 여러 면에서 PowerShell이나 Rust와 유사합니다.

즉, 문자열 _"Hello, World"_와 echo "Hello, World"의 출력 값은 동일합니다.

"Hello, World" == (echo "Hello, World")
# => true

다음은 사용자 지정 명령 정의가 있는 또 다른 예입니다.

def latest-file [] {
    ls | sort-by modified | last
}

해당 파이프라인의 출력("값")은 latest-file 사용자 지정 명령의 _반환 값_이 됩니다.

표현식당 단일 반환 값

표현식은 단일 값만 반환할 수 있다는 것을 이해하는 것이 중요합니다. 표현식 내에 여러 하위 표현식이 있는 경우 마지막 값만 반환됩니다.

일반적인 실수는 다음과 같은 사용자 지정 명령 정의를 작성하는 것입니다.

def latest-file [] {
    echo "Returning the last file"
    ls | sort-by modified | last
}

latest-file

새로운 사용자는 다음을 기대할 수 있습니다.

• 2행에서 "Returning the last file" 출력
• 3행에서 파일 반환/출력

그러나 echo가 **값을 반환**한다는 것을 기억하십시오. 마지막 값만 반환되므로 2행의 _값_은 버려집니다. 3행에서 파일만 반환됩니다.

첫 번째 줄이 _표시_되도록 하려면 print 명령을 사용하십시오.

def latest-file [] {
    print "Returning last file"
    ls | sort-by modified | last
}

또한 다음을 비교하십시오.

40; 50; 60

40
50
60

echo 40
echo 50
echo 60

위의 모든 경우:

• 첫 번째 값은 정수 40으로 평가되지만 반환되지 않습니다.
• 두 번째 값은 정수 50으로 평가되지만 반환되지 않습니다.
• 세 번째 값은 정수 60으로 평가되며, 마지막 값이므로 반환되어 표시(렌더링)됩니다.

모든 명령은 값을 반환합니다

일부 언어에는 값을 반환하지 않는 "문"이라는 개념이 있습니다. 누셸에는 없습니다.

누셸에서는 **모든 명령이 값을 반환**합니다. 해당 값이 null( nothing 유형)인 경우에도 마찬가지입니다. 다음 여러 줄 표현식을 고려하십시오.

let p = 7
print $p
$p * 6

1. 1행: 정수 7이 $p에 할당되지만 let 명령 자체의 반환 값은 null입니다. 그러나 표현식의 마지막 값이 아니므로 표시되지 않습니다.
2. 2행: print 명령 자체의 반환 값은 null이지만 print 명령은 해당 인수($p, 즉 7)를 _표시_하도록 강제합니다. 1행과 마찬가지로 이것이 표현식의 마지막 값이 아니므로 null 반환 값은 버려집니다.
3. 3행: 정수 값 42로 평가됩니다. 표현식의 마지막 값이므로 이것이 반환 결과이며 표시(렌더링)됩니다.

누셸을 컴파일된 언어로 생각하십시오

누셸에서는 코드를 실행할 때 정확히 두 개의 별도 상위 수준 단계가 있습니다.

1. 1단계(파서): 전체 소스 코드 구문 분석
2. 2단계(엔진): 전체 소스 코드 평가

누셸의 구문 분석 단계를 Rust 또는 C++와 같은 정적 언어의 _컴파일_로 생각하는 것이 유용할 수 있습니다. 즉, 2단계에서 평가될 모든 코드는 구문 분석 단계 중에 **알려지고 사용 가능**해야 합니다.

정적 구문 분석에 기반한 기능

반면에 구문 분석의 정적 결과는 다음과 같은 누셸의 REPL의 많은 기능에 대한 핵심입니다.

• 정확하고 표현력 있는 오류 메시지
• 오류 조건의 조기 및 강력한 감지를 위한 의미 분석
• IDE 통합
• 유형 시스템
• 모듈 시스템
• 완성
• 사용자 지정 명령 인수 구문 분석
• 구문 강조
• 실시간 오류 강조
• 프로파일링 및 디버깅 명령
• (미래) 서식 지정
• (미래) 더 빠른 실행을 위해 "컴파일된" IR(중간 표현) 결과 저장

제한 사항

누셸의 정적 특성은 eval을 사용할 수 있는 언어에서 온 사용자에게 종종 혼란을 야기합니다.

간단한 두 줄 파일을 고려하십시오.

<line1 code>
<line2 code>

1. 구문 분석:
   1. 1행이 구문 분석됩니다.
   2. 2행이 구문 분석됩니다.
2. 구문 분석이 성공하면 평가:
   1. 1행이 평가됩니다.
   2. 2행이 평가됩니다.

이것은 다음 예제가 누셸에서 단일 표현식(예: 스크립트)으로 실행될 수 없는 이유를 설명하는 데 도움이 됩니다.

예제: 동적으로 소스 생성

이 시나리오를 고려하십시오.

"print Hello" | save output.nu
source output.nu
# => Error: nu::parser::sourced_file_not_found
# =>
# =>   × File not found
# =>    ╭─[entry #5:2:8]
# =>  1 │ "print Hello" | save output.nu
# =>  2 │ source output.nu
# =>    ·        ────┬────
# =>    ·            ╰── File not found: output.nu
# =>    ╰────
# =>   help: sourced files need to be available before your script is run

이것은 문제가 있습니다. 왜냐하면:

1. 1행은 구문 분석되지만 평가되지 않습니다. 즉, output.nu는 구문 분석 단계에서는 생성되지 않고 평가 중에만 생성됩니다.
2. 2행이 구문 분석됩니다. source는 파서 키워드이므로 소스 파일의 확인은 구문 분석(1단계) 중에 시도됩니다. 그러나 output.nu는 아직 존재하지도 않습니다! 존재하는 경우에도 올바른 파일이 아닐 수 있습니다! 이로 인해 오류가 발생합니다.

예제: 동적으로 소싱할 파일 이름 만들기

다른 셸에서 올 때 흔히 볼 수 있는 또 다른 시나리오는 소싱될 파일 이름을 동적으로 만들려고 시도하는 것입니다.

let my_path = "~/nushell-files"
source $"($my_path)/common.nu"
# => Error:
# =>   × Error: nu::shell::not_a_constant
# =>   │
# =>   │   × Not a constant.
# =>   │    ╭─[entry #6:2:11]
# =>   │  1 │ let my_path = "~/nushell-files"
# =>   │  2 │ source $"($my_path)/common.nu"
# =>   │    ·           ────┬───
# =>   │    ·               ╰── Value is not a parse-time constant
# =>   │    ╰────
# =>   │   help: Only a subset of expressions are allowed constants during parsing. Try using the 'const' command or typing the value literally.
# =>   │
# =>    ╭─[entry #6:2:8]
# =>  1 │ let my_path = "~/nushell-files"
# =>  2 │ source $"($my_path)/common.nu"
# =>    ·        ───────────┬───────────
# =>    ·                   ╰── Encountered error during parse-time evaluation
# =>    ╰────

let 할당은 평가될 때까지 확인되지 않으므로 파서 키워드 source는 변수가 전달되면 구문 분석 중에 실패합니다.

#include <string>

std::string my_path("foo");
#include <my_path + "/common.h">

let my_path = "foo";
use format!("{}::common", my_path);

const my_path = "~/nushell-files"
source $"($my_path)/common.nu"

예제: 다른 디렉터리로 변경(cd)하고 파일 source하기

하나 더 있습니다. 다른 디렉터리로 변경한 다음 해당 디렉터리에서 파일을 source하려고 시도합니다.

if ('spam/foo.nu' | path exists) {
    cd spam
    source-env foo.nu
}

누셸의 구문 분석/평가 단계에 대해 다룬 내용을 바탕으로 해당 예제의 문제를 찾아보십시오.

    source-env spam/foo.nu

요약

변수는 기본적으로 불변입니다

다른 언어에서 올 때 흔히 놀라는 또 다른 점은 누셸 변수가 기본적으로 불변이라는 것입니다. 누셸에는 선택적 가변 변수가 있지만 누셸의 많은 명령은 불변성을 요구하는 함수형 프로그래밍 스타일을 기반으로 합니다.

불변 변수는 또한 여러 값을 스레드를 사용하여 병렬로 작업할 수 있는 누셸의 par-each 명령의 핵심입니다.

자세한 내용은 불변 변수 및 가변 변수와 불변 변수 중에서 선택을 참조하십시오.

누셸의 환경은 범위가 지정됩니다

누셸은 컴파일된 언어에서 여러 디자인 단서를 가져옵니다. 그러한 단서 중 하나는 언어가 전역 가변 상태를 피해야 한다는 것입니다. 셸은 일반적으로 환경을 업데이트하기 위해 전역 변형을 사용했지만 누셸은 이 접근 방식을 피하려고 합니다.

누셸에서 블록은 자체 환경을 제어합니다. 환경에 대한 변경 사항은 발생하는 블록으로 범위가 지정됩니다.

실제로 이것은 (한 가지 예일 뿐이지만) 하위 디렉터리로 작업하기 위한 더 간결한 코드를 작성할 수 있게 해줍니다. 다음은 현재 디렉터리의 각 하위 프로젝트를 빌드하는 예입니다.

ls | each { |row|
  cd $row.name
  make
}

cd 명령은 PWD 환경 변수를 변경하지만 이 변수 변경은 블록이 끝난 후에도 유지되지 않습니다. 이를 통해 각 반복은 현재 디렉터리에서 시작하여 다음 하위 디렉터리로 들어갈 수 있습니다.

범위가 지정된 환경을 사용하면 명령을 더 예측 가능하고 읽기 쉽게 만들고, 때가 되면 디버깅하기 더 쉬워집니다. 이것은 또한 위에서 논의한 par-each 명령의 핵심 기능이기도 합니다.

누셸은 또한 한 번에 환경에 대한 여러 업데이트를 로드하는 편리한 방법으로 load-env와 같은 도우미 명령을 제공합니다.