\x1e를 표현할 방법이 없다는 걱정입니까? 아니면 아키텍처 개선에 대해 생각하고 있습니까?

배열 구분자는 주로 범용 변수나 환경 변수와 같이 문자열만 취하는 위치에 배열을 유지하는 데 사용된다고 생각합니다.

2012-12-12 上午2:09, "ridiculousfish" 알림@github.com에 위치 :

\x1e를 표현할 방법이 없다는 걱정입니까? 아니면 생각하고 있습니까?
아키텍처 개선에 대해?

나는 두 가지 측면을 모두 염두에 두고 있다고 말하고 싶다. 전자의 경우 다음을 생각하십시오.
\x1e가 포함된 파일 이름. POSIX는 \0 이외의 것은 허용된다고 말합니다.
파일 이름이므로 완벽하게 가능합니다. \0을 배열 구분 기호로 사용하면
약간 더 나은 선택이지만 이는 두 번째 문제로 이어집니다.
연약하고 명백하게 잘못되었습니다.

배열 구분 기호는 주로 배열을 제자리에 유지하는 데 사용된다고 생각합니다.
범용 변수 또는 환경 변수와 같은 문자열만 사용합니다.

지속이 "직렬화"를 의미하는 경우 아니요. 배열은 항상 다음 위치에 저장됩니다.
\x1e로 구분된 형식입니다. 내보낸 환경 배열은 ":"로 결합됩니다. 그들
그러나 IMHO를 구현해야 하는 범용 변수에 사용됩니다.
대신 적절한 탈출로.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

개인용 영역 문자를 구분 기호로 사용하는 것은 어떻습니까? 물고기는 이미 어떤 경우에는 그 중 일부를 사용합니다.

@JanKanis 더 좋지 않습니다. 파일 이름(비 utf8, 기본 인코딩을 사용하는 파일 시스템 고려) 및 기타 문자열에서 완벽하게 가능합니다.

나는 무엇보다도 "\0" 가 _약간_ 더 나은 선택이라고 말하고 싶습니다. UNIX가 파일 이름에서 금지하는 유일한 문자이기 때문입니다. 그러나 여전히 나에게 나쁜 냄새가 납니다. 또한 우리는 이미 배열의 많은 분할 및 조합을 수행하고 있으므로 실제 배열을 구현하면 아키텍처가 개선되고 코드가 줄어들 것으로 기대합니다.

Fish는 외부 문자열을 wchar로 인코딩할 때 이미 개인용 문자와 유효하지 않은 바이트를 처리합니다. 이러한 특수 값은 물고기가 출력 시 다시 디코딩하는 특정 개인용 문자 집합으로 바이트 단위로 인코딩되므로 원칙적으로 다른 개인용 문자를 사용하는 것이 작동할 수 있습니다. 그러나 실제 배열을 사용하는 것이 훨씬 낫다는 데 동의합니다. fish와 fishd 사이의 통신이 utf8 문자열을 사용하는 소켓을 통해 발생하고 fish가 배열 항목을 분리하기 위해 이스케이프 시퀀스 "\x1e"(0x1e 바이트가 아닌)를 사용한다는 점에서 한 가지 복잡한 문제가 있습니다. 그러나 예를 들어 개인용 사용되지 않은 이스케이프 시퀀스를 사용하여 해결할 수 있습니다.

나는 xiaq의 우려를 공유하지만 (실제적인 것의 경우) 암묵적인 분할이 \n 훨씬 더 공격적이라는 것을 알았습니다.

a<strong i="6">@raspeball</strong> ~> count (printf 'a\x1eb')
1
a<strong i="7">@raspeball</strong> ~> count (printf 'a\nb')
2

하위 프로세스 출력의 (개행으로 구분된) 배열 해석은 명시적이고 선택 사항이어야 합니다!

그러나 그것은 아마도 어레이의 기본 스토리지와 아무 관련이 없을 것입니다…

@xiaq : \0 을(를) 사용하는 데 어떤 문제가 있습니까? xargs 는 그것을 "신뢰할 수 있는" 옵션으로 사용하는 것 같습니다.

환경 변수에 \0 를 사용할 수 없으므로 배열을 자식 셸로 내보내기가 어렵습니다.

저는 이 시퀀스를 사용하여 "연결된" 변수 기능을 활용하여 정상적인 방식으로 $LESS env var를 정의하는 zsh에서 마이그레이션하고 있습니다.

typeset -xT LESS less ' '
less=(
    --HILITE-UNREAD
    --LONG-PROMPT
)

간결함을 위해 전체 옵션 목록을 생략했습니다. zsh에서 $LESS env var는 $less 배열에 있는 옵션의 공백으로 구분된 목록이 됩니다. 물고기에 해당하는 항목은 레코드 구분 기호(\x1e) 문자로 요소를 구분합니다. 배열의 요소가 공백으로 구분된다는 문서에도 불구하고(PATH와 같은 특수 배열을 모듈로). 예상 결과를 얻으려면 값을 단일 문자열로 보간하는 할당을 명시적으로 수행해야 합니다.

set -x LESS --HILITE-UNREAD \
    --LONG-PROMPT
set LESS "$LESS"

현재로서는 \x1e가 \x00이 아닌 배열을 직렬화하는 데 내부적으로 사용되는지 여부는 별로 신경 쓰지 않습니다. 내보낸 배열의 요소가 \x1e로 구분되어 있다는 점에 유의합니다. 그건 그냥 고장났어, 잘못됐어, fubar. 형용사를 선택하세요. 또한 앞서 언급한 해결 방법 및 문서화된 동작과도 일치하지 않습니다. 이 문제는 버그 IMHO로 태그가 지정되어야 합니다.

추신, 문서의 어디에도 언급된 레코드 구분 문자(\x1e)의 사용이 없습니다. 또 다른 문제입니다.

@krader1961 공유해주셔서 감사합니다. 목록과 같은 환경 변수에 대한 표준 Unix 규칙은 없습니다. 일부는 콜론으로 구분되고 나머지는 공백으로 구분됩니다. 물고기는 자체 배열을 구별할 수 있도록 \x1e를 사용합니다.

잘못된 문서를 지적해 주시겠습니까?

콜론, 공백, 줄 바꿈 등의 배열을 어떻게 내보낼 수 있습니까? 물고기는 이 캐릭터의 환경 변수도 토큰화해야 합니까?

공백으로 구분된 인수가 덜 예상되는 것 같습니다. 아마도 가장 간단한 해결 방법은 set -x LESS '--HILITE-UNREAD --LONG-PROMPT' 등입니다.

환경 변수와 같은 목록에 대한 표준은 없습니다. 정의에 따라 등호로 구분되고 null 바이트로 끝나는 키와 값으로 구성된 임의의 바이트 시퀀스이기 때문입니다. 인쇄 가능한 문자일 필요도 없습니다. 더 높은 수준의 추상화에 대해 널리 인정되는 유일한 규칙은 PATH 환경 변수에 대한 execlp() 함수에 의해 설정된 것입니다.

둘 이상의 요소가 있는 var를 내보낼 때 배열의 요소를 구분하기 위해 \x1E, \036, 30 또는 "레코드 구분 기호" 문자를 사용하는 것에 대한 언급이 없는 한 문서는 잘못된 것입니다. 문서에는 다음과 같이 나와 있습니다.

..., and array variables will be concatenated using the space character.

http://fishshell.com/docs/current/index.html의 "변수 확장" 섹션에서 가져온 것입니다. 동일한 문서의 "배열" 및 "특수 변수" 섹션에 설명된 대로 특수 사례가 아닌 내보낸 변수에도 해당 명령문이 적용된다고 추론하는 것이 합리적입니다.

물고기가 자동으로 env 변수를 PATH와 같은 콜론으로 구분된 특수 케이스 변수 외부의 목록으로 토큰화해서는 안 된다고 생각합니다. 그러나 사용자가 var를 임의의 문자에 대한 배열로 토큰화할 수 있는 강력한 수단이 있어야 합니다.

var 기반으로 var에 사용할 문자를 구성하는 메커니즘이 없으면(zsh "typeset -T" 명령) 배열의 요소를 연결할 때 공백을 사용해야 합니다(다시 콜론으로 구분된 특수 케이스 var 제외 ). 분명히 이것은 범용 변수의 저장과 같은 개인 데이터 저장소에는 적용되지 않습니다.

마지막으로 env var가 하나 이상의 요소를 포함하는 배열을 다른 함수나 스크립트에 전달하는 데 사용되는 표준 물고기 함수에서 용도를 찾지 못했습니다. 이러한 사용 사례가 있을 수 있지만 문자열에 레코드 구분 문자가 포함된 var에서 배열을 암시적으로 재구성하기 위해 물고기에 의존하기 보다는 스크립트가 데이터의 직렬화/역직렬화에 명시적으로 협력해야 합니다.

사려 깊은 답변에 감사드립니다. 공백을 사용한 연결에 대해 인용한 섹션은 특히 큰따옴표로 묶인 문자열을 위한 것입니다. 내보낸 배열에 어떤 일이 발생하는지에 대한 논의를 추가해야 합니다.

사용자는 set SOMEPATH (string split : $SOMEPATH) 와 같이 문자열을 토큰화할 수 있습니다.

공간 연결 내보낸 변수의 단점은 물고기가 재귀적으로 실행될 때 변경된다는 것입니다. 오늘은 다음과 같이 작동합니다.

> set -x list 1 2 3
> count $list
3
> fish -c 'count $list'
3

그러나 공백과 함께 내보내면 재귀 호출에 대해 1이 표시됩니다. 당신이 말했듯이 우리는 이것에 의존하지 않지만 일관성 관점에서는 좋습니다.

사려 깊은 답변에 감사드립니다.

두 번째로 해야 합니다! 항상 새로운 관점에서 사물을 바라보는 것이 좋습니다.

이 토론을 처음 접하는 분들을 위해 저는 이것과 관련된 몇 가지 사항을 가져와야 한다고 생각합니다.

즉시 마음에 떠오르는 것은 #2090과 같은 문제에 나타나는 listify 화이트리스트 입니다.

이것은 $PATH, $CDPATH 및 $MANPATH의 경우 물고기에 대한 목록/배열로 나타나지만 내보낼 때 ":"와 다시 결합됨을 의미합니다. 그러면 물고기 안의 물고기가 그들을 다시 쪼갤 것입니다. 이것은 \x1e가 아닌 콜론에서 작동합니다. 코드에 대한 내 이해에 따르면 이스케이프할 기회가 없는 모든 콜론에서 수행하는 것으로 보이므로 내부에 콜론이 있는 $PATH 항목에서 중단될 수 있습니다. UNIX에서는 파일 경로 내부에서 허용하지만 적어도 $PATH에 대해서는 손상된 것 같습니다 . . 이 체계는 PYTHONPATH 및 GOPATH에도 사용됩니다.

나는 암시적 always-split-on-\x1e-except-for-se-three-split-them-on-colon보다 환경 변수 분할에 대해 약간 더 명시적인 것을 원합니다. 왜냐하면 이것은 실제로 두 개의 다른 체계이기 때문입니다. 현재 목록을 내보내는 것은 항상 물고기를 제외한 모든 것을 혼동합니다.

내가 선호하는 솔루션은 splitenv var1 var2 var3 와 같은 기능입니다.

function splitenv --no-scope-shadowing
    set -e IFS # string split doesn't have superpowers, so unset IFS lest we split on both : and \n
    for arg in $argv
        set -q $arg; and set $arg (string split ":" $$arg)
    end
end

( string split 에 초능력 이 있다면 이것은 조금 더 간단할 것입니다)

그러면 모든 목록은 내보낼 때 콜론으로 결합되므로 사용자는 splitenv 를 사용하여 명시적으로 목록을 결합 해제할 수 있습니다. 해야 할 일). 이전 버전과의 호환성을 위해 시작 시 splitenv PATH CDPATH MANPATH 가 실행됩니다. 사용자가 다르게 내보내기를 원하는 경우 string join 를 사용할 수 있습니다.

이 모든 것은 우리가 더 이상 \x1e를 필요로 하지 않는다는 것을 의미합니다. 우리는 적어도 다른 프로그램에서 이해될 가능성이 있는 계획을 가지고 있지만 (다소 이국적인 IMHO) fish-in-side-fish는 이제 fish -c 'splitenv list; count $list' 가 됩니다. .

문제는 물론 언급했듯이 일반적인 콜론으로 구분된 목록 체계에는 콜론을 이스케이프할 방법이 없으며 콜론을 추가하려는 경우 string split 에 "--unscaped"가 없습니다. 이스케이프되지 않은 구분 기호에서만 분할하는 옵션입니다.

내가 의미가 있습니까?

@faho 그 아이디어는 가치가 있다고 생각합니다. 이전 방식의 최악의 부분은 암시적으로 콜론에서 분할되어 분할되어서는 안 되는 변수를 엉망으로 만들었습니다. 귀하의 생각에 이것은 (거의) 항상 명시적이므로 매우 안전하다고 생각합니다.

이스케이프와 관련하여 PATH에서 콜론을 이스케이프하지 않는 것은 찾은 링크에 따라 의도적입니다. 나는 PYTHONPATH, CLASSPATH 등이 이와 관련하여 더 일관성이 있는지 의심합니다. 이 경로에는 콜론을 사용할 수 없으므로 이스케이프 처리 여부를 선택할 수 있습니다. 그러나 콜론을 이스케이프 처리하는 경우 백슬래시를 이스케이프 처리해야 하며 PATH에 백슬래시가 있을 수 있습니다. 우리는 "도피하지 말라"는 화이트리스트가 필요할 수도 있습니다(uh).

또는 우리는 그것에 대해 걱정하지 않고 콜론을 구분 기호로 사용하도록 합니다. 나는 단순함과 다른 쉘과의 친숙함을 위해 이것에 기대고 있다고 생각합니다.

우리는 여전히 일부 목록과 같은 변수가 공백으로 구분되고 다른 변수는 콜론으로 구분된다는 문제에 직면해 있습니다. 한 가지 가능성은 splitenv 가 구분 기호를 허용하고 기억하고 이를 사용하여 내보낼 때 값을 다시 작성하는 것입니다.

splitenv --on ' ' LESS
splitenv --on ':' PYTHONPATH

이러한 호출은 이제 기존 변수를 가져오고 변수를 내보내는 방법을 표시하는 이중 역할을 합니다. 어떻게 생각해?

또한 config.fish를 편집하지 않고 이 작업을 수행할 수 있는 방법이 있습니까? 아마도 범용 변수의 일부로?

우리는 여전히 일부 목록과 같은 변수가 공백으로 구분되고 다른 변수는 콜론으로 구분된다는 문제에 직면해 있습니다. 한 가지 가능성은 splitenv가 구분 기호를 수락하고 기억하고 내보낼 때 값을 다시 작성하는 데 사용하는 것입니다.

잘 들린다. 그 시점에서 splitenv를 스크립트로 만드는 것은 아마도 도움이 되지 않을 것입니다. 왜냐하면 어쨌든 C++ 측의 협력이 필요하기 때문입니다.

이러한 호출은 이제 기존 변수를 가져오고 변수를 내보내는 방법을 표시하는 이중 역할을 합니다.

이제 "splitenv"가 더 이상 완벽한 이름이 아닐 수도 있습니다. (당연히 생각했을 때였습니다.웃음: ) - "listify"도 고려했습니다.

우리가 전에 어디서 관련 토론을 했는지 기억이 나지 않는다는 것이 나를 괴롭게 하지만 - 내 생각에 나는 오늘 밤 이 문제를 다시 조사해야 할 필요가 있을 것입니다.

사용자는 set SOMEPATH (string split : $SOMEPATH) 와 같이 문자열을 토큰화할 수 있습니다.

string 명령은 내가 찾을 수 있는 어디에도 문서화되어 있지 않습니다. 또한 man string 는 BSD(및 Mac OS X)에서 문자열 조작 기능을 문서화한 string(3) 매뉴얼 페이지를 보여줍니다.

그러나 공백과 함께 내보내면 재귀 호출에 대해 1이 표시됩니다. 당신이 말했듯이 우리는 이것에 의존하지 않지만 일관성 관점에서는 좋습니다.

그러나 그 행동은 놀랍습니다. 100명에게 둘 이상의 요소가 있는 var를 내보낼 때 어떻게 되는지 묻는다면 그 중 90명은 값이 구분 기호로 공백과 연결되어 있다고 말할 것입니다. 몇몇 사람들은 쉼표나 다른 문자가 구분 기호로 사용된다고 말할 수 있습니다. env 를 실행한 두 사람은 cat -evt 와 같은 것을 통해 출력을 필터링하지 않는 한 레코드 구분 문자가 보이지 않기 때문에 값이 구분 기호 없이 연결되었다고 말할 것입니다.

#2090과 같은 문제에 표시됩니다.

죄송합니다만 해당 사용자의 불만 사항이 타당하지 않다고 생각합니다. 문제는 MANPATH가 이미 설정되었는지 여부를 명시적으로 테스트하여 간단하게 해결됩니다. 제 생각에는 선행 콜론과 후행 콜론의 의미를 고려할 때 어떤 경우에도 수행해야 하는 것 같습니다.

따라서 내부에 콜론이 있는 $PATH 항목에서 중단될 수 있습니다.

그것을 고치기에는 적어도 삼십년은 늦었다. 콜론의 이스케이프(및 확장하여 이스케이프 문자)를 구현해서는 안 됩니다. 이는 비표준 동작이기 때문입니다. 최근까지 저는 UNIX 지원 전문가로 20년 이상을 보냈습니다. $PATH 또는 유사한 변수에 포함된 디렉토리에 콜론이 있는 것이 문제라고 불평하는 사람을 본 적이 없습니다.

내가 선호하는 솔루션은 splitenv var1 var2 var3과 같은 기능입니다.

(문서화되지 않은) string split 가 충분하지 않은 이유는 분명하지 않지만 괜찮습니다. 새로운 기능이 필요한지 여부에 관계없이 새로운 자동 분할 환경 변수를 추가해서는 안 됩니다. 동작을 보증할 만큼 충분히 일반적인 두 가지는 PATH와 CDPATH(및 이미 특수 사례이므로 MANPATH)입니다. PYTHONPATH와 같은 다른 변수는 사용자가 유용하다고 생각하는 경우 명시적으로 분할할 수 있습니다.

그러나 주어진 var(예: PYTHONPATH)에 내보낼 때 요소가 특정 구분 기호 문자와 연결되어야 함을 등록하는 방법이 분명히 있어야 한다고 말했습니다. 이를 수행하는 가장 자연스러운 방법은 set 명령에 대한 새 옵션을 사용하는 것입니다. 예를 들어,

set -x -S ':' PYTHONPATH dir1 dir2 dir3

이것은 레코드 구분 기호 char가 계속 사용되는 범용 var 데이터 저장소에 var가 저장되는 방식에 영향을 미치지 않으며 해당 데이터 저장소에서 로드될 때 자동 분할됩니다. 결정해야 할 것은 내보내기를 위해 등록된 구분 기호 문자가 문자열 보간에도 영향을 주어야 하는지 여부입니다. 제 느낌은 그래야 한다는 것입니다. 즉, 위의 "set" 명령이 실행되면 후속

echo "PYTHONPATH is $PYTHONPATH"

PYTHONPATH 값을 연결하기 위해 공백 대신 콜론을 사용해야 합니다. 기본 구분 기호는 기존 의미를 보존하고 사용자의 놀라움을 최소화하기 위한 공간입니다. PATH와 같은 특수한 경우의 vars도 해당 예에서 콜론을 사용합니다. 현재 동작과 호환되지 않지만 새로운 의미와 일치하고 덜 놀랍습니다. 즉, 내보낸 환경에서는 $PATH의 요소가 콜론으로 구분되지만 출력에서는 공백인 이유가 무엇입니까?

echo "PATH is $PATH"

string 명령은 내가 찾을 수 있는 곳 어디에도 문서화되어 있지 않습니다. 또한 man string은 BSD(및 Mac OS X)에서 문자열 조작 기능을 문서화한 string(3) 매뉴얼 페이지를 보여줍니다.

진정해, 호랑이. 개발 버전에 있습니다 - https://github.com/fish-shell/fish-shell/blob/master/doc_src/string.txt 참조

(문서화되지 않은) 문자열 분할이 충분하지 않은 이유는 분명하지 않지만 괜찮습니다.

내 원래 아이디어는 편의 기능이므로 이 작업이 완전히 사소해집니다. @ridiculousfish 의 제안으로 그것은 더 많은 것이 되고 어떤 종류의 저장소를 조정하여 내보낼 때 변수도 해당 문자에 결합됩니다. string split 는 문자열을 분할하는 명령일 뿐입니다. 기본적으로 cut 버전입니다.

이를 수행하는 가장 자연스러운 방법은 set 명령에 대한 새 옵션을 사용하는 것입니다.

의미론에 대해 완전히 팔리지는 않았지만 그것은 또 다른 옵션입니다. 예: set -S ':' PYTHONPATH . 그러면 PYTHONPATH가 빈 목록으로 설정됩니까 아니면 기존 PYTHONPATH만 분할됩니까? 지금까지 모든 설정 옵션이 전자를 수행했으므로 set -S ':' PYTHONPATH $PYTHONPATH 를 수행해야 합니다. 또는 그렇게 하지 _않도록_ 하고 동일한 도구 내에서 불일치가 발생합니다.

즉, 내보낸 환경에서는 $PATH의 요소가 콜론으로 구분되지만 echo "PATH is $PATH" 의 출력에서는 공백인 이유가 무엇입니까?

그것은 실제로 좋은 질문입니다. 물론 for p in $PATH; echo $p; end 에 구분 기호가 표시될 것으로 예상하지는 않지만 변수별 구분 기호 char 와 결합하는 것이 올바른 방법일 수 있습니다. 물론 수동으로 수행하는 string join 가 있습니다.

그러나 그 행동은 놀랍습니다. 100명에게 둘 이상의 요소가 있는 var를 내보낼 때 어떻게 되는지 묻는다면 그 중 90명은 값이 구분 기호로 공백과 연결되어 있다고 말할 것입니다.

설문 조사 및 물고기에 의한 설계를 수행하는 데는 일반적인 문제가 있습니다. 설문에 응한 사람들은 bash(및 다른 POSIXy 쉘)에 대한 지식을 자주 갖고 있는 반면 물고기에 대한 아이디어는 POSIX의 일부를 버려서 _더 나은_ 일을 하는 것입니다.

그것이 완전히 무가치하다는 것은 아닙니다. 단지 염두에 두어야 할 사항입니다. 우리가 이러한 종류의 아이디어를 고수한다면 우리는 bash의 단어 분리 동작과 if-fi를 갖게 될 것입니다.

set -S ':' PYTHONPATH 는 PYTHONPATH를 빈 목록으로 설정합니까 아니면 기존 PYTHONPATH만 분할합니까?

빈 목록으로 설정합니다. 사용자가 기존 값을 유지하려면 명시적으로 포함해야 합니다(아래 참조).

내보내기 또는 보간을 위해 지정된 var의 배열 요소를 연결할 때 사용할 문자(또는 빈 문자열)를 구성하는 수단을 제외하고는 이미 필요한 모든 기능이 있습니다. 누군가가 PYTHONPATH와 같은 var를 조작하려는 경우 간단한 문자열로 처리할 수 있습니다.

set PYTHONPATH "/a/new/dir:$PYTHONPATH"

또는 배열로 처리할 수 있습니다.

set -S ":" PYTHONPATH /a/new/dir (string split ":" $PYTHONPATH)

문자열로 삽입할 때 공백 대신 분할/연결 문자를 사용하자는 제 제안은 사용자가 var를 배열로 분할하는지 여부에 관계없이 일관된 동작을 제공합니다.

나는 확실히 위원회에 의해 디자인을 제안하지 않습니다. 그런 식으로 zsh와 같은 광기와 거짓이 있습니다. 나는 단순히 둘 이상의 옵션이 주어졌을 때 하나를 선택할 다른 이유 없이 셸 사용자를 최소한으로 놀라게 하는 옵션을 선택하는 것이 최선의 선택임을 지적하고 있습니다. 또한 내가 (현재로서는) 자동 분할 vars(물론 PATH 및 CDPATH 제외)와 같은 새로운 명령이나 동작을 도입하는 것에 반대하는 이유이기도 합니다. 이것은 드물게 config.fish와 Anaconda의 "activate" 스크립트와 같은 몇 가지 특수 기능에서만 수행되는 일종의 작업입니다. 그리고 사용자가 config.fish에서 var를 이미 배열로 분할했는지 여부에 관계없이 후자가 올바르게 작동하도록 하는 방법은 항상 분할해야 하는 문자열로 처리하는 것입니다. 예를 들어 PYTHONPATH를 수정해야 하는 경우 다음과 같이 할 수 있습니다.

# Hypothetical snippet from the Anaconda activate script.
if test (count PYTHONPATH) -gt 1
    set -S ':' PYTHONPATH /activated/python/tree $PYTHONPATH
else
    set PYTHONPATH "/activated/python/tree:$PYTHONPATH"
end

또는 더 간단히,

# Hypothetical snippet from the Anaconda activate script.
set -S ':' PYTHONPATH /activated/python/tree (string split ':' $PYTHONPATH)

예, 이는 잠재적으로 단순한 문자열일 수 있는 것을 배열로 바꿉니다. 그러나 내 규칙에 따르면 -S 스위치에 의해 지정된 문자는 해당 변환을 배열로 내보내고 보간할 때 사용되어 실제로는 문제가 되지 않습니다. 그러나 한 코너 케이스가 있습니다. 사용자가 config.fish에서 var를 배열로 명시적으로 변환하지 않고 위의 가상 스크립트와 같은 것을 실행하면 어떻게 됩니까? var는 잠재적으로 다중 요소 배열이 될 수 있습니다.

for elem in $PYTHONPATH
   echo $elem
end

사용자가 가상의 "활성화" 스크립트에 의해 수행된 분할을 인식하지 못했기 때문에 콜론으로 구분된 디렉토리 형식의 값을 사용하여 for 루프의 본문을 한 번만 실행하지 않습니다. 사용자가 그런 일을 하는 것은 비뚤어질 것이기 때문에 우리는 그것을 가지고 살 수 있다고 생각합니다.

tl;dr 내 생각에 목록은 구분 기호를 "기억"해야 하며 아래는 그 이유입니다.

나는 위의 대부분의 많은 부분에 동의합니다. 여전히 지루해 보이는 한 가지는 위의 명령이 여전히 지나치게 장황해 보인다는 것입니다. 즉, 이러한 명령 중 일부를 일반 영어로 설명하는 것이 더 간단한 경우가 있습니다.

예를 들어(그리고 저는 반복되는 것만큼 길이에 초점을 맞추지 않았습니다):

• 물고기: set -S ':' PYTHONPATH /activated/python/tree (string split ':' $PYTHONPATH)
• 영어: "$ PYTHONPATH /activated/python/tree 추가( : -delimited`)"

여기에는 PYTHONPATH 및 구분 기호 : 의 두 가지가 반복됩니다. PYTHONPATH 를 반복해야 하는 것은 두 가지 이유에서 틀림없으며 이 두 가지 이유 중 어느 것도 구분 기호에 적용되지 않습니다.

1. 누군가가 set PYTHONPATH /activated/python/tree $PYTHONPATH 라고 말할 때 무슨 일이 일어나는지 직감하는 것은 어렵지 않습니다. 이는 매우 친숙한 개념/관용구인 i = 2 + i 와 매우 유사하기 때문입니다. (하지만 += 와 같은 바로 가기가 여전히 있으므로 아래에 --append 플래그를 제안합니다.) 반면에 사람들은 목록에 추가를 생각할 때 분할에 대해 생각하지 않습니다. 그리고 구분 기호에 결합합니다. 그들은 전체 목록을 다른 형식으로 변환하고 실제 작업을 수행하고 다시 넣는 것에 대해 생각하지 않습니다. 마음속으로 그들은 구분자를 "내부" 또는 "선호하는" 구분 기호로 변경하는 대신 구분 기호로 자연스럽게 읽습니다.
2. 추가를 위해 일반 set 명령을 사용하면 두 개의 다른 목록을 결합하기 위한 또 다른 명령을 추가하는 것을 절약할 수 있습니다. 반면에, 하나의 구분 기호에서 다른 구분 기호로 변환하는 것은 사용자가 수동으로 수행하는 것을 이상적으로 원하지 않는 것입니다. 대부분 위의 이유 때문입니다.

대조적으로 목록에 구분 기호를 지정하는 또 다른 방법을 제안합니다. 목록과 무기한 연결하는 것입니다. 따라서 위의 예는 다음과 같이 수행할 수 있습니다.

# Changes the delimiter for this list. This might be done in some global config file for common lists as this one.
set -S ':' --no-modify PYTHONPATH
# or, workaround if you don't want to add extra options to set:
set -S ':' PYTHONPATH $PYTHONPATH

# The actual append operation
set --prepend PYTHONPATH /activated/python/tree
# or, workaround if you don't want to add extra options to set:
set PYTHONPATH /activated/python/tree $PYTHONPATH

시사점/후속 질문/기타:

1. 이것은 현재 제안과 상당히 호환됩니다. 필요한 변경 사항은 다음과 같습니다.
   
   
   
   • 구분 기호를 고정합니다(다른 변수를 __fish_sep_PYTHONPATH 로 사용하여 가능).
   
   
   • (선택 사항) 현재 --no-modify 라고 부르는 플래그를 추가합니다. 이 플래그는 물고기가 내용을 변경하지 않고 목록의 구분 기호를 변경하도록 지시합니다. 위의 이유 (1) 때문에 --append 및 --prepend 플래그도 추가할 수 있습니다. 어쨌든 이것은 필요하지 않습니다. 위의 해결 방법에서 알 수 있듯이 오늘날 물고기에서 추가 및 추가가 어떻게 수행되는지 알 수 있습니다.
   
   
2. 물고기에서 목록은 최소한 일류 시민처럼 _취급_받아야 합니다. 즉, 구분 기호를 변경하면 목록 표현이 아니라 문자열 표현이 변경되어야 합니다(구분자가 요소 중 하나에 존재하지 않는 한, 분할이 불가피한 경우). 예를 들어, 구분 기호를 , 에서 : 로 변경하는 경우 ["0:1", "2"] 는 ["0", "1,2"] ["0", "1", "2"] 가 되어야 합니다. 목록을 뒷받침하는 문자열을 변경하지 않고 단순히 구분 기호를 변경하면 발생합니다. 이 동작은 현재 동작과 현재 기본 불변 구분 기호가 있다는 사실과의 호환성을 최대화해야 합니다.

결론은 다음과 같습니다.

• 여기에는 훨씬 적은 수의 토큰이 포함되며 거의 아무 것도 반복되지 않습니다.
• 이것은 많은 사용자가 가지고 있는 멘탈 모델과 유사합니다. 사용자는 "앞에 추가", "구분 기호 설정", "수정하지 않음"과 같은 용어로 생각합니다.
• 이것은 이 작업을 수행하는 유일한 올바른 방법인 것 같으므로(이전 방식은 이제 매우 서투르게 보입니다) 이러한 추가는 직교성을 파괴하지 않습니다.

set --no-modify -S : PYTHONPATH
set --prepend PYTHONPATH /activated/python/tree

내 제안에 대한 자세한 의견을 주신 @szhu님 , 감사합니다. 그러나 제안한 솔루션에는 많은 문제가 있습니다. 예를 들어 --no-modify 옵션을 추가하면 실제로 변수를 목록으로 변환하여 변수를 수정하므로 변수가 수정됩니다. 나는 당신의 제안의 거의 모든 요소를 ​​거부하지만 당신의 요점의 전부는 아닐지라도 대부분을 다룰 보다 직접적인 해결책에 대해 생각하게 했습니다. 주어진 env var가 항상 주어진 토큰(예: ":" 또는 " ")에서 자동으로 분할되고 재구성되어야 함을 물고기에게 알려주는 메커니즘이 있어야 합니다. 이것은 자동 배열 지정 이라고 할 수 있으며 실행될 때 기존 값이 이미 배열이 아닌 경우 즉시 분할됩니다.

이 동작을 활성화하기 위해 새로운 옵션을 set 명령에 추가할 수 있습니다. 그러나 그렇게 하는 것이 모호하고 값이 없는 변수를 정의하는 것으로 해석될 수 있다는 점이 우려됩니다. set 명령에 -A 토큰 옵션을 추가하는 것이 명확합니까? 예를 들어:

set -x -A ':' PYTHONPATH

아마도 콜론으로 분할된 후 기존 PYTHONPATH 환경 변수를 즉시 배열로 변환할 것입니다. 반대로 문자열로 내보내거나 보간할 때 값이 콜론에 연결됩니다. 마찬가지로, 해당 명령이 실행될 때 PYTHONPATH가 존재하지 않더라도 자동 배열 사양이 기억되고 후속 사용이 영향을 받습니다. 예를 들어, 이것은 분명히 배열을 생성할 것입니다:

set PYTHONPATH /a/path /b/path /c:/d/path

그러나 그 마지막 주장은 어떻습니까? 자동으로 두 개의 토큰으로 분할되어야 합니까?

이 동작은 내보낸 변수에만 적용되어야 하며 그렇지 않으면 오류가 발생합니다. 철자가 필요한 일부 코너 케이스도 있습니다. 예를 들어 원래 자동 분할 선언에 다음 예와 같은 값이 포함되어 있으면 어떻게 될까요?

set -x -A ':' PYTHONPATH 'hello:goodbye' $PYTHONPATH

자동 분할 토큰에서 해당 값을 분할해야 합니까? 아니면 오류가 발생하고 별도의 명령문에서 값을 수정해야 합니까? 어떤 구문을 선택하든 자동 분할 토큰이 포함된 값에 대해 수행할 작업에 대한 문제가 있습니다. 악마는 디테일에 있다. 즉, 내가 생각하지 못한 이 제안의 다른 결과가 있을 수 있습니다. 더 자세한 구문을 사용하는 원래 제안은 내가 말할 수 있는 한 이러한 문제를 방지합니다.

@krader1961 , 응답해 주셔서 감사합니다. 그러나 내가 변수를 문자열에서 목록으로 변환하고 있다고 생각하는 것 같습니다. 나는 당신이 물고기의 한 가지 중요한 개념을 오해하고 있다고 생각합니다. 모든 변수는 문자열의 목록입니다 . 문자열로 보이는 변수는 실제로 길이가 1인 목록입니다. fish는 길이가 0 또는 2인 목록이나 다른 길이의 목록과 다르지 않게 취급합니다.

또한 구분 기호를 변경할 때 환경 변수를 전달하는 데 사용되는 기본 문자열이 변경될 수 있지만 물고기의 장점 중 하나는 일반적으로 사용자가 구분 기호에 대해 전혀 생각할 필요가 없다는 것입니다. 이것이 내가 모든 -S 옵션이 물고기 _외부로 내보낼 때 이 목록을 문자열로 변환하는 방법을 지정하는 것을 권장하는 이유입니다. -S 는 in-fish 목록 표현을 변경해서는 안 됩니다(대상 구분 기호를 사용하여 해당 목록을 표현하는 것이 불가능한 경우 제외).

그건 그렇고, 여기 내 제안이 얼마나 깨끗한 지 보여주는 한 가지 예가 있습니다. 다음은 $L 변수를 $ \x1e 의 기본 구분 기호로 다시 변환하는 코드입니다. 오늘날 물고기에서 생성할 수 있는 변수(범위, 항목 수)에는 전혀 영향을 미치지 않습니다.

set -S \x1e L $L

한 가지 더: --no-modify 인수 계열은 바로 가기입니다. 다음은 해당 항목입니다.

| 바로 가기 | 동등한 |
| --- | --- |
| set [other args] --no-modify L | set [other args] L $L |
| set [other args] --prepend L $TOADD... | set [other args] L $TOADD... $L |
| set [other args] --append L $TOADD... | set [other args] L $L $TOADD... |

(이전에 다음을 언급했지만 지금은 더 잘 설명할 수 있다고 생각합니다.) 이 세 가지 주장이 얼마나 "멍청한"지를 강조함으로써 일부 사람들은 그것이 전혀 필요한지 의문을 제기할 수 있습니다. 물고기 는 직교성의 설계 원칙을 가지고 있다고 인용할 수 있습니다. 모든 것이 직교할 때 이는 수행하려는 큰 작업에 대해 해당 작업을 수행하기 위해 선택할 기능 집합이 분명해야 함을 의미합니다. 올바른 방법은 하나만 있어야 합니다. 여기에서 실제로 목록에 수정을 추가/추가/방지하는 또 다른 방법을 추가했지만 이는 대체되는 등가물이 불필요하게 장황하다고 생각하기 때문입니다. 수정 목록을 추가하는 올바른 방법이 아니어야 합니다. 이것을 확신하는 한 가지 방법은 목록에 추가하는 것에 대해 생각하는 것입니다. "set $L to $L $TOADD $ "가 아니라 " $TOADD to $L 추가"라고 생각할 수 있습니다.

당신이 어떻게 생각하는지 알려주십시오. 그리고 이것이 내 제안에 대해 더 설득력 있는 사례가 된다면. (또한 제가 잘못 이해하는 경우가 많으니 자유롭게 수정해주세요.)

@szhu 나는 물고기의 모든 변수가 0, 1 또는 그 이상의 값 목록이라는 것을 알고 있습니다. 또한 관련 구분 기호가 내부 표현에 영향을 주어서는 안 되거나 값이 범용 데이터 저장소에 유지되는 방식(구분 기호 저장 제외)에 영향을 미치지 않아야 한다고 분명히 명시한 이전 의견을 읽지 않은 것 같습니다. 당신은 또한 나의 이전 요점을 다루지 않았습니다. 마지막 예를 고려하십시오.

set -S \x1e L $L

L 에 이미 두 개 이상의 값이 포함되어 있으면 어떻게 해야 합니까? 연결된 구분 기호를 변경하는 것 외에는 아무 것도 없습니다. 이 경우 $L 인수는 선택 사항입니까? 아니면 먼저 기존 배열을 간단한 문자열(기존 구분 기호를 사용하여 연결)로 변환한 다음 해당 문자열을 새 구분 기호로 분할해야 합니까? 앞서 말했듯이 악마는 디테일에 있다.

궁극적으로 기존 디자이너와 유지 관리자는 --no-modify 기능 제품군을 추가해야 하는지 여부를 결정할 것이지만 비용에 비해 제 생각에 충분한 가치를 추가하지 않기 때문에 저는 반대합니다.

죄송합니다. 이 스레드가 길어서 위의 내용에 대한 귀하의 인정을 놓쳤을 것입니다. 우리가 같은 페이지에 있다는 것을 알게되어 기쁩니다! 위에서도 대부분의 우려 사항을 해결했다고 생각하지만 전부는 아닙니다. 아래에서 각각의 우려 사항을 구체적으로 설명하겠습니다.

1. set -S \x1e L $L $L 는 선택 사항입니까?

set 의 기존 동작은 변경되지 않습니다. 현재 동작에서 set L $L 는 L 를 변경하지 않고 set L 는 L 를 빈 목록으로 만듭니다. set -S \x1e L $L 및 set -S \x1e L 와 동일합니다.

1.1 set -S \x1e L $L 는 구분 기호를 변경하기 위해 지나치게 장황하게 보이지 않습니까?

약간. 이것이 바로 내가 --no-modify 옵션을 바로 가기로 제안하는 이유입니다.

하지만 이 바로 가기가 존재하지 않으면 내 계획이 무너지지 않습니다. set PATH ~/.bin $PATH 목록을 추가할 때 이미 매일 이 문제를 다루고 있습니다. 그래서 같은 이유로 --prepend 와 --append 도 제안합니다.

2. 전환 프로세스는 어떻게 진행됩니까?

이전 구분 기호가 \x1e 이고 새 구분 기호가 $ : 이며 물고기 목록 ["hello", "world"] ( hello\x1eworld 로 내보냄)이 있다고 가정해 보겠습니다. 변환을 수행하는 두 가지 기본 방법(" 변환 옵션 ")이 있습니다.

1. ["hello", "world"] 를 사용하여 ["hello", "world"] 로 변환합니다( hello,world 로 내보냄).
   장점: 목록 표현이 변경되지 않습니다.
2. hello\x1eworld 를 사용하여 ["hello\x1eworld"] 로 변환합니다( hello\x1eworld 로 내보냄).
   장점: 내보낸 값 표현이 변경되지 않습니다.

이것은 구현 관점이 아니라 UI 관점에서 나온 것임을 유의하십시오. 우리는 그것이 사용자에게 어떻게 보이는지에 대해 이야기하고 있습니다. 다음 질문에서 구현에 대해 다루겠습니다. _참고: 이 답변의 나머지 부분은 귀하의 질문에 따라 위에서 다루지 않은 새로운 내용입니다. 감사 해요!_

물고기 내에서. 첫째, 우리가 완전히 물고기에서 작업하는 경우 목록은 일급이며 구분 기호에 대해 걱정할 필요가 없으므로 둘 다 필요하지 않습니다. (다시 말하지만 "해야 한다"는 것은 사용자의 관점에서 보는 것이며 개발자로서 이를 사실로 만드는 것은 우리의 책임입니다.)

vars의 내보내기 형식 변경 따라서 사용자가 구분 기호를 변경해야 하는 유일한 이유는 환경 변수를 읽는 프로그램에 대해 내보낸 문자열을 변경하는 것입니다. 물고기에서 생성된 목록의 경우 목록으로서의 변수의 의미가 중요하고 잘 정의되어 있으므로 목록 표현을 보존해야 하므로 변환 옵션 1 을 확실히 사용합니다.

vars의 가져오기 형식 변경 그러나 PATH 와 같은 환경 변수가 처음에 물고기 외부에서 생성된 경우 이미 구분 기호가 있는 목록에 대해 해당 구분 기호가 무엇인지 물고기에게 알려야 합니다. 이를 위해 변환 옵션 2 를 사용할 수 있습니다.

2.1 이것은 어떻게 구현됩니까?

사용자가 이것을 알 필요는 없지만 물고기는 실제로 목록을 문자열로 저장합니다. x hello\x1eworld #$ 로 저장됩니다. 내 제안에 x 변수의 구분 기호를 지정하는 또 다른 변수 __fish_delimiter_x $ 가 있습니다. 지금은 존재하지 않으므로 기본 구분 기호 \x1e 를 사용합니다.

변환 옵션 1의 경우:

1. 이전 구분 기호에서 변수를 분할하면 구현 언어(C++)에서 실제 목록이 생성됩니다.
2. 새 구분 기호를 사용하여 목록을 결합하면 새 문자열이 생성됩니다.
3. 새 구분 기호를 __fish_delimiter_x 에 저장합니다.

변환 옵션 1의 경우 동등한 구현:

1. 변수에서 이전 구분 기호의 모든 항목을 새 구분 기호로 바꿉니다.
2. 새 구분 기호를 __fish_delimiter_x 에 저장합니다.

변환 옵션 2의 경우:

1. 새 구분 기호를 __fish_delimiter_x 에 저장합니다.

2.2 두 가지 변환 옵션이 모두 필요한 경우 사용자는 어떤 변환 옵션을 사용할지 어떻게 지정합니까?

옵션 1의 경우 -D 또는 --convert-delimiter , 옵션 2의 경우 -d 또는 --set-delimiter 의 두 가지 옵션이 있을 수 있습니다.

2.3 두 가지 옵션이 모두 필요한가요?

현재 물고기에서 우리는 물고기 외부의 야생에서 \x1e 를 볼 수 없다고 가정하기로 선택합니다. 이것을 기본 구분 기호로 유지하고 이 가정을 유지하면 변환 옵션 1 은 구분 기호를 변환하고 설정하는 데 충분하며 변환 옵션 2가 필요하지 않습니다 . (이를 확신하는 쉬운 방법은 가정이 사실인 경우 외부에서 생성된 목록을 변환할 때 변환 옵션 1의 "이전 구분 기호를 새 구분 기호로 모두 바꾸기"가 아무 작업도 수행하지 않아 전체 변환이 감소한다는 것을 깨닫는 것입니다. 변환 옵션 2로)

@ridiculousfish , 특히 UI 및 구현 세부 정보와 관련하여 이에 대한 피드백도 감사합니다. 감사 해요!

여기에 두 가지 문제가 있는 것 같습니다. 첫 번째 이야기만 해볼까요?

실제 배열의 경우 +1

그 구분 트릭이 물고기에게 정말 필요한가요? 핑 #627

변수 값에 대한 문자열 표현을 배열로 변환하는 두 가지 호환되지 않는 방법이 있음을 발견한 문제 #2106에 대한 수정 사항에 비추어 이것을 다시 방문합니다. 그 중 하나는 빈 요소를 잘못 생략했습니다. 핵심 문제는 class env_var_t 가 wcstring의 벡터가 아니라 wcstring 를 기반으로 한다는 것입니다. 노력할 가치가 있는지 여부는 논쟁의 여지가 있습니다.

이 문제를 따르고 있다면 PR #4082를 살펴보고 테스트할 것을 권장합니다. 이 문제를 해결하는 가장 좋은 방법은 zsh에서 같은 이름의 기능과 유사한 "연결된" 변수입니다.

콜론으로 내보낸 이러한 목록과 이 화이트리스트에 어떤 환경을 포함해야 하는지에 대한 질문은 아직 결정되지 않은 것 같습니다. 이 문제에 대한 현재 상태는 무엇입니까? 이 주제에 대한 최종 해결책을 기대할 수 있습니까? 바로 오늘, 나는 LD_LIBRARY_PATH가 화이트리스트에 없다는 함정에 다시 빠졌다...

요약하자면: Unix 환경 변수는 문자열이므로 배열과 같은 환경 변수는 구분 기호를 사용해야 합니다. 대부분은 콜론($PATH)을 사용합니다. 모두는 아니지만($LESS). 우리는 가져오기/내보내기에서 모든 배열을 구분하기 위해 콜론을 사용하고 싶습니다(실제로 물고기는 이런 식으로 작동했습니다). 문제는 일부 플랫 변수에 콜론($DISPLAY, $SSH_CONNECTION)이 포함되어 있다는 것입니다.

목표는 구분된 변수가 물고기의 배열 지원과 함께 자연스럽게 작동하도록 하는 것입니다. @szhu 는 구분 기호를 추적하기 위해 set 를 향상시킬 것을 제안했지만 set 를 향상시키는 IMO는 이것을 첨부하기에 잘못된 위치입니다.

• 변수 설정과 구분 기호 설정 간의 성가신 상호 작용(동기부여 --no-modify ).
• 구분 기호가 변수 범위와 상호 작용하는 방식에 대한 까다로운 질문입니다.
• 범용 변수에 대한 문제. uvar를 사용하여 변수를 현재 값으로 설정할 방법이 없기 때문에 uvar가 구분 기호를 기억하도록 가르쳐야 하고 --no-modify 에 대해서도 가르쳐야 합니다.

리뷰에서 나는 @faho 의 splitenv 아이디어 를 선호합니다. splitenv name 는 기존 변수를 콜론으로 분할합니다. 놀랍도록 간단합니다. 콜론을 사용하지 않는 변수는 특별한 지원이 필요하지 않을 만큼 매우 드뭅니다.

단점은 물고기로 내보낸 배열이 콜론으로 구분된 문자열로 다시 가져올 수 있다는 것입니다. 실제로는 이것이 드물다고 생각합니다.

피할 수만 있다면 이 splitenv 합병증을 사용자에게 가해서는 안 됩니다. 그래서 한 단계 더 나아가 이름이 PATH로 끝나는 모든 환경 변수 (예: LD_LIBRARY_PATH, PYTHONPATH 등)로 콜론 화이트리스트를 확장하고 싶습니다. 실제로 이것은 거의 항상 올바른 일을 해야 합니다. 그것에 물린 사람은 string join 를 사용하여 값을 수정할 수 있습니다.

그래서 내가 제안하는 것(정말로 faho의 제안):

• 콜론을 사용하여 모든 배열을 내보냅니다. 더 이상 ASCII 레코드 구분 기호가 없습니다.
• 콜론에서 변수를 분할하는 splitenv 함수를 구현합니다. 이것은 물고기 스크립트로 작성할 수 있습니다.
• PATH로 끝나는 모든 변수에 대해 콜론으로 구분된 화이트리스트를 향상합니다.

나는 이것이 콜론으로 구분된 배열과 관련된 대부분의 고통을 미니멀하고 호환되는 방식으로 해결할 것이라고 믿습니다.

splitenv 아이디어에 관하여:

예를 들어 ["item1", "item:2"] 와 같이 항목에 콜론이 포함된 목록을 물고기가 내보내도록 한다고 가정해 보겠습니다. (특히 배열이 사용자 입력을 저장하는 데 사용되는 경우에는 이것이 드문 일이 아니라고 생각합니다.)

목록을 item1:item:2 로 내보내나요? 그렇다면 내보내기 후 원래 목록을 다시 만드는 것이 불가능합니다.

또한 변수에 대해 변경할 수 없는 화이트리스트를 갖는 것은 잘못된 느낌을 주지만 화이트리스트를 *?PATH 로 설정하는 것은 덜 잘못된 것 같습니다. (그것은 내가 구분자를 변수로 저장하자는 제안의 또 다른 이유였습니다. 변수를 설정하여 화이트리스트를 변경할 수 있습니다.)

@szhu 맞습니다. Exported-lists-can't-contain-colons는 Unix 가 이미 겪고 있는 문제입니다.

부터 \

그래서 물고기에 대해 동일한 제한을 도입하는 것에 대해 그다지 나쁘게 생각하지 않습니다(내보낸 변수에만 해당).

또한 이 문제는 배열을 재귀적으로 호출되는 물고기 인스턴스로 내보낼 때만 발생합니다. 이것이 일반적인 것으로 판명되면 다른 변수에 사이드카 데이터를 첨부하거나 물고기를 재귀적으로 호출할 때 다른 배열 구분자를 사용할 수 있습니다. 내 생각에 우리는 그렇게 멀리 갈 필요가 없을 것입니다.

나는 제안이 잘 작동하지 않는 극단적인 경우가 흔하지 않다는 데 동의하지만 사람들이 그것에 부딪치면 정말 나쁠 것 같아 두렵습니다.

다음은 부분적으로만 고안된 예입니다.

set -x TEST color:red 
set -x TEST2 color:red font:serif
set -x TEST_PATH color:red 
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST #=> color:red
echo $TEST2 #=> color:red:font:serif
echo $TEST_PATH #=> color red 
echo $TEST2_PATH #=> color red font serif

위의 사항을 지켜본 후 많은 신규 사용자들이 혼란스러워 하는 모습을 상상할 수 있습니다.

다음 행동이 훨씬 더 재미있을 것이라고 생각합니다.

set -x TEST color:red 
set -x TEST2 color:red font:serif
set -x TEST_PATH color:red 
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST # color:red
echo $TEST2 # color:red font:serif
echo $TEST_PATH #=> color:red 
echo $TEST2_PATH #=> color:red font:serif

이에 대한 귀하와 지역사회의 생각을 듣고 싶습니다.

기존 콜론을 탈출하지 않는 이유는 무엇입니까? 그렇게 하면 구별이 유지됩니다.

탈출은 나에게 의미가 있습니다.

변수가 배열인지 여부가 기억되지 않는다는 것이 여전히 혼란스러울 수 있습니까?

set -x TEST2 color:red font:serif
set -x TEST2_PATH color:red font:serif
exec fish
echo $TEST2 # color\:red:font\:serif
echo $TEST2_PATH #=> color:red font:serif

네. 내 가설은 배열 내보내기가 경로 목록 외부에서 일반적이지 않다는 것입니다.

MANPATH에는 이중 콜론(::)에 대한 특별한 의미가 있습니다. - #2090 참조 - 이 작업에서 스패너가 발생합니까?

나는 또한 어떤 경우에도 사이드카 변수 FISH_ARRAY_VARIABLES=FOO\t:\nBAR\t;\nBAZ\t-\n 를 갖는 것이 다른 프로세스를 방해하지 않고 "우리는 지금 물고기 포함" 검사기..

재: https://github.com/fish-shell/fish-shell/issues/436#issuecomment -392409659 @zanchey
#2090을 자세히 읽지는 않았지만 콜론으로 구분된 문자열과 배열 형식 간의 변환이 완전히 원활하다고 생각합니다(배열 항목에 콜론 ~가 나타나지 않는 경우 제외).

MANPATH 에 이중 콜론을 포함하려면 이중 콜론이 표시되어야 하는 곳에 빈 문자열을 추가하기만 하면 됩니다.

$ set -x MANPATH 1 2 '' 3
# Check if it's set
$ bash -c 'echo $MANPATH'
1:2::3

MANPATH 를 콜론으로 시작하려면 시작 부분에 빈 문자열 항목을 추가하기만 하면 됩니다.

$ set -x MANPATH '' 1 2 3
# Check if it's set
$ bash -c 'echo $MANPATH'
:1:2:3

나는 여기에서 모든 것을 따르지는 않았지만 사용자로서 "구성 없음"을 옹호하고 싶습니다.
set -S 및 splitenv 는 구성 형식이라고 생각합니다. 일부 사용자는 fish.config에서 이를 수행하고 PYTHONPATH를 배열로 처리합니다. 다른 사람들은 PYTHONPATH를 콜론으로 구분된 단일 단어로 처리하지 않고 처리합니다. stackoverflow 조언을 복사하여 붙여넣고 한 사용자에서 다른 사용자로 PYTHONPATH를 조작하는 스크립트를 실행하면 항상 작동하지 않습니다...

" PATH 로 끝나는 경우" 규칙은 구성이 필요 없으며 가능한 한 완벽하게 들립니다. +1:
(이전 버전과의 비호환성이 가치가 있는지 여부에 대한 의견이 없습니다)
예, set -x TEST2_PATH color:red font:serif 는 color red font serif 배열로 가져올 수 있지만 변수 내보내기와 관련된 문제입니다. 작동 방식을 이해하지 않고는 내보낸 var를 배열로 설정할 수 없습니다.

네. 내 가설은 배열 내보내기가 경로 목록 외부에서 일반적이지 않다는 것입니다.

@ridiculousfish 현재 조개에서는 사실일 수 있지만 물고기가 더 많은 견인력을 얻으면 사용자가 물고기의 기능을 활용하여 목록을 자식 물고기 조개에 보낼 수 있다고 생각합니다. 나는 결국 물고기 세션의 상태를 관리하는 프로그램/플러그인이 있을 수 있다고 상상할 수 있습니다(몇 년 후에 이 의견을 다시 확인하여 이것이 사실인지 확인하겠습니다). 그리고 보편적으로 목록을 자동으로 역/직렬화할 수 있습니다. 그 코드를 더 깨끗하고 덜 해결하도록 만들 것입니다.

비슷하지만 약간 다른 생각입니다. PATH 를 특수한 경우로 취급하는 것은 사용자가 쉘의 일반적인 사용 사례에 대한 기록이 있는 경우에만 이해할 수 있는 시대착오적인 극단적인 경우입니다. 이것은 물고기가 일반적인 스크립팅 언어로 사용되는 기능을 제한하고 잠재적인 향후 사용 사례를 제한합니다.

@ridiculousfish 한 가지 가능한 솔루션은 각 환경 변수/배열을 자체 구분 기호와 연결하는 것입니다( '\x1e' 또는 ' ' 또는 ':' 를 기본값으로 유지할 수 있음). 환경 변수를 생성하는 사용자는 충돌을 피하기 위해 적절한 구분 기호를 선택할 책임이 있습니다. 명령은 set --separator ':' TMP 1 2 3 와 같을 수 있습니다. 따라서 잘 알려진 환경 변수의 경우 사용자는 다른 프로그램에서도 인식할 수 있고 더 많은 프로그램(예: Python)과 물고기의 호환성을 높일 수 있는 해당하는 잘 알려진 구분 기호를 선택할 수 있습니다.

최근 댓글만 읽는 분들을 위해 @thuzhf 의 set --separator 권장 사항은 이 스레드 전체에서 반복적으로 언급된 set -S 권장 사항과 동일합니다. 해당 토론에 대한 자세한 내용을 보려면 이 페이지를 set -S grep할 수 있습니다.

@szhu 이전 set -S 을 눈치채지 못해서 죄송합니다. 그것은 기본적으로 저도 원하는 것입니다. 나는 또한 다른 사람들이 이 새로운 옵션에 대해 가지고 있는 몇 가지 우려 사항이 있음을 알게 되었습니다. 아래에 이러한 문제에 대한 내 생각을 말할 수 있습니다(fish's set 는 -s 를 옵션으로 사용하지 않았으므로 앞으로 $#$ --separator -s 를 사용하겠습니다).

1. --no-modify 는 무언가를 수정합니다. 예, 이름을 명시적으로 변경해야 합니다(예: --change-separator ).
2. 일부 코너/어려운 경우가 있습니다. 이것은 기본적으로 잘 정의되지 않은 구문 때문이며 구문을 엄격하게 정의하면 자연스럽게 피할 수 있습니다. 예를 들어:
   
   
   
   1. 기본 아이디어: 모든 var(목록)는 정의될 때 자체 구분 기호와 연결됩니다(기본값은 ' ' ). 이 구분 기호는 이 var가 문자열에서 생성되고 문자열로 변환될 때 사용됩니다(이는 Python의 join() 함수와 같은 일부 언어에서 일반적인 아이디어입니다). var는 내보낼 때 또는 사용자가 이를 원할 때 문자열로 변환됩니다.
   
   
   2. 환경 변수를 만드는 방법
      
      
      
      
      
      1. set ENV_VAR a b c . -s 가 없으면 기본 구분 기호로 ' ' 를 선택합니다.
      
      
      
      2. set -s ':' ENV_VAR . 이 경우 ENV_VAR은 빈 목록으로 설정됩니다.
      
      
      
      3. set -s ':' ENV_VAR a b:c d e:f . 이 경우 이 코드를 작성하는 사용자는 ':' 가 구분 기호임을 분명히 이해하고 ENV_VAR 이 ['a b', 'c d e', 'f'] 와 같은 배열이 되고 'a b:c d e:f' 로 내보내진다는 것을 이해해야 합니다. 내보낸 ENV_VAR이 공백으로 시작하고 공백으로 끝나도록 하려면 어떻게 해야 합니까? set -s ':' ENV_VAR \ a b:c d e:f\ 와 같은 이스케이프를 사용해야 합니다. 그러면 ENV_VAR은 [' a b', 'c d e', 'f '] 가 되고 ' a b:c d e:f ' 로 내보내집니다.
      
      
      
      4. set -s ':' ENV_VAR a b:c d e:f $ENV_VAR . 이 경우 $ 의 작동 방식에 따라 다릅니다. 목록 대신 ENV_VAR의 문자열 값을 추출하는 것으로 정의하면 이 명령은 $ENV_VAR을 아래 목록에서 변환된 문자열 값으로 바꾸는 것과 같으며 이 경우 set -s ':' ENV_VAR a b:c d e:f:$ENV_VAR 는 아마도 당신이 정말로 원하는 것( f : 주목); ENV_VAR(문자열이 아닌 목록)의 변수를 추출하는 것으로 정의하면 파이썬에서와 같이 목록 확장 작업이 되어야 합니다. 예를 들어 후자의 경우 ENV_VAR 가 이전에 ['x', 'y'] 였다면 이 작업 후에 ENV_VAR 는 ['a b', 'c d e', 'f', 'x', 'y'] 가 됩니다. ENV_VAR 의 이전 구분 기호가 ':' 가 아니면 어떻게 됩니까? 전자의 경우 올바른 작업을 수행하고 있는지 확인하는 것은 사용자의 책임입니다. 예를 들어 원래 구분 기호를 ':' 로 변경하거나 현재 구분 기호를 원래 구분 기호로 변경하여 일관된 구분 기호를 사용해야 합니다. 후자의 경우 이 배열의 구분 기호를 원래 배열(무엇이든 관계없이)에서 ':' 설정합니다.
      
      
      
   
   
   3. 구분 기호를 변경하는 방법
      
      
      
      
      
      1. set --change-separator ':' ENV_VAR . ENV_VAR이 존재하지 않으면 프로그램은 0 이외의 오류 코드와 함께 종료되어야 합니다. 쉽고 명확합니다.
      
      
      
   
   
   4. 구분자를 보는 방법
      
      
      
      
      
      1. set --view-separator ENV_VAR .
      
      
      
   
   

게다가 이 문제는 명백하고 시급 하며 사용자에게 큰 고통점이라고 생각하며 사용자 경험에 큰 영향을 미치기 때문에 이 문제가 가능한 한 빨리 해결되기를 바랍니다. 사실 저는 이 큰 문제를 제외하고는 현재 물고기를 사용하는 동안 다른(아주 작은) 문제에 직면하지 않았습니다.

정말 이 문제는 명백하고 시급하다고 생각합니다

@thuzhf : 나는 당신이 그것을 과대 평가하고 있다고 말하고 싶습니다.

한 가지 이유는 #5169의 문제가 $LD_LIBRARY_PATH에 있었지만 실제로는 물고기 목록이 아니기 때문입니다! 다른 쉘과 마찬가지로 set LD_LIBRARY_PATH "$LD_LIBRARY_PATH:/some/path" 와 같이 설정해야 합니다.

Fish는 정확히 3개의 상속/내보낸 변수를 자동으로 목록으로 바꿉니다.

$PATH, $MANPATH 및 $CDPATH. 그리고 정확히 이 목록은 내보낼 때 ":" 구분 기호가 있습니다.

$LD_LIBRARY_PATH와 같은 다른 "표준화된" 변수는 fishscript의 목록으로 처리되어서는 안 되므로 이 문제가 발생하지 않습니다. 표준화되지 않은 변수는 원하는 대로 처리할 수 있습니다. 다른 프로그램에서는 아무 작업도 수행하지 않으므로 구분 기호가 중요하지 않기 때문입니다.

@faho 명쾌한 설명 감사합니다. 그것은 나에게 정말 많은 의미가 있습니다. 좋아, 나는 이 문제가 나를 위해 해결되었다고 말할 수 있다.

#2090에 설명된 MANPATH 문제를 살펴보았습니다. 시나리오는 시스템 경로를 계속 사용하도록 manpath에 추가하는 것입니다.

bash에서는 이것을 export MANPATH="$MANPATH:/new/path" 로 작성합니다. MANPATH가 설정되어 있으면 추가됩니다. 설정하지 않으면 콜론이 앞에 추가되며 이는 시스템 디렉토리를 사용하기 위한 사람 고유의 표시입니다. 이 구문은 물고기에서 작동하지 않습니다. 문제는 MANPATH가 배열이므로 "$MANPATH"에 콜론 대신 공백이 있다는 것입니다.

"연결된 변수" 접근 방식을 사용하면 MANPATH를 콜론으로 구분된 문자열로 미러링하는 배열로 fish_manpath 를 가질 수 있습니다. 이것은 완전히 물고기 스크립트로 만들 수 있습니다. 그러나 우리는 MANPATH뿐만 아니라 모든 경로와 유사한 변수에 대해 이 작업을 수행하기를 원할 것이며 이는 관리 방법이 명확하지 않은 중요한 호환성 중단이 될 것입니다. 또한 동일한 문제가 있습니다. 예를 들어 zsh의 manpath array-variable은 추가하기가 어색하므로 왜 존재하는지 명확하지 않습니다.

여기서 내 제안이 MANPATH 상황을 더 좋게 만들거나 더 나쁘게 만들지 않습니다. 나는 할 일은 펀트하고 MANPATH에 추가하기 위한 쉬운 이야기를 가지고 있다고 생각합니다. 이것이 바로 다음과 같습니다.

set -q MANPATH || set MANPATH ''
set -x MANPATH $MANPATH /new/path

config.fish에 붙여넣는 것은 그리 어렵지 않습니다.

여기서 내 제안이 MANPATH 상황을 더 좋게 만들거나 더 나쁘게 만들지 않습니다. 나는 할 일은 펀트하고 MANPATH에 추가하기 위한 쉬운 이야기를 가지고 있다고 생각합니다. 이것이 바로 다음과 같습니다.

@ridiculousfish : 실제로 한 단계 더 나아가는 것을 생각하고 있습니다. 할당 시에도 ":"에서 이러한 특수 변수를 분할하고 인용된 확장에서 공백 대신 ":"으로 결합합니다.

즉, set -gx MANPATH "$MANPATH:/new/path" 하면 물고기가 자동으로 분할을 수행하여 set -gx MANPATH "" /new/path 와 동일한 결과를 얻습니다.

이제 이것은 ":"가 $MANPATH(및 $PATH 및 $CDPATH)의 경로에 나타날 수 없다는 것을 의미합니다. 그러나 물고기가 아닌 유틸리티를 중단시키기 때문에 어쨌든 그렇게 할 수 없습니다 !

그것은 또한 우리가 언젠가 특별한 처리를 제거할 수 있게 해줄 것입니다. 왜냐하면 그것은 그것을 처리하는 교차 호환 방법을 추가하기 때문입니다 - : 로 할당하고 (string split : -- $MANPATH) 와 함께 사용하면 됩니다.

@faho 아이디어를 내고 있습니다. 사용자는 어떻게 변수를 이 특별 대우를 받는 것으로 표시할까요? splitenv 하시겠습니까?

사용자는 이 특별 대우를 받는 변수를 어떻게 표시할까요?

내 생각은 실제로 마킹을 전혀 허용하지 않는 것이었습니다. $PATH et al에 대한 특별한 동작으로 두십시오. 그러면 미래의 어느 시점에서 목록화에서 벗어날 수 있습니다.

그러나 다른 변수에 대해 이것을 허용하면 다른 변수에도 도움이 된다는 것을 이해하게 되었습니다. 예를 들어, 이전에 내 $EDITOR가 외부와의 호환성을 위해 하나의 요소( set EDITOR "emacs -nw" )로 설정되었다고 말했습니다. 도구이지만 물고기는 그것이 목록이라면 더 좋아할 것입니다.

따라서 PATH와 유사하지 않은 경우(그리고 이름이 PATH로 끝나는 경우라고 가정하면 아마 괜찮을 것입니다) 구분 기호로 _space_를 기본값으로 사용합니다.

splitenv가 할 것인가?

나는 이것을 위해 다른 내장을 도입하는 것을 정말로 좋아하지 않으므로 아마도 argument-to-set 옵션을 사용할 것입니다.

나는 "특수 케이스 PATH/MANPATH/CDPATH가 이상하다. 우리는 더 일반적인 솔루션이 필요하다"는 데 동의합니다.

특수 케이스 PATH/MANPATH/CDPATH를 중지할 것을 제안합니다. 그것들은 다른 조개 껍질과 같은 방식으로 (어류 최종 사용자에 의해) 취급됩니다. $PATH(및 기타)는 콜론이 포함된 단일 문자열(또는 생선 전문 용어로 길이가 1인 목록)입니다. 이러한 것들이 내부적으로 처리되는 방식이 아니라 물고기 사용자 경험을 언급하고 있다는 점에 유의하십시오. 나는 물고기 내부의 구현이 어떻게 생겼는지 모릅니다. 나는 다른 사람들에게 의존하여 문제를 지적합니다.

물론 하위호환성이 없다는 단점이 있지만, 심플함과 우아함 면에서 큰 이득을 볼 수 있다는 점에서 그만한 가치가 있다고 생각합니다. 나는 그것이 # 2090도 다룰 것이라고 생각합니다.

다들 어떻게 생각하세요?

5245가 병합되어 해결된 것 같습니다.