이것은 globbing이 수행되지 않기 때문에 rm , ls 등을 사용하게 만듭니다.

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

어쩌다.

사용성 동기화는 일반적으로 별칭없이 대화 형 환경이 좋지 않다는 데 동의합니다. 우리가 동의하지 않는 것은 기본적으로 기본 바이너리를 사용하려는 사용자에게 제공되어야하는 대안입니다. 플로팅 된 몇 가지 옵션은 다음과 같습니다.

• * nix 바이너리와 충돌하는 모든 별칭을 끄는 환경 변수
• 기본 PATH에 자동으로 포함되는 단일 문자 (예 ^ )
• 사람들에게 bash -c 한다고 말합니다. (많은 사람들이 문자가 너무 많아서 사용할 수 없다고 말했습니다.)
• 사람들에게 전체 경로를 제공해야한다고 말합니다 (이 경험은 기술적으로 이미 작동하지만 매우 좋지 않음).
• 추가 제안 : "힌팅 하위 시스템"을 활용하여 기본 * nix 바이너리에 대해 패턴과 일치하는 매개 변수 세트를 사용하는 경우 기본 명령을 사용하고 싶었을 수도 있음을 사람들에게 알리십시오. 이것은 명령이 실패 할 때만 작동 할 수 있습니다 (예를 들어 rm -e 는 실패하지 않습니다).

나는 이것이 우리가 조만간 알아 내고 싶은 것이라고 생각하기 때문에 v0.5.0으로 옮겼습니다. 제 생각에는 모드를 전환하는 PowerShell 설정이 가장 좋은 첫 번째 단계입니다.

@andschwa 및 기본값은 ....?

@vors 내 _personal_ 의견 : PowerShell 별칭이 활성화되었습니다. PowerShell을 실행하고 있기 때문입니다.

결국 우리는 어쨌든 PowerShell에 대한 최초 시작 "시작"가이드를 원할 것이며 이것이 사용 가능한 설정이라고 명시 할 것입니다.

@BrucePay에 대한 업데이트가 있습니까?

오늘 사용성 동기화는 별칭을 다시 입력해야한다고 반복했습니다. ( sort 로 파이프하는 것은 PS 경험이 완전히 손상되는 또 다른 데이터 포인트입니다.)

Bruce를 양수인으로 남겨두고 위의 완화 조치를 통해 최선의 경로를 결정합니다. @andschwa : 별칭을 되돌리려면 작업을 수행 할 다른 사람이 필요할 것입니다.

방금 @jpsnover 와 대화를 않는다는 것을 매우 분명히했습니다. 받은 편지함 aliases.ps1 파일을 만들고 도트 소싱을 홍보해야합니다.

bash의 ls 는 일반적으로 단순히 ls 가 아니라 일부 기본 인수가있는 별칭이며 색상을 사용하여 출력하는 것이 가장 주목할만한 별칭이라는 점을 지적 할 가치가 있습니다.

PowerShell 별칭은 Linux의 별칭처럼 전혀 작동하지 않으므로 ls 를 함수로 정의하거나 bash 별칭처럼 작동하도록 별칭을 개선해야합니다.

또한 갤러리에서 모듈을 분석하는 데 시간을 할애하여 별칭이 제거 된 상태에서 작동하지 않는 모듈 수를 확인하는 것도 가치가있을 수 있습니다. sort 가 특히 중요합니다.

별칭은 오늘에 없습니다. 우리는 8 월 17 일에 사람들이 참여할 별칭 상황의 장단점에 대해 건전한 토론을해야합니다.

문제를 종결시키는 이야기가있는 것 같습니다.

이에 대한 내 2p-PSv3에 도입 된 $ PSModuleAutoLoadingPreference와 유사한 새로운 PowerShell 설정 변수를 사용하면 최종 사용자가 프로필에서이를 제어 할 수 있습니다 (PS를 사용하거나 사용하지 않고 실행되는 일부 명령을 보여주는 간단한 예제를 함께 만들 수도 있음). 좋은 별칭

추천 이름 $ PSUsePowerShellAliases 및 명시 적으로 true로 설정되지 않은 경우 (프로필 내에서 또는 대화 형으로) 표준 * nix 별칭이 제자리에 사용됩니다.
나는 이것이 이전에 해보지 않았을 PowerShell로 물을 테스트하기로 결정한 사람들에게 더 나은 UX를 제공 할 것이라고 생각합니다. 그렇게하기 위해.

그들이 아는 것을 빼앗지 않고

물론. 타협이 필요하다면 Linux Bash 사용자, 즉 잠재적 인 새로운 PowerShell 사용자를 선호해야합니다. 기존의 PowerShell 충실한 사람들은 * nix 별칭을 충분히 쉽게 다시 만들 수 있지만 해당 별칭을 제거 할 수 있습니다.

사실 이제 Linux에 PowerShell이 ​​있으므로 PowerShell Core의 모든 OS 버전에서 제거 된 기본 제공 * nix 별칭을보고 싶습니다. 그러면 기본 제공 PowerShell 명령과 일치하는 기본 제공 별칭이 남게되며 "속이는"시도를하지 않습니다.

저는 기본적으로 Linux의 ps에서 공통 별칭을 제거하는 팬입니다. Keith가 제안한 것처럼 Windows에서이 문제를 "수정"하는 팬이 아닙니다. 이에 대한 내 주장은 Linux 사용자를 PowerShell로 이기고 Windows에서도 사용하기로 결정하면 공통 별칭이 없다는 것입니다.

Linux 별칭을 활성화하는 기능인 PSReadline에 추가 할 수 있습니까? 나를 위해 함수에 짧은 이름을 사용하는 코드를 수정하는 것은 간단합니다. 그래도 항상 LS 먼저 입력하고 Get-ChildItem 대한 PowerShell LS 별칭처럼 작동 할 것으로 예상합니다.

이 문제를 사용하여 PowerShell의 동작이 무엇인지에 대한 의견을 표명하십시오.

@kilasuit , @rkeithhill 및 @ 1RedOne 이 가장 좋은 해결책이라고 생각합니다. Linux 및 macOS에서는 기본적으로 비활성화했지만 동시에 콘솔이나에서 쉽게 활성화 할 수 있습니다. 우리 스크립트.

기존 스크립트를 업데이트하여이 변수를 확인하고 즉시 옵션을 비활성화하거나 활성화 할 수 있으며, 예상대로 작동하지 않는 짧은 이름을 찾기 위해 많은 코드를 따르는 것보다 훨씬 좋습니다.

주제에서 벗어남-다른 플랫폼에서 PowerShell을 사용할 수 있다는 사실에 대한 기대 이상! 😄

즉 전혀 PSReadline를 사용하지 않는 @juneb 같은 사람들이 있기 때문에 내가 PSReadLine에 대한 요구 사항보다 PS 변수로 선호하는 것하지만 전혀 가능성이있는 경우 PSReadLine에 관한 것은 다음 @lzybkr 제안 할 수 있어야한다

특정 별칭을 PowerShell cmdlet으로 대체하기 위해 PSReadline에 대한 샘플을 확실히 게시 할 수 있습니다.이 샘플은 https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354를 기반으로합니다.

그건 진짜 해결책이 아닌 것 같은데 ..

제 생각에 가장 큰 문제는 스크립트 이식성과 친숙 함 사이의 충돌입니다. 스크립트가 별칭을 사용해서는 안된다는 지침을 제공했지만 여전히 일반적인 관행입니다. 일부 별칭은 다른 별칭보다 문제가 더 클 수 있습니다. 예를 들어 sort ls 는 스크립트에서 ps 또는 ls 보다 많이 사용될 수 있습니다.

우리는 해당 별칭을 다시 가져 오기 위해 방금 가져온 모듈을 제공하는 것과 같은 몇 가지 옵션에 대해 확실히 논의했습니다. 그러나 우리는 아직 아무것도 결정하지 않았으며 더 많은 피드백을 기대하고 있습니다.

지원을 중단하지 않고 PowerShell 명령을 기본 실행 파일로 바꾸는 것은 bash 사용자가 PowerShell을 사용하도록 설득하는 데 확실히 도움이되지 않습니다.

자, 여러분, 네이티브 실행 파일에 글 로빙 지원을 추가하는 것이 더 나을까요? 그러면 모든 문제가 해결되고 모든 사람이 PowerShell을 더 유용하게 사용할 수 있습니다. 링크 # 954.

창을 거의 만져본 적이없는 * nix 사용자로서 저는 별칭을 남겨 두는 것에 대해 강력한 투표를하고 싶습니다. 수년간의 근육 기억을 통해 ls , rm 사용을 배웠습니다

내가 틀렸다면 정정하십시오. 그러나 Windows에서 dir 와 다른가요? Windows의 PS에서 dir 는 dir.exe 가 아닙니다. Get-ChildItem 입니다. * nix에서 스크립트에서 왜해야 ls 수 /bin/ls 대신 Get-ChildItem ?

@Gaelan 나는 당신의 요점을 얻었지만 Windows에는 dir.exe 파일이 없다는 것을 고려하십시오. dir 는 bash 내장과 유사한 cmd 명령 프로세서의 내부 명령입니다. PowerShell이 ​​외부 dir.exe 명령을 직접 호출하도록 설계되지 않았기 때문에 이것이 (하나) 이유 일 수 있습니다.

@Gaelan , @ForNeVeR : cmd-built-ins는 프로그램으로 존재하지 않기 때문에 충돌하지 않지만 Windows에서도 기본 실행 파일과 충돌하는 PowerShell 별칭이 있습니다.

일반적으로 나는 이론적으로 모든 단일 별칭 ( ? 와 같이 파일 시스템에 존재할 수없는 별칭 제외)이 기본 실행 파일을 섀도 잉 할 수 있기 때문에 별칭을 안전하게 유지하고 항목을 손상 시키지는 _ 않는 _ 안전한 방법이 있다고 생각하지 않습니다

PS> gal|?{gcm "$_.exe" -ea 0}

CommandType     Name
-----------     ----
Alias           fc -> Format-Custom
Alias           sc -> Set-Content
Alias           sort -> Sort-Object
Alias           where -> Where-Object
Alias           write -> Write-Output

따라서 유일한 _safe_ 경로는 별칭을 전혀 갖지 않는 것이므로 목적에 위배됩니다. 그리고 의심 할 여지없이 기본 별칭이 가장 편리합니다. 사실 여기에는 좋은 대답이 없습니다.

개인적으로 별명을 남겨 두는 것을 선호합니다. 일반적으로 탐색 및 일반 쉘 사용을 더 빠르고 편안하게하기 위해 존재합니다. 이를 제거하면 PowerShell 사용 환경이 저하됩니다.

대신 내장 Linux 바이너리를 호출하고 있음을 나타내는 방법을 추가 할 수 있다는 생각을지지합니다. 프로필 선호도일까요?

여기의 역사를 살펴보면 동등한 비 Windows 명령에 매핑되는 별칭에 대한 UX 관점에서 최고의 솔루션이라고 생각하는 것을 제안했습니다.

이것은 오랫동안 지속되어 온 PowerShell 문제입니다. cmd의 dir 또는 ls 필적하는 명령이 없다고 불평합니다. 응답은 매번 "하지만 별칭이 있습니다!"입니다.

별칭은이 문제에 대한 해결책이 아니며 결코 해결책이 아닙니다. dir 및 ls 별칭은 dir 및 ls 제공하는 기능을 제공하지 않습니다. wget 및 curl 별칭도 마찬가지입니다.

별칭에 대한 전체 접근 방식을 재고해야하며 이는 중대한 변화를 의미합니다.

시스템 정의 별칭이 PATH의 바이너리에 대한 2 등급 시민이 될 수없는 이유는 무엇입니까?

Linux에서 * nix 별칭을 모두 제거하면 OS X가 수행 할 작업을 알아낼 때까지 빌드됩니다.

편집 :이 작업이 이미 완료되었음을 명확히 해주셔서 감사합니다.

이미 완료된 @okket . 변경이 필요한지 논의 중입니다.

사람들이 프로필에서 소싱 할 수있는 파일에 모든 별칭을 넣은 다음 기본 시스템 별 프로필을 제공해야합니다.

bash-aliases.ps1
dos-aliases.ps1
initial-aliases.ps1

다른 것이 없다면 모든 사람이 동일한 짧은 이름을 가지고 있지 않다는 것을 사람들에게 상기시켜줍니다.

의 PowerShell을의 별칭 이름 바꾸기를 제외하고 _do_ 것을 명령 및 재정의 명령을 확인 순서를하지 않는 (@sleepypikachu)을 잊지 말자. Bash의 alias 기능에는 PowerShell에서 _functions_가 필요합니다.

@Gaelan 귀하의 근육 기억은 별칭을 사용하도록하지만 실제 명령과 동일하게 작동하지 않는 매개 변수와 동작에 실망 하시겠습니까?

이것이 진짜 문제이며 @DrPizza 가 자리 잡고 있습니다. 좋은 예는 _dir / s_입니다. 이 명령은 PowerShell에서 실패하므로 dir -recurse로 변경해야합니다.

여기에는 실제로 세 가지 관련 문제가 있습니다.

1. 모든 매개 변수가 별칭이 아닙니다.
2. 모든 기본 매개 변수 또는 동작이 PowerShell CmdLet에 매핑되는 것은 아닙니다.
3. 별칭이있는 경우 기본 명령을 실행하는 방법이 필요합니다.

나는 # 1이 문제가 너무 나쁘다고 생각하지 않으며 별칭이 지정되면 상황을 악화시킬 것입니다. Dir -recurse는 어쨌든 dir / s보다 더 읽기 쉬운 매개 변수입니다. 또한 크로스 플랫폼을 사용하면 Windows에서 Linux로 또는 그 반대로 이동하려고 할 때 스크립트가 일관성이 없게됩니다.

2 번과 3 번이 가장 중요합니다. 나는 curl을 사용하지 않았지만 Invoke-WebRequest로 인해 curl이 할 수 있다고 기대하는 한계에 부딪혔다는 것을 알고 있습니다. (머리 꼭대기에서 기억하지 마십시오).

단기적으로는 구성 옵션과 별칭이 활성화 된 경우 네이티브 명령을 호출하는 방법이 모두 필요하다고 생각합니다.

기본값은 활성화 된 상태로 둡니다. Linux에서 PowerShell ....입니다. 사용할 CmdLets를 학습 할 수 있도록 PowerShell로 작동해야합니다. Linux 및 Perl 배경이있는 동료는 스크립트 작업에 필요한 cmd를 파악하는 것이 훨씬 쉽다는 것을 알았습니다. 그에게 핵심이었던 것은 grep, ls, man이었다고 생각합니다. man을 사용하면 cmd를 올바르게 사용하는 방법을 알아낼 수 있습니다.

장기적으로 네이티브 cmdlet에 적용 범위를 추가하여 네이티브 명령의 모든 매개 변수와 기능을 갖습니다. 이는보다 강력한 옵션을 제공하여 Windows 및 Linux 용 PowerShell을 향상시킵니다. 일부 비헤이비어는 여러 CmdLet으로 변환하고 개체 및 파이프 라인을 사용해야 할 가능성이 있지만 이는 대단한 일입니다! 그렇게하지 않았다면 PowerShell의 요점은 무엇일까요?

내 의견은 그대로 유지하는 것입니다. PowerShell에 별칭 없음 (선택 등 제외, 필수 항목 임), Windows PowerShell의 별칭.

옵션을 제공하는 것이 더 좋지만 모든 별칭을 옵션으로 제공하는 것은 불가능하지 않습니다.

내가 쉽게 Where-Object를 사용하여 파일을 필터링 할 수 있기 때문에 dir에 ls 별칭을 갖는 IMHO는 의미가 있습니다. 나는 수년 동안 Linux 사용자였으며 dir을 입력하는 것은 ls를 사용하는 것만 큼 자연스럽지 않습니다.

일관성이 중요하다고 생각합니다. 나는 다른 플랫폼에서 별칭을 제거하는 것에 반대하는 것이 아니라 OS에 따라 다르게 작동하는 인터페이스를 갖는 것이 나를 괴롭 힙니다. * nix에서 PS를 실행하는 주요 포인트 중 하나는 모든 것을 관리하는 하나의 인터페이스라는 것입니다. 새로 지원되는 플랫폼의 PowerShell에서 별칭을 제거하려면 Windows에서도 제거해야하는지 여부를 고려해야한다고 생각합니다.

아니요, PS가 기본적으로 별칭을 제공한다는 것을 강력히 지원하지만, 아래의 실제 기능은 입력 지원을 제외하고 원래 네이티브 바이너리와 정확히 동일한 기능 (및 매개 변수 호환성)을 가져야합니다.
유형이없는 PowerShell은 쓸모가 없습니다.

기본 시스템 바이너리를 사용하고 유닉스 도구 철학을 채택하면 채택이 촉진됩니다. 유닉스 상점에서 데브 옵스를하는 사람으로서, 나는 일반적인 유닉스 바이너리가이 구현에서 어느 정도 작동하고 있다는 사실에 놀랐습니다. * 문자 문제와 관련하여 * nix 쪽의 대부분의 사람들은 * nix 쉘 글롭을 표시 할 때 * nix 쉘 글롭을 표시 할 때 * nix 쪽의 이스케이프 문자를 사용하는 것이 현재 powershell에서 수행되는 것과는 대조적으로 편할 것이라고 생각합니다. 아마도 수용 가능한 솔루션이 될 것입니다 | 파일 사이를 통과하는 옥텟 스트림 대신 객체를 생성하는 파이프는 게시 된 표준에 위배되며 채택을 방해합니다. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis 참고 : 아무도 PowerShell에서 유형을 제거하지 않습니다 . gci 및 Get-ChildItem 는 Windows PowerShell과 Linux PowerShell 모두에서 동일하게 유지됩니다. 여기서는 ls -> Get-ChildItem 와 같은 내장 별칭이 Linux에 존재해야하는지 여부에 대해서만 이야기합니다. Get-ChildItem 를 호출하려는 경우 스크립트 는 ls 또는 gci 를 호출해서는 안됩니다 (스크립트에서 별칭을 사용하는 것은 권장되지 않으며 권장되지 않았기 때문입니다). ls 및 gci 는 명령 줄 사용을위한 편리한 별칭 일 뿐이며 ls 가 갑자기 Get-ChildItem 별칭이 지정되고 그의 별칭이 아닌 경우 Linux 사용자를 _ 혼동시킬 수 있습니다. 좋아하는 기본 명령; 이 명령을 직접 호출하는 간결한 방법이 없다면 더욱 혼란 스러울 것입니다.

나는 powershell에서 별칭을 활성화하는 명령을 사용합니다.
모든 별칭을 유지하고 Windows PowerShell에서 천천히 사용하지 않습니다.

나는 다음과 같은 명령을 사용한다고 생각한다.

Enable-Alias Unix
Enable-Alias dos

별칭을 사용하려면 다음과 같은 이점이 있습니다.

1. 네이티브 컬을 사용하고자하는 사람들의 문제를 해결합니다.
2. 사람들이 스크립트에서 별칭을 사용하지 않도록 권장합니다 (스크립트의 가독성을 떨어 뜨림).
3. 또한 이러한 별칭을 좋아하는 사람들이이를 활성화하는 것도 매우 쉽습니다.
4. 성능을 거의 손상시키지 않습니다.

@ForNeVeR 저는 ls 를 gci 하루 종일 사용합니다.
그러나이 변경 사항 (unix-y 및 dos-y 별칭 제거)을 도입하는 것은 확실히 주요 변경 사항입니다 ( curl 와 같지 않음). "완벽한"솔루션은 이러한 명령을 기존 도구의 유형화 된 향상에 구현하는 것입니다.
스크립트의 경우 using 문일까요?

@ForNeVeR @ be5invis를 오해했다고 생각합니다. 그는 powershell의 강력한 지지자입니다. 그가 의미하는 "타입없는 파워 쉘은 쓸모가 없다"는 것은 사람들이 파워 쉘에서 네이티브 컬을 사용해서는 안된다는 것입니다.

@ be5invis 또한 네이티브 컬의 호환성에 대한 아이디어가 멀리 도달했다고 생각합니다. 파워 쉘 문법 예를 들어, 당신은 할 수있는 표준 유닉스 문법과 호환되지 않습니다 rm -rf 유닉스에 있지만 PowerShell에서 당신이 할 필요가 rm -r -fo .
따라서 어떤 경우에도 매개 변수 호환성에 도달 할 수 없습니다.

@chantisnake 그러면 -recurse -force 동일한 "rf"라는 매개 변수를 추가하지 않겠습니까?

@ be5invis 이것은 PowerShell에서 매개 변수가 작동하는 방식에 위배됩니다. 직교하며 그렇지 않은 경우 다른 매개 변수 세트가 있습니다. 또한 긴 이름 만 있으며 짧은 이름 대신 명확하게 유지되는 한 개별적으로 축약 할 수 있습니다. 귀하의 경우에는 해당 매개 변수 fr 별칭을 추가해야합니다. 또한 갑자기 -Recurse 를 더 이상 -r 로 줄일 수 없지만 대신 제안 된 -rf 매개 변수와 충돌하지 않으려면 -re 가되어야합니다.

다른 쪽에서도 동일한 질문을 할 수 있습니다. 두 매개 변수를 별도로 지정하지 않는 이유는 무엇입니까? 비록 그렇지 않더라도 여전히 동일한 Unix 도구로 작업하고있는 것처럼 가장하기 위해 PowerShell 코드 원칙 및 규칙을 상당히 크게 위반할 의향이 있습니다. 그러나 짧고 긴 이름을 사용하는 GNU 매개 변수 규칙은 보편적이지 않으며 tar 또는 find 와 같이 잘 확립 된 많은 도구가이를 위반합니다. 그러나 버그 추적기를 변경하기 위해 팔짱을 끼지 않았습니다. 유닉스의 핵심 부분은 항상 약간 씩 다른 방식으로 작동하는 수십억 개의 다른 유틸리티 프로그램이 있다는 것이었지만, 갑자기 또 다른 하나를 갖게되는 것 (분명히 더 많은 것을 수행하고 그 자체로 많은 다른 유틸리티를 포함하려고 시도 함)은 너무 당황스럽고 문제가있어서 변경해야합니까? 나는 그렇게 생각하지 않는다.

기억하십시오 : 컴퓨터의 셸은 사용자의 것입니다. 그냥 별명 명으로 rm 에 rm -i 자신의 편안함을 위해, 거기 제거에서 당신을 방지 아무것도 rm 별칭과 기능 포장이 Remove-Item 라는 rm 와 -rf 매개 변수.

그러나 모든 Unix 도구를 완전히 복제하기 위해 PowerShell 전체를 변경하려는 시도는 상당히 잘못된 것입니다.

ls 의 기능과 출력은 수년 동안 잘 정의되어 있습니다. ls 명령은 잘 알려진 형식으로 옥텟 스트림을 출력합니다. ls 명령은 DirectoryInfo 및 FileInfo 개체를 출력하지 않습니다. ls 다른 것을 출력하는 것은 최소한 혼란스럽고 약간 기만적 일 수 있습니다.

사용자가 파이프 라인의 개체를 활용할 준비가되면 Get-ChildItem 및 gci에 대해 학습하게됩니다. 사용자가 파이프 라인에서 객체의 이점을 얻거나 처리하지 않으려는 경우 bash, ksh, csh, sh 등을 사용하는 것이 더 나을 수 있습니다.

Windows의 DIR 명령에 대해서도 마찬가지입니다.

* nix를 * nix로 만들고 Powershell을 최상의 상태로 만드십시오.

뿡뿡

사용자가 파이프 라인의 개체를 활용할 준비가되면 Get-ChildItem 및 gci에 대해 학습하게됩니다. 사용자가 파이프 라인에서 객체의 이점을 얻거나 처리하지 않으려는 경우 bash, ksh, csh, sh 등을 사용하는 것이 더 나을 수 있습니다.

이것은 당신의 요점과 모순됩니다. 사람들이 Powershell을 사용하는 경우 파이프 라인의 개체를 원할 것입니다. 이를 활용하기 위해 기본 명령을 다시 배우면 안됩니다.

@Gaelan과 동의하십시오.
누군가 객체를 원하지 않는 경우 bash 또는 zsh로 간단히 전환 할 수 있습니다.
그들은 객체의 이점을 원하고 ls 와 같은 것을 호환 가능하지만 유형이 지정된 버전으로 별칭을 지정하면 원하는 것을 정확하게 얻을 수 있습니다.

@Gaelan 및 @ be5invis , 사용자가 Powershell을 사용하기 위해 수행해야하는 변경의 양을 제한하려는 욕구를 이해합니다. 내 뇌가 신호를 보내기 전에 내 손가락이 ls 를 입력하는 것 같습니다.

문제는 객체를 생성하지 않는 기존의 기본 명령입니다. 실제 변경은 ls 에서 gci 로 변경되지 않습니다. 더 큰 변화는 텍스트 줄을 처리하기 위해 행해진 생각에서 객체의 속성과 객체에 적용 할 수있는 방법에 대해 생각하는 것입니다.

원하는 별칭을 만드는 것은 모든 사용자의 권리입니다. 사용자가 $ Host (System.Management.Automation.Internal.Host.InternalHost)에 메서드와 속성을 추가하여 네이티브 명령 대체를 활성화 또는 비활성화함으로써이 작업을 쉽게 수행 할 수 있다는 데 동의합니다. 다른 사람을 본 적이 있지만 Powershell에 포함 된 GUI 프로필 구성 도구가 있습니까?

누군가 객체를 원하지 않는 경우 bash 또는 zsh로 간단히 전환 할 수 있습니다.

몇 년 동안 bash를 사용한 후 PowerShell 물에 몸을 담그기로 결정한 사람들에게 PowerShell이 ​​"쉬운 진입로"를 제공 할 수없는 이유는 무엇입니까? 그들이 알고있는 것부터 시작하여 PowerShell을 사용하는 것이 더 편안 해짐에 따라 PowerShell 기능 (예 : 개체 방출 명령 및 파이프 라인의 개체)을 단계적으로 시작하도록합니다.

"_PowerShell is a shell . 좋아하는 기본 유틸리티를 잘 실행할 수 있습니다 _"라는 줄을 몇 번이나 사용해야했는지는 알 수 없습니다. 실제로 PowerShell을 사용해 보도록 유도합니다. PowerShell은 널리 사용되는 기본 유틸리티를 최대한 존중하고 사용할 수 있어야합니다. 그것은 결국 "쉘"의 주요 작업 중 하나입니다.

@rkeithhill 그럼 제가 /bin/ls 와 같은 기본 도구는 유형과 통신 할 수 없습니다. 따라서 유형이 지정된 셸로 전환하지만 유형이 지정된 유틸리티가 없으면 변경 사항이 의미가 없습니다.

따라서 일반적인 Unix 사용자는 동일한 명령을 입력하되 입력 된 결과를 직접 얻을 수 있습니다. 따라서 두 가지 옵션이 있습니다.

1. 목적 a는 IPC 프로토콜을 입력하고 자신의 도구를 업데이트 리누스에게 - 아니오, 그들은 wont't, 그것은 그들의 적 목적의 때문에, 악마 주, 자유 세계의 파괴자! 그들은 우리를“포옹하고 소멸”시킬 것입니다! 또는...
2. 별칭 ls 는 호환 가능한 매개 변수가있는 내장 기능입니다.

사용자는 Powershell을 사용하기를 원하지만 유형을 원합니다.

결국 그들은 아마 그렇게 될 것입니다. 즉 (뭔가 CMD가 제공 할 수없는) 나는 단지 힘내와 포쉬 - 힘내와 함께 사용하여이를 판매하여 내가 PowerShell을 시작했습니다 DEVS의 번호와 작업했다. 이 시점에서는 거의 파이프 라인을 사용하지 않지만 거기에 도달 할 것으로 예상합니다. 즉, git.exe 유틸리티는 CMD에서 동작하는 것처럼 PowerShell에서도 동작합니다. 쉬운 전환.

나에게 ls (ps, grep, sed, awk, gcc, curl 등)는 "쉘"이 실행할 수있는 또 다른 기본 유틸리티 일뿐입니다. 이제 누군가 컨테이너 내용을 나열하기위한 객체 방출 명령을 사용할 준비가되어 있고 원하는 경우 Get-ChildItem 또는 별칭 gci 있습니다. 기본 ls 유틸리티를 사용하지 않을 정도로 구부러진 경우 프로필에서 Get-ChildItem에 대한 ls 별칭을 만들 수 있습니다.

BTW 저는 Get-ChildItem 매개 변수를 ls 와 호환되도록 만들려고하는 것이 불가능하다고 생각합니다. 대소 문자를 구분하지 않는 PowerShell 매개 변수 (예 : -c / -C, -d / -D, -i / -I)를 사용하면 매우 빠르게 전화를 끊을 수 있습니다. 그리고 PowerShell은 ls -rt와 같은 매개 변수 결합을 지원하지 않습니다. 도달 범위이며 PowerShell의 Monad 원칙을 위반합니다. 정렬과 같은 작업은 Get-ChildItem 자체가 아니라 별도의 cmdlet (Sort-Object)에 의해 수행됩니다.

@rkeithhill 나는 Get-ChildItem 를 ls 와 호환되도록 만들지 않을 것입니다. UnixCompatibles-ls 라고하는 다른 cmdlet을 전체 이름으로 사용하고 PowerShell 대신 GNU getopt 플레이버를 허용하는 별도의 명령 파서를 가지고 있습니다.

@ be5invis 그 시점에서 더 쉬운 옵션은 ls 를 실행하고 모든 인수를 전달하고 출력을 구문 분석하고 개체를 만드는 별도의 함수가 아닙니까? 완전히 분리 된 명령 구문 분석기 (완전히 분리 된 명령 메타 데이터와 함께 Get-Help , ...에 대한 형식 지정)는 약간 과잉입니다 (호환되지 않는 방식으로 PowerShell의 내부 작업 대부분을 복제하는 것과는 별개로).

여기에는 항상 두 개의 분리 된 세계가있을 것입니다. 하나는 네이티브이고 하나는 타이핑입니다. PowerShell은 네이티브 프로그램과 cmdlet을 실행할 수 있으므로 이미 두 가지를 모두 지원합니다. 개인적으로 PowerShell 내에서 매개 변수 메타 데이터를 복제하는 기본 명령 위에 계층을 추가하려고 시도 할 때 어떤 이점 (개발 노력에 대한 엄청난 노력)을 보지 못했습니다. 게다가 AFAIK가 GNU 규칙을 따르지 않는 tar 또는 find (및 기타 많은 프로그램)에 대해 무엇을 하시겠습니까? 아직 _another_ 명령 파서를 구현하고이를 호출하는 래퍼 함수와 함께? 명령 구문 분석기가 작동하려면 기본 프로그램의 인수가 PowerShell 내에서 구문 분석되어야하며 언어와 충돌하지 않아야합니다. [ 와 같은 이상한 것들로는 어려울 수 있습니다.

@ygra 도 괜찮습니다.

사용자는 Powershell을 사용하기를 원하지만 유형을 원합니다.

@ be5invis , 아마도 이것은 약간의 연결이 끊어지는 곳입니다. 아니요, 그들은 유형을 원하지 않습니다. 사용자는 자신의 일을 끝내고 싶어합니다. 사용자는 ls 가 텍스트 스트림을 생성한다는 것을 알고 있습니다.

UnixCompatibles 는 동사입니까? 사용자의 $ PROFILE 스크립트가 영구적으로 변경됩니까, 아니면이 세션에 대해서만 변경됩니까? Get-ChildItem이 ls와 호환되는 것을 원하지 않습니다. ls 를 ls 하고 ls 는 일을합니다. 이것은 사용자에게 ls 를 Get-ChildItem 로 대체 할 수있는 선택권을주는 것처럼 들립니다. 괜찮아. 나는 그것을 원하는지 확실하지 않지만 원하는 사람들에게는 괜찮습니다.

@Liturgist @ be5invis가 의미하는 바는 사람들이 Powershell로 전환하는 데 어려움을 겪는 경우 (Bash에 머무르는 것과는 반대로) Powershell이 ​​제공하는 것을 원하기 때문이라고 생각합니다. 사람들이 ls 에서 텍스트 스트림을 원했다면 (Linux 또는 macOS에서) Powershell을 사용하지 않았을 것입니다.

@Gaelan 그래서 gcc 또는 git을 사용해야하는 경우 PowerShell을 사용하지 않아야합니까? 사람들이 텍스트 (ls) 또는 객체 (gci)를 원하는지 결정하게하는 것이 잘못된 이유는 무엇입니까? PowerShell을 사용하는 이유는 OO 특성보다 강력합니다. C / C #과 같은 제어 흐름 문 (vs if / fi 및 switch case / esac)과 적절한 형식 시스템 (숫자는 문자열이 아니라 숫자 임)에만 PowerShell을 사용하고 싶습니다.

뿡뿡

따라서 gcc 또는 git을 사용해야하는 경우 PowerShell을 사용하지 않아야합니까?

* nix 시스템에서 사용자가 gcc 또는 git 용 셸을 사용하기를 원하면 OS와 함께 제공되는 셸이 완벽하게 잘 수행하기 때문에 PowerShell을 사용하지 않아도됩니다.

Heck 나는 제어 흐름 문과 같은 C / C #에만 PowerShell을 사용하고 싶습니다 (vs if / fi 및 switch case / esac)

아마도 누군가 이미 PowerShell을 사용하고 있다면 그 때문에 그것을 선호 할 것이지만 누군가가 그것을 위해 PS를 설치할 것 같지 않습니다.

적절한 유형 시스템 (숫자는 문자열이 아니라 숫자 임)

/bin/ls 는 유형 시스템에서도 작동하지 않습니다. ls -l 실행하면 적절한 PS 번호 대신 문자열로 파일 크기가 표시됩니다.

새로운 사용자가 * nix에서 PS로 전환하는 이유는 주로 OO와 유형 시스템을 중심으로 이루어집니다. 새로운 사용자가 PS를 시작할 수 있도록 가능한 한 쉽게 만들어야합니다. PS에 대한 내용을보고 확인해 보려고했지만 사용하기 위해 명령 줄에 대한 모든 것을 다시 배워야한다는 사실을 알게 된 경우에만 가능했을 것입니다. 내가 PS를 실행하고 ls 하고 즉시 유형 시스템이 작동하는 것을 볼 수있는 것보다 배우는 데 신경 쓰지 않을 가능성이 훨씬 적습니다. 예, 별명을 사용할 수 있지만 몇 분 안에 PS를 시험 해보고 있다면 뛰어 들어 놀기 전에 많은 구성을하고 싶지 않을 것입니다.

* nix 시스템에서 사용자가 gcc 또는 git 용 셸을 사용하기를 원하면 OS와 함께 제공되는 셸이 완벽하게 잘 수행하기 때문에 PowerShell을 사용하지 않아도됩니다.

아마도 누군가 이미 PowerShell을 사용하고 있다면 그 때문에 그것을 선호 할 것이지만 누군가가 그것을 위해 PS를 설치할 것 같지 않습니다.

미안하지만 동의하지 않습니다. 리눅스 사용자로서, 나는 나의 OS와 함께 제공되는 대신 쉘의 PowerShell을 사용하고 싶습니다. 모두를위한. 굉장하기 때문에 알다시피 :)

도대체 모든 것에 사용하기 위해 지금은 NixOS 용 PowerShell을 패키징하고 있습니다.

우리의 대상 사용자는 실수로 Windows + PowerShell을 사용하는 기본 Unix 사용자 일뿐만 아니라 실수로 Unix + PowerShell을 사용하는 Windows 사용자입니다.)

기본 PATH에 자동으로 포함되는 단일 문자 (예 : ^)

나는 또한 별칭이 이러한 플랫폼에서 유효 할 때마다 OS간에 호환되도록 유지하고 이스케이프 문자 (예 ^ls )를 사용하여 @joeyaiello가 제안한대로 네이티브 명령에 대한 암시 적 액세스를 얻습니다.
저는 PowersShell의 전체 철학에 익숙하지 않지만 그러한 접근 방식에 무엇이 문제가 될 수 있습니까?

사실, 단일 문자 이스케이프 사용에 대한 또 다른 요점은 bash가 이미 수행하고 있습니다. https://twitter.com/climagic/status/806536501232340992

\ls 은 모든 별칭을 무시합니다.

별칭에 대한 대답은 WSL (Linux 용 Windows 하위 시스템)을 활성화하여 해결됩니까? 이것은 bash 셸에서 네이티브 sed, awk, ls 등의 명령을 제공합니다.

여전히 Windows 10 용 베타 코드이지만 서버 2016 및 2012에서 제공 될 예정입니다.

@Liturgist 현재 WSL은 PowerShell과는 매우 별개의 환경입니다. 명령은 PowerShell 세션에서 호출 할 수 없습니다. 그들은 GNU, 말,의 출력을받은 경우 많은 스크립트가 휴식하는 것처럼 또한이 가능성이 많은 현재 Windows PowerShell 사용자가 회귀 간주됩니다 ls 보다는 ls -> Get-ChildItem . 별칭의 사용은 스크립트에서 권장되지 않았지만 실제로 사용되어 손상되면 많은 사람들이 어려움을 겪을 수 있습니다.

@Liturgist : @bgshacklett 이 바로 여기에 있습니다. 문제는 ls 를 입력 할 때 어떤 일이 발생한다는 ls | Where-Object Name -like *foo* 에서 객체 지향 방식으로 소비 가능한지 여부입니다. WSL ls 사용하는 경우 ls | Where-Object Name -like *foo* 이 작동하지 않습니다.

기본 cmd와 별칭이 충돌하는 원래 문제가 해결되었습니다. 널리 사용되는 Windows PowerShell 별칭을 다시 추가 할 수있는 기능이 필요한 경우 이는 별도의 문제입니다.

https://github.com/PowerShell/PowerShell/issues/3610 을 열어 2 차 문제 캡처