Powershell: powershell.exe를 호출하기위한 더 짧은 이름으로 pwsh 만들기

나는 너무 짧은 별칭을 싶지만, 이것은 우리가 이동되지 않은 이유는 posh 우리가 처음 밖으로 갔을 때 (우리가 길이에 대해 이야기). 나타납니다 최신 패키지도 여전히 할 수 있습니다.

다른 제안에 개방적이지만 대부분의 명백한 * sh 제안이 채택되었습니다. 유일한 wget / curl 별칭 이후, 덜 일반적이더라도 다른 패키지와 충돌하는 것을 정말로 피하고 싶습니다.

나는이 모든 아이디어에 너무 열광하지는 않지만 pwsh 어떻습니까?

나는 powershell의 단축으로 포쉬에 열중 한 적이 없습니다. pwsh가 더 좋아 보이지만 빠른 인터넷 검색은 몇 가지 가능한 문제를 제기합니다. 우리가 이것을한다면 가능한 한 짧게 제안 할 것입니다. 그래서 ps는 어떻습니까?

좋아요-잊어 버려요-방금 ps가 get-process의 별칭이라는 것을 깨달았습니다. 그것은 너무 혼란 스러울 것입니다

나는 지금 강한 데자뷰를 얻고있다. 😉

PowerShell의 가독성을 높이 평가하므로 (별칭을 사용하지 않을 때) powershell 실행하면 잘 작동합니다.

ps 는 Linux에서도 기존 명령입니다.

기타 아이디어 : pscmd , psc , monad , psh , pshell

이 이름은 실제로 무엇이든 저장하는지 또는 사용 가능한 경우 불필요한 혼란을 추가하는지 여부에 관계없이 확실히 감소하는 수익이 있습니다.

CoreSh , pcs , psc

너무 나쁜 mosh 가 사용됩니다. psh 가 사용됩니다. [pshell]은 많은 히트를 반환합니다. 흥미롭게도 Bing과 Google 모두에서 msh 를 검색하면 PowerShell (Microsoft Shell이라고 함)에 대한 많은 히트가 표시되지만 Unix에는 msh 가 있습니다 (아마 많이 사용되지 않음).

😄 S #, P #

@ PowerShell / powershell-committee는 이에 대해 논의했으며 더 짧은 심볼릭 링크 이름을 가질 수 있지만 이미 존재하는 누구에게도 스쿼트를 할 수는 없습니다. prsh 괜찮아 보입니다.

기다려, 기다려! 알았습니다 : ^sh -아니면 **sh 입니까? (jk).

prsh 은 (는) 합리적으로 보입니다. 예를 들어 pwrsh 이지만 pwsh 보다 입력하기가 더 쉽습니다. 더 이상- "pwr"이 "power"의 알려진 약자이므로 고려할 가치가 있습니다.

또 다른 _complementary_ 옵션 : _invariably_ 값이 현재 세션을 시작한 바이너리의 동일한 경로를 반영하는 _automatic 변수 _를 제공합니다.

bash 에는 $BASH 가 있습니다.

이 접근 방식의 장점은 $env:PATH 의 / 조작의 변형에 영향을받지 않는다는 것입니다.

우리는 이미 $PSHOME -틀림없이 $PS 와 같은 것은 너무 무리가 아닙니다.

즉, 이것은 자동 변수로 전역 네임 스페이스를 오염시키지 않는 것에 대한 논의와 관련이 있습니다. # 4216을 참조하십시오.

.Net Core, CoreFX, CoreCLR, PowerShell Core- "코어"를 기본으로 간주 할 수 있습니다.

pscore 다른위원회 구성원이 거부했지만 sh 끝나지 않아도 괜찮아 보입니다.

pscore 또는 coreps -LGTM.

monad 및 msh (위에 언급)를 기억할 수 있습니다.

나는 지금까지 pwrsh 를 가장 좋아합니다. pscore 도 6 자에서 다소 길어지고 있지만 나쁘지 않습니다. 4 개 이하의 문자가 이상적 일 수 있지만 pwrsh 필요한 5 개의 문자로 살 수 있습니다.

"핵심"이라는 단어를 통합하는 것에 대한 나의 우려는 유닉스 플랫폼에서 유용한 정보를 전달하지 않는다는 것입니다. 여기서 구별해야 할 다른 에디션이 없습니다.

@rkeithhill 어때요 pscx , 하! PowerShell 핵심 경험. 그래도 pscsh , PowerShell Core Shell을 생각하게되었습니다.

나는 같은 이름의 일부를 찢어 버렸습니다. pwrsh 및 pscore 의 가독성이 마음에 들지만 5 자 제한에 동의합니다. 5 개의 문자는 첫 번째 단어 power 를 포함하며 전체 내용을 입력하는 것이 좋습니다. monad 은 훌륭한 이스터 에그이며 읽기 쉽지만 PowerShell의 배경을 모르는 사람들에게는 혼란 스럽습니다. 4 자 prsh 도 잘 작동합니다.

사용할 수있는 최종 이름 목록을 만들고 Edge 팀이 한 것처럼 공식 투표를하는 것이 좋을 것입니다. 예정된 PS 커뮤니티 또는 공식 이벤트가있는 경우 더 많은 청중에게 다가 가기 위해 투표 링크를 제공 할 수 있습니다.

@ dragonwolf83 :

pscsh 는 위험 할 정도로 csh 가깝습니다-우리는 피해야 할 연결입니다.

다시 말하지만 "핵심"이라는 단어를 포함해도 아무런 이점이 없습니다. 특히 에디션이 언젠가 통합 될 가능성이있는 경우 (그리고 _Windows_에서는 사람들이 10 년 동안 _Windows PowerShell_에 대한 짧은 이름없이 편안하게 살았던 것 같습니다) .

monad 의 다시 모호함을 동의했습니다.

내 개인 투표는 pwsh , prsh 또는 pwrsh 입니다.

추신 : 경우 _WINDOWS PowerShell_은 단순히 함께 접두사, 짧은 이름이 필요합니다 w , 해결책이 될 수 내 즐겨 찾기 중 비록 그와 같은 키보드에서 정말에만 (합리적으로) 롤 wprsh , 그래서에서 두 가지 버전의 짧은 이름 시나리오에서 내 투표는 prsh / wprsh 쌍입니다.

"핵심"이라는 단어를 통합하는 것에 대한 나의 우려는 유닉스 플랫폼에서 유용한 정보를 전달하지 않는다는 것입니다. 여기서 구별해야 할 다른 에디션이 없습니다.

:-) .Net Core의 이름을 바꿔야합니까?

@iSazonov : Windows PowerShell의 이름을 "Windows PowerShell .NET Framework [FullCLR]"로 바꿔야합니까?

저는 psh 투표 할 것입니다. 충돌로 언급 한 프로젝트는 10 년 동안 출시 되지 않았으며 어떤 경우에도 패키지 저장소에 포함되지 않았습니다.

@Jaykul :

psh ? 몰라요-더 많은 "핵심"이 필요합니다.

농담 제쳐두고 : 프로젝트의 상태와 패키지 저장소에 대한 부재에 대한 훌륭한 포인트.

psh 도 내 투표를 받았습니다 (Windows PowerShell의 경우 wpsh ).

(각각 'pshaw'와 'whiplash'로 발음).

psh 도 내 투표를 받았습니다 (Windows PowerShell의 경우 wpsh ).
(각각 'pshaw'와 'whiplash'로 발음).

창에서 posh 만 사용하면 안 되나요? 🤡

피시 토시! 그것은 전체 mishpocha에 대해 너무 많은 혼란입니다. 🤡

나는 psh에 투표 할 것입니다. 충돌로 언급 한 프로젝트는 10 년 동안 출시되지 않았으며 어떤 경우에도 패키지 저장소에 없었습니다.

카피 라이트 문제가 없습니까?

저작권 문제가 없습니까?

나는 진정으로 _ 알고있는 _ 누군가가 무게를 읊기를 바라지 만, 내 _guess_는 두 가지 이유로 이것이 문제가되지 않을 것이라는 것입니다.

• psh 은 (는) 공식적인 제품 이름이 아니라 단순히 기술적 인 도움이되는 이니셜 (보다 느슨하게 말하면 두문자어) 일뿐입니다 (일반적인 사용에서는 결국 전체 제품 이름에 대한 일반적인 속기가 될 수 있습니다. 상표 이니셜 / 약어).

• 상표 문제는 종종 기존 상표와 _ 혼동 _ 할 가능성에 관한 것입니다. 여기에서 본 것에서 적어도 소프트웨어 공간에서는 충돌이없는 것 같습니다 (거의 존재하지 않는 기존 psh 의 제작자는 생각하지 않습니다.

누군가 실험을 원하거나 임시 해결책이 필요한 경우 :

다음은 지원되는 모든 플랫폼에서 PowerShell 내부 및 외부 모두에서 별칭을 정의하는 모든 별칭 솔루션입니다. PS Core의 경우 psh , Windows PowerShell의 경우 wpsh 입니다.

• PowerShell을의 별칭 바깥 설정하는 ONCE 다음을 실행 (에 cmd.exe 윈도우에 대한 bash 유닉스) :

  # Note: 
  #   * On Unix, this will define alias `psh` for *interactive* Bash sessions,
  #     via initialization file ~/.bashrc (Linux) or ~/.bash_profile (macOS).
  #   * On Windows, this defines doskey.exe-based aliases `psh` and `wpsh`
  #     via registry key [HKEY_CURRENT_USER\Software\Microsoft\Command Processor],
  #     value 'AutoRun', and even though *any* cmd.exe instance will run
  #     these alias definitions, they only work in *interactive* ones.
  #     Note that both aliases open a new window.
if ($env:OS -eq 'Windows_NT') {
  $cmd = 'doskey wpsh=start powershell.exe & doskey psh=powershell.exe -nologo -command "psh"'
  $currVal =  try { Get-ItemPropertyValue 'HKCU:\Software\Microsoft\Command Processor' AutoRun } catch {}
  if (-not (Select-String -Quiet -SimpleMatch -Pattern "$cmd" -InputObject $currVal)) {
    if ($currVal) { $cmd += " & $currVal" }
    Set-ItemProperty 'HKCU:\Software\Microsoft\Command Processor' AutoRun $cmd
  }
} else {
  $cmd = 'alias psh=powershell'
  $initFile = ("$HOME/.bashrc", "$HOME/.bash_profile")[(uname) -eq 'Darwin']
  if (-not (Select-String -Quiet -LiteralPath $initFile -Pattern "^\s*$cmd\b")) {
    Add-Content -LiteralPath $initFile -Encoding utf8 "`n$cmd"
  }
}

• $PROFILE 에 다음을 입력하여 PowerShell 내부에 동일한 별칭을 정의합니다. PS Core와 Windows PS 모두에서 작동합니다.

  # ===
  # Portable alias definitions for PowerShell Core (`psh`) 
  # and, on Windows, for Windows PowerShell (`wpsh`) too.
  #
  # Place them in $PROFILE.
  #
  # * On Unix, invoking `psh` always runs the new instance in the current terminal window.
  # * On Windows, only invoking the same edition runs in the current console window.
  #   Invoking the respective other edition opens a new window; if you also
  #   pass a command, add -NoExit to keep the new window open.
  #
  # ===
  if ($env:OS -eq 'Windows_NT') { # on Windows
    if ($PSVersionTable.PSEdition -eq 'Core') { # running in a PS Core session
      # PS Core alias: Invoke the same binary that started the current session.
      Set-Alias psh "$PSHOME\powershell.exe"
      # Windows PowerShell alias
      function wpsh {
        # Assume a fixed location in SYSTEM32.
        $exe = "$env:SYSTEMROOT\System32\WindowsPowerShell\v1.0\powershell.exe"
        $psModulePathSav = $env:PSModulePath
        try {
          # Note: We must remove all *\PowerShell\* entries from $env:PSModulePath, because they are Core-specific
          #       and interfere with module loading in Windows PowerShell.
          # Note that Start-Process -UseNewEnvironment is NOT an option: see https://github.com/PowerShell/PowerShell/issues/3545
          $env:PSModulePath = (($env:PSModulePath -split ';') -notmatch '[/\\]PowerShell[/\\]') -join ';'
          # Start Windows PowerShell in a new window.
          $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
          Start-Process $exe <strong i="18">@htArgs</strong>
        } finally {
          $env:PSModulePath = $psModulePathSav
        }
      }
    } else { # running in a Windows PowerShell session
      # PS Core alias:
      Function psh {
        # Given that the PS Core *.exe is not in $env:PATH as of PowerShell Core v6.0.0-beta.5, determine its location.
        # Since multiple versions may be installed, find the highest version installed.
        # Unfortunately on PSv5.1- [semver] ([System.Management.Automation.SemanticVersion]) is not available, so we fall back to the *.exe files' last-write timestamp.
        # WISHFUL THINKING: Set-Alias psh ((Get-ChildItem -Directory $env:ProgramFiles\PowerShell | Sort-Object -Descending { [semver] $_.Name })[0].FullName + '\powershell.exe')
        $exe = ((Get-ChildItem -File $env:ProgramFiles\PowerShell\*\powershell.exe | Sort-Object -Descending LastWriteTime)[0].FullName)
        # Note: The Core-specific module directories are automatically added to $env:PSModulePath, so no other action is required.
        # Start PS Core in a new window.
        $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
        Start-Process $exe <strong i="19">@htArgs</strong>
      }
      # Windows PowerShell alias: invoke the same executable that started the current session.
      Set-Alias wpsh "$PSHOME\powershell.exe"
    }
  } else { # on Unix (Linux, macOS)
    # Simply invoke the same binary that started the current session.
    Set-Alias psh "$PSHOME/powershell"
  }

Paua 어떻습니까? 이것은 아름다운 전복 조개 (뉴질랜드 산 바다 조개)에 대한 언급입니다. 그렇지 않으면 psh 도 좋다고 생각합니다.

뉴질랜드 해안에서 조개를 파나요? (농담입니다. 정말 아름답습니다.)

면책 조항 : 다음 내용은 [취미] 언어 전문가에게만 관심이 있습니다.

음성 학적으로 paua 는 영어의 비 로트 성 방언 (예 : 영국, 뉴질랜드, 호주)에서만 작동합니다.

그리고 Bostonians.

@ PowerShell / powershell-committee는 beta.8을 위해 이것을 닫아야합니다.

Posh6는 어떻습니까

Posh6는 어떻습니까

파일 확장자에 버전 번호를 넣는 것보다 빨리 구식이 될 것 같습니다 ...;)

예,하지만이를 실행하는 쉘 스크립트는 실행중인 버전을 알 수 있습니다.

나는 posh 를 좋아하지만, 주된 관심사는 Posh 라는 기존 Linux 용 패키지가 있으므로 또 다른 curl 사고를 피하기 위해 다음으로 좋은 옵션은 pwsh 라고 생각합니다.

나는 pwsh 좋아합니다. 10 년 전에 있으면 좋았을 텐데. msh 그리워합니다.

나는 psh 투표합니다.
gnp / psh 는 거의 5 년 동안 약속되지 않았습니다. 포기할 수도 있습니다.

나는 그것을 말하기 싫지만 이것은 강한 합의를 얻기가 너무 어려울 수도있는 것들 중 하나입니다. : \

이 시점에서 모든 것을 닫고 어떤 종류의 충돌도 피하기 위해 (합법적 인 것보다 더 "선의"), 저는 pwsh 에 올인합니다.

이 방법으로 물어 보겠습니다. pwsh 하지 않을 강력한 이유가있는 사람이 있습니까?

pwsh 이 실행 파일의 이름이고 powershell 가 심볼릭 링크 / 바로 가기이면 누구든지 우려할까요?

여기에서 승인하기 전에 "현재"버전이 무엇이며 어떻게 참조하고 대상 버전을 참조 할 것인가?

@iSazonov가 귀하의 질문을 이해하지 못합니다. powershell -v N 와 관련이 없습니다. 이렇게하면 pwsh 대신 powershell (하지만 powershell 철자는 여전히 지원됩니다).

내 관심사는 powershell-> powershell-6.0.0-beta.7과 같은 심볼릭 링크에 대한 것입니다.
언어에 대해 말하면 대화식 세션에서 별칭을 좋아합니다. 편안한 환경을 제공하기 때문에 별칭은 스크립트에서 큰 골칫거리입니다. powershell 짧은 이름에 대해서도 똑같이 보입니다. 아마도 속도 유형에는 좋지만 디렉터리 트리 (symlinks)에는 실제로 문제가 될 수 있습니다.

또 다른 생각. 속도 유형에 대해 생각해 볼까요? 제안 된 모든 사례가 이러한 관점에서 좋은 것은 아닙니다.
마지막 생각은 발음입니다. 흥미롭게도 러시아어에서는 PowerShell 탄생 이후 "пош"( "posh")와 hypocorism "пошик"( "poshik")을 사용합니다. 러시아인이라면 누구나 "posh"또는 "psh"에 투표 할 것이라고 생각합니다.

명확하게 말하면 pwsh 는 별칭 (PowerShell 용어)이 아니므로 cmd.exe 또는 물리적으로 존재하는 배치 파일에서 호출 할 수있는 것이어야합니다. 두 개의 실행 파일없이 짧은 이름과 powershell 를 모두 지원하려는 경우 실제로 구현하는 방법은 명확하지 않지만 poweshell.exe는 비교적 작습니다.

posh 및 psh 대 pwsh 경우 posh 및 psh 의 주요 관심사는 이미 존재한다는 것입니다 (아무리 눈에 띄는 지에 관계없이 아르). curl 별칭이 기존의 기본 도구와 충돌하여 초기에 문제가 발생했으며 (아마 여기서 지나치게주의를 기울 였을 것입니다) 우리는 짧은 손으로 비슷한 상황을 피하려고합니다. pwsh 쪽으로 기울고 있습니다. 아마도 pwsh 자주 입력하면 충분한 사람들이 익숙해 질 것입니다. :)

다른 쪽. PowerShell에서 동일한 문제를 어떻게 해결합니까? 사용자 별칭 및 IntelliSense를 사용하여 입력을 시작하는 것이 좋습니다.
여기서 논의 중 하나에서 별칭에 대해 논의 할 때 현재 모든 별칭이 읽기 전용이 아니어야한다고 말했습니다. 사용자가 별칭을 제거 / 변경할 수 있도록 허용해야합니다. 즉, 별칭이 배타적으로 표준이되어서는 안됩니다. 기본 cmdlet 이름 만 표준이어야합니다. 이러한 관점에서 "powershell"에 대한 "표준"별칭을 제공해서는 안됩니다. 모든 커뮤니티 또는 배포자는 자신이 좋아하고 정신에 맞는 이름을 선택할 수 있어야하며 IntelliSense도 제공 할 수 있어야합니다.

@ SteveL-MSFT-나는 'pwsh'가 아마도 사람들과 잘 어울릴 것이라고 생각합니다.

즉, 여러분은 'psh'를 사용하지 않는 이유로 컬 사건을 언급했습니다. 나는 당신이 너무 멀리 평행선을 그려서 구석으로 자신 (우리)을 권투하고 있기 때문에 문제가 있음을 발견했습니다!

'curl'은 리눅스 세계에서 가장 많이 사용되는 도구 중 하나입니다. '살아있는'/ '액티브 한' 소프트웨어에 대해 '컬'을 반복하지 않도록 지나치게 조심하는 것이 현명한 데, 왜이 예의가 포기하는 것으로 확장되어야 하는가?

컬 사건이 우리에게 교훈을 가르쳐주게하세요. 잘못된 것이 아닙니다.

@AdilHindistan 의 조언을 지원하기 위해 하겠습니다 (쓰레드가 길어지고 추적하기가 어렵습니다).

나는 psh에 투표 할 것입니다. 충돌로 언급 한 프로젝트는 10 년 동안 출시되지 않았으며 어떤 경우에도 패키지 저장소에 없었습니다.

즉, psh 가 (주요) 패키지 리포지토리의 일부가 아닌 것처럼 보였습니다 ( apt (Ubuntu, Debian) 및 yum (Fedora, RedHat))-즉, 항상 _ 틈새 제품이었습니다.-_ 그리고 _ 모든 의도와 목적을 위해 10 년 이상의 활동이 없으면 버려지는 것으로 간주되어 완벽한 후보가되었습니다.

(반대로 posh 는 유지 관리 상태에 관계없이 apt 를 통해 여전히 사용할 수있는 패키지라는 사실은 제 생각에 자격이 박탈됩니다.)

psh 이 실행 가능한 옵션이며 고려되어야한다는 점에 동의합니다.

실제 실행 파일의 이름이 powershell[.exe] 유지된다고 가정하여 짧은 이름을 심볼릭 링크 / 스텁으로 _implement_하는 방법은 다음과 같습니다.

짧은 이름이 예를 들어 psh 라고 가정 해 보겠습니다 (토론 된 이름 중 하나를 무작위로 선택하기 위해).

Unix 플랫폼

설치 프로그램은 _additionally_ 다음과 같은 작업을 수행해야합니다.

# Linux
/usr/bin$ sudo ln -s powershell psh

# macOS
/usr/local/bin$ sudo ln -s powershell psh

즉, 단순히 기존 powershell 심볼릭 링크를 가리키는 psh 라는 추가 심볼릭 링크를 만듭니다.

macOS에서는 다음과 같은 심볼릭 링크 체인이 생성됩니다.

/usr/local/bin/psh@ -> /usr/local/bin/powershell@ -> /usr/local/microsoft/powershell/6.0.0-beta.7/powershell

PS 코어 자체를 포함하여 모든 호출 쉘은, 따라서 사용할 수있을 것입니다 psh 에 짧은 대안으로 powershell .

윈도우

Windows에서는 상황이 더 복잡합니다.

• 최소한 beta.7부터 PS _Core_의 _outside_에서 PATH에있는 것은 _Windows_ PowerShell뿐입니다.
• : 대상 호출을위한 파워 쉘 코어 대 Windows PowerShell을위한 별개의 shorthands이 있어야합니다 psh PS 코어 및 wpsh 가 프로그램도 사용하지 않기 때문에이 이름이 너무 잘해야한다 (윈도우 PS에 대한 apt 및 yum 저장소).

Windows PS

_Windows_ PS는 다음과 같이 $env:SystemRoot\System32\PowerShell\v1.0 (64 비트) 및 $env:SystemRoot\SysWOW64\PowerShell\v1.0 (32 비트)에 각각 하나씩 심볼릭 링크를 정의 할 수 있습니다.

Set-Location $PSHOME
cmd /c mklink wpsh.exe powershell.exe

$PSHOME 가 $PATH 에 있기 때문에 PS Core 및 Windows PS 자체를 포함한 모든 쉘은 Window PS를 wpsh 로 호출 할 수 있습니다.

PS 코어

속기 파일 자체는 기본적으로 PATH에있는 디렉토리에 배치 될 수 있으므로 PS Core의 $PSHOME 자체가 PATH에 있지 않아도 호출이 가능합니다.

64 비트 대 32 비트 고려 사항은 적용되지 않으므로 (PS Core는 64 비트 만 해당) $env:SystemRoot (일반적으로 C:\Windows )를 선택할 수 있습니다.

불행히도 _symbolic links_의 사용은 적어도 현재는 옵션이 _ 아닙니다 _. PowerShell Core는 다른 이름을 가진 심볼릭 링크를 통해 호출 될 때 실행을 거부하기 때문입니다.

_elevated_ PS 세션에서 :

Set-Location $env:SystemRoot   # typically, C:\Windows
cmd /c mklink psh.exe "C:\Program Files\PowerShell\6.0.0-beta.7\powershell.exe"

psh.exe 호출은 다음과 같이 실패합니다.

The managed DLL bound to this executable: 'powershell.dll', did not match own name 'psh.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

이 문제를 해결하는 방법을 아는 사람이 있으면 알려주십시오.

(호기심, 사용자가 정의하는 경우 심볼릭 링크 _without extension_ - psh 대신 psh.exe -. 호출이 원칙적으로 성공하지만 매개 변수가 통과되지 않음)

해결 방법 은 스텁 배치 파일 을 사용하는 것입니다 (다시 _elevated_ PowerShell 세션에서 실행).

Set-Location $env:SystemRoot   # typically, C:\Windows
'@"%ProgramW6432%\PowerShell\6.0.0-beta.7\powershell.exe" %*' | Set-Content -Encoding ASCII psh.cmd

Windows PowerShell 및 PS Core 자체를 포함한 모든 호출 셸은 PS Core를 호출하는 약어로 psh 를 사용할 수 있습니다.

@ mklement0 Linux / macOS에서 심볼릭 링크를 사용하고 Windows 용 배치 파일을 사용한다는 점에서 똑같은 생각을하고있었습니다 (그리고 Windows PowerShell에서는 powershell 로 유지되므로 Windows PowerShell에서는 아무것도하지 않습니다).

가장 명백한 것은 powershell 이 기본이고 psh 가 링크라는 것입니다.하지만 저는 아마 우리가 그것을 뒤집어서 psh 가 exe와 powershell 는 링크입니다. 그 이유는 Windows가 아닌 사용자를 대상으로하고 Windows PowerShell과 차별화하기 위해 사람들이 psh 를 사용하여 PowerShell Core를 참조하고 powershell 를 제공하는 것이 선호되는 것 같습니다. app-compat (일부 사람들은 전환 할 때 근육 기억). 그러나 모든 사람이이 아이디어에 대해 팔리는 것은 아닙니다.

psh 매우 인기가 많다면 powershell 와 psh 바꿀 수 있습니다.

별칭을 추가 하려면 https://stackoverflow.com/questions/2016722/one-dll-multiple-projects에 도움이 될 수

psh가 exe가되고 PowerShell이 ​​링크로 강등된다는 생각은 마음에 들지 않습니다. 청중 규모를 알 수없고 (최소한 처음부터) 잠재적으로 작을 수있는 비 Windows에서 잠재적으로 쉽게 사용할 수 있도록 10 년 간의 청중 충성도를 버리고 있습니다.

PowerShell v6을 많이 볼수록 Windows가 아닌 사용자가 PowerShell을 채택하도록 설득하려는 시도에서 기존 Windows 사용자가 무시되는 것 같습니다. 이 과정은 어디에서 끝나나요?

@RichardSiddaway PowerShell 팀이 Windows 사용자를 전혀 무시하고 있으며 주로 Windows Phone을 사용하는 Windows 사용자라는 인상을받지 못했습니다. 나는 이것을 리눅스 개념에서가 아니라 cmd에서 powershell로 옮기는 내 자신의 도전에서 이것을 요청한 사람이었습니다.

사실 Windows PowerShell은 성숙한 제품이지만 교차 플랫폼을 염두에두고 구축되지 않았습니다. 이 작업을 수행하려면 초기 투자는 두 세계 모두에 이익이 될 크로스 플랫폼에 더 높아야합니다. 다음 몇 번의 릴리스에서 상황이 균일해질 것입니다.

별칭 및 매개 변수 별칭 외에 Windows 사용자에게 부정적인 영향을 미치는 것은 많지 않습니다. 우려되는 특정 문제가있는 경우 해당 문제에서 제기하십시오. 토론은 플랫폼에 도움이되며 PowerShell에 대한 특별한 사항이 전환 과정에서 손실되지 않도록해야합니다.

@ SteveL-MSFT psh 또는 pwsh 가 .exe가되는 이유를 좀 더 설명해 주시겠습니까? 그것으로부터 얻는 이익이 있다면 나는 그것을 더 선호 할 것입니다.

배치 파일에 아야. 어쨌든 Windows에서 symlink가 작동하도록하려면? 차라리 cmd를 통해 다른 레이어보다 있습니다.

@ dragonwolf83 시간이 지남에 따라 사람들은 10 자보다 3 자 또는 4 자 입력을 선호하므로 항상 powershell 입력을 지원할 것이지만 장기적인 관점에서 보면 더 짧은 버전에 최적화해야합니다.

Windows PowerShell에 대한 의견이 있습니다.

@ dragonwolf83 :

배치 파일에 아야. Windows에서 심볼릭 링크를 작동시키는 방법이 있습니까?

들려요. 아아, 도움을 청하 는 나의

powershell.exe는 78k입니다. psh.exe로 78k를 추가하는 것이 그렇게 나쁠까요?

2 개의 중복 실행 파일을 갖는 것은 쉬운 해결책 일 수 있지만 사용자가 2 사이에 차이가 있는지 고민하기 시작할 것이라고 상상할 수 있기 때문에 혼란을 초래할 수 있습니다. PowerShell을 호출 / 열기하는 방법을 보여 주면 차이점이 있다고 가정하기 때문에 어떤 예제를 선택해야하는지 즉시 궁금해 할 것입니다.

IMO 이것은 바보입니다. cmd.exe는 Windows 10 1703에서 대부분 숨겨져 있으므로 레거시 셸에서 powershell.exe를 실행하는 경우는 거의 없습니다.

이것에 대한 열렬한 팬이 아닙니다. powershell 를 얼마나 자주 입력하여 문제가됩니까? (또한 전체 자전거 통행 문제;)) Windows 10 및 Server 2016에서 "시작 메뉴를 마우스 오른쪽 버튼으로 클릭하거나 Win + X를 누를 때 명령 프롬프트를 Windows PowerShell로 대체"를 설정하면 Win + x, i 또는 Linux의 짧은 길이입니다. , 원하는 이름으로 기존 셸에 별칭을 추가합니다.

즉, 다음은 어떻습니까?

• ps1 -Windows의 파일 확장자 뒤에 짧고 입력하기 쉬우 며 기억에 남는
• psps -짧고 타이핑이 가능하지만 '전형적인 M $ bloat'속어에 개방되어 있습니다.
• ips -Invoke-PowerShell의 경우처럼 RedHat 또는 Ubuntu 리포지토리에 패키지로 표시되지 않고 yum provides "*/ips" 는 빠른 검사에서 충돌 할 바이너리가 없음을 보여줍니다.

이렇게 물어 보겠습니다 : 누구든지 pwsh를 사용하지 않을 강력한 이유가 있습니까?

추악하고 발음 할 수 없으며 'powershell'자체보다 더 많은 음절이 필요하며 입력하기가 특히 쉽지 않으며 인터넷에서 말하는 pwnd / pwnt에서 파생 된 것처럼 보입니다.

Windows에서 PowerShell을 기본 셸로 곧 사용하게되면 파일 이름 (길이)이 중요하지 않게됩니다.

PowerShell Core는 이식 가능한 프로젝트입니다. Unix도 고려해야합니다.

@ PowerShell을 / PowerShell을-위원회는이 문제를 논의 어디에 우리가 도착하는 PSCore6 바이너리 단지라는 것입니다 pwsh 에 대한 추가 바로 가기없이에게 / 별칭 powershell . 이점은 Windows PowerShell을 사용하든 PowerShell Core를 사용하든 Windows에서 모호함없이이를 명시 적으로 만드는 것입니다. Windows가 아닌 경우 입력하는 것이 더 짧고 다른 셸 이름과 더 일치합니다. 고객 피드백에 따라 향후 언제든지 powershell 링크 / 바로 가기 / 별칭을 추가 할 수 있습니다.

내 투표는 psh.exe입니다.

@jandrusk PR 이 어제 이미 병합되었으므로 pwsh.exe가됩니다. Jeffrey는 이미 여기 에 대해 트윗

새로운 PassWord / 주당 / PoliceWoman SHell 만세!

내 투표는 그것을 내버려 두는 것이었다.

그래서 우리는 pwsh를 어떻게 발음하고 있습니까?

pwsh
p.wush
p.woosh
puh.wush

바라건대 그보다 더 나은 것

내가 사용하고 @jonathanmedd pwish 같은 wish A를 p .

_pwsh_가 재귀 적 약어 (_GNU_와 유사)라는 점을 감안할 때-제발, 왜 pwSH입니까? - "제발"이라고 말하는 입술을 가진 귀여운 토끼처럼 "pweesh"를 제안합니다.

제쳐두고 농담 :

• 개인적으로 pwsh 에 정착하는 것이 불행하다고 생각하지만, 곧 익숙해 질 것이며 다시는 생각하지 않을 것입니다.

• 발음에 관해서 : 저는 개인적으로 이름이 충분히 짧고 PowerShell의 세계에 사는 모든 사람에게 매핑이 분명하다는 점을 감안할 때 하나가 필요하다고 생각하지 않습니다. (유닉스 세계의 예 : zsh 는 한 음절이 아니라 zee shell 또는 zed shell 로 발음됩니다.)

P-Dub Shell ?

P Double U Shell 또는 P Double U S H 는 말하기가 고통 스럽습니다. PowerShell 보다 더 많은 음절이 있지만 PowerShell 를 pwsh 와 구분하고 싶을 것입니다. bash 가 Bourne-Again Shell 와 구별되는 것과 같습니다.

아마도 PowerShell과 pwsh를 구별하고 싶을 것입니다.

공식적인 전체 이름 의 관점에서 보면 _PowerShell Core_ 대 _Windows PowerShell _-_
컨텍스트에서 명확하지 않은 경우 적절한 한정자를 추가하면 명확 해집니다. 그리고 아마도 그렇게 자주 필요하지 않을 것입니다 (예 : 순수 Unix 컨텍스트에서).

장기적으로는 PowerShell Core가 "모든"플랫폼에서 실행되는 에디션이라는 점을 감안할 때 _PowerShell_이 한정자-_Windows_-와 함께 _PowerShell Core_ ( "기본"PowerShell)에 대한 일반적인 비공식 축약 형이 되더라도 놀라지 않을 것입니다. Windows 버전을 참조하는 데만 사용됩니다.

여담으로:

bash가 Bourne-Again Shell과 구별되는 것과 같습니다.

bash _is_ _Bourne-Again SHell_-이전 모델 인 _Bourne SHell_ ( sh ,
POSIX가 언어를 표준화하기 전에).

@ mklement0 저는 pwsh 바이너리를 PowerShell 언어 / 쉘과 구별하는 것에 대해 이야기하고 있습니다. PowerShell의 다른 구현 / 플랫폼을 구별하지 않습니다. bash 이 바이너리를 Bourn-Again SHell 와 구별하는 데 사용되는 것과 같습니다. 그것들은 서로 바꿔서 사용할 수 있지만 2를 구별해야 할 때 pwsh 발음하는 명확한 방법이 필요합니다.

푸시 : 미소 :

그래서 아마도 :

p shell 또는 p w shell

@markekraus :

아, 설명 해주셔서 감사합니다.

바이너리의 _exact_ 이름을 전달하려면 _spelling out_이라는 짧은 발음이 없으면 이름이 도움이 될 것입니다 ( posh 와 같은 경우에만 작동했을 것입니다).

따라서 _PowerShell 바이너리 / 실행 파일 _을 참조하는 것은 이미 알고있는 모든 사람들에게 작동해야하며 다른 사람들에게는 어쨌든 철자를 써야합니다.

바이너리의 정확한 이름을 전달하고 싶다면 이름의 철자가 짧은 발음이 도움이되지 않습니다.

우리는 그것에 동의하지 않는 것에 동의해야 할 것입니다 😃.

예를 들어 "bash"및 "posh"와 마찬가지로 작동하는 _desire_를 이해합니다. 그러나 위에서 증명 한 것처럼 "pwsh"와는 작동하지 않습니다. 지금은 붙어 있습니다.

"pwsh"에서는 작동하지 않습니다.

글쎄, 그런 태도로는 그렇지 않습니다! 😉 나는 그것을 pwish 라고 부르고 아마도 계속 그렇게 할 것입니다. 그러나 나는 다른 사람들이 다른 것을 생각해 내는지 확인하기 위해 대화를 만들고 있습니다. push 은 일부 언어의 w 발음을 고려할 때 좋은 것입니다. pwsh 완전히 회복 할 수는 없습니다, IMO. 아마도 모두가 p w s h 에 정착 할 것입니다. 그러나 "우리는 여기서 끝났다"라고 말하고 결정된 문제를 고려하기에는 너무 이르다, IMO.

:)

네가 옳아.

이미 알고있는 사람들 (이미 pwsh 해당 짧은 이름을 매핑하는 방법을 알고있는 사람)을 위해 _ 관습에 따라 _ 설정된 짧은 이름보다는 아직 PowerShell에 익숙하지 않은 사람에게 _ 정확한 철자 _를 전달하는 측면에 너무 많은 초점을 맞추고 있었던 것 같습니다.

MSPosh는 어떻습니까? PowerShell.exe보다 짧고 표준을 따르며 The PowerShell Hero ?

@ 1RedOne PowerShell 영웅 / 아바타는 항상 내 ❤️에서 PoSH-Chan입니다.

PWSH 팀이 이름을 바꾸기 위해 서두르고있는 것 같습니다. :-)

pscmd.exe에 투표합니다.

창에 cmd를 입력하면 실제로 나타납니다! 실제로 cmd를 대체하고 있습니다.

이것이 근육 기억 문제라면 그 문제를 고쳐 보자 ..

멋진 새 이름을 찾는 것이 재미를위한 것이라면 pscore.exe 여야합니다.

내 2 센트.

pwsh , wwrld의 fwremwst Wbject-Wriented 셸. 이 패턴을 계속하는 새로운 cmdlet을 tw 개 사용하고 있습니다.

Get-Cwntent servers.txt | FwrEach-Wbject { 
    Invwke-Cwmmand -CwmputerName $_ -Scriptblwck { .. }
}

;)

-

Ref 발음, " powsh "는 부드러운 "s"와 함께 "pouch"또는 "couch"처럼

The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

이 오류 메시지가이 문제와 관련이 있다고 생각합니다. 이 문제를 어떻게 해결합니까?

실제 이름 문제에 관해서는 Bash가 Bourne Again SHell이기 때문에 pwsh에 투표합니다.

나는 PWSH에 투표합니다. 그리고 나는 그것을 푸시라고 발음 할 것입니다.
나는 커뮤니티에서 posh를 사용하는 것을 많이 보았 기 때문에 MS가 그것을 posh라고 부르지 않으려 고 할 수도 있지만 그것이 나의 두 번째 선택이 될 것입니다.

나는 pwr 투표합니다!

@DaleMitchell 어떻게 그 오류를 얻었습니까? 직접 빌드 한 경우 build.psm1을 다시로드 했습니까?

나는 커뮤니티에서 posh를 사용하는 것을 많이 보았습니다.

예를 들어 https://github.com/dahlbyk/posh-git .

pwsh 은 posh 로 발음됩니다. @SaschaNaz POSH는 불행히도 이미 쉘로 존재합니다.

발음 방법에 대한 @ PowerShell / powershell-committee 투표를 놓쳤습니까? :)

나는 우리가 그것을 Microsoft Next Generation Command Line Interface Shell Experience 2017 로 발음 할 수있을 것이라고 생각했습니다. 아니면 그냥 powershell 라고 발음 할 수도 있습니다.

Microsoft Next Generation Command Line Interface Shell Experience 2017 서비스 팩 2가 출시 될 때까지 사용하지 않습니다.

불행히도 POSH는 이미 쉘로 존재합니다.

예, 사용자가 고급 스러움을 원하고 sudo apt install posh 시도한 다음 완전히 다른 셸을 얻을 때 매우 혼란 스러울 것입니다.

BTW, poh-sh 또는 pah-sh ? 가장 확실하게 후자는?

패키지 이름은 여전히 ​​powershell이며 변경 사항은 없습니다.

sudo apt install powershell

빠른 (의견이있는) 최신 토론 게시물 :

• 바이너리의 _ 파일명 _ : 결정이 내려 져서 공개되었습니다 : pwsh 그렇습니다.

• _ 발음 _의 경우 :

  • 바이너리의 정확한 철자를 _uninitiated_에 전달할 수있는 사람은 없습니다. 철자를 써야합니다.

  • _initiated_에게 "PowerShell"은 틀림없이 필요한 모든 것입니다. _product_ 또는 바이너리 _의 _file 이름 ( @markekraus 의 관심사)을 참조하는지 일반적으로 컨텍스트에서 명확하기 때문입니다. 후자의 경우 입문자는 자동으로 머리 속에 pwsh 로 번역합니다.
    필요한 경우 명확성을 위해 "Core"및 "Windows"를 추가합니다.

  • 말할 필요도없이, 명확한 비공식적 인 한 음절 별명에 대한 열정적 인 탐구는 계속 될 것입니다 ...
    어떤 경우에도 pwsh 에 대한 정신적 매핑 작업이 필요하기 때문에 "Posh"와 같이 비공식적으로 확립 된 사람들은 계속 사용되는 것이 좋습니다.

예전에는 플랫폼 간 스크립트 지원을 위해 MKS Toolkit을 사용했을 때 ksh.exe 했지만 항상 KornShell 라고했습니다. 따라서 바이너리가 pwsh 이지만 PowerShell이라고 부를 것입니다.

바이너리 이름이 pwrsh 이었지만 그 배가 항해했다면이 모든 "바이너리 이름을 어떻게 발음합니까"문제를 피할 수 있었을 것입니다.

"옛날"(15 년 전이 중요합니까?)으로 돌아가서 우리 팀은 바이너리 "kish"라고 불렀고 "KornShell"은 쉘에 대한 일반적인 논의를위한 것입니다.

예:

"ooser bin kish를 입력 한 다음 Enter 키를 누르십시오. 이제 KornShell에 있습니다."

15 년 전이 중요합니까?

내가 추측하는 사람과 다소 상대적입니다. KornShell에서의 경험은 24 년 전에 시작되었습니다. 15 년 전 제 딸은 어렸을 때 그다지 오래되지 않은 것 같습니다. Yikes-시간이 빠릅니다.

우리 팀은 바이너리 "키시"라고 불렀습니다.

그렇게 발음 한 적이 있다고 말할 수 없습니다. :-)

그렇게 발음 한 적이 있다고 말할 수 없습니다. :-)

네. 그 팀 밖에서는 항상 "ksh"또는 "KornShell"이었습니다. 그러나 그것은 일종의 요점입니다. 사람들이 "pwsh"( "PowerShell"없음) 문자를 어떻게 발음할지 논의하고 합의가 있는지 확인합니다. 그것은 완전히 진지한 토론이 아니며 발음 할 수없는 단어이기 때문에 공식 발음이되지 않을 것입니다 (팀에 대한 무례 함은 없습니다- push ). 하지만 아마도 인기있는 경쟁자가 이기고 프레젠테이션에서 듣기 시작할 것이라는 장점이 있습니다.

Microsoft에서 일하기 전에 저는 Unix 사람이었으며 항상 ksh Korn Shell 및 csh C Shell을 호출했습니다. 나는 그들을 단어로 발음하려고했던 그 당시에 아무도 기억하지 않는다 : P

누군가 이와 같은 주요 변경 사항이 발생한 이유를 간결하게 설명 할 수 있습니까? 나는 루프를 벗어 났고 (분명히!) @powerschill 과 채팅을하고

지금 바로 기여 과정에 대해 다시 읽었습니다. 처음에는 RFC가 필요하다고 생각했지만 어떻게 적용되지 않는지 알 수 있습니다. 다음으로 주요 변경 사항에 대한 정책 (https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md)을 살펴 봅니다. 이 변경 사항이 어떤 버킷에 포함되었는지 등에 대해 언급 할 수 있습니까?

명확하게 해결 된 것을 자극하지 않고, 스펙과 이슈를 읽지 않는 관심있는 다른 사람들과 효과적으로 소통 할 수 있기를 바랍니다. 감사!

@ halr9000 https://github.com/PowerShell/PowerShell/issues/4214#issuecomment -335989245

내 2c. 이것은 주요 변경 사항입니다. 기존 프로덕션 시나리오에서 너무 많은 기존 배치 파일이 이미 powershell.exe를 사용하여 PowerShell 스크립트를 시작합니다. 동일한 실행 파일을 시작하기 위해 추가 짧은 명령을 제공하는 것에 반대하지는 않지만 'powershell'을 제거하면 큰 혼란이 발생합니다. 둘 다 사용하는 방법을 제공하십시오 (별칭 또는 기타).

@RudolfHenning 이전 버전의 Windows PowerShell과 달리 PowerShell Core는 다른 버전의 자체 및 이전 버전의 Windows PowerShell과 나란히 작동합니다. 의도 한 EXE의 전체 경로를 호출 할 필요없이 또는 powershell.exe 에서 잘못된 호출을 초래하는 경로 순서의 위험없이 명령 줄과 배치 스크립트에서 Windows PowerShell 및 PowerShell 코어를 모두 호출 할 수있는 방법이 있어야합니다. 버전.

PowerShell Core 6.0이 출시 된 후에도 많은 공식 및 커뮤니티 모듈과 스크립트가 Core에서 사용할 수없는 전체 CLR 개체에 액세스해야하므로 많은 Windows 중심 작업에 Windows PowerShell (5.1 이하)을 계속 사용해야합니다.

또한 이전 버전에서 6.0으로 스크립트를 이식하는 사람은 5.1과 6.0 사이에 상당히 많은 주요 변경 사항이 있기 때문에 조정이 필요할 것입니다. 어쨌든 코드를 터치해야하므로 배치를 pwsh.exe 에서 powershell.exe pwsh.exe 로 전환 할 수 있습니다. PowerShell Core를 포팅하지 않으면 중단되지 않으며 스크립트는 Windows PowerShell을 사용하여 powershell.exe 계속 실행됩니다.

설명 해주셔서 감사합니다.
Windows와 일부 Linux OS를 모두 사용하고 있기 때문에 스크립트의 호환성이 때때로 문제가됩니다. 예, Linux의 PowerShell 라이브러리는 여전히 베타 버전이라는 것을 알고 있습니다. 저는 제 리눅스 머신을위한 스크립트를 만드는 데 상당한 시간과 노력을 투자했습니다.
어쨌든 좋은 일을 계속하십시오!

TeamCity의 Powershell 실행기는 실행 파일이 powershell 라고 가정합니다. Linux에는 호환성 문제를 일으키는 Powershell 5가 없기 때문에 Linux 패키지는 계속해서 powershell 심볼릭 링크를 생성해야합니다. 이것은 불필요한 파손이었습니다.

뭐야, 4 월에 도착 했어? 다음에 PowerShell 커맨드 렛에서 모음을 제거할까요? 농담 이겠네요.

"powershell -command xxxx"를 사용하는 이전 스크립트 (도커)는 새 베타 -9 릴리스에서 더 이상 작동하지 않습니다 ....

폭풍우를 기다리고

"가장 중요한"위치 또는 진입 점에 대한 주요 변경 사항에 대한 많은 이유가 있지만, 명령 이름을 6 바이트로 줄여서 가독성을 떨어 뜨리는 것은 그중 하나가 아닙니다 ....
읽기가 쓰기보다 더 쉬울 수 있고 / 반드시 더 쉬워야하기 때문에 과거에 얼마나 자주 코드 내에서 더 나은 / 긴 이름을 사용하기로 결정했는지 ....

내 2 센트를 구해줘
문안 인사
베르너

나는 분노와 실패를 이해하려고 노력하고 있습니다.

사람들은 새로운 이름이 문제를 일으키고 있다고 불평하지만 PowerShell Core는 아직 베타 버전입니다. IMO, 누군가가 프로덕션 코드에서 베타 기술을 사용하는 경우 재앙을 불러 일으키는 것입니다 (여기서는 정중 한 언어를 사용하고 있습니다). 알파 및 베타 릴리스의 특성은 주요 변경 사항으로 채워지는 것입니다. 이것이 베타가 아니라는 환상은 없습니다. 베타는 버전 이름 6.0.0-beta.9 로 구워집니다.

이 이름 변경은 Windows PowerShell에 영향을주지 않습니다. 현재 Windows에서 수행중인 작업이 중단되지 않아야합니다. Linux에서 작업을 수행하는 경우 베타 버전을 베타 버전이라고 비난하는 대신 베타 버전을 사용하고 있다는 사실까지 소유해야합니다. 베타 릴리스 간의 주요 변경 사항을 처리 할 수없는 경우 안정적인 릴리스가 RTM이 될 때까지 다른 것을 사용하는 것이 좋습니다.

나는 사람들이 이름을 좋아하지 않는다는 것을 알고 있습니다. 항상 원하는 것을 얻을 수는 없습니다. 저는 개인적으로 PowerShell.exe가 길고 입력하기 어색하기 때문에 싫어했습니다. pwsh 은 적어도 내가 엉망으로 만드는 문자가 적습니다. 토론 스레드를 살펴보면 여러 옵션이 pwsh 보다 훨씬 나쁘게 (IMO) 논의 된 것을 볼 수 있습니다.

사람들은 이것을 새로운 바이너리 이름에 대한 주요 동기 중 하나가 Windows와 관련된 멋진 Linux 아이들과 섞이려는 어색한 시도로 오해합니다. 예, Linux-y 이름이 선택되었지만 무엇을 추측합니까? PowerShell은 이제 * nix 시민이기도합니다. 사람들이 그 사실에 익숙해 질 때라고 생각합니다. Core의 목표 중 하나는 플랫폼 간 이식성입니다. 그렇기 때문에 Windows 이상을 염두에두고 결정을 내릴 수 있으며 앞으로 내릴 수 있습니다.

그래서 그것은 나의 2 센트 가치입니다.

Core의 목표 중 하나는 크로스 플랫폼 이식성입니다.

크로스 플랫폼 이식성의 한 부분은 동일한 명령이 동일한 작업을 수행하는 경우 두 플랫폼 모두에서 작동해야한다는 것입니다. 이 변경 전에는 어떤 OS를 사용하든 powershell 실행하여 올바른 것을 얻을 수있었습니다. 이제 더 이상 그렇게 할 수 없습니다.

사용하기 쉬운 소프트웨어를 만드는 것은 수많은 작은 것들을 적절하게 돌보는 것을 의미합니다. 이상하고 직관적이지 않은 이름을 사용하는 것은 그 반대입니다.

내가 사용하는 OS에 상관없이 powershell 실행하고 올바른 것을 얻을 수있었습니다. 이제 더 이상 그렇게 할 수 없습니다.

정확하지 않습니다. Windows에서 powershell 를 실행하고 Windows PowerShell을 가져온 다음 Linux에서 powersehll 를 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 Windows 또는 Linux에서 pwsh 를 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 우리는 당신이 원하는 상태에 있습니다. 이전과 마찬가지로 일관성이없는 상태였습니다.

이상하고 직관적이지 않은 이름을 사용하는 것은 그 반대입니다.

보편적으로 좋아하지는 않지만 ... 어떤 대안을 제안 하시겠습니까? 나는 모든 사람들이 이름에 대해 불평하지만이 이름 변경이 해결하는 근본적인 문제에 대한 대안은 없습니다. 내가 말했듯이 "항상 원하는 것을 얻을 수는 없습니다"

어떤 이름을 선택해도 사람들은 불행 할 것입니다.

뿡 빵뀨

• 이것이 베타 버전이라는 것을 알고 있습니다. 주요 변경 사항은 괜찮습니다!
• Windows에서 * nix로 내 (PS) 지식을 이전하는 데 도움이되므로 * nix에서 더 나은 PS를 만드는 것을 좋아합니다.

내 피드백은 유용성에 관한 것이었고 이름을 다시 바꾸고 끝없는 토론을 강요하는 엄청난 우려였습니다.

Windows에서 powershell을 실행하고 Windows PowerShell을 가져온 다음 Linux에서 powersehll을 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 Windows 또는 Linux에서 pwsh를 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 우리는 당신이 원하는 상태에 있습니다. 이전과 마찬가지로 일관성이없는 상태였습니다.

Windows와 Core를 분리하는 것은 이름을 바꾸고 "짧은 이름 만들기"를하는 더 좋은 이유입니다!

이에 대해보다 명확한 커뮤니케이션을 수행 할 것을 제안합니다 (이슈 제목, 릴리스 노트 등).
나는이 호의 처음 2-3 페이지를 읽었고 토론은 길이에 관한 것이었다 ....

기타 피드백 :
지난주에 저는 Docker와 * nix에서 PS-Core로 많은 코딩을했습니다.
나는 그것을 좋아하지만 약간의 연마가 필요합니다.
아이디어 / 제안 :
이름이 Powershell에서 pwsh로 변경된 경우 버전을 6.0에서 1.0으로 변경하지 않는 이유는 무엇입니까 ( ".Net 5.0"에서 "dotnet core 1.0"으로 변환하는 것과 동일한 논의)
기본적으로 CORE는 특히 * nix에서 버전 1.0, 버전 6과 비슷합니다 !!

문안 인사
베르너

@WernerMairl 6.0.0 # 5165 대신 1.0을 사용하는 것에 대한 공개 토론이 있습니다. 해당 스레드로 이동하여 읽고 의견을 말하십시오.

또한, 당신이 그것을 사용하고 있고 당신이 다듬을 필요가 있다고 생각하는 것들에 부딪 혔기 때문에, 그들이 당신이 겪은 것을 해결하는지 확인하기 위해 열린 문제를 확인하십시오. 미해결 문제가있는 경우 투표하거나 의견을 말하고, 그렇지 않은 경우 새로운 문제를 열어 수정하십시오. 우리 커뮤니티 회원 중 몇몇은 우선 순위가 낮은 문제를 해결하는 데 적극적으로 참여하고 있으며 Microsoft 팀은 더 높은 우선 순위와 더 어려운 문제를 처리하는 놀라운 작업을 수행하고 있습니다. 또한 직접 기여자가 되기에는 너무 늦지 않았습니다!

이슈 설명 및 변경 커뮤니케이션에 대해이 변경 사항에 대한 커뮤니케이션 개선의 여지가 있었고 왜 필요한지에 동의합니다. 이 리포지토리에서 다른 사람의 역할은 다소 혼란 스러울 수 있지만 저는 PowerShell 팀의 일원이 아니며 (본질적으로) 포럼 중재 권한을 가진 커뮤니티 기여자 일뿐입니다. PowerShell 팀을 대변 할 수는 없지만 그들이이 사실을 스스로 이해한다고 생각합니다.

그들의 방어에서 이것은 의사 소통하기가 다소 어렵습니다. 대부분의 불만은 Windows PowerShell과 PowerShell Core의 유사점과 차이점에 대한 이해 부족에서 비롯된 것 같습니다. 이 변경 사항을 효과적으로 전달하려면 7 월 14 일 블로그 기사에 설명 된 내용 을 다시 해시해야했습니다. 그럼에도 불구하고 사람들은 유사점과 차이점을 탐색하는 데 여전히 어려움을 겪고 있습니다. 많은 사람들이 아직 읽지 못했던 이름 변경이 왜 이루어 졌는지에 대한 긴 설명이 필요하다고 생각합니다. 나는 횃불과 갈퀴가 무슨 일이 있어도 왔을 것이라고 생각합니다.

정확하지 않습니다. Windows에서 powershell을 실행하고 Windows PowerShell을 가져온 다음 Linux에서 powersehll을 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 Windows 또는 Linux에서 pwsh를 실행하고 PowerShell Core를 가져올 수 있습니다. 이제 우리는 당신이 원하는 상태에 있습니다. 이전과 마찬가지로 일관성이없는 상태였습니다.

나는 당신이 의미하는 바를 이해하지만 이것이 내가 원하는 것이 아니라고 반박합니다. 내 진술에는 숨겨진 가정이 있습니다. 공통 기능을 사용하는 한 PowerShell과 PowerShell Core는 완전히 동일 할 것으로 예상합니다. 지금까지 모든 사용 사례에서 문제가 발생하지 않았습니다.

@sandersaares 나는 당신의 경험이 행운이라고 믿습니다. 확실히 내 경험과 일치하지 않습니다. 또한 나는 그 가정이 위험하다고 생각합니다. 이것은 완전히 다른 기본 플랫폼을 사용하여 문서화 된 수많은 주요 변경 사항이 포함 된 주요 버전입니다. 이는 이전 버전과 거의 100 % 이전 버전과의 호환성을 제공하는 PowerShell의 이전 주 버전과는 다릅니다.

일부 사람들은 실행 파일 이름을 변경하는 것이 주로 타이핑을 절약하기위한 것이라고 잘못된 가정을하는 것을 봅니다. PR에 사용 된이 원호가 더 짧은 이름을 묻는 제목으로 시작 되었기 때문에 사람들이 어떻게 이런 인상을 받았는지 알 수 있습니다.

모든 사람이위원회가 결정에 대해 내리는 모든 의견을 읽지 않기를 기 대해서는 안되므로 커뮤니케이션을 개선 할 수 있다는 데 동의합니다. 특히 결정의 요약 을 쉽게 잃어 버리는 이와 같이 논란이 많은 부분에서.

특히 Windows PowerShell과 관련하여 PowerShell Core 6이 무엇인지에 대한 근본적인 오해가있는 것 같습니다. Windows PowerShell 5.1은 여전히 ​​Windows에서 제공되는 PowerShell 버전이 될 것입니다. 우리 팀은 또한 필요에 따라 계속 지원합니다. 우리는 고객이 최소한 향후 10 년이 될 수있는 한 Windows PowerShell에 계속 의존 할 것으로 기대합니다. WMF5.1의 다운로드가 마침내 WMF4.0의 다운로드를 능가한 것은 최근의 일이라고 생각합니다.

PowerShell Core 6은 크로스 플랫폼뿐만 아니라 오픈 소스이기도 한 PowerShell의 차세대 진화입니다. @markekraus가 언급했듯이 Windows PowerShell에서는 고려하지 않았던 주요 변경 사항을 수용하는 데 더 많은 유연성을 제공하는 주요 버전 변경입니다. 또한 PowerShell Core 6은 Windows PowerShell뿐만 아니라 다른 PSCore6 버전과도 함께 작동하도록 명시 적으로 설계되었습니다. powershell 를 입력 할 때 Windows에서 얻는 내용이 모호하지 않아야합니다. 6.0 대 1.0 토론은 우리가 공개되기 훨씬 전에 이미 일어 났고 다시 열릴 것 같지 않습니다.

@ SteveL-MSFT의 이름 변경에 대한 블로그 게시물이 좋을 것입니다. Windows의 문제에 대한 명확한 예를 통해 이름이 변경된 이유에 대한 주요 드라이버를 다룰 ​​수 있습니다. posh와 psh가 왜 잘리지 않았는지 설명하는 것도 좋을 것입니다.

압축을 풀고 설치하는 동안 pwsh의 별칭으로 "powershell"을 설정할 수 있습니다. 이 문제를 추적 할 때까지 며칠 동안 작업 중이던 빌드가 깨졌습니다.

편집 : 리눅스에서

@markekraus 에는 무엇과 이유를 보여주는 멋진 블로그 게시물이 있습니다.

https://get-powershellblog.blogspot.sg/2017/10/why-pwsh-was-chosen-for-powershell-core.html

오늘 나는 그 사람 이이 스레드에 대해 알고 있는지 의심 스럽지만 여기 에서 pwsh 의 첫 번째 사용법을 보았습니다.

pwsh 발음에 대한 공식적인 판결을받을 수 있습니까? PNG 사양 에는 섹션 1에 발음이 포함되어 있습니다. PowerShell 용 발음도 제공 할 수 있습니다. 다른 SCSI "scuzzy"/ "sexy"상황을 원하지 않습니다.

나에게 "똥"처럼 보인다.

@apjanke 일반적으로 통용되는 pwsh 발음은 posh

나를 위해 작동합니다. 공식 확인에 감사드립니다!

다른 발음 : ^[1]

• _Pish Posh! _

• _Poppyposh! _

• _ 이전에 PowerShell로 알려진 셸 _ ( 조지아 어로 _TSFKAP_)

• _ 그 이름을 말할 수없는 쉘 (실행 파일의 이름을 발음 할 수 없기 때문에) _ ( 웨일스 어 사용자가 선호 함).

^{[1] [패러디.}