आप ऐसा क्यों सोचते हैं कि "\"a\"" अपेक्षित व्यवहार है? पावरशेल एस्केप की मेरी समझ यह कहती है कि वास्तविक व्यवहार सही और अपेक्षित व्यवहार है। " " "" एक a आसपास उद्धरणों की एक बची हुई जोड़ी के आसपास के उद्धरणों की एक जोड़ी है, इसलिए PowerShell बाहरी अनिर्धारित जोड़ी की व्याख्या करता है क्योंकि यह" एक स्ट्रिंग तर्क है "और तो उन्हें छोड़ देता है, फिर बची हुई जोड़ी की व्याख्या करता है क्योंकि बच गए उद्धरण के साथ और इसलिए उन्हें रखता है, आपको "a" साथ छोड़ रहा है। किसी भी बिंदु पर \ स्ट्रिंग में जोड़ा नहीं गया था।

तथ्य यह है कि बाश एक बच चरित्र के रूप में \ का उपयोग करता है अप्रासंगिक है। PowerShell में, एस्केप चरित्र एक बैकटिक है। PowerShell एस्केप वर्ण देखें।

यदि आप सचमुच "\"a\"" पास करना चाहते हैं, तो मेरा मानना ​​है कि आप इसका उपयोग करेंगे:

> echo `"\`"a\`"`"
"\"a\""

@andschwa
हां, आंतरिक cmdlets के लिए एस्केप ठीक काम करता है, लेकिन देशी बायनेरिज़ के साथ संवाद करने पर चीजें अजीब हो जाती हैं, खासकर विंडोज पर।
native.exe " " "" चलने पर, ARGV [1] होना चाहिए

"a"

(तीन अक्षर)

के बजाय

a

(एक वर्ण)।

वर्तमान में native.exe सही ढंग से दो उद्धरणों और a वर्ण के साथ ARGV प्राप्त करने के लिए, आपको इस अजीब कॉल का उपयोग करना होगा:

native.exe "\`"a\`""

ओह समझा। फिर से खोलने।

एक मजबूत जिज्ञासा से, यदि आप # 1639 का उपयोग करके निर्माण की कोशिश करते हैं तो क्या होता है?

@ndchwa वही। आपके पास PowerShell और CommandLineToArgvW दोनों को संतृप्त करने के लिए डबल-एस्केपे है। यह रेखा:

native.exe "`"a`""

cmd के लिए एक StartProcess बराबर है

native.exe ""a""

@ be5invis @douglaswth इस के माध्यम से हल हो गई है https://github.com/PowerShell/PowerShell/pull/2182?

नहीं, हम अभी भी एक backtick-escaped डबल उद्धरण से पहले एक बैकस्लैश जोड़ने की आवश्यकता है? यह डबल-भागने की समस्या को हल नहीं करता है। (अर्थात्, हमें PowerShell और CommandLineToArgvWW दोनों के लिए एक दोहरे उद्धरण से बचना होगा।)

चूँकि " " "" '"a"' बराबर है, क्या आप सुझाव देते हैं कि native.exe '"a"' का परिणाम "\"a\"" में होना चाहिए?

यह एक सुविधा अनुरोध की तरह लगता है कि यदि कार्यान्वित किया जा सकता है तो पहले से मौजूद पॉवरशेल स्क्रिप्ट की एक बड़ी संख्या को तोड़ सकते हैं जो आवश्यक दोहरी बचने का उपयोग करते हैं, इसलिए किसी भी समाधान के साथ चरम देखभाल की आवश्यकता होगी।

@ हॉर्स हाँ।
@douglaswth डबल-

@vors @douglaswth
यह एक C कोड है जिसका इस्तेमाल GetCommandLineW और CommandLineToArgvW परिणाम दिखाने के लिए किया जाता है:

#include <stdio.h>
#include <wchar.h>
#include <Windows.h>

int main() {
  LPWSTR cmdline = GetCommandLineW();
  wprintf(L"Command Line : %s\n", cmdline);

  int nArgs;
  LPWSTR *szArglist = CommandLineToArgvW(cmdline, &nArgs);
  if (NULL == szArglist) {
    wprintf(L"CommandLineToArgvW failed\n");
    return 0;
  } else {
    for (int i = 0; i < nArgs; i++) {
      wprintf(L"argv[%d]: %s\n", i, szArglist[i]);
    }
  }
  LocalFree(szArglist);
}

यहाँ परिणाम है

$ ./a "a b"
Command Line : "Z:\playground\ps-cmdline\a.exe" "a b"
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a b

$ ./a 'a b'
Command Line : "Z:\playground\ps-cmdline\a.exe" "a b"
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a b

$ ./a 'a"b'
Command Line : "Z:\playground\ps-cmdline\a.exe" a"b
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: ab

$ ./a 'a"b"c'
Command Line : "Z:\playground\ps-cmdline\a.exe" a"b"c
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: abc

$ ./a 'a\"b\"c'
Command Line : "Z:\playground\ps-cmdline\a.exe" a\"b\"c
argv[0]: Z:\playground\ps-cmdline\a.exe
argv[1]: a"b"c

@ be5invis मैं

वे कितने हैं? मुझे नहीं लगता कि इस तरह के दोहरे-उद्धरण के बारे में स्क्रिप्ट लेखक जानते हैं। यह बग है, फ़ीचर नहीं है और यह प्रलेखित नहीं है।

???? आई - फ़ोन

? 2016 9 21 ?? 01?? 58 डगलस बचत < [email protected] [email protected] > ???

@ be5i nvishttps: //github.com/be5invis मैं

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
सीधे इस ईमेल का उत्तर दें, इसे Gi tHubhttps: //github.com/PowerShell/PowerShell/issues/1995#issuecomment -248381045 पर देखें, या thhhttps: //github.com/notifications/unsubscribe-auth/AAOpnf_f0f0m05Um05_mf पर डाउनलोड करें।

PowerShell को लगभग 9 साल हो गए हैं, इसलिए वहाँ से बाहर स्क्रिप्ट की अच्छी संख्या होने की संभावना है। मुझे स्टैकऑवरफ्लो और अन्य स्रोतों से डबल भागने की आवश्यकता के बारे में बहुत सारी जानकारी मिली जब मैं इसकी आवश्यकता में भाग गया, इसलिए मुझे नहीं पता कि क्या मैं इसके दावों से सहमत हूं कि किसी को भी इसकी आवश्यकता के बारे में जानने के बारे में या यह दस्तावेज नहीं है ।

अतिरिक्त संदर्भ के लिए, मैं कार्यान्वयन के बारे में थोड़ी बात करना चाहूंगा।
PowerShell एक नई प्रक्रिया को स्पॉन करने के लिए .NET API को कॉल करता है, जो Win32 API (विंडोज़ पर) को कॉल करता है।

यहाँ, PS StartProcessInfo का उपयोग करता है
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/NativeCommandProcessor.cs#L1063

प्रदान की गई एपीआई तर्कों के लिए एक एकल स्ट्रिंग लेती है और फिर इसे निष्पादित करने के लिए तर्कों की एक सरणी में पुन: पार्स किया जाता है।
इस पुन: पार्सिंग के नियमों को PowerShell द्वारा नियंत्रित नहीं किया जाता है। यह एक Win32 एपीआई है (और सौभाग्य से, यह डॉटनेट कोर और यूनिक्स नियमों में सुसंगत है)।
विशेष रूप से, यह अनुबंध \ और " व्यवहार का वर्णन करता है।

हालाँकि, PowerShell चालाक होने की कोशिश कर सकता है और एक अच्छा अनुभव प्रदान कर सकता है, वर्तमान व्यवहार cmd और bash के अनुरूप है: आप उनमें से मूल निष्पादन योग्य लाइन की प्रतिलिपि बना सकते हैं और इसे पॉलीशेल में उपयोग कर सकते हैं और यह समान कार्य करता है।

@ be5invis यदि आप गैर-ब्रेकिंग तरीके से पंक्तिबद्ध करें। ब्रेकिंग परिवर्तन के लिए, हमें https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md में वर्णित RFC प्रक्रिया का उपयोग करने की आवश्यकता होगी

यह विंडोज पर लागू होता है, लेकिन लिनक्स या यूनिक्स पर कमांड चलाते समय, यह अजीब है कि एक को उद्धरण से बचने की जरूरत है।

लिनक्स प्रक्रियाओं पर एक कमांडलाइन नहीं होती है, बल्कि तर्कों की एक सरणी होती है।
इसलिए शक्तियां में तर्क समान होने चाहिए, जो सभी तर्कों को मर्ज करने और फिर हटाने के बजाय निष्पादन योग्य को पारित किए जाते हैं।

खिड़कियों पर भी, वर्तमान व्यवहार असंगत है:
यदि किसी तर्क में कोई स्थान नहीं है, तो उसे अपरिवर्तित रखा जाता है।
यदि किसी तर्क में रिक्त स्थान होते हैं, यदि यह उद्धरणों से घिरा होगा, तो इसे CommandLineToArgvW कॉल के माध्यम से एक साथ रखा जाएगा। => CommandLineToArgvW आवश्यकता को पूरा करने के लिए तर्क को बदला जाता है।
लेकिन अगर तर्क में उद्धरण शामिल हैं, तो वे बच नहीं जाते हैं। => तर्क नहीं बदला गया है, हालांकि CommandLineToArgvW को इसकी आवश्यकता है।

मुझे लगता है कि तर्कों को या तो कभी नहीं बदला जाना चाहिए, या हमेशा CommandLineToArgvW आवश्यकताओं को पूरा करने के लिए बदला जाना चाहिए, लेकिन आधे मामलों में नहीं।

अनुबंध तोड़ने के बारे में:
जैसा कि मुझे डबल भागने के बारे में कोई आधिकारिक दस्तावेज नहीं मिला, मैं इसे "बकेट 2: रीजनेबल ग्रे एरिया" की श्रेणी में मानता हूं, इसलिए इसे बदलने की संभावना है, या मैं गलत हूं?

@vors यह बेहद कष्टप्रद है यदि आपका तर्क एक चर या कुछ और है: आपको इसे मूल ऐप में भेजने से पहले मैन्युअल रूप से बचना होगा।
एक "ऑटो-एस्केप" ऑपरेटर मदद कर सकता है। जैसे ^"a " " -> "a\ " ""

मुझे लगता है कि @TSlivede ने व्यवहार में असंगति के साथ इसे सही रखा।

मुझे लगता है कि या तो तर्कों को कभी भी नहीं बदला जाना चाहिए, या हमेशा कमांडलाइनटॉयरगर्ल की आवश्यकताओं को पूरा करने के लिए बदला जाना चाहिए, लेकिन आधे मामलों में नहीं।

मैं बाल्टी के बारे में निश्चित नहीं हूं, लेकिन यहां तक ​​कि "स्पष्ट रूप से टूटने वाला बदलाव" बाल्टी को संभवतः बदला जा सकता है। हम PowerShell को बेहतर बनाना चाहते हैं, लेकिन पिछड़ी संगतता हमारी सर्वोच्च प्राथमिकताओं में से एक है। इसलिए यह इतना आसान नहीं है।
हमारे पास एक महान समुदाय है और मुझे विश्वास है कि हम आम सहमति पा सकते हैं।

क्या कोई आरएफसी प्रक्रिया शुरू करना चाहता है?

यह एक प्रक्रिया शुरू करने के लिए .net के बजाय P / Invoke के उपयोग की जांच करने के लायक होगा यदि वह तर्क से उद्धरण जोड़ने के लिए PowerShell की आवश्यकता को टालता है।

@lzybkr जहां तक ​​मैं बता सकता हूं, PInvoke मदद नहीं करेगा।
और यह वह जगह है जहाँ यूनिक्स और विंडोज़ एपीआई अलग हैं:

https://msdn.microsoft.com/en-us/library/20y988d2.aspx (विभाजक के रूप में रिक्त स्थान मानते हैं)
https://linux.die.net/man/3/execvp (विभाजक के रूप में रिक्त स्थान का इलाज नहीं करता है)

मैं विंडोज कार्यान्वयन को बदलने का सुझाव नहीं दे रहा था।

मैं यहाँ मंच-विशिष्ट व्यवहार रखने से बचने की कोशिश करूँगा। यह स्क्रिप्ट की पोर्टेबिलिटी को नुकसान पहुंचाएगा।
मुझे लगता है कि हम गैर-ब्रेकिंग तरीके से खिड़कियों के व्यवहार को बदलने पर विचार कर सकते हैं। प्राथमिकता वाले चर के साथ। और फिर हमारे पास अलग-अलग चूक या ऐसा कुछ हो सकता है।

हम बाहरी आदेशों को कॉल करने के बारे में बात कर रहे हैं - कुछ भी मंच पर निर्भर।

खैर, मुझे लगता है कि यह वास्तव में स्वतंत्र मंच नहीं हो सकता है, क्योंकि विंडोज और लिनक्स के पास निष्पादन योग्य कॉल करने के लिए अलग-अलग तरीके हैं। लिनक्स में एक प्रक्रिया को एक तर्क सरणी मिलती है जबकि विंडोज पर एक प्रक्रिया में केवल एक कमांडलाइन (एक स्ट्रिंग) मिलती है।
(अधिक बुनियादी तुलना करें
CreateProcess -> कमांडलाइन (https://msdn.microsoft.com/library/windows/desktop/ms682425)
तथा
execve -> कमांड एरे (https://linux.die.net/man/2/execve)
)

जैसा कि पॉवरशेल उन उद्धरणों को जोड़ता है जब तर्कों में उनके स्थान होते हैं, यह मुझे लगता है, कि पॉवरशेल एक तरह से तर्कों को पारित करने के लिए ** कोशिश करता है, कि CommandLineToArgvW तर्कों को कमांडलाइन विभाजित करता है जो मूल रूप से शक्तियां में दिए गए थे। (इस तरह से एक सामान्य सी-प्रोग्राम को अपने argv एरे में उतने ही तर्क मिलते हैं, जितने में पॉवरशेल फंक्शन को $ args मिलता है।)
यह पूरी तरह से सिर्फ linux systemcall (जैसा कि p / invoke के माध्यम से सुझाव दिया गया है) के लिए तर्कों को पारित करने के लिए मेल खाता है।

** (विफल रहता है, क्योंकि यह उद्धरण से बच नहीं जाता है)

पुनश्च: RFC प्रक्रिया शुरू करने के लिए क्या आवश्यक है?

सटीक रूप से - PowerShell यह सुनिश्चित करने की कोशिश करता है कि CommandLineToArgvW सही कमांड उत्पन्न करे और _After_ पॉवरशेल जो पहले ही पार्स हो चुका है उसे रिप्रेजेंट करे।

यह विंडोज पर एक लंबे समय तक दर्द बिंदु रहा है, मैं उस कठिनाई को * nix पर लाने के लिए कारण देखता हूं।

मेरे लिए, यह एक कार्यान्वयन विवरण की तरह लगता है, वास्तव में आरएफसी की आवश्यकता नहीं है। यदि हमने Windows PowerShell में व्यवहार को बदल दिया है, तो यह RFC को वारंट कर सकता है, लेकिन फिर भी, सही परिवर्तन को एक (संभवतः जोखिम भरा) बग फिक्स माना जा सकता है।

हां, मुझे भी लगता है, कि डायरेक्ट सिस्टम कॉल का उपयोग करने के लिए इसे लिनक्स पर बदलने से सभी को अधिक खुशी महसूस होगी।

मुझे अभी भी लगता है कि इसे खिड़कियों पर भी बदलना चाहिए,
(हो सकता है कि जो लोग अपनी लिपियों को बदलना नहीं चाहते हैं उनके लिए एक वरीयता चर जोड़कर)
क्योंकि यह अभी गलत है - यह एक बग है। यदि इसे ठीक किया गया, तो लिनक्स पर एक प्रत्यक्ष syscall भी आवश्यक नहीं होगा, क्योंकि कोई भी तर्क अगली प्रक्रिया में अपरिवर्तित होगा।

लेकिन जैसे कि निष्पादक होते हैं, जो कमांडलाइन को एक तरह से विभाजित करते हैं, CommandLineToArgvW लिए असंगत, मुझे तर्कों के लिए ऑपरेटर के विचार का @ be5invis पसंद है - लेकिन मैं ऑटो-एस्केप ऑपरेटर नहीं

यह मुद्दा अभी हमारे लिए तब आया था जब किसी ने PowerShell में निम्न कमांड की कोशिश की थी और जब यह काम नहीं कर रहा था तब PowerShell को विस्थापित कर रहा था लेकिन CMP ने किया:

wmic useraccount where name='username' get sid

PSCX गूंज से, wmic.exe इसे देखता है:

94> echoargs wmic useraccount where name='tso_bldadm' get sid
Arg 0 is <wmic>
Arg 1 is <useraccount>
Arg 2 is <where>
Arg 3 is <name=tso_bldadm>
Arg 4 is <get>
Arg 5 is <sid>

Command line:
"C:\Users\hillr\Documents\WindowsPowerShell\Modules\Pscx\3.2.2\Apps\EchoArgs.exe" wmic useraccount where name=tso_bldadm get sid

तो क्या API सीएमडी। Exe प्रक्रिया को लागू करने / कमांड लाइन बनाने के लिए उपयोग करता है? उस बात के लिए, इस कमांड को बनाने के लिए% क्या करता है?

@rkeithhill CreateProcessW । प्रत्यक्ष कॉल। वास्तव में।

पॉवरशेल इन दो स्थितियों में अलग-अलग व्यवहार क्यों कर रही है? विशेष रूप से, यह असंगत रूप से डबल-कोट्स में रिक्त स्थान वाले आर्ग्स को लपेटता है।

# Desired argv[1] is 4 characters: A, space, double-quote, B
$ .\echoargs.exe 'A \"B'
<"C:\test\echoargs.exe" "A \"B">
<A "B>
# Correct!

# Desired argv value is 4 characters: A, double-quote, space, B
$ .\echoargs.exe 'A\" B'
<"C:\test\echoargs.exe" A\" B>
<A"> <B>
# Wrong...

लगता है कोई तुक या तर्क नहीं है। पहली स्थिति में, यह डबल-कोट्स के साथ मेरे आर्ग को लपेटता है, लेकिन दूसरी स्थिति में ऐसा नहीं होता है। मुझे यह जानने की जरूरत है कि यह डबल-कोट्स में कब लपेटा जाएगा और ऐसा नहीं होगा ताकि मैं अपनी स्क्रिप्ट में मैन्युअल रूप से लपेट (या नहीं) कर सकूं।

.echoargs.exe cl echoargs.c साथ निम्नलिखित संकलन करके बनाया गया है

// echoargs.c
#include <windows.h>
#include <stdio.h>
int wmain(int argc, WCHAR** argv) {
    wprintf(L"<%ls>\n", GetCommandLineW());
    for(int i = 1; i < argc; i++) {
        wprintf(L">%s< ", argv[i]);
    }
    wprintf(L"\n");
}

संपादित करें: यहाँ मेरा $ PSVersionTable है:

Name                           Value
----                           -----
PSVersion                      5.1.15063.296
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.296
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

उद्धरणों के संबंध में व्यवहार कई बार बदल गया है, इसलिए मैं इस तरह से कुछ का उपयोग करने का सुझाव दूंगा:

# call helper

function Run-Native($command) {
    $env:commandlineargumentstring=($args | %{'"'+ ($_ -replace '(\\*)"','$1$1\"' -replace '(\\*)$','$1$1') + '"'}) -join ' ';
    & $command --% %commandlineargumentstring%
}

# some test cases

Run-Native .\echoargs.exe 'A "B' 'A" B'
Run-Native .\echoargs.exe 'A "B'
Run-Native .\echoargs.exe 'A" B'
Run-Native .\echoargs.exe 'A\" B\\" \'

आउटपुट:

<"C:\test\echoargs.exe"  "A \"B" "A\" B">
<A "B> <A" B>

<"C:\test\echoargs.exe"  "A \"B">
<A "B>

<"C:\test\echoargs.exe"  "A\" B">
<A" B>

<"C:\test\echoargs.exe"  "A\\\" B\\\\\" \\">
<A\" B\\" \>

पहले -replace कोट्स के सामने बैकस्लैश हो जाता है और एक अतिरिक्त बैकस्लैश जोड़ता है, क्यूटी से बचने के लिए।
दूसरा -replace बैकस्लैश को तर्क के अंत में दोगुना कर देता है, जैसे कि समापन उद्धरण से बच नहीं जाता है।

यह --% (PS v3 और इसके बाद के संस्करण) का उपयोग करता है, जो कि AFAIK को देशी निष्पादन योग्य उद्धरणों को पारित करने का एकमात्र विश्वसनीय तरीका है।

संपादित करें:

Run-Native का अपडेट किया गया संस्करण, अब Invoke-NativeCommand (जैसा कि सुझाव दिया गया ) कहा जाता है

function Invoke-NativeCommand() {
    $command, [string[]] $argsForExe = $args
    if($argsForExe.Length -eq 0){
        & $command
    } else {
        $env:commandlineargumentstring=($argsForExe | %{
            if($_ -match '^[\w\d\-:/\\=]+$'){
                $_ #don't quote nonempty arguments consisting of only letters, numbers, or one of -:/\=
            } else {
                $_ <# double backslashes in front of quotes and escape quotes with backslash #> `
                    -replace '(\\*)"','$1$1\"' `
                   <# opening quote after xxx= or after /xxx: or at beginning otherwise #> `
                    -replace '^([\w\d]+=(?=.)|[/-][\w\d]+[:=](?=.)|^)','$1"' `
                   <# double backslashes in front of closing quote #> `
                    -replace '(\\*)$','$1$1' `
                   <# add closing quote #> `
                    -replace '$','"'
            }
        }) -join ' ';
        & $command --% %commandlineargumentstring%
    }
}

( iep से कुछ प्रेरणा के साथ)

• सरल स्विच बोली नहीं है
• अभी भी खाली आर्ग के साथ काम करता है
• काम करता है अगर कोई मौजूद नहीं है
• ज्यादातर msiexec, cmdkey, आदि के साथ काम करना चाहिए ...
• अभी भी हमेशा कार्यक्रमों के लिए काम करता है, जो सामान्य नियमों का पालन करते
• का उपयोग नहीं करता गैरमानक "" बच गए के रूप में " - होगा इसलिए अभी भी में एम्बेडेड उद्धरण के लिए काम करते नहीं .bat या msiexec तर्क

धन्यवाद, मैं --% बारे में नहीं जानता था। क्या ऐसा करने का कोई तरीका है जो पर्यावरण चर को मूल प्रक्रिया में लीक किए बिना? (और किसी भी प्रक्रिया में इसे लागू किया जा सकता है)

क्या कोई PowerShell मॉड्यूल है जो सभी के उपयोग के लिए Run-Native Cmdlet लागू करता है? यह कुछ ऐसा लगता है जो पॉवर्सशेल गैलरी पर होना चाहिए। यदि यह काफी अच्छा था, तो यह एक आरएफसी के लिए आधार हो सकता है।

"लीक" लगता है जैसे आप सुरक्षा के बारे में चिंतित हैं। ध्यान दें कि कमांडलाइन वैसे भी चाइल्ड प्रोसेस को दिखाई देती है। (उदाहरण के लिए: विंडोज पर gwmi win32_process |select name,handle,commandline|Format-Table और लिनक्स पर ps -f )

यदि आप अभी भी पर्यावरण चर से बचना चाहते हैं, तो आप इनवोक-एक्सप्रेशन का उपयोग करके कुछ निर्माण कर सकते हैं।

RFC के बारे में:
मुझे नहीं लगता कि इस तरह के एक कमांडलेट आवश्यक होना चाहिए, इसके बजाय यह डिफ़ॉल्ट व्यवहार होना चाहिए:

https://github.com/PowerShell/PowerShell-RFC/issues/90

मैं सहमत हूं कि PowerShell का डिफ़ॉल्ट व्यवहार तय होना चाहिए। मैं निराशावादी रूप से यह मान रहा था कि यह पश्चगामी संगतता कारणों से कभी नहीं बदलेगा, यही वजह है कि मैंने एक मॉड्यूल लिखने का सुझाव दिया। हालाँकि, मुझे वास्तव में पसंद है कि आपका RFC पुराने भागने वाले व्यवहार को वरीयता चर के माध्यम से फिर से सक्षम करने की अनुमति देता है।

मुझे केवल सही राय के साथ चर्चा को संक्षेप में प्रस्तुत करने दें:

• यह स्पष्ट है कि हमारे पास एक पिछड़ा-संगतता मुद्दा है, इसलिए पुराने व्यवहार को उपलब्ध रहना जारी रखना चाहिए।

• @TSlivede का RFC प्रस्ताव उस समय के लिए है, जब वह भविष्य में __ की ओर ध्यानपूर्वक संकेत दे रहा हो।
  दुर्भाग्य से, उनका प्रस्ताव इस लेखन के रूप में _PR_ के रूप में समाप्त हो गया, और इसे RFC _draft_ के रूप में अभी तक स्वीकार नहीं किया गया है।

_The future_ द्वारा, मेरा मतलब है:

• PowerShell अपने आप में एक ऐसा शेल है जो उम्मीद करता है कि जल्द ही अपना cmd.exe -नियंत्रित सामान बहा लेगा, इसलिए केवल एक ही बात मायने रखती है कि जब यह बाहरी उपयोगिताओं को कॉल करने की बात हो (निष्पादक जो कि (आमतौर पर) कंसोल / टर्मिनल एप्लिकेशन हैं) :

  • पारित करने के लिए तर्क _PowerShell_ के तर्क-मोड पार्सिंग _only_ के नियमों द्वारा निर्दिष्ट किए जाने चाहिए।

  • जो भी _literals_ उस प्रक्रिया से परिणाम _as-is_ पास होना चाहिए, वह लक्ष्य निष्पादन योग्य, जैसा कि _indateral_ तर्कों।

  • दूसरे शब्दों में: एक उपयोगकर्ता के रूप में, आप सभी को कभी भी ध्यान केंद्रित करने की आवश्यकता है कि _PowerShell_ के पार्सिंग का परिणाम क्या होगा, और उस परिणाम पर निर्भर होने में सक्षम होने के लिए, जैसे कि PowerShell किसी भी पीछे की देखभाल करता है - एन्कोडिंग एन्कोडिंग - यदि आवश्यक हो।

भविष्य में _ लागू करना:

• _Windows_ पर:

  • _Historical_ कारणों के लिए, Windows _not_ अनुमति देता है पासिंग तर्क _as सरणी का एक अक्षर_ निष्पादन योग्य करने के लिए; इसके बजाय, _pseudo शेल सिंटैक्स_ का उपयोग करके एक _single_ string एन्कोडिंग _all_ तर्कों की आवश्यकता है। इससे भी बुरी बात यह है कि यह एकल स्ट्रिंग_ की व्याख्या करने के लिए व्यक्तिगत लक्ष्य तक पहुंचने के लिए है और इसे तर्कों में विभाजित कर देता है।

  • सबसे अच्छा PowerShell कर सकता है कि सिंगल स्ट्रिंग - दृश्यों के पीछे, उसके _own_ को अलग-अलग तर्कों में कमांड लाइन को विभाजित करने के बाद - एक _predictable, मानकीकृत तरीके से।

  • @TSlivede का RFC प्रस्ताव सिर्फ यह प्रस्तावित करता है कि, PowerShell इस तरीके से छद्म शेल कमांड लाइन को संश्लेषित करता है, जो इनपुट तर्क को पुनर्प्राप्त करने के लिए Windows C / C ++ रनटाइम का कारण होगा

    • यह देखते हुए कि यह अंततः कमांड लाइन की व्याख्या करने के लिए प्रत्येक लक्ष्य के लिए निष्पादन योग्य है, कोई _guarantee_ नहीं है कि यह सभी मामलों में काम करेगा, लेकिन कहा कि नियम सबसे समझदार विकल्प हैं, क्योंकि _most_ मौजूदा उपयोगिताओं इन सम्मेलनों का उपयोग करती हैं।

    • केवल उल्लेखनीय अपवाद _batch files_ हैं, जो विशेष उपचार प्राप्त कर सकते हैं, जैसा कि RFC के प्रस्ताव से पता चलता है।

• _Unix_ प्लेटफार्मों पर:

  • कड़ाई से बोलते हुए, Windows तर्क को पार्स करने वाले मुद्दे _need कभी उत्पन्न नहीं होते हैं, क्योंकि नई प्रक्रियाओं को बनाने के लिए प्लेटफ़ॉर्म-नेटिव कॉल करता है _ साहित्य को सरणियों के रूप में तर्क देता है - जो भी तर्क PowerShell को समाप्त करता है उसके _own_ पार्सिंग को केवल _as-is_ पर पास किया जाना चाहिए। ।
    @Lzybkr को उद्धृत करने के लिए: "मुझे उस कठिनाई को * nix पर लाने का कोई कारण नहीं दिख रहा है।"

  • दुख की बात है कि .NET कोर (CoreFX) की वर्तमान सीमाओं के कारण, ये मुद्दे _do_ खेलने में आते हैं, क्योंकि CoreFX API अनावश्यक रूप से _Windows_ तर्क की अराजकता को यूनिक्स दुनिया पर भी गुजरने के लिए मजबूर करता है, यहां तक ​​कि एक छद्म कमांड लाइन के उपयोग की भी आवश्यकता होती है। यूनिक्स।

  • मैंने इस CoreFX मुद्दे को उस समस्या के निवारण के लिए बनाया है।

  • इस बीच, यह देखते हुए कि CoreFX छद्म कमांड लाइन को वापस C / C ++ नियमों के आधार पर तर्कों में विभाजित करता है, @TSlivede का प्रस्ताव यूनिक्स प्लेटफार्मों पर भी काम करना चाहिए।

जैसा कि https://github.com/PowerShell/PowerShell/issues/4358 को इस के डुप्लिकेट के रूप में बंद कर दिया गया था, यहाँ उस समस्या का एक संक्षिप्त सारांश है:

यदि अनुगामी बैकस्लैश के साथ बाहरी निष्पादन योग्य के एक तर्क में एक स्थान होता है, तो यह वर्तमान में भोली है (तर्क से पहले और बाद में उद्धरण जोड़ें)। कोई भी निष्पादन योग्य, जो सामान्य नियमों का पालन
_{@ Mklement0 की टिप्पणी से :}

दूसरा " ".\test 2\" , पूर्ववर्ती होने के कारण \ _ को एक पलायन के रूप में व्याख्यायित किया जाता है ", जिससे स्ट्रिंग का शेष बच जाता है - फिर एक गायब होने के बावजूद" के भाग के रूप में व्याख्या की जा सकती है। एक ही तर्क।

उदाहरण:
_{( @akervinen की टिप्पणी से )}

PS X:\scratch> .\ps-args-test.exe '.\test 2\'
प्राप्त तर्क: .\test 2"

यह समस्या बहुत बार होती है, क्योंकि PSReadLine निर्देशिकाओं के लिए स्वत: पूर्ण होने पर एक पीछे आने वाला कदम जोड़ता है।

चूंकि Corefx को एपीआई की जरूरत है, जिसके लिए मैं उत्पादन कर रहा हूं। 6.0.0 के लिए, मैं देखूंगा कि क्या हम # 4358 को ठीक कर सकते हैं

@TSlivede मैंने आपका फ़ंक्शन लिया, इसका नाम बदलकर Invoke-NativeCommand ( Run में एक मान्य क्रिया नहीं है) और एक उपनाम ^ जोड़ा और इसे PowerShellGallery पर एक मॉड्यूल के रूप में प्रकाशित किया:

install-module NativeCommand -scope currentuser
^ ./echoargs 'A "B' 'A" B'

@ SteveL-MSFT:

एक स्टॉपगैप होना अच्छा है, लेकिन एक कम बोझिल होगा - जब हम एक CoreFX समाधान की प्रतीक्षा करते हैं - अच्छी तरह से परिभाषित आधिकारिक उद्धरण / तर्क-पार्सिंग नियमों को लागू करने के लिए @TSlivede के RFC में विस्तृत रूप से खुद को लागू करना - जो doesn 'करने के लिए बहुत मुश्किल लग रहा है।

यदि हम केवल \" समस्या को ठीक करते हैं , तो तर्क अभी भी मौलिक रूप से टूटा हुआ है, यहां तक ​​कि निम्नलिखित जैसे सरल परिदृश्यों में भी:

PS> bash -c 'echo "hi there"'
hi    # !! Bash sees the following tokens:  '-c', 'echo hi', 'there'

मुझे लगता है कि इस बिंदु पर पर्याप्त समझौता है कि व्यवहार क्या होना चाहिए ताकि हमें एक पूर्ण आरएफसी प्रक्रिया की आवश्यकता न हो, क्या हम?

एकमात्र उत्कृष्ट निर्णय यह है कि _Windows_ में पिछड़े-संगतता मुद्दों से कैसे निपटें।

@ mklement0 @ स्टीवएल-एमएसएफटी
क्या हम पहले ही संगतता तोड़

एकमात्र उत्कृष्ट निर्णय यह है कि विंडोज में पिछड़े-संगतता मुद्दों से कैसे निपटें।

हाँ, लेकिन यह कठिन हिस्सा है, है ना?

@ be5invis "पहले से ही टूटी हुई संगतता" से

इसके अलावा, अगर CoreFX अपनी परत में एक सुधार के कगार पर है, तो मैं ऐसा करने से पहले हमारी परत में स्टॉपगैप नहीं बनाऊंगा।

और जैसा कि किसी ने थ्रेड में ऊपर कहा है, यह कष्टप्रद है, लेकिन यह समुदाय में बहुत अच्छी तरह से प्रलेखित है। मुझे यकीन नहीं है कि हमें इसे अगले दो रिलीज में दो बार तोड़ना चाहिए।

@joeyaiello :

# 4358 के लिए पहले से ही उन लोगों के लिए एक ब्रेकिंग परिवर्तन नहीं है, जिन्होंने अंतिम \ को दोगुना करके इस मुद्दे पर काम किया है; जैसे, "c:\tmp 1\\" ? दूसरे शब्दों में: यदि आप इस फिक्स में परिवर्तन को सीमित करते हैं, तो _two_ ब्रेकिंग परिवर्तन की गारंटी दी जाती है: यह एक अब, और बाद में भविष्य के CoreFx API पर स्विच करने के बाद; और जबकि _could_ भी तब होता है जब एक पूर्ण स्टॉपगैप अब लागू किया जाता है, यह संभावना नहीं है, यह देखते हुए कि हम इस आने वाले बदलाव के बारे में क्या जानते हैं।

इसके विपरीत, यह यूनिक्स पर गोद लेने में बाधा उत्पन्न कर सकता है यदि सामान्य उद्धरण परिदृश्य जैसे
bash -c 'echo "hi there"' ठीक से काम नहीं करते हैं।

मुझे पता है कि इसे ठीक करना एक बहुत बड़ा परिवर्तन है, हालाँकि।

@ पॉवरशेल / पॉवरशेल-कमेटी ने इस पर चर्चा की और इस बात पर सहमति व्यक्त की कि न्यूनतम --% का उपयोग करते हुए व्यवहार में उतावलापन होना चाहिए क्योंकि उद्धरण से बच जाते हैं ताकि देशी कमांड उन्हें प्राप्त हो। बहस के लिए अभी भी खुला है अगर यह --% का उपयोग करके डिफ़ॉल्ट व्यवहार w / o होना चाहिए

ध्यान दें:

• मैं मान रहा हूं कि _Unix_ पर --% का उपयोग करते समय वास्तविक शेल निष्पादन योग्य के लिए एक कॉल आवश्यक है, क्योंकि शेल व्यवहार को _emulate_ करने की कोशिश कर रहा है, जो _Windows_ पर होता है। विंडोज़ पर अनुकरण करना कठिन नहीं है, लेकिन यूनिक्स पर बहुत अधिक कठिन होगा, कई और विशेषताओं को देखते हुए जिन्हें अनुकरण की आवश्यकता होगी।

• एक वास्तविक शेल का उपयोग करने पर यह प्रश्न उठता है कि किस शेल का उपयोग किया जाए: जबकि bash सर्वव्यापी है, इसका डिफ़ॉल्ट व्यवहार POSIX-compliant नहीं है और न ही POSIX द्वारा मौजूद होने की आवश्यकता है, इसलिए पोर्टिंग के लिए अन्य स्क्रिप्टिंग भाषाओं को कॉल करें /bin/sh , POSIX द्वारा शेल निष्पादन योग्य डिकोड (जो _can_ संगतता मोड में चल रहा है, जैसे कि macOS पर), लेकिन निश्चित रूप से (जैसे, Ubuntu पर डैश) नहीं है।

यकीनन, हमें /bin/sh लक्ष्य बनाना चाहिए - जो, हालांकि, इसका अर्थ है कि कुछ बैश विशेषताएं - विशेष रूप से ब्रेस विस्तार, कुछ स्वचालित चर, ... - उपलब्ध नहीं होंगे।

--%

मैं नीचे दिए गए उदाहरण के रूप में कमांड echoargs --% 'echo "hi there"' उपयोग करूंगा।

व्यवहार में उतावलापन है कि उद्धरण से बच रहे हैं ताकि देशी आदेश उन्हें प्राप्त हो।

_Fin को करने का तरीका, एक बार CoreFX API को बढ़ा दिया गया हो, तो यह होगा कि कोई भी भागने से बचना चाहिए, और इसके बजाय निम्नलिखित करें:

• एक प्रक्रिया इस प्रकार बनाएँ:
  
  
  
  • /bin/sh निष्पादन योग्य के रूप में, (प्रभावी रूप से) ProcessStartInfo.FileName को सौंपा गया।
  
  
  • _Literal_, _indateral_ तर्क टोकन के रूप में ProcessStartInfo.ArgumentList निम्न सरणी:
  
  
  • 1 तर्क के रूप में -c
  
  
  • echoargs 'echo "hi there"' 2 तर्क के रूप में - यानी, मूल कमांड लाइन _literally_ का उपयोग करती है, बिल्कुल निर्दिष्ट के अलावा, इसके अलावा --% हटा दिया गया था।
  
  

वास्तव में, कमांड लाइन _as-is_ के माध्यम से शेल निष्पादन योग्य के लिए पारित की जाती है, जो तब _its_ पार्सिंग कर सकती है।

मैं समझता हूं कि, शाब्दिक तर्कों को पारित करने के लिए एक सरणी-आधारित तरीके की वर्तमान अनुपस्थिति में, हमें -c और echoargs 'echo "hi there"' को एक _single_ string में जोड़ना होगा। इससे बचने के लिए, अफसोस करने के लिए खेद है। CoreFX API_, जो, जब वास्तविक प्रक्रिया बनाने का समय आता है, तब _reverses_ यह कदम और एकल स्ट्रिंग को शाब्दिक टोकन में वापस विभाजित करता है - और यह सुनिश्चित करना कि यह उलट हमेशा शाब्दिक टोकन की मूल सूची में परिणत होता है।

फिर से: वर्तमान में सभी में यहां भागने का एकमात्र कारण वर्तमान CoreFX सीमा है।
इस सीमा के साथ काम करने के लिए, निम्नलिखित एकल, बची हुई स्ट्रिंग को .Arguments ProcessStartInfo उदाहरण के लिए असाइन किया जाना चाहिए, साथ ही भागने वाले C ++ कमांड-लाइन संलयन द्वारा निर्दिष्ट पलायन के साथ:

• /bin/sh निष्पादन योग्य के रूप में, (प्रभावी रूप से) ProcessStartInfo.FileName को सौंपा गया।
• निम्नलिखित एकल, ProcessStartInfo.Arguments के मूल्य के रूप में स्ट्रिंग से बच गया:
  -c "echoargs 'echo \"hi there\"'"

## डिफ़ॉल्ट व्यवहार

बहस के लिए अभी भी खुला है अगर यह डिफ़ॉल्ट व्यवहार w / o का उपयोग करना चाहिए -%

यूनिक्स पर डिफ़ॉल्ट व्यवहार बहुत अलग होना चाहिए:

• पॉवरशेल के खुद के मुकाबले कोई भी बचने वाला विचार नहीं है। कभी भी खेल में आना चाहिए (_Windows_ को छोड़कर, जहां इसे टाला नहीं जा सकता है, दुःख की बात है; लेकिन वहाँ एमएस सी ++ नियम जाने का रास्ता है, _to पर्दे के पीछे लागू किया जा सकता है; असफल हो रहा है, --% एक पलायन हैच प्रदान करता है)।

• जो भी तर्क _PowerShell_ के साथ समाप्त होता है, अपने स्वयं के पार्सिंग के बाद , आगामी ProcessStartInfo.ArgumentList संपत्ति के माध्यम से, शाब्दिक_ के _reray के रूप में पारित किया जाना चाहिए ।

--% : echoargs 'echo "hi there"' बिना उदाहरण के लिए लागू:

• PowerShell अपनी सामान्य पार्सिंग करता है और निम्नलिखित 2 तर्कों के साथ समाप्त होता है:

  • echoargs
  • echo "hi there" (एकल उद्धरण - जिसमें केवल _PowerShell_ के लिए वाक्य रचना समारोह था, हटा दिया गया)

• ProcessStartInfo को तब निम्नानुसार पॉप्युलेट किया गया है, जैसे कि आने वाले CoreFX एक्सटेंशन के साथ:

  • echoargs रूप में (प्रभावी) .FileName संपत्ति का मूल्य
  • _Literal_ echo "hi there" एकमात्र तत्व के रूप में Collection<string> इंस्टेंस को .ArgumentList द्वारा उजागर किया गया।

फिर से, .ArgumentList की अनुपस्थिति में जो कि एक विकल्प नहीं है _yet_, लेकिन _in MS_ समान MS C ++ - जैसा कि ऊपर वर्णित किया गया है, सहायक सहायक भाग लेना नियोजित किया जा सकता है।

@ SteveL-MSFT
जैसा कि मैंने पहले ही मेक द स्टॉप-पार्सिंग सिंबल (-%) का यूनिक्स (# 3733) पर काम किया है, मैं --% के व्यवहार को बदलने के खिलाफ दृढ़ता से सलाह दूंगा ।

यदि /bin/sh -c लिए कुछ विशेष कार्यक्षमता की आवश्यकता है, तो कृपया एक अलग प्रतीक का उपयोग करें और --% को जिस तरह से छोड़ दें!

@ टिकट :

_If_ कुछ --% -_लाइड_ यूनिक्स पर लागू किया गया है - और देशी ग्लोबिंग के साथ और आम तौर पर यूनिक्स पर अधिक कमांड-लाइन-प्रेमी भीड़ के लिए मुझे इसकी आवश्यकता कम महसूस होती है - फिर एक _dadferent symbol_ - जैसे --$ चुनना

अलग-अलग प्रतीक भी नेत्रहीन विशिष्ट अनुस्मारक के रूप में काम करेंगे कि गैर-पोर्टेबल _platform-specific_ व्यवहार को आमंत्रित किया जा रहा है।

यह सवाल छोड़ देता है कि PowerShell को क्या करना चाहिए जब यह यूनिक्स पर --% आता है और विंडोज पर --$ होता है।

मैं ठीक हूँ --% रूप में छोड़ रहा है। --$ जैसी कुछ चीज़ों का परिचय जो / बिन / श को कॉल करता है और मुझे लगता है कि विंडोज पर cmd.exe इसे हल करने का एक अच्छा तरीका हो सकता है।

इन व्यवहारों के लिए एक cmdlet बनाने का कोई मौका नहीं?

@iSazonov क्या आप Invoke-Native जैसा कुछ सुझा रहे हैं? यकीन नहीं होता कि मैं उसका प्रशंसक हूं।

हाँ, जैसे Start-Native ।
एक मजाक के रूप में :-), क्या आपको पॉवरशेल में cmdlets पसंद नहीं है?

Build.psm1 में हमारे पास https://mnaoumov.wordpress.com/2015/01/11/execution-of-external-commands-in-powershell-done-right/ के लिंक के साथ Start-NativeExecution

@ SteveL-MSFT

मैं ठीक हूं -% as- है।

मुझे लगता है कि हम सभी सहमत हैं कि --% को उस तरह से व्यवहार करना जारी रखना चाहिए, जो _Windows_ पर करता है।

इसके विपरीत, _Unix_ पर, इस व्यवहार का कोई मतलब नहीं है, जैसा कि मैंने यहाँ प्रदर्शित करने की कोशिश की

• सिंगल कोट्स को सही तरीके से हैंडल नहीं किया जा रहा है
• पर्यावरण चर को संदर्भित करने का एकमात्र तरीका _cmd.exe-style_ ( %var% ) है
• ग्लोबबिंग और वर्ड-स्प्लिटिंग जैसे महत्वपूर्ण देशी फीचर काम नहीं करते हैं।

--% शुरू करने के लिए प्राथमिक प्रेरणा, अगर मैं सही ढंग से समझता हूं, तो मौजूदा cmd.exe कमांड लाइनों_ के रूप में सक्षम करने के लिए।

• इस प्रकार, --% अपने वर्तमान व्यवहार के साथ यूनिक्स पर बेकार है।
• _I__ हम यूनिक्स पर एक _analogous_ सुविधा चाहते थे, यह /bin/sh -c -आधारित होगा, जैसा कि ऊपर प्रस्तावित है, शायद एक अलग प्रतीक का उपयोग कर रहा है।

मुझे नहीं लगता कि एक की जरूरत है cmd /c विंडोज पर आधारित फीचर के रूप में, --% यकीनन एक तरह से _good enough_ है कि में है कि _mostly_ कवर किया है,।
@TSlivede ने बताया है कि सभी शेल फीचर्स का अनुकरण नहीं किया जा रहा है, लेकिन व्यवहार में यह चिंता का विषय नहीं प्रतीत होता है (जैसे, चर-मूल्य प्रतिस्थापन जैसे %envVar:old=new% समर्थित नहीं हैं, ^ एक एस्केप चार नहीं है, और --% का उपयोग एक _single_ कमांड तक सीमित है - cmd.exe का पुनर्निर्देशन और नियंत्रण ऑपरेटरों का कोई उपयोग नहीं है; उन्होंने कहा, मुझे नहीं लगता कि --% पूरे कमांड _lines_ का अनुकरण करने के लिए था।

जैसे, --$ - यदि लागू हो - कुछ यूनिक्स _counterpart_ से --% ।

किसी भी घटना में, बहुत कम से कम about_Parsing मदद विषय एक विशिष्ट चेतावनी के पात्र हैं कि --% सभी लेकिन कुछ मामलों में

@iSazonov कुछ विशिष्ट परिदृश्यों को संभालने के लिए Start-Native का अर्थ हो सकता है, लेकिन हमें PowerShell को बेहतर बनाने का प्रयास करना चाहिए ताकि मूल निर्गमन का उपयोग करना अधिक प्राकृतिक और पूर्वानुमान योग्य हो

@ पॉवरशेल / पॉवरशेल-कमेटी ने इसकी समीक्षा की और इस बात से सहमत हैं कि --% का अर्थ तर्कों का व्यवहार करना चाहिए क्योंकि वे अपने प्रासंगिक प्लेटफार्मों पर होंगे, जिसका अर्थ है कि वे विंडोज और लिनक्स पर अलग-अलग व्यवहार करते हैं, लेकिन विंडोज के भीतर और लिनक्स के भीतर सुसंगत हैं। उपयोगकर्ता के लिए एक नए सर्जन को पेश करना अधिक भ्रामक होगा। हम इसे कैसे सक्षम करें पर इंजीनियर को कार्यान्वयन छोड़ देंगे।

क्रॉस प्लेटफ़ॉर्म स्क्रिप्ट को व्यवहार में इस अंतर के बारे में पता होना चाहिए, लेकिन ऐसा लगता है कि उपयोगकर्ता इसे हिट नहीं करेंगे। यदि उपयोगकर्ता की प्रतिक्रिया है कि अधिक क्रॉस प्लेटफॉर्म के उपयोग के कारण कोई आवश्यकता है, तो हम एक नए सर्जन को फिर से शुरू कर सकते हैं।

दूसरी बार जब मैंने इन देशी बनाम cmdlets स्ट्रिंग तर्क को काट दिया है, जब रिप्रिप्प का इस्तेमाल किया जाता है।

यहाँ पॉवरशेल कॉल का परिणाम है (echo.exe "C: \ Program Files \ Git \ usrbin \ echo.exe" से है)

अब मुझे पता है कि मुझे इस " quirk के लिए बाहर देखना चाहिए:

> echo.exe '"test'
test

लेकिन यह विचित्रता मुझसे परे है ...

echo.exe '^\+.+;'
^\+.+;
echo.exe '^\+.*;'
^+.*;

दूसरे मामले में, मुझे मूल आदेश में \ \ करने की आवश्यकता है, पहले मामले में मुझे ऐसा करने की आवश्यकता नहीं है to

मैं समझता हूं कि इस व्यवहार को बदलने के लिए यह एक ब्रेकिंग बदलाव होगा ताकि cmlets और देशी कमांड्स के बीच अंतर नहीं होगा। हालाँकि, मुझे लगता है कि यह इस तरह की विचित्रता है जो लोगों को डिफ़ॉल्ट शेल के रूप में पावरशेल का उपयोग करने से रोकता है।

@mpawelski मैंने सिर्फ git 2.20.1.vfs.1.1.102.gdb3f8ae के साथ अपने विंडोज बॉक्स पर यह कोशिश की और यह 6.2-RC.1 के साथ मेरे लिए रिप्रोज नहीं करता। इसे कई बार दौड़ाया और इसने लगातार ^\+.+; कमाया

@ स्टीवएल-एमएसएफटी, मुझे लगता है कि @mpawelski ने गलती से एक ही कमांड को दो बार निर्दिष्ट किया। यदि आप उदाहरण के लिए '^\"+.*;' पास करते हैं, तो आपको समस्या दिखाई देगी - \" भाग को ध्यान में रखते हुए - उचित - अपेक्षा के साथ कि एकल-उद्धृत स्ट्रिंग की सामग्री को इस प्रकार से पार किया जाएगा , ताकि बाहरी लक्ष्य कार्यक्रम तर्क के मूल्य के रूप में ^\"+.*; देखता है:

# Note how the "\" char. is eaten.
PS> bash -c 'printf %s "$1"' - '^\"+.*;'
^"+.*; 

#"# Running the very same command from Bash does NOT exhibit the problem:
$ bash -c 'printf %s "$1"' - '^\"+.*;'
^\"+.*; 

-% था, अगर मैं सही ढंग से समझता हूं, मौजूदा cmd.exe कमांड लाइनों के पुन: उपयोग को सक्षम करने के लिए।

यह काफी नहीं है। --% पेश किया गया था क्योंकि कई विंडोज कमांड लाइन के बर्तन पावरस्ले द्वारा व्याख्या किए गए हैं जो उपयोगिता के आह्वान को पूरी तरह से विफल कर देते हैं। यह तेजी से लोगों को खट्टा कर सकता है यदि वे अब आसानी से अपने पसंदीदा देशी बर्तनों का उपयोग नहीं कर सकते हैं। अगर मेरे पास एसओ और अन्य जगहों पर सवालों के जवाब देने वाले हर बार के लिए एक चौथाई है, तो देशी विदेशी कमांड्स जो इस मुद्दे के कारण सही काम नहीं करते हैं, मैं शायद परिवार को क्यूबा में रात के खाने के लिए बाहर ले जा सकता हूं। :-) उदाहरण के लिए, tf.exe ; को कार्यक्षेत्र निर्दिष्ट करने के भाग के रूप में अनुमति देता है। Git {} और @~1 , आदि, आदि की अनुमति देता है।

--% को PowerShell को बताने के लिए जोड़ा गया था ताकि कमांड लाइन के बाकी हिस्सों को पार्स न किया जा सके - बस इसे "as-is" नेटिव exe पर भेजें। एक रगड़ के साथ, cmd env var सिंटैक्स का उपयोग करके चर की अनुमति दें। यह थोड़ा बदसूरत है लेकिन आदमी, यह वास्तव में, विंडोज पर अभी भी काम में आता है।

यह एक cmdlet बनाने के बाद, मुझे यकीन नहीं है कि मैं देखता हूं कि यह कैसे काम करता है। --% पार्सल को पार्स करने के लिए ईओएल तक एक संकेत है।

सच कहूँ तो, PowerShell के एक लंबे समय के उपयोगकर्ता और विशेष रूप से इस सुविधा के रूप में, यह मेरे लिए अन्य प्लेटफार्मों पर एक ही ऑपरेटर का उपयोग करने के लिए समझ में आता है - केवल ईओएल तक पार्सिंग को गूंगा। चर प्रतिस्थापन के कुछ प्रकार की अनुमति देने का मुद्दा है। भले ही यह थोड़ा बदसूरत लगता है, macOS / लिनक्स पर आप% envvar% ले सकते हैं और किसी भी संगत en-var के मूल्य को प्रतिस्थापित कर सकते हैं। तब यह प्लेटफार्मों के बीच पोर्टेबल हो सकता है।

बात यह है, यदि आप ऐसा नहीं करते हैं, तो आप सशर्त कोड के साथ हवा देते हैं - ठीक वही नहीं जो मैं पोर्टेबल कहूंगा:

$env:Index = 1
if ($IsWindows) {
    git show --% @~%Index%
}
else {
    git show --$ @~$Index
}

मैं सभी प्लेटफार्मों पर यह काम पसंद करूंगा:

$env:Index = 1
git show --% @~%Index%

विंडोज पर व्यवहार के रूप में रहना है क्योंकि संगतता है।

@rkeithhill

यह काफी नहीं है।

उन्मूलन की प्रक्रिया के द्वारा, विंडोज दुनिया में पावरशेल की भविष्यवाणी करने वाली

• --% cmd.exe -स्टाइल %...% पर्यावरण-चर संदर्भ, जैसे %USERNAME% (यदि कोई शेल और कोई विशेष तर्क शामिल नहीं थे, तो टोकन पारित हो जाएंगे) _verbatim_)

• सीधे PowerShell के मुंह से (यदि आप करेंगे; जोर जोड़ा गया):

वेब Cmd.exe के लिए लिखी गई कमांड लाइनों से भरा है । ये कमांड लाइन पॉवरशेल में अक्सर पर्याप्त काम करते हैं, लेकिन जब वे कुछ अक्षर शामिल करते हैं, जैसे एक अर्धविराम (;) एक डॉलर चिह्न ($), या घुंघराले ब्रेसिज़, आपको कुछ बदलाव करने होंगे, शायद कुछ उद्धरण जोड़ना होगा। यह कई छोटे सिरदर्द का स्रोत प्रतीत हो रहा था।

इस परिदृश्य को संबोधित करने में मदद करने के लिए, हमने कमांड लाइनों के पार्सिंग "भागने" के लिए एक नया तरीका जोड़ा। यदि आप एक जादू पैरामीटर -% का उपयोग करते हैं, तो हम आपकी कमांड लाइन के हमारे सामान्य पार्सिंग को रोकते हैं और कुछ बहुत सरल पर स्विच करते हैं। हम उद्धरण से मेल नहीं खाते। हम अर्धविराम पर नहीं रुकते। हम PowerShell चर का विस्तार नहीं करते हैं। यदि आप Cmd.exe सिंटैक्स (जैसे% TEMP%) का उपयोग करते हैं तो हम पर्यावरण चर का विस्तार करते हैं। इसके अलावा, लाइन के अंत तक तर्क (या पाइप, यदि आप पाइप कर रहे हैं) को पारित कर दिया गया है। यहाँ एक उदाहरण है:

ध्यान दें कि यह दृष्टिकोण _Unix_ दुनिया के लिए एक खराब फिट है (ऊपर से

• *.txt जैसे बिना किसी तर्क के ग्लोबिंग से काम नहीं चलेगा।

• Unix की दुनिया में पारंपरिक (POSIX-like) गोले _not_ पर्यावरण चर को संदर्भित करने के लिए %...% का उपयोग करते हैं; वे $... सिंटैक्स की अपेक्षा करते हैं।

• यूनिक्स दुनिया में (सौभाग्य से) कोई _raw_ कमांड लाइन नहीं है: किसी भी बाहरी निष्पादन योग्य को _literals_ का _array_ पास किया जाना चाहिए, इसलिए यह अभी भी PowerShell या CoreFx है जिसे पहले तर्क के लिए कमांड लाइन को पार्स करना होगा।

• यूनिक्स दुनिया में पारंपरिक (POSIX-like) गोले '...' (एकल-उद्धृत) तार को स्वीकार करते हैं, जो --% नहीं पहचानते हैं - # 10831 देखें।

लेकिन विंडोज की दुनिया में भी --% की गंभीर, गैर-स्पष्ट सीमाएँ हैं :

• यदि आप --% उपयोग करते हैं, तो जाहिर है, आप सीधे अपनी कमांड लाइन में PowerShell चर का संदर्भ नहीं दे सकते; एकमात्र - बोझिल - वर्कअराउंड अस्थायी रूप से _environment_ चर को परिभाषित करना है, जिसे आपको तब %...% साथ संदर्भित करना होगा।
• आप (...) में कमांड लाइन को संलग्न नहीं कर सकते - क्योंकि ) को कमांड लाइन के शाब्दिक भाग के रूप में व्याख्या की जाती है।
• आप ; और एक अन्य कथन के साथ कमांड लाइन का पालन नहीं कर सकते - क्योंकि ; को कमांड लाइन के शाब्दिक भाग के रूप में व्याख्या की जाती है।
• आप सिंगल-लाइन स्क्रिप्ट ब्लॉक के अंदर --% उपयोग नहीं कर सकते - क्योंकि } को कमांड लाइन के शाब्दिक भाग के रूप में व्याख्या की जाती है।
• आप पुनर्निर्देशन का उपयोग नहीं कर सकते - क्योंकि उन्हें कमांड लाइन के शाब्दिक भाग के रूप में माना जाता है - हालाँकि, आप cmd --% /c ... > file उपयोग कर सकते हैं, cmd.exe पुनर्निर्देशन को संभालने के लिए।
• आप पंक्ति-निरंतरता वर्णों का उपयोग नहीं कर सकते - न ही पॉवरशेल ( ` ) और न ही cmd.exe ( ^ ) - उन्हें _literals_ के रूप में माना जाएगा।
  
  
  
  • --% केवल कभी (अधिकतम पर) लाइन के अंत तक।
  
  

सौभाग्य से, हमारे पास पहले से ही _do_ का क्रॉस-प्लेटफ़ॉर्म सिंटैक्स है: _PowerShell का अपना सिंटैक्स_।

हां, इसका उपयोग करने के लिए आपको यह जानना होगा कि _PowerShell_ मेटाचैटर्स को क्या मानता है, जो दोनों का _superset_ है जो cmd.exe और POSIX- जैसे गोले जैसे बैश को मेटाचैटर्स मानते हैं, लेकिन यह एक अमीर, प्लेटफॉर्म- के लिए भुगतान करने की कीमत है अज्ञेय कमांड-लाइन का अनुभव।

तब यह कितना दुर्भाग्यपूर्ण है, कि PowerShell ने " वर्णों को इतने खराब तरीके से उद्धृत किया - जो इस मुद्दे का बहुत ही विषय है, और जिसे इस डॉक्स मुद्दे में संक्षेप में प्रस्तुत किया गया है।

@rkeithhill , मैंने एक स्पर्शरेखा की शुरुआत की; मुझे इसे बंद करने का प्रयास करने दें:

• --% वास्तव में पहले से ही _is_ को PowerShell Core 6.2.0 के रूप में लागू किया गया है; जैसे,
  /bin/echo --% %HOME% पर्यावरण चर का मूल्य प्रिंट करता है HOME ; इसके विपरीत,
  /bin/ls --% *.txt उम्मीद के अनुसार काम नहीं करेगा, क्योंकि *.txt को शाब्दिक रूप से पारित किया गया है।

• अंततः, जब --% का उपयोग नहीं किया जाता है, तो हमें उपयोगकर्ताओं को यह पता लगाने में मदद करने की आवश्यकता होती है कि कमांड लाइन / तर्क सरणी का निर्माण किया जाता है जो दृश्यों के निर्माण के बाद अंततः दिखता है (जो हमें वापस लेने योग्य # 1761 पर ले जाता है):

  • आपका मददगार echoArgs.exe बस यही करता है, और जुड़े मामले में आपने समझदारी से ऐसी कार्यक्षमता के लिए खुद को पॉवरशेल का हिस्सा बनने के लिए बुलाया।
  • @ स्टीवएल-एमएसएफटी ने त्रुटि रिकॉर्ड में परिणामी कमांड लाइन को शामिल किया।

अंत में, मेरे पिछले तर्क को लागू करने के लिए - पॉवरशेल के सिंटैक्स को स्वाभाविक रूप से पोर्टेबल एक के रूप में उपयोग करना - आपके उदाहरण के लिए:

# Works cross-platform, uses PowerShell syntax 
# Note: No need for an aux. *environment* variable (which should be cleaned up afterward)
$Index = 1
git show "@~$Index"

# Alternative, quoting just the '@'
git show `@~$Index

हां, आपको यह जानना आवश्यक है कि एक टोकन-शुरुआती @ एक मेटाचैकर है जिसे आपको उद्धृत करना है, लेकिन जैसा कि PowerShell अधिक व्यापक रूप से उपयोग किया जाता है, ऐसी आवश्यकताओं के बारे में जागरूकता और भी व्यापक होनी चाहिए।

FYI करें, यह समस्या लगभग विंडोज और यूनिक्स-पसंदों पर समान होनी चाहिए। यूनिक्स एसडीप्रोसेस के CoreFx कार्यान्वयन में ParseArgumentsIntoList नामक एक चीज है, जो CommandLineToArgvW पास बिलकुल _setargv स्विच के बिना लागू होती है (और अविकसित "" उद्धरणों में " सुविधा)। यूनिक्स को इसमें दर्द का एक अतिरिक्त बिंदु नहीं होना चाहिए क्योंकि वर्तमान आकार में यह उसी तरह से टूट गया है जैसे कि विंडोज है।

_setargv प्रत्येक प्रोग्राम के बाद हर प्रोग्राम का उपयोग करने वाली चीज नहीं है, और यह शायद इस पर विचार करने के लायक नहीं है क्योंकि, ठीक है, यह थोड़े सीआरटी संस्करणों के बीच व्यवहार परिवर्तन के साथ जुड़ा हुआ

एक और उदाहरण जहां आर्ग को सही ढंग से पार्स नहीं किया जा रहा है:

az "myargs&b"

इस मामले में, az को myargs और b नए आदेश के रूप में निष्पादित करने का प्रयास किया जाता है।

समाधान है: az -% "myargs & b"

@ स्टीवएल-एमएसएफटी, हम Waiting - DotNetCore लेबल को हटा सकते हैं, यह देखते हुए कि अपेक्षित विशेषता - संग्रह आधारित ProcessStartInfo.ArgumentList संपत्ति .NET कोर 2.1 के बाद से उपलब्ध है।

@TSlivede नई पद्धति से अवगत है और इसका उपयोग करने की योजना बना रहा है, लेकिन संबंधित RFC, https://github.com/PowerShell/PowerShell-RFC/pull/90 , दुर्भाग्यपूर्ण है, दुर्भाग्य से।

मेरा सुझाव है कि हम वहाँ _implementation_ चर्चा जारी रखें।

हालाँकि, RFC चर्चा में, @joeyaiello परिवर्तनों को एक प्रायोगिक सुविधा बनाने के बारे में बात करता है, लेकिन यह मेरे लिए तेजी से स्पष्ट हो रहा है कि आप मौजूदा कोड को बड़े पैमाने पर तोड़ने के बिना उद्धरण व्यवहार को ठीक नहीं कर सकते हैं:

जो किसी को __ के आसपास काम करना था:

• खाली स्ट्रिंग तर्क पारित करने में असमर्थता ( foo.exe "" वर्तमान में _no_ तर्क पारित करता है)
• एम्बेडेड उद्धरणों के स्वचालित बचने की कमी के कारण दोहरे उद्धरणों का अप्रत्याशित प्रभावी निष्कासन ( foo.exe '{ "foo": "bar" }' अनुचित रूप से पारित होने के कारण "{ "foo": "bar" }" बच गया)
• msiexec रूप में कुछ CLIs की quirks जो कुछ दलीलों को स्वीकार नहीं करते हैं _as को एक पूरे__ ( foo.exe foo="bar none" "foo=bar none" रूप में पारित किया जा रहा है)।
  नोट: यह msiexec जो कि यहाँ दोष है, और लागू किए गए प्रस्तावित परिवर्तनों के साथ, आवश्यक foo="bar none" उद्धरण के रूप में पास करने के बाद --% आवश्यकता होगी।

परेशानी में पड़ जाएगा, क्योंकि प्रस्तावित बदलावों के साथ वर्कअराउंड _break_ हो जाएगा।

इसलिए, एक अतिरिक्त प्रश्न यह है:

• हम कम से कम एक _opt-in_ सुविधा के रूप में सही व्यवहार कैसे उपलब्ध कर सकते हैं?

  • Start-Process साथ टूटी हुई उद्धरण के मामले में, हमारे पास कम से कम सही व्यवहार के लिए एक नया पैरामीटर शुरू करने का विकल्प है, लेकिन सीधे मंगलाचरण के साथ स्पष्ट रूप से एक विकल्प नहीं है (जब तक कि हम एक और "जादू प्रतीक" का परिचय न दें --% )।

• इस तरह के तंत्र के साथ एक मूलभूत समस्या - आम तौर पर, वरीयता चर द्वारा, लेकिन using बयानों द्वारा भी तेजी से बढ़ रही है - पॉवरशेल का डायनेमिक स्कूपिंग है; अर्थात्, ऑप्ट-इन व्यवहार डिफ़ॉल्ट रूप से कोड के लिए लागू किया जाएगा जिसे _from_ किसी के ऑप्ट-इन कोड के रूप में अच्छी तरह से कोडित किया जाता है, जो समस्याग्रस्त है।

  • शायद यह आमतौर पर _lexical_ सुविधाओं के स्कोपिंग के लिए समय है, lexically scoped using strict प्रस्ताव का एक सामान्यीकरण - समान रूप से सुस्त - lexical सख्त-मोड RFC @lbbkr द्वारा लिखित।

  • लेक्सिकली स्कॉप्ड using preference ProperArgumentQuoting जैसा कुछ? (नाम स्पष्ट रूप से परक्राम्य है, लेकिन मैं एक के साथ आने के लिए संघर्ष कर रहा हूं)।

उन सभी कोनों को देखते हुए, और यह सीधे आह्वान के साथ एक मुद्दा है, जहां हम केवल एक नया पैरामीटर नहीं जोड़ सकते, मैं दृढ़ता से पुराने व्यवहार को तोड़ने के पक्ष में हूं।

हाँ, यह शायद बहुत टूट जाएगा। लेकिन वास्तव में, केवल इसलिए कि इसके साथ शुरुआत करने के लिए इतनी अच्छी तरह से टूट गया था। मुझे नहीं लगता कि यह विशेष रूप से संभव है कि एक विशेषता है कि वास्तव में काम करता है पर एक टूटे हुए व्यवहार के लिए workarounds के एक विशाल ढेर के लिए क्या मात्रा बनाए रखने के लिए प्राथमिकता है।

एक नए प्रमुख संस्करण के रूप में, मुझे लगता है कि v7 वास्तव में एकमात्र मौका है जो हमें इस स्थिति को ठीक करने के लिए काफी समय के लिए मिलेगा, और हमें अवसर लेना चाहिए। बशर्ते हम उपयोगकर्ताओं को जागरूक करें, मुझे नहीं लगता कि संक्रमण खराब रूप से समग्र रूप से प्राप्त होगा।

अगर हमें लगता है कि ब्रेकिंग परिवर्तन अपरिहार्य है, तो शायद हमें आदर्श समाधान को डिजाइन करना चाहिए, इस बात को ध्यान में रखते हुए कि इंटरएक्टिव सत्र में प्रिंट करना आसान होना चाहिए और स्क्रिप्ट संस्करण होना संभव है जो सभी प्लेटफार्मों पर बेहतर काम करता है।

सहमत, @ vexx32 : मौजूदा व्यवहार को बनाए रखना, भले ही केवल डिफ़ॉल्ट रूप से, एक बारहमासी दर्द बिंदु बना रहेगा। उपयोगकर्ताओं को ऑप्ट-इन होने की आवश्यकता की उम्मीद नहीं है, और, एक बार वे ऐसा करते हैं, वे या तो अवसर पर भूल जाते हैं और / या हर बार इसे लागू करने की आवश्यकता पर नाराजगी जताते हैं।

एक शेल जो बाहरी कार्यक्रमों के लिए मज़बूती से तर्कों को पारित नहीं करता है, वह इसके मुख्य शासनों में से एक को विफल कर रहा है।

आपके पास ब्रेकिंग चेंज करने के लिए निश्चित रूप से _my_ वोट है, लेकिन मुझे डर है कि अन्य लोग अलग-अलग महसूस करेंगे, कम से कम नहीं क्योंकि v7 को लंबे समय से WinPS उपयोगकर्ताओं को PSCore में माइग्रेट करने की अनुमति के रूप में टाल दिया जा रहा है।

@iSazonov : https://github.com/PowerShell/PowerShell-RFC/pull/90 सही समाधान का वर्णन करता है।

इसकी आत्मा को पुन: प्राप्त करने के लिए:

PowerShell, एक शेल के रूप में, _its_ नियमों के अनुसार तर्कों को पार्स करने की आवश्यकता है और फिर लक्ष्य कार्यक्रम में परिणामी, विस्तारित तर्क मानों _verbatim_ को पास करें - उपयोगकर्ताओं को कभी भी यह नहीं सोचना चाहिए कि PowerShell कैसे होता है; वे सभी के बारे में चिंता करने की ज़रूरत है कि क्या _PowerShell_ सिंटैक्स सही हो रहा है।

• यूनिक्स-जैसे प्लेटफार्मों पर, ProcessStartInfo.ArgumentList अब हमें इसे पूरी तरह से लागू करने का एक तरीका देता है, यह देखते हुए कि विस्तारित तर्क मूल्यों के _ray_ को लक्ष्य कार्यक्रम में _as-is_ पास किया जा सकता है, क्योंकि यह तर्क कैसे गुजरता है - समझदारी से काम करता है - इस दुनिया में।

• विंडोज पर, हमें अराजकता की दुर्भाग्यपूर्ण वास्तविकता से निपटना होगा, जो एक झुर्री की खोज की है जो ProcessStartInfo.ArgumentList का एकमात्र उपयोग पर्याप्त रूप से अच्छा नहीं है, दुर्भाग्य से (_batch files_ के व्यापक कारण के रूप में CLI प्रविष्टि बिंदुओं के रूप में, @ SteveL-MSFT के az[.cmd] द्वारा प्रदर्शित किया गया है ऊपर --% ।

शायद PSSA उपयोगकर्ताओं को चेतावनी द्वारा परिवर्तन को कम करने में मदद कर सकता है कि वे एक तर्क प्रारूप का उपयोग करते हैं जिसे बदल दिया जाएगा।

मुझे लगता है कि हमें कुछ अन्य लोगों के साथ-साथ इस ब्रेकिंग बदलाव पर आगे बढ़ने के लिए वैकल्पिक सुविधाओं को अपनाने पर विचार करने की आवश्यकता है।

क्या मौजूदा व्यवहार को बनाए रखने में वास्तव में कोई मूल्य है? पीछे की संगतता के अलावा, मेरा मतलब है।

मुझे नहीं लगता कि इसके लिए दो कोड पथ बनाए रखना उचित है, बस एक टूटे हुए कार्यान्वयन को बनाए रखने के लिए क्योंकि कुछ पुराने कोड को एक समय में एक बार इसकी आवश्यकता हो सकती है। मुझे नहीं लगता कि एक बार में अपने कोड को अपडेट करने के लिए फॉक्स की उम्मीद करना अनुचित है। 😅

संदेह है कि अगर हम उम्मीद करते हैं कि PS7 WinPS के लिए एक स्टैंड-इन रिप्लेसमेंट हो; एकमात्र कारण जो मैं v7 के लिए व्यवहार को बनाए रखने के लिए देख सकता हूं, यदि हम लोगों से अपेक्षा करते हैं कि वे 5.1 और 7 दोनों पर कमांड चलाने के लिए एक ही स्क्रिप्ट का उपयोग कर रहे हैं, जो (उम्मीद है) एक बहुत ही दुर्लभ मामला होना चाहिए अगर PS7 5.1 के लिए अच्छा प्रतिस्थापन है।

और फिर भी, उपयोगकर्ताओं के लिए दोनों के लिए खाता होना मुश्किल नहीं होगा। बशर्ते हम वास्तविक भाषा वाक्य रचना को नहीं बदल रहे हैं, ऐसा कुछ करना बहुत आसान होना चाहिए:

if ($PSVersionTable.PSVersion.Major -lt 7) {
    # use old form
}
else {
    # use new form
}

बशर्ते हम उपयोगकर्ताओं को अंतर से अवगत कराते हैं, मुझे लगता है कि यह उस दर्द से राहत का स्वागत होगा जो अब तक पीएस में अजीब देशी निष्पादकों को संभालने के लिए किया गया है। 😄

जैसा कि @TylerLeonhardt ने वैकल्पिक विशेषताओं की चर्चा में उल्लेख किया है - इसका अर्थ है कि अब आप _multiple_ अलग-अलग कार्यान्वयन बनाए रखते हैं, जिन्हें प्रत्येक को बनाए रखना और परीक्षण करना होगा, साथ ही वैकल्पिक सुविधा ढांचे को बनाए रखना और परीक्षण करना भी होगा। वास्तव में इसके लिए इसके लायक नहीं है, tbh।

@ vexx32 पश्चगामी संगतता यहाँ एक बड़ा मुद्दा है। यह मूल निष्पादन के लिए args का एकमात्र मुद्दा नहीं है। मैं उन सभी को बाल्टी देना चाहता हूं और उन सभी को एक "वैकल्पिक सुविधा" होना चाहिए। उदाहरण के लिए, https://github.com/PowerShell/PowerShell/issues/1761 और https://github.com/PowerShell/PowerShell/issues/10675। देशी कमांड्स के साथ "फिक्सिंग" इंटरऑपरेबिलिटी एक ऐसी चीज़ है जिसे मैं vNext के लिए हल करना चाहूंगा। इसलिए अगर कोई भी इस श्रेणी में कोई भी मौजूदा या नए मुद्दों को देखता है, तो मुझे cc करें और मैं इसे उचित रूप से टैग कर दूंगा (या यदि आपके पास ट्रिपल अनुमति है, तो इसे अन्य लोगों की तरह टैग करें)।

वैकल्पिक सुविधाएँ मॉड्यूल हैं: इंजन में वैकल्पिक सुविधाएँ होना समर्थन के लिए बड़ा सिरदर्द है, विशेष रूप से विंडोज समर्थन के लिए। हम आंतरिक निर्भरता को कम करके और जनता के साथ आंतरिक एपीआई को बदलकर इंजन को संशोधित कर सकते हैं - इसके बाद हम आसान तरीके से इंजन में वैकल्पिक सुविधाओं को लागू कर सकते हैं।

@iSazonov मेरी टीम vNext में दिखाई देने वाली चीजों में से एक इंजन को और अधिक मॉड्यूलर बनाने के लिए है :)

अंतिम उपयोगकर्ताओं के लिए यहां अनुशंसित समाधान क्या है?

यह वंचित है, लेकिन यह सही तरीका पाने के लिए सबसे सरल तरीका है। * .NET फ्रेमवर्क से आर्ग्यूमेंटलिस्ट हैंडलिंग:

Add-Type -AssemblyName "System"
function startProcess([string] $FileName, [string[]] $ArgumentList) {
    $proc = ([System.Diagnostics.Process]::new())
    $proc.StartInfo.UseShellExecute = $false
    $proc.StartInfo.FileName = $FileName
    $proc.StartInfo.CreateNoWindow = $true
    foreach ($a in $ArgumentList) { $proc.StartInfo.ArgumentList.Add($a) }
    $proc.Start()
    return $proc
}

startProcess -FileName 'C:\Program Files\nodejs\node.exe' -ArgumentList '-e','console.log(process.argv.join(''\n''))','--','abc" \" messyString'

बेशक आप इसे कम उपयोग करने के लिए यहाँ स्थितीय मापदंडों और कुछ get-command प्रवंचना का उपयोग करके बना सकते हैं।

* अस्वीकरण: विंडोज पर एक cmdline पार्स करने का कोई सही तरीका नहीं है। "सही" से मेरा मतलब है कि ArgmentList हैंडलिंग के लिए सभी प्लेटफार्मों पर .NET द्वारा कार्यान्वित / argv रूपांतरण के लिए cmdline की MSVCRT शैली, main (string[] args) प्रसंस्करण, और यूनिक्स पर बाहरी स्पॉन कॉल। यह नमूना सामान्य अंतर के लिए कोई गारंटी नहीं के साथ IS है। प्रस्तावित NodeJS child_process प्रलेखन की "विंडोज़ कमांड लाइन" अनुभाग भी देखें।

@ Artoria2e5 ठीक यही निष्कर्ष मैं आया था। System.Diagnostics.Process बाहरी निष्पादन योग्य चलाने का एकमात्र विश्वसनीय तरीका है, लेकिन तर्कों से बचना stdlib नियमों के कारण मुश्किल हो सकता है:

2N backslashes + " ==> N backslashes and begin/end quote
2N+1 backslashes + " ==> N backslashes + literal " 
N backslashes ==> N backslashes

परिणामस्वरूप मैं तर्क से बचने के लिए निम्नलिखित तर्क के साथ आया हूं उन्हें प्रक्रिया उद्धरण के लिए " उद्धरण में लपेटें:
https://github.com/choovick/ps-invoke-externalcommand/blob/master/ExternalCommand/ExternalCommand.psm1#L244

बाह्य निष्पादन योग्य होने के साथ-साथ वास्तविक समय में STDOUT और STDERR प्राप्त करना मुश्किल हो सकता है, इसलिए मैंने यह पैकेज बनाया है

https://github.com/choovick/ps-invoke-externalcommand

कि मैं विंडोज, लिनक्स और मैक पर बहुत अधिक उपयोग कर रहा हूं और अब तक बिना मुद्दों के और मैं उन पर नईलाइन और अन्य विशेष पात्रों के साथ तर्क पारित कर सकता हूं।

GitHub

choovick / PS-आह्वान-externalcommand

GitHub पर एक खाता बनाकर choovick / ps-invoke-externalcommand विकास में योगदान करें।

GitHub

choovick / PS-आह्वान-externalcommand

GitHub पर एक खाता बनाकर choovick / ps-invoke-externalcommand विकास में योगदान करें।

@ स्त्रोविच पूरे stdio पुनर्निर्देशित बात महान है!

मैं बचने वाले हिस्से पर थोड़ा असहमत हूं, क्योंकि पहले से ही एक ऐसी चीज है जो इसे आपके लिए ArgumentList कहती है। मैं समझता हूं कि यह हाल ही में एक रिश्तेदार है (?) इसके अलावा, और यह निराशाजनक है क्योंकि एमएस एक स्ट्रिंग, स्ट्रिंग [] SDProcessStartInfo के लिए इनिशलाइज़र डालना भूल गया है। (क्या इनके लिए कोई स्थान है ... .NET इंटरफ़ेस प्रस्ताव?)

उस NodeJS उदाहरण से मेरा भागने का कार्य आप से थोड़ा अलग है: यह अनिर्दिष्ट (लेकिन .NET कोर और MSVCRT में पाया गया) "" उद्धरण चिह्नों के लिए \" को स्ट्रिंग के बाकी हिस्सों को अनक्वॉट नहीं करना चाहिए। \^" साथ संघर्ष करने के बजाय मुझे लगा कि मैं समय की शुरुआत के बाद से गुप्त उपयोग में आने वाली किसी चीज़ से बेहतर हो जाऊंगा।

@ Artoria2e5 दुर्भाग्य से ArgumentList अपने विंडो पर PowerShell 5.1 में उपलब्ध नहीं है, अपने उदाहरण का उपयोग कर रहा हूं:

`` `आप अशक्त-भाव पर एक विधि नहीं कह सकते।
C: Users \ yser \ dev \ test.ps1: 7 char: 37

• ... oreach ($ a $ ArgumentList में) {$ proc.StartInfo.ArgumentList.Add ($ a)}
• ~ ~ ~ ~ ~ ~ ~ ~ ~
  
  
  
  • CategoryInfo: InvalidOperation: (:) [], RuntimeException
  
  
  • फुल्लीक्यूलाइज़्डइरॉयरआईड: इनवोकमैथोडॉनऑन
    
    `` `
  
  

चूंकि कस्टम तर्क बच तर्क ...।

NodeJS में `\ _" के संबंध में, मुझे लगता है कि मुझे कई साल पहले ऐसा करना था :) और मुझे लगता है कि यह काम कर रहा है

System.Diagnostics.Process बाहरी निष्पादन योग्य चलाने का एकमात्र विश्वसनीय तरीका है

समस्या यह है कि आपको PowerShell के आउटपुट स्ट्रीम के साथ एकीकरण नहीं मिलेगा और आपको पाइपलाइन में स्ट्रीमिंग व्यवहार नहीं मिलेगा।

यदि आप अभी भी PowerShell को मंगलाचरण करने देना चाहते हैं (जो निश्चित रूप से बेहतर है) :

• यदि आपको _embedded_ " chars के साथ तर्क पारित करने की आवश्यकता है, तो _double_ उन्हें Windows पर, यदि संभव हो तो, या \ -स्केप करें:

  • विंडोज पर, जब _batch files_ को कॉल किया जाता है और यदि आप जानते हैं कि लक्ष्य कार्यक्रम "" समझता है तो बच गया " , $arg -replace '"', '""'

    • विंडोज पर "" करना श्रेयस्कर है (यह Windows PowerShell समस्या से बचा जाता है और CLIs के साथ काम करता है जो बैच फ़ाइलों का उपयोग _stubs_, जैसे Node.js और Azure) के साथ करते हैं, लेकिन सभी निष्पादन इसे समर्थन नहीं करते हैं (विशेष रूप से रूबी और नहीं पर्ल)।

  • अन्यथा (हमेशा यूनिक्स पर), $arg -replace '"', '\"'

  • नोट: _Windows PowerShell_ में, यह अभी भी हमेशा ठीक से काम नहीं करता है यदि मान में _spaces_ भी शामिल है, क्योंकि शाब्दिक \" की उपस्थिति मूल्य में स्थितिजन्य रूप से _not_ ट्रिगर होती है, जो PowerShell Core के विपरीत, दोहरे-उद्धरण को संलग्न करता है; जैसे, '3\" of snow' विराम।

  • इसके अतिरिक्त, उपरोक्त भागने से पहले, आपको \ तुरंत " , यदि उन्हें शाब्दिक रूप से माना जाए:

    • $arg = $arg -replace '(\\+)"', '$1$1"'

• यदि आपको _empty_ तर्क पारित करने की आवश्यकता है, तो '""' ।

  • '' -eq $arg ? '""' : $arg (WinPS विकल्प: ($arg, '""')['' -eq $arg]

• Windows PowerShell केवल, PS कोर में ऐसा न करें (जहां समस्या ठीक हो गई है):

  • यदि आपका तर्क _contains स्थान_ और _end in_ (एक या अधिक) \ , तो अनुगामी \ इंस्टेंस (s) दोगुना करें।

    • if ($arg -match ' .*?(\\+)$') { $arg = $arg + $Matches[1] }

• यदि cmd / एक बैच फ़ाइल उन तर्कों के साथ मंगाई जा रही है जो _not_ के पास रिक्त स्थान हैं (इसलिए PowerShell द्वारा _not_ स्वचालित स्वत: दोहरे-उद्धरण को ट्रिगर करते हैं) लेकिन &|<>^,; (जैसे: a&b ) के किसी भी शामिल होते हैं cmd / बैच / फ़ाइल कॉल को तोड़ता नहीं है:

  • $arg = '"' + $arg + '"'

• यदि आपको msiexec.exe जैसे गैर-व्यवहार वाले निष्पादन से निपटने की आवश्यकता है, तो तर्क को उद्धृत करें:

  • 'foo="bar none"'

जैसा कि कहा गया है, एक बार अंतर्निहित समस्या ठीक हो जाने पर ये वर्कअराउंड _break_ हो जाएंगे।

नीचे सरल (गैर-उन्नत) फ़ंक्शन iep ("बाहरी प्रोग्राम को लागू करने के लिए") है, जो:

• सब से ऊपर वर्णित बचाव सहित, के प्रदर्शन करती है स्वत: विशेष आवरण के लिए msiexec और पसंद करते हैं "" से अधिक से बचने \" लक्ष्य कार्यक्रम पर निर्भर करता है।
  
  
  
  • विचार यह है कि आप किसी भी तर्क को केवल _PowerShell_ के स्ट्रिंग सिंटैक्स पर ध्यान केंद्रित करके पास कर सकते हैं, और आवश्यक एस्केपिंग करने के लिए फ़ंक्शन पर भरोसा करते हैं, ताकि पावरशेल जो वर्बेट मान देखता है वह लक्ष्य प्रोग्राम द्वारा भी देखा जाता है।
  
  
  • PowerShell _Core_ में, इसे बहुत मज़बूती से काम करना चाहिए; Windows PowerShell में आपके पास अभी भी एम्बेडेड दोहरे उद्धरण चिह्नों के साथ किनारे के मामले हैं जो \" भागने का उपयोग करते हैं (जैसा कि ऊपर चर्चा की गई है)।
  
  
• शेल-कमांड इनवोकेशन सिंटैक्स को संरक्षित करता है।
  
  
  
  • बस अपनी कमांड लाइन में iep  प्रीपेंड करें।
  
  
• सीधे मंगलाचरण के रूप में, यह होगा:
  
  
  
  • PowerShell की धाराओं के साथ एकीकृत करता है
  
  
  • पाइपलाइन के माध्यम से लाइन द्वारा आउटपुट लाइन भेजता है
  
  
  • बाह्य कार्यक्रम के निकास कोड के आधार पर $LASTEXITCODE सेट करता है; हालाँकि, $? _not_ पर भरोसा किया जा सकता है।
  
  

नोट: फ़ंक्शन जानबूझकर न्यूनतर है (कोई पैरामीटर घोषणाएं, कोई कमांड-लाइन सहायता, लघु (अनियमित) नाम), क्योंकि इसका मतलब जितना संभव हो उतना विनीत होना चाहिए: बस अपनी कमांड लाइन में iep प्रीपेंड करें, और चीजें कार्य करना चाहिए।

EchoArgs.exe का उपयोग करके उदाहरण आह्वान ( EchoArgs.exe _ choco install echoargs -y साथ _elevated_ सत्र से चॉकलेट के माध्यम से संस्थापित):

PS> iep echoargs '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
Arg 0 is <>
Arg 1 is <a&b>
Arg 2 is <3" of snow>
Arg 3 is <Nat "King" Cole>
Arg 4 is <c:\temp 1\>
Arg 5 is <a \" b>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "" a&b "3\" of snow" "Nat \"King\" Cole" "c:\temp 1\\" "a \\\" b"

उपरोक्त PowerShell कोर आउटपुट दिखाता है। ध्यान दें कि खाली तर्क सहित पावरशेल द्वारा सभी तर्कों को सही तरीके से देखा गया था।

विंडोज पॉवरशेल में, 3" of snow तर्क को सही ढंग से पारित नहीं किया जाएगा, क्योंकि \" बचने का उपयोग किसी अज्ञात निष्पादन योग्य (जैसा कि ऊपर चर्चा की गई है) को कॉल करने के कारण किया जाता है।

यह सत्यापित करने के लिए कि बैच फ़ाइलें सही तरीके से तर्क पास करती हैं, आप echoargs.cmd को echoargs.exe लिए एक आवरण के रूप में बना सकते हैं:

'@echoargs.exe %*' | Set-Content echoargs.cmd

iep .\echoargs.cmd '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b' रूप में आमंत्रित करें

चूँकि अब बैच फ़ाइल को कॉल किया जाता है, "" -सॉर्फ़िंग कार्यरत है, जो विंडोज पॉवरशेल से कॉल करने पर 3" of snow समस्या को ठीक करता है।

यह फ़ंक्शन समान रूप से यूनिक्स-जैसे प्लेटफ़ॉर्म पर काम करता है, जिसे आप sh शेल स्क्रिप्ट बनाकर सत्यापित कर सकते हैं, जिसका नाम echoargs :

@'
#!/bin/sh
i=0; for a; do printf '%s\n' "\$$((i+=1))=[$a]"; done
'@ > echoargs; chmod a+x echoargs

iep ./echoargs '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b' रूप में आमंत्रित करें

महत्वपूर्ण: इस समारोह का एक ie (मैं nvoke (बाह्य) ई xecutable) में मैं सिर्फ प्रकाशित किया है एक मॉड्यूल Native , जो मैं उपयोग करने के लिए प्रोत्साहित बजाय। मॉड्यूल के साथ स्थापित करें
Install-Module Native -Scope CurrentUser ।
मॉड्यूल में ins ( Invoke-NativeShell ) कमांड भी शामिल है जो # 13068 में चर्चा किए गए उपयोग के मामले को संबोधित करता है - https://github.com/PowerShell/PowerShell/issues/13068#ecuecomment-671572939 देखें ब्योरा हेतु।

iep का स्रोत कोड (उपयोग मॉड्यूल Native बजाय - ऊपर देखें):

function iep {

  Set-StrictMode -Version 1
  if (-not (Test-Path Variable:IsCoreClr)) { $IsCoreCLR = $false }
  if (-not (Test-Path Variable:IsWindows)) { $IsWindows = $env:OS -eq 'Windows_NT' }

  # Split into executable name/path and arguments.
  $exe, [string[]] $argsForExe = $args

  # Resolve to the underlying command (if it's an alias) and ensure that an external executable was specified.
  $app = Get-Command -ErrorAction Stop $exe
  if ($app.ResolvedCommand) { $app = $app.ResolvedCommand }
  if ($app.CommandType -ne 'Application') { Throw "Not an external program, non-PS script, or batch file: $exe" }

  if ($argsForExe.Count -eq 0) {
    # Argument-less invocation
    & $exe
  }
  else {
    # Invocation with arguments: escape them properly to pass them through as literals.
    # Decide whether to escape embedded double quotes as \" or as "", based on the target executable.
    # * On Unix-like platforms, we always use \"
    # * On Windows, we use "" where we know it's safe to do. cmd.exe / batch files require "", and Microsoft compiler-generated executables do too, often in addition to supporting \",
    #   notably including Python and Node.js
    #   However, notable interpreters that support \" ONLY are Ruby and Perl (as well as PowerShell's own CLI, but it's better to call that with a script block from within PowerShell).
    #   Targeting a batch file triggers "" escaping, but in the case of stub batch files that simply relay to a different executable, that could still break
    #   if the ultimate target executable only supports \" 
    $useDoubledDoubleQuotes = $IsWindows -and ($app.Source -match '[/\\]?(?<exe>cmd|msiexec)(?:\.exe)?$' -or $app.Source -match '\.(?<ext>cmd|bat|py|pyw)$')
    $doubleQuoteEscapeSequence = ('\"', '""')[$useDoubledDoubleQuotes]
    $isMsiExec = $useDoubledDoubleQuotes -and $Matches['exe'] -eq 'msiexec'
    $isCmd = $useDoubledDoubleQuotes -and ($Matches['exe'] -eq 'cmd' -or $Matches['ext'] -in 'cmd', 'bat')
    $escapedArgs = foreach ($arg in $argsForExe) {
      if ('' -eq $arg) { '""'; continue } # Empty arguments must be passed as `'""'`(!), otherwise they are omitted.
      $hasDoubleQuotes = $arg.Contains('"')
      $hasSpaces = $arg.Contains(' ')
      if ($hasDoubleQuotes) {
        # First, always double any preexisting `\` instances before embedded `"` chars. 
        # so that `\"` isn't interpreted as an escaped `"`.
        $arg = $arg -replace '(\\+)"', '$1$1"'
        # Then, escape the embedded `"` chars. either as `\"` or as `""`.
        # If \" escaping is used:
        # * In PS Core, use of `\"` is safe, because its use triggers enclosing double-quoting (if spaces are also present).
        # * !! In WinPS, sadly, that isn't true, so something like `'foo="bar none"'` results in `foo=\"bar none\"` -
        #   !! which - due to the lack of enclosing "..." - is seen as *2* arguments by the target app, `foo="bar` and `none"`.
        #   !! Similarly, '3" of snow' would result in `3\" of snow`, which the target app receives as *3* arguments, `3"`, `of`, and `snow`.
        #   !! Even manually enclosing the value in *embedded* " doesn't help, because that then triggers *additional* double-quoting.
        $arg = $arg -replace '"', $doubleQuoteEscapeSequence
    }
      elseif ($isMsiExec -and $arg -match '^(\w+)=(.* .*)$') { 
        # An msiexec argument originally passed in the form `PROP="value with spaces"`, which PowerShell turned into `PROP=value with spaces`
        # This would be passed as `"PROP=value with spaces"`, which msiexec, sady, doesn't recognize (`PROP=valueWithoutSpaces` works fine, however).
        # We reconstruct the form `PROP="value with spaces"`, which both WinPS And PS Core pass through as-is.
        $arg = '{0}="{1}"' -f $Matches[1], $Matches[2]
      }
      # As a courtesy, enclose tokens that PowerShell would pass unquoted in "...", 
      # if they contain cmd.exe metachars. that would break calls to cmd.exe / batch files.
      $manuallyDoubleQuoteForCmd = $isCmd -and -not $hasSpaces -and $arg -match '[&|<>^,;]'
      # In WinPS, double trailing `\` instances in arguments that have spaces and will therefore be "..."-enclosed,
      # so that `\"` isn't mistaken for an escaped `"` - in PS Core, this escaping happens automatically.
      if (-not $IsCoreCLR -and ($hasSpaces -or $manuallyDoubleQuoteForCmd) -and $arg -match '\\') {
        $arg = $arg -replace '\\+$', '$&$&'
      }
      if ($manuallyDoubleQuoteForCmd) {
        # Wrap in *embedded* enclosing double quotes, which both WinPS and PS Core pass through as-is.
        $arg = '"' + $arg + '"'
      }
      $arg
    }
    # Invoke the executable with the properly escaped arguments.
    & $exe $escapedArgs
  }
}

@ mklement0 प्रभावशाली, लेकिन यहां ऐसे जोड़े हैं जो मेरे लिए खिड़कियों पर काम नहीं करते हैं:

iep echoargs 'somekey="value with spaces"' 'te\" st'

Arg 0 is <somekey="value>
Arg 1 is <with>
Arg 2 is <spaces">
Arg 3 is <te\">
Arg 4 is <st>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" somekey=\"value with spaces\" te\\\" st

यहाँ मेरे परीक्षण का तर्क है :)

$Arguments = @(
    'trippe slash at the end \\\',
    '4 slash at the end \\\\',
    '\\servername\path\',
    'path=\\servername\path\',
    'key="\\servername\pa th\"',
    '5 slash at the end \\\\\',
    '\\" double slashed double quote',
    'simple',
    'white space',
    'slash at the end \',
    'double slash at the end \\',
    'trippe slash at the end \\\',
    'trippe slash at the end with space \\\ ',
    '\\" double slashed double quote',
    'double slashed double quote at the end \\"',
    '\\\" triple slashed double quote',
    'triple slashed double quote at the end \\\"',
    # slash
    'single slashes \a ^ \: \"',
    'path="C:\Program Files (x86)\test\"'
    # quotes
    'double quote " and single quote ''',
    # windows env var syntax
    "env var OS: %OS%",
    # utf16
    ('"utf16 ETHIOPIC WORDSPACE: \u1361"' | ConvertFrom-Json),
    # special chars
    "newLine`newLine"
    "tab`tab"
    "backspace`bbackspace"
    "carriage`rafter",
    "formFeed`fformFeed",
    # JSON Strings
    @"
[{"_id":"5cdab57e4853ea7b5a707070","index":0,"guid":"25319946-950e-4fe8-9586-ddd031cbb0fc","isActive":false,"balance":"`$2,841.15","picture":"http://placehold.it/32x32","age":39,"eyeColor":"blue","name":{"first":"Leach","last":"Campbell"},"company":"EMOLTRA","email":"[email protected]","phone":"+1 (864) 412-3166","address":"127 Beadel Street, Vivian, Vermont, 1991","about":"Ex labore non enim consectetur id ullamco nulla veniam Lorem velit cillum aliqua amet nostrud. Occaecat ipsum do est qui sint aliquip anim culpa laboris tempor amet. Aute sint anim est sint elit amet nisi veniam culpa commodo nostrud cupidatat in ex.","registered":"Monday, August 25, 2014 4:04 AM","latitude":"-12.814443","longitude":"75.880149","tags":["pariatur","voluptate","sint","Lorem","eiusmod"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Lester Bender"},{"id":1,"name":"Concepcion Jarvis"},{"id":2,"name":"Elsie Whitfield"}],"greeting":"Hello, Leach! You have 10 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57e8cd0ac577ab534a4","index":1,"guid":"0be10c87-6ce7-46c4-8dd6-23b1d9827538","isActive":false,"balance":"`$1,049.56","picture":"http://placehold.it/32x32","age":33,"eyeColor":"green","name":{"first":"Lacey","last":"Terrell"},"company":"XSPORTS","email":"[email protected]","phone":"+1 (858) 511-2896","address":"850 Franklin Street, Gordon, Virginia, 4968","about":"Eiusmod nostrud mollit occaecat Lorem consectetur enim pariatur qui eu. Proident aliqua sunt incididunt Lorem adipisicing ea esse do ullamco excepteur duis qui. Irure labore cillum aliqua officia commodo incididunt esse ad duis ea. Occaecat officia officia laboris veniam id dolor minim magna ut sit. Aute quis occaecat eu veniam. Quis exercitation mollit consectetur magna officia sit. Irure ullamco laborum cillum dolore mollit culpa deserunt veniam minim sunt.","registered":"Monday, February 3, 2014 9:19 PM","latitude":"-82.240949","longitude":"2.361739","tags":["nostrud","et","non","eiusmod","qui"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Meyers Dillard"},{"id":1,"name":"Jacobson Franco"},{"id":2,"name":"Hunt Hernandez"}],"greeting":"Hello, Lacey! You have 8 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57eae2f9bc5184f1768","index":2,"guid":"3c0de017-1c2a-470e-87dc-5a6257e8d9d9","isActive":true,"balance":"`$3,349.49","picture":"http://placehold.it/32x32","age":20,"eyeColor":"green","name":{"first":"Knowles","last":"Farrell"},"company":"DAYCORE","email":"[email protected]","phone":"+1 (971) 586-2740","address":"150 Bath Avenue, Marion, Oregon, 991","about":"Eiusmod sint commodo eu id sunt. Labore esse id veniam ea et laborum. Dolor ad cupidatat Lorem amet. Labore ut commodo amet commodo. Ipsum reprehenderit voluptate non exercitation anim nostrud do. Aute incididunt ad aliquip aute mollit id eu ea. Voluptate ex consequat velit commodo anim proident ea anim magna amet nisi dolore.","registered":"Friday, September 28, 2018 7:51 PM","latitude":"-11.475201","longitude":"-115.967191","tags":["laborum","dolor","dolor","magna","mollit"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Roxanne Griffith"},{"id":1,"name":"Walls Moore"},{"id":2,"name":"Mattie Carney"}],"greeting":"Hello, Knowles! You have 8 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57e80ff4c4085cd63ef","index":3,"guid":"dca20009-f606-4b99-af94-ded6cfbbfa38","isActive":true,"balance":"`$2,742.32","picture":"http://placehold.it/32x32","age":26,"eyeColor":"brown","name":{"first":"Ila","last":"Hardy"},"company":"OBLIQ","email":"[email protected]","phone":"+1 (996) 556-2855","address":"605 Hillel Place, Herald, Delaware, 9670","about":"Enim eiusmod laboris amet ex laborum do dolor qui occaecat ex do labore quis sunt. Veniam magna non nisi ipsum occaecat anim ipsum consectetur ex laboris aute ut consectetur. Do eiusmod tempor dolore eu in dolore qui anim non et. Minim amet exercitation in in velit proident sint aliqua Lorem reprehenderit labore exercitation.","registered":"Friday, April 21, 2017 6:33 AM","latitude":"64.864232","longitude":"-163.200794","tags":["tempor","eiusmod","mollit","aliquip","aute"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Duncan Guy"},{"id":1,"name":"Jami Maxwell"},{"id":2,"name":"Gale Hutchinson"}],"greeting":"Hello, Ila! You have 7 unread messages.","favoriteFruit":"banana"},{"_id":"5cdab57ef1556326f77730f0","index":4,"guid":"f2b3bf60-652f-414c-a5cf-094678eb319f","isActive":true,"balance":"`$2,603.20","picture":"http://placehold.it/32x32","age":27,"eyeColor":"brown","name":{"first":"Turner","last":"King"},"company":"DADABASE","email":"[email protected]","phone":"+1 (803) 506-2511","address":"915 Quay Street, Hinsdale, Texas, 9573","about":"Consequat sunt labore tempor anim duis pariatur ad tempor minim sint. Nulla non aliqua veniam elit officia. Ullamco et irure mollit nulla do eiusmod ullamco. Aute officia elit irure in adipisicing et cupidatat dolor in sint elit dolore labore. Id esse velit nisi culpa velit adipisicing tempor sunt. Eu sunt occaecat ex pariatur esse.","registered":"Thursday, May 21, 2015 7:44 PM","latitude":"88.502961","longitude":"-119.654437","tags":["Lorem","culpa","labore","et","nisi"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Leanne Lawson"},{"id":1,"name":"Jo Shepard"},{"id":2,"name":"Effie Barnes"}],"greeting":"Hello, Turner! You have 6 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57e248f8196e1a60d05","index":5,"guid":"875a12f0-d36a-4e7b-aaf1-73f67aba83f8","isActive":false,"balance":"`$1,001.89","picture":"http://placehold.it/32x32","age":38,"eyeColor":"blue","name":{"first":"Petty","last":"Langley"},"company":"NETUR","email":"[email protected]","phone":"+1 (875) 505-2277","address":"677 Leonard Street, Ticonderoga, Utah, 1152","about":"Nisi do quis sunt nisi cillum pariatur elit dolore commodo aliqua esse est aute esse. Laboris esse mollit mollit dolor excepteur consequat duis aute eu minim tempor occaecat. Deserunt amet amet quis adipisicing exercitation consequat deserunt sunt voluptate amet. Ad magna quis nostrud esse ullamco incididunt laboris consectetur.","registered":"Thursday, July 31, 2014 5:16 PM","latitude":"-57.612396","longitude":"103.91364","tags":["id","labore","deserunt","cillum","culpa"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Colette Mullen"},{"id":1,"name":"Lynnette Tanner"},{"id":2,"name":"Vickie Hardin"}],"greeting":"Hello, Petty! You have 9 unread messages.","favoriteFruit":"banana"},{"_id":"5cdab57e4df76cbb0db9be43","index":6,"guid":"ee3852fe-c597-4cb6-a336-1466e8978080","isActive":true,"balance":"`$3,087.87","picture":"http://placehold.it/32x32","age":33,"eyeColor":"brown","name":{"first":"Salas","last":"Young"},"company":"PLAYCE","email":"[email protected]","phone":"+1 (976) 473-2919","address":"927 Elm Place, Terlingua, North Carolina, 2150","about":"Laborum laboris ullamco aliquip occaecat fugiat sit ex laboris veniam tempor tempor. Anim quis veniam ad commodo culpa irure est esse laboris. Fugiat nostrud elit mollit minim. Velit est laborum ut quis anim velit aute enim culpa amet ipsum.","registered":"Thursday, October 1, 2015 10:59 AM","latitude":"-57.861212","longitude":"69.823065","tags":["eu","est","et","proident","nisi"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Day Solomon"},{"id":1,"name":"Stevens Boyd"},{"id":2,"name":"Erika Mayer"}],"greeting":"Hello, Salas! You have 10 unread messages.","favoriteFruit":"apple"},{"_id":"5cdab57ed3c91292d30e141d","index":7,"guid":"ef7c0beb-8413-4f39-987f-022c4e8ec482","isActive":false,"balance":"`$2,612.45","picture":"http://placehold.it/32x32","age":36,"eyeColor":"brown","name":{"first":"Gloria","last":"Black"},"company":"PULZE","email":"[email protected]","phone":"+1 (872) 513-2364","address":"311 Guernsey Street, Hatteras, New Mexico, 2241","about":"Laborum sunt exercitation ea labore ullamco dolor pariatur laborum deserunt adipisicing pariatur. Officia velit duis cupidatat eu officia magna magna deserunt do. Aliquip cupidatat commodo duis aliquip in aute dolore occaecat esse ad. Incididunt est magna in pariatur ut do ex sit minim cupidatat culpa. Voluptate eu veniam cupidatat exercitation.","registered":"Friday, June 26, 2015 7:59 AM","latitude":"38.644208","longitude":"-45.481555","tags":["sint","ea","anim","voluptate","elit"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Abby Walton"},{"id":1,"name":"Elsa Miranda"},{"id":2,"name":"Carr Abbott"}],"greeting":"Hello, Gloria! You have 5 unread messages.","favoriteFruit":"strawberry"},{"_id":"5cdab57edc91491fb70b705d","index":8,"guid":"631ff8a0-ce4c-4111-b1e4-1d112f4ecdc7","isActive":false,"balance":"`$2,550.70","picture":"http://placehold.it/32x32","age":25,"eyeColor":"brown","name":{"first":"Deirdre","last":"Huber"},"company":"VERBUS","email":"[email protected]","phone":"+1 (871) 468-3420","address":"814 Coles Street, Bartonsville, Tennessee, 7313","about":"Ipsum ex est culpa veniam voluptate officia consectetur quis et irure proident pariatur non. In excepteur est aliqua duis duis. Veniam consectetur cupidatat reprehenderit qui qui aliqua.","registered":"Monday, April 1, 2019 2:33 AM","latitude":"-75.702323","longitude":"45.165458","tags":["labore","aute","nisi","laborum","laborum"],"range":[0,1,2,3,4,5,6,7,8,9],"friends":[{"id":0,"name":"Genevieve Clarke"},{"id":1,"name":"Black Sykes"},{"id":2,"name":"Watson Hudson"}],"greeting":"Hello, Deirdre! You have 8 unread messages.","favoriteFruit":"strawberry"}]
"@
)

System.Diagnostics.Process का उपयोग करते समय सीमाएं होती हैं, यही कारण है कि मुझे STDOUT STDERR पर कब्जा करने और फिर चर में संयोजन के लिए क्षमताओं के साथ अपना खुद का धावक लिखना पड़ा, जो मेरे उपयोग के मामलों के लिए पर्याप्त है, लेकिन सही नहीं है।

संपादित करें: जैसा कि आपने कहा कि इसके चलते विंडोज पॉज़शेल 5 में किनारे के मामले हैं। मैंने पॉवर्सशेल 6 पर परीक्षण किया और यह बहुत अच्छा काम करता है! दुर्भाग्य से मैं 5 से निपटने के लिए है जब तक 7 विंडोज मामले में इसे लेता है ...

प्रभावशाली, लेकिन यहां कुछ ऐसे जोड़े हैं जो खिड़कियों पर मेरे लिए काम नहीं करते हैं:

हां, ये सीमाएँ _Windows PowerShell_ पर लागू होती हैं, जिसके निष्पादन के लिए "" एम्बेडेड " बचने का समर्थन नहीं किया जा सकता है, जैसा कि मेरी पिछली टिप्पणी में विस्तृत है।
यदि आप अपने सभी इनवोकेशन में "" भागने के लिए समर्थन प्राप्त करने के इच्छुक हैं (_most_, लेकिन विंडोज़ के सभी निष्पादन योग्य इसका समर्थन नहीं करते हैं), तो आप आसानी से फ़ंक्शन को ट्विक कर सकते हैं।

और, आपके संपादन में आपने क्या कहा है, इसकी पुष्टि करने के लिए: PowerShell _Core_ में:

• iep echoargs 'somekey="value with spaces"' 'te\" st' ठीक काम करता है।
• आपके परीक्षण के तर्क भी ठीक काम करने लगते हैं।

यदि आप अपने सभी इनवोकेशन में "" भागने के लिए समर्थन प्राप्त करने के लिए तैयार हैं (_most_, लेकिन विंडोज़ पर सभी निष्पादन योग्य इसका समर्थन नहीं करते हैं), तो आप आसानी से फ़ंक्शन को ट्विक कर सकते हैं।

धन्यवाद मैं इसे निकट भविष्य में एक कोशिश दूंगा। मैं इस अवसर पर sqlcmd से निपटता हूं और यह सुनिश्चित करने के लिए "" समर्थन नहीं करता है। उस मामले के लिए - विशिष्ट तर्कों के लिए भागने के तर्क को छोड़ने का एक विकल्प प्रदान करना आसान है।

जिस तरह से विंडोज कमांड लाइन तर्क को पार्सिंग C ++ कमांड लाइन तर्क में पाया जा सकता

ऑपरेटिंग सिस्टम कमांड लाइन पर दिए गए तर्कों की व्याख्या करते समय Microsoft C / C ++ स्टार्टअप कोड निम्नलिखित नियमों का उपयोग करता है:

• तर्क को सफेद स्थान द्वारा सीमांकित किया जाता है, जो या तो एक स्थान या एक टैब है।

• कैरेट कैरेक्टर (^) को एस्केप कैरेक्टर या सीमांकक के रूप में मान्यता प्राप्त नहीं है। कार्यक्रम में argv सरणी में पारित होने से पहले ऑपरेटिंग सिस्टम में कमांड-लाइन पार्सर द्वारा चरित्र को पूरी तरह से संभाला जाता है।

• दोहरे उद्धरण चिह्नों (" स्ट्रिंग ") से घिरे एक स्ट्रिंग को एक एकल तर्क के रूप में व्याख्या की जाती है, भले ही भीतर निहित सफेद अंतरिक्ष की परवाह किए बिना। एक उद्धृत स्ट्रिंग को एक तर्क में एम्बेड किया जा सकता है।

• एक बैकस्लैश (\ ") से पहले एक दोहरे उद्धरण चिह्न को शाब्दिक दोहरे उद्धरण चिह्न चरित्र (") के रूप में व्याख्या किया गया है।

• बैकस्लैश की व्याख्या शाब्दिक रूप से की जाती है, जब तक कि वे तुरंत दोहरे उद्धरण चिह्न से पहले न हों।

• यदि बैकस्लैश की एक भी संख्या दोहरे उद्धरण चिह्न के बाद होती है, तो बैकस्लैश की प्रत्येक जोड़ी के लिए argv सरणी में एक बैकस्लैश रखा जाता है, और दोहरे उद्धरण चिह्न को स्ट्रिंग सिमरिटर के रूप में व्याख्या किया जाता है।

• यदि बैकस्लैश की एक विषम संख्या दोहरे उद्धरण चिह्न के बाद होती है, तो बैकस्लैश के प्रत्येक जोड़े के लिए argv सरणी में एक बैकस्लैश रखा जाता है, और शेष उद्धरण के द्वारा डबल कोटेशन चिह्न "बच" जाता है, जिससे एक शाब्दिक कारण बनता है। डबल उद्धरण चिह्न (") argv में रखा जाना है।

यह भी _exec, _wexec के कार्यों पर चर्चा की गई है:

स्ट्रिंग्स में एम्बेडेड स्पेस अप्रत्याशित व्यवहार का कारण बन सकते हैं; उदाहरण के लिए, _exec स्ट्रिंग "hi there" होने से नई प्रक्रिया दो तर्क, "hi" और "there" । यदि नई प्रक्रिया "हाय वहाँ" नामक एक फ़ाइल खोलने का इरादा था, तो प्रक्रिया विफल हो जाएगी। आप स्ट्रिंग को उद्धृत करके इससे बच सकते हैं: "\"hi there\"" ।

पायथन कैसे मूल निष्पादन योग्य कॉल करता है

पायथन के subprocess.Popen विंडोज पर एक स्ट्रिंग के लिए एक तर्क अनुक्रम परिवर्तित करने में वर्णित तरीके से args को स्ट्रिंग में परिवर्तित करके सही ढंग से भागने से बच सकते हैं। कार्यान्वयन subprocess.list2cmdline ।

उम्मीद है कि यह --% या डबल भागने (PowerShell और CMD सिंटैक्स दोनों का उपयोग करके) के बजाय PowerShell को अधिक सुरुचिपूर्ण तरीके से कैसे संभाल सकता है, इस पर कुछ प्रकाश डाला जा सकता है। वर्तमान वर्कअराउंड्स वास्तव में बग एज़्योर सीएलआई (जो कि python.exe पर आधारित है) ग्राहक हैं।

हमारे पास अभी भी यह समझने के लिए स्पष्ट और संक्षिप्त तरीका नहीं है कि इस समस्या को कैसे हल किया जाए। अगर यह v7 के साथ सरलीकृत है, तो क्या पॉवर्सशेल टीम का कोई भी व्यक्ति प्रकाश को बहा सकता है?

खैर, अच्छी खबर यह है कि PS 7.1 के लिए फ़ोकस में से एक देशी आदेशों को लागू करना आसान बनाना है। 7.1 निवेश पर एक

अधिकांश देशी कमांड्स PowerShell के भीतर से ठीक काम करते हैं, हालांकि, कुछ ऐसे मामले हैं जहां तर्क पार्स करना आदर्श नहीं है (जैसे उद्धरणों को संभालना)। इरादा उपयोगकर्ताओं को किसी भी लोकप्रिय देशी उपकरण के लिए नमूना कमांड लाइनों को काटने के लिए सक्षम करने के लिए है, इसे PowerShell में पेस्ट करें, और यह केवल PowerShell के विशिष्ट भागने की आवश्यकता के बिना काम करता है।

तो शायद (उम्मीद है) यह 7.1 में संबोधित किया जाएगा

धन्यवाद, @rkeithhill , लेकिन नहीं:

इरादा उपयोगकर्ताओं को किसी भी लोकप्रिय देशी उपकरण के लिए नमूना कमांड लाइनों को काटने के लिए सक्षम करने के लिए है, इसे PowerShell में पेस्ट करें, और यह केवल PowerShell के विशिष्ट भागने की आवश्यकता के बिना काम करता है।

एक और तरह की ध्वनि अंतर्निहित वैचारिक रूप से समस्याग्रस्त --% (स्टॉप-पार्सिंग प्रतीक) पर ले जाती है?

@ स्टीवएल-एमएसएफटी, क्या आप हमें इस आगामी फीचर के बारे में अधिक बता सकते हैं?

पुनर्कथन करने के लिए, यहाँ प्रस्तावित फिक्स यह है कि आप सभी पर ध्यान केंद्रित करने की जरूरत है _PowerShell_ की वाक्यविन्यास आवश्यकताओं को पूरा करने के लिए और PowerShell ने दृश्यों से बचकर सभी का ख्याल रखा है _ (Windows पर) Unix पर यह अब भी आवश्यक नहीं है, अब .NET की अनुमति है हमें टारगेट प्रोग्राम में शब्दशः टोकन की एक सरणी पास करने के लिए) - लेकिन इसमें कोई संदेह नहीं है कि फिक्स को ऑप्ट-इन करना होगा, अगर पिछड़े संगतता को बनाए रखना होगा।

इस फिक्स के साथ, अन्य गोले के लिए कमांड लाइनों के साथ _some_ fiddling की अभी भी आवश्यकता होगी, लेकिन यह अधिक सीधा होगा - और, --% , आप PowerShell के सिंटैक्स और चर विस्तार ( (...) साथ भाव) की पूरी शक्ति को बनाए रखते हैं

• आपको \" को `" साथ बदलने की आवश्यकता है, लेकिन _ "..." _ के अंदर।

• आपको यह जानने की आवश्यकता है कि _no (अन्य) शेल_ शामिल है, ताकि बैश-शैली के पर्यावरण-चर संदर्भ जैसे $USER _not_ काम करें (उन्हें _PowerShell_ चर के रूप में व्याख्या किया जाएगा), जब तक आप उन्हें प्रतिस्थापित नहीं करते समतुल्य PowerShell वाक्यविन्यास, $env:USER ।

  • एक तरफ के रूप में: --% लिए क्षतिपूर्ति करने की कोशिश करता है - विशेष रूप से _invariably_ - cmd.exe -स्टाइल पर्यावरण-चर संदर्भ जैसे %USERNAME% , लेकिन ध्यान दें कि न केवल doesn ' t समर्थन बैश-शैली के संदर्भ ( $USER ) _verbatim_ को लक्ष्य कार्यक्रम में पारित कर दिया गया है, लेकिन अनिक्स जैसे प्लेटफार्मों पर cmd.exe -स्टाइल संदर्भों का अप्रत्याशित रूप से विस्तार करता है, और '...' को नहीं पहचानता है
  • एक विकल्प के लिए नीचे देखें कि _does_ संबंधित प्लेटफ़ॉर्म-देशी शेल को शामिल करता है।

• आपको इस बात से अवगत होना चाहिए कि PowerShell में _aditional_ metacharacters हैं जिन्हें शब्दशः उपयोग के लिए उद्धृत / भागने की आवश्यकता है; ये हैं (ध्यान दें कि @ केवल तर्क के _first_ char के रूप में समस्याग्रस्त है।)

  • POSIX- जैसे गोले (जैसे, बैश): @ { } ` (और $ , अगर आप PowerShell द्वारा अप-फ्रंट विस्तार को रोकना चाहते हैं)
  • cmd.exe : ( ) @ { } # `
  • व्यक्तिगत रूप से ` ऐसे चार्ट से बचने। पर्याप्त है (जैसे, printf %s `@list.txt )।

कुछ हद तक एक विपरीत उदाहरण:

निम्नलिखित बैश कमांड लाइन लें:

# Bash
$ printf '"%s"\n' "3\" of snow"
"3" of snow"        # output

जगह में प्रस्तावित तय के साथ, सभी आवश्यक है कि \" इंस्टेंस को "..." `" साथ-युक्त तर्क के अंदर बदल दिया जाए:

# PowerShell - WISHFUL THINKING
PS> printf '"%s"\n' "3`" of snow"
"3" of snow"        # output

यही है, आपको " '...' " अंदर एम्बेडेड "..." अंदर आपको केवल उन्हें बचने के लिए _PowerShell_ को खुश करने की आवश्यकता है (जो आप भी कर सकते हैं "" यहाँ के साथ)।

उपरोक्त iep फ़ंक्शन इस फ़िक्स को लागू iep printf '"%s"\n' "3`" of snow" इच्छित के रूप में काम करे।

वर्तमान, टूटे हुए व्यवहार के साथ इसका विरोध करें, जहां आपको बश में काम करने के लिए निम्नलिखित हुप्स के माध्यम से कूदना होगा ( \ साथ भागने के लिए एक _additional_ राउंड की आवश्यकता है):

# PowerShell - messy workaround to compensate for the current, broken behavior.
PS> printf '\"%s\"\n' "3\`" of snow"
"3" of snow"        # output

जगह तय करने के साथ, जो लोग दिए गए कमांड लाइन _as-is_ का उपयोग प्लेटफ़ॉर्म के _default शेल_ के माध्यम से करना चाहते हैं ,

# PowerShell - WISHFUL THINKING
PS> sh -c @'
printf '"%s"\n' "3\" of snow"
'@
"3" of snow"  # output

ध्यान दें कि --% उपयोग _not_ यहां काम करता है ( printf --% '"%s"\n' "3\" of snow" ), और यहां-स्ट्रिंग-आधारित दृष्टिकोण का अतिरिक्त लाभ यह है कि विभिन्न --% सीमाएं लागू नहीं होती हैं , विशेष रूप से एक आउटपुट पुनर्निर्देशन ( > ) का उपयोग करने में असमर्थता।

यदि आप एक _double_-quoted यहाँ-स्ट्रिंग ( @"<newline>....<newline>"@ ) पर स्विच करते हैं, तो आप --% साथ, _PowerShell वैरिएबल्स और एक्सप्रेशन_ भी एम्बेड कर सकते हैं; हालाँकि, आपको यह सुनिश्चित करने की आवश्यकता है कि विस्तारित मान लक्ष्य शेल के सिंटैक्स को तोड़ न दें।

हम इस तरह के कॉल के लिए sh -c / cmd /c जरूरत न हो निर्दिष्ट किया जा सकता है), लेकिन इस तरह से जटिल कमांड लाइनों को पारित करने के लिए, मुझे यहां-स्ट्रिंग्स का उपयोग करने के बारे में एक तरीका नहीं लगता है:

# PowerShell - WISHFUL THINKING
# Passes the string to `sh -c` / `cmd /c` for execution, as appropriate.
# Short alias: ins
PS> Invoke-NativeShell @'
printf '"%s"\n' "3\" of snow"
'@
"3" of snow"  # output

बेशक, यदि आप प्लेटफ़ॉर्म-देशी शेल के फीचर्स पर भरोसा कर रहे हैं, तो इस तरह की कॉलें प्लैटफॉर्म [-family] -specific होंगी - वे _both_ विंडोज और यूनिक्स-जैसे प्लेटफॉर्म पर काम नहीं करेंगी।

यही कारण है कि PowerShell _alone_ पर भरोसा करना, इसके _own सिंटैक्स_ के साथ लंबे समय में बेहतर है : यह बाहरी कार्यक्रमों को कॉल करने के लिए एक पूर्वानुमानित क्रॉस-प्लेटफॉर्म अनुभव प्रदान करता है - भले ही इसका मतलब है कि आप अन्य गोले के रूप में तैयार की गई कमांड लाइनों का उपयोग नहीं कर सकते हैं- है; लोकप्रियता में पावरशेल के लाभ के रूप में, मुझे उम्मीद है कि कम संशोधनों की खोज करने और जानने की पीड़ा कम होगी, और मैं अधिक से अधिक प्रलेखन को कमांड लाइनों (भी) के पावरशेल संस्करणों को दिखाने की अपेक्षा करता हूं।

• आपको \" को `" साथ बदलने की आवश्यकता है, लेकिन _ "..." _ के अंदर।

यह हर जगह काम नहीं करता है।

# working everywhere but polluted with \
❯ node -e 'console.log(\"hey\")'
hey

# working in Node:
❯ node -e 'console.log(`"hey`")'
hey

# not working in Julia:
❯ julia -e 'print(`"hey`")'
`hey`

# not working anywhere:
❯ node -e "console.log(`"hey`")"
❯ node -e "console.log("hey")"
❯ node -e "console.log(""hey"")"
❯ node -e 'console.log(""hey"")'

बैश वाक्य रचना:

❯ node -e 'console.log("hey")'
hey

शक्तियों का सुझाव:

यदि PowerShell टीम सिर्फ एक प्रतीक की तलाश कर रही है, जो पिछले सिंटैक्स को नहीं तोड़ती है, तो बस एक बैश के लिए कुछ भी इस्तेमाल नहीं किया जाता है `व्यवहार की तरह बैश के लिए, जो स्वचालित रूप से शाब्दिक रूप से बच जाता है, और स्ट्रिंग प्रक्षेप की अनुमति देता है। यह जावास्क्रिप्ट के सिंटैक्स के समान है।

❯ node -e `console.log("hey")`
hey

❯ $a=hey 
❯ node -e `console.log($hey)`
hey

व्यवहार के लिए बैश के लिए बैकटिक्स की तरह कुछ का उपयोग क्यों न करें

बैकटिक्स का उपयोग पहले से ही सामान से बचने के लिए किया जाता है, पोसिक्स शेल में बैकस्लैस के समान उद्देश्य। आप जिस टिप्पणी का जिक्र कर रहे हैं वह पहले से ही इंगित करती है। हमने ASCII के सभी सामानों का उपयोग किया है। सामान्य स्ट्रिंग शाब्दिक में $ उपसर्ग जोड़ना काम कर सकता है, लेकिन मुझे नहीं लगता कि यह पर्याप्त समझ में आता है।

जिस तरह से विंडोज कमांड लाइन तर्क तर्कों को पाया जा सकता है ...

समस्या यह है कि विंडोज MSVCR ऐसा नहीं करता है: यह अनिर्दिष्ट तरीकों से कोने के मामलों है । "" सामान इतना ठोस रूप से सेट किया गया है कि उन्होंने इसे .NET को Unix में पोर्ट करने पर CoreFX में भी डाल दिया। लेकिन वैसे भी, यह हमेशा भागने के लिए पर्याप्त है, कम से कम जब तक कोई ग्लोबिंग के लिए नहीं कहता।

वहाँ भी हर किसी की क्लासिक समस्या इसे अलग तरह से कर रही है, लेकिन हमें इसके बारे में चिंता करने की ज़रूरत नहीं है क्योंकि हमारे पास हमेशा कच्ची cmdline के लिए .NET है।

व्यवहार के लिए बैश के लिए बैकटिक्स की तरह कुछ का उपयोग क्यों न करें

बैकटिक्स का उपयोग पहले से ही सामान से बचने के लिए किया जाता है, पोसिक्स शेल में बैकस्लैस के समान उद्देश्य। हमने ASCII के सभी सामानों का उपयोग किया है।

यदि पार्सर यह पता लगाने में सक्षम नहीं है कि प्रतीकों का एक संयोजन का उपयोग करने की संभावना है तो यहां `एक स्ट्रिंग शुरू कर रहा है। '' जैसा कुछ भी काम कर सकता है।

@ स्वामी यहां एक समाधान है कि आप पुरानी खिड़कियों का उपयोग नहीं कर रहे हैं Powershell 5.1 और 6+ पर:
https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -56/34346

जैसा कि मुझे विंडोज़ पर पॉवरशेल ५,१ और लिनक्स / मैक पर ६+ से निपटना है, मेरा अपना कार्यान्वयन है जो वर्षों से बिना मुद्दों के काम कर रहा है जो कि कुब्तेल, हेल्म, टेराफॉर्म और अन्य उपकरण जैसे JSON के साथ काम करने की अनुमति देता है मापदंडों के भीतर वस्तुएं:
https://github.com/choovick/ps-invoke-externalcommand

GitHub

choovick / PS-आह्वान-externalcommand

GitHub पर एक खाता बनाकर choovick / ps-invoke-externalcommand विकास में योगदान करें।

@choovick कुछ छोटे कार्यान्वयन इस धागे में ऊपर दिए गए थे, मैं अभी भी एक ऐसा मामला ढूंढ रहा हूं जहां यह मेरे लिए विफल होगा। यह PS में v3 से शुरू होकर काम करता है।

@AndrewSav @TSlivede के Run-Native समारोह बहुत चालाक और संक्षिप्त, और भाँति भी _Windows PowerShell_ में मज़बूती से काम करता है; कुछ बातें ध्यान देने योग्य हैं: आवश्यकता के कारण, बच्चे की प्रक्रिया ऑक्स को देखती है। commandlineargumentstring पर्यावरण चर (शायद ही कभी, अगर कभी, व्यवहार में एक समस्या), तर्क-कम इनवोकेशन वर्तमान में सही तरीके से नियंत्रित नहीं किए जाते हैं (आसानी से तय किया गया और एक समस्या भी नहीं है, यदि आप यह सुनिश्चित करते हैं कि आप केवल फ़ंक्शन का उपयोग करते हैं _with_ तर्कों, जो यह है के लिए है), _all_ तर्कों को दोहरे-उद्धृत (जैसे, 42 कुछ "42" ) के रूप में पारित किया जाता है, जो विंडोज पर (दुर्भाग्य से) के दुष्प्रभाव हो सकते हैं ऐसे प्रोग्राम जो डबल-कोटेड (या आंशिक रूप से डबल-कोटेड) की व्याख्या करते हैं, जैसे msiexec केस में) अलग-अलग तर्क देते हैं।

@aminya , एकमात्र कारण है कि node -e 'console.log(`"hey`")' (प्रकार) का कार्य वर्तमान, टूटे हुए व्यवहार (नीचे देखें) के कारण होता है। मुझे लगता है कि आप जो पास करना चाहते थे, वह था _verbatim_ console.log("hey") , जो कि, अगर Windows पर PowerShell ने यहां प्रस्तावित चीजों को सही ढंग से बचा लिया, तो आप एकल उद्धरणों में पास होंगे: node -e 'console.log("hey")' । यह _automatically_ को node -e "console.log(\"hey\")" (डबल-कोटिंग, \ -प्रकाशित शब्दशः " ) के दृश्यों के पीछे होना चाहिए।

यह देखते हुए कि यह धागा कब तक बन गया है, मुझे पुनः प्रयास करने दें:
आपको केवल कभी भी _PowerShell_ के सिंटैक्स आवश्यकताओं के बारे में चिंता करनी चाहिए, और यह सुनिश्चित करने के लिए कि PowerShell का तर्क मान_ है कि पॉवरसेहेल के स्वयं के पार्सिंग से परिणाम बाह्य प्रोग्राम _as-is_ तक पहुंच गया है, यह सुनिश्चित करने के लिए PowerShell का कार्य _as है।

• यूनिक्स जैसे प्लेटफ़ॉर्म पर, अब हमारे पास इसके लिए .NET कोर सपोर्ट है, ऐसा करना तुच्छ है, क्योंकि वर्बिटिम वैल्यूज़ को केवल उतने ही पास किया जा सकता है-उतने ही तर्क के तत्व के तत्व के रूप में है, जो है कि कैसे प्रोग्राम मूल निवासी को तर्क प्राप्त होता है ।
• विंडोज पर, बाहरी कार्यक्रमों को एक _single कमांड-लाइन string_ (एक अफसोसजनक ऐतिहासिक डिजाइन निर्णय) के रूप में तर्क प्राप्त होते हैं और उन्हें अपना कमांड-लाइन पार्सिंग करना चाहिए। एक ही स्ट्रिंग के हिस्से के रूप में कई तर्कों को पारित करना, ठीक से तर्क देने के लिए नियमों को उद्धृत करना और पार्स करना आवश्यक है; हालांकि यह अंततः एक फ्री-फॉर-ऑल है (प्रोग्राम उन जैसे पार्स करने के लिए स्वतंत्र हैं), सबसे व्यापक रूप से इस्तेमाल किया गया सिंटैक्स कन्वेंशन (जैसा कि पहले कहा गया था और दुर्भाग्य से अब आरएफसी को भी छोड़ दिया गया है ) में प्रस्तावित है, जिसे माइक्रोसॉफ्ट के सी / सी + + + कंप्लायंस लागू करते हैं । इसलिए यह उस के साथ जाने के लिए समझ में आता है।
  
  
  
  • _Update_: यहां तक कि विंडोज पर हम संग्रह के- शब्दशः-टोकन का लाभ ले सकते ArgumentList की संपत्ति System.Diagnostics.ProcessStartInfo नेट कोर में: विंडोज पर यह स्वचालित रूप से एक ठीक से उद्धृत और भाग निकले आदेश को अनुवाद किया है -लाइन स्ट्रिंग जब प्रक्रिया शुरू की जाती है; हालाँकि, _batch files_ के लिए हमें अभी भी विशेष हैंडलिंग की आवश्यकता हो सकती है - https://github.com/PowerShell/PowerShell-RFC/pull/90#issuecomment -552231174 देखें
  
  

उपरोक्त को लागू करना निस्संदेह एक बड़े पैमाने पर ब्रेकिंग परिवर्तन है, इसलिए इसे संभवतः एक ऑप्ट-इन की आवश्यकता होती है।
मुझे लगता है कि इसके साथ आगे बढ़ना एक जरूरी है, अगर हम सभी मौजूदा कोट्सिंग सिरदर्द से छुटकारा पाना चाहते हैं, जो कि आते रहते हैं और पावरस्ले को अपनाने में बाधा आती है, खासकर यूनिक्स दुनिया में।

के रूप में के लिए node -e 'console.log(`"hey`")' : अंदर '...' , का उपयोग नहीं करते ` - जब तक आप चाहते हैं कि चरित्र के रूप में-है के माध्यम से पारित किया जाना है। क्योंकि PowerShell वर्तमान में _does't_ verbatim " char से बचता है। के रूप में अपने तर्क में \" पर्दे के पीछे, क्या node कमांड लाइन पर देखता है console.log(`"hey`") है, जो दो सीधे आसन्न स्ट्रिंग शाब्दिक रूप में पार्स किया जाता है: गैर उद्धृत console.log(` और डबल-उद्धृत "hey`" । " छीनने के बाद, जिसके पास _syntactic_ फ़ंक्शन \ -प्रकाशित नहीं होने के कारण, जावास्क्रिप्ट कोड निष्पादित हो रहा है, अंततः console.log(`hey`) , और वह केवल इसलिए काम करता है क्योंकि `....` संलग्न टोकन जावास्क्रिप्ट में स्ट्रिंग शाब्दिक का एक रूप है, जिसका अर्थ है _template शाब्दिक_।

@AndrewSav मैंने अपनी पागल परीक्षण वस्तु के साथ परीक्षण किया है और इसने मेरे लिए काम किया है! बहुत सुंदर समाधान, लिनक्स पर विंडोज 5.1 और पीएस 7 पर परीक्षण किया गया। मैं सब कुछ डबल उद्धृत करने के साथ ठीक हूं, मैं msiexec या sqlcmd के साथ सौदा नहीं करता " स्पष्ट रूप से व्यवहार करने के लिए जाना जाता है।

मेरे व्यक्तिगत कार्यान्वयन में आपके द्वारा उल्लेखित के समान सरल एस्केप लॉजिक भी है: https://github.com/choovick/ps-invoke-externalcommand/blob/master/ExternalCommand/ExternalCommand.psm1##278

लेकिन मैंने उस मॉड्यूल के भीतर STDOUT और STDERR थ्रेड्स को वास्तविक समय में प्रदर्शित करने और कैप्चर करने के लिए कोड का गुच्छा लिखा है ... यह शायद बहुत सरल किया जा सकता है, लेकिन मुझे इसकी कोई आवश्यकता नहीं थी ...

@ mklement0 यह धागा कभी खत्म नहीं होगा (: हमें या तो ps गैलरी में प्रकाशित PowerShell मॉड्यूल प्रदान करने की आवश्यकता है जो ज्यादातर उपयोग के मामलों को सूट करेगा और आगामी शेल सुधारों के लिए उपयोग करने या प्रतीक्षा करने के लिए पर्याप्त सरल होगा।

GitHub

choovick / PS-आह्वान-externalcommand

GitHub पर एक खाता बनाकर choovick / ps-invoke-externalcommand विकास में योगदान करें।

@ mklement0 यह धागा कभी खत्म नहीं होगा (: हमें या तो ps गैलरी में प्रकाशित PowerShell मॉड्यूल प्रदान करने की आवश्यकता है जो ज्यादातर उपयोग के मामलों को सूट करेगा और आगामी शेल सुधारों के लिए उपयोग करने या प्रतीक्षा करने के लिए पर्याप्त सरल होगा।

यदि PowerShell टीम इस कार्यक्रम में खुद को ठीक नहीं करने का निर्णय लेती है, तो मैं कहूंगा कि एक शेल जो बाहरी कार्यक्रमों को मूल रूप से नहीं चला सकता है और सही ढंग से मेरी पसंद का शेल नहीं होगा! ये मूल सामान हैं जो पावरशेल से गायब हैं।

@ यामिया जी , मैंने पाया कि यह मुद्दा खुद को बहुत परेशान कर रहा है जब मुझे इसे स्थानांतरित करना पड़ा। लेकिन नीचे की तरह सुविधाओं ने इसे इसके लायक बना दिया।

• लचीले मापदंडों की रूपरेखा, विश्वसनीय CMDlets का निर्माण करना आसान है।
• मॉड्यूल और आंतरिक मॉड्यूल रिपॉजिटरी संगठन में आम तर्क साझा करने के लिए, कोड के दोहराव और कोर कार्यक्षमता के केंद्रीकरण से बचने के लिए जो एक ही बार में फिर से बनाए जा सकते हैं।
• क्रॉस प्लेटफॉर्म। मेरे पास पीएस 5.1 में विंडोज पर अपने उपकरण चलाने वाले लोग हैं, और पीएस 6/7 में लिनक्स / मैक पर

मैं वास्तव में आशा करता हूं कि पीएस टीम भविष्य में इसे कम जटिल बनाने के लिए इसमें सुधार करेगी।

उपरोक्त को लागू करना निस्संदेह एक बड़े पैमाने पर ब्रेकिंग परिवर्तन है, इसलिए इसे संभवतः एक ऑप्ट-इन की आवश्यकता होती है।

क्या आपका मतलब है https://github.com/PowerShell/PowerShell-RFC/pull/90 लागू करना

@ स्वामी , मैं मानता हूं कि तर्कों के साथ बाहरी कार्यक्रमों को बुलाना एक खोल का मुख्य जनादेश है और इसे ठीक से काम करना चाहिए।

@Choovick द्वारा सुझाया गया एक मॉड्यूल, अभी भी _Windows PowerShell_ के लिए समझ में आता है, जो सुरक्षा-महत्वपूर्ण-फिक्स-ओनली मेंटेनेंस मोड में है।
पूरक रूप से, अगर / जब बाहरी कार्यक्रमों को कॉल करने के बारे में प्रस्तावित वैचारिक सहायता विषय लिखा जाता है - https://github.com/MicrosoftDocs/PowerShell-Docs/issues/5152 देखें - एक सहायक फ़ंक्शन जो पहले के संस्करणों में समस्याओं को ठीक करता है / Windows PowerShell's ऊपर @TSlivede जैसे कि सीधे वहां पोस्ट किया जा सकता है।

@iSazonov हाँ, https://github.com/PowerShell/PowerShell-RFC/pull/90 को लागू करने का मेरा मतलब है।

जैसे कि धागा कभी खत्म नहीं होता और टूटती-बदलती चिंताएं:

लिंक किए गए RFC की अंतिम आधिकारिक प्रतिक्रिया @joeyaiello द्वारा 8 जुलाई 2019 (

लेकिन हमें लगता है कि यह [RFC] मौजूदा व्यवहार के बावजूद और इसके टूटने के संबंध के बिना समझ में आता है। अब जब हमारे पास प्रायोगिक विशेषताएं हैं, तो हमें लगता है कि प्रायोगिक सुविधा ध्वज के पीछे आज इसे लागू करना और इसे लागू करना पूरी तरह से उचित है, और हम रेखा के नीचे यह पता लगा सकते हैं कि क्या यह ऑप्ट-इन बनाम ऑप्ट-आउट व्यवहार है , क्या कुछ संक्रमण है पथ, और यदि एक वरीयता चर इसे चालू और बंद करने के लिए सही तंत्र है।

_Personally_, मैं व्यवहार को ठीक करने में बुरा नहीं मानूंगा। भले ही यह एक परिवर्तन है; RFC वास्तव में प्रस्ताव करता है और यदि आप _old_ (टूटा हुआ) व्यवहार चाहते हैं तो एक ऑप्ट-इन सुझाता है।

मुझे संदेह है कि बनाए रखने के लिए विरासत कोड के साथ उन लोगों को आपत्ति होगी, हालांकि, जैसा कि सभी मौजूदा वर्कअराउंड कार्य करने के लिए संघर्ष करेंगे_ - ऊपर देखें - और पिछड़े संगतता को बनाए रखना अभी भी लक्ष्य बनाना लगता है।

यदि नया, निश्चित व्यवहार ऑप्ट-इन किया गया है, तो आपके पास अभी भी सही व्यवहार प्राप्त करने के लिए कुछ करने की अजीबता है, लेकिन कम से कम मौजूदा कोड नहीं टूटेगा।

लेकिन मौजूदा ऑप्ट-इन तंत्र स्वयं समस्याग्रस्त हैं:
अब जब @KirkMunro की वैकल्पिक विशेषताओं को RFC खारिज कर दिया गया है, तो वह बहुत अधिक एक _preference variable_ को छोड़ देता है, और वहां चुनौती है PowerShell का डायनामिक स्कोपिंग: थर्ड-पार्टी कोड को उस स्कोप से बुलाया जाता है, जिसे ऑप्ट-इन किया गया था जिसे नए का उपयोग करने के लिए डिज़ाइन नहीं किया गया था कार्यान्वयन तब टूट सकता है (जब तक कि वरीयता चर अस्थायी रूप से रीसेट न हो जाए)।

यहाँ ऑप्ट-इन के _Lexical_ स्कोपिंग की आवश्यकता है, जो वर्तमान में हमारे पास नहीं है। कठोर मोड के _lexical_ स्कोपिंग के लिए RFC एक using कथन (जो, विशेष रूप से, आमतौर पर _dynamically_ sceded) के माध्यम से एक शाब्दिक रूप से स्कोप्ड सुविधा (या एक अलग उद्देश्य) के कार्यान्वयन का प्रस्ताव करता है। इस पैटर्न के बाद, एक शाब्दिक रूप से using ProperExternalArgumentQuoting कथन (नाम एक WIP :) है - यदि तकनीकी रूप से व्यवहार्य है - विचार करने योग्य है।

हमें (फिर से) तौलना और आगे बढ़ने के तरीके के रूप में स्पष्ट मार्गदर्शन प्रदान करने की आवश्यकता है, क्योंकि वे उठते ही प्रश्नों पर प्रतिक्रिया दें। @ SteveL-MSFT?

ध्यान दें कि --% 7.1 ऊपर देखें) द्वारा संकेत दिया गया है (जो मुझे लगता है कि व्यक्तिगत रूप से पीछा करने लायक नहीं है - ऊपर और इस टिप्पणी को देखें ), एक _separate_ सुविधा होगी - पॉवरहेल का मूल फिक्सिंग (गैर-अनुकरण) व्यवहार अभी भी जरूरी है।

व्यक्तिगत रूप से, मैं डिफ़ॉल्ट रूप से व्यवहार को ठीक करने में बुरा नहीं मानूंगा, भले ही यह एक परिवर्तन है; RFC वास्तव में यह प्रस्तावित करता है और यदि आप पुराने (टूटे हुए) व्यवहार चाहते हैं तो एक ऑप्ट-इन सुझाता है।

यदि नया, निश्चित व्यवहार ऑप्ट-इन किया गया है, तो आपके पास अभी भी सही व्यवहार प्राप्त करने के लिए कुछ करने की अजीबता है, लेकिन कम से कम मौजूदा कोड नहीं टूटेगा।

सहमत, वास्तव में मैं यह तर्क दूंगा कि एक टूटी हुई डिफ़ॉल्ट होने के लिए कम समझ है, फिर एक सही ढंग से लागू डिफ़ॉल्ट। इस तथ्य को देखते हुए कि वर्तमान कार्यान्वयन वास्तव में बग है , नया व्यवहार ऑप्ट-इन होना चाहिए, ऑप्ट-आउट नहीं होना चाहिए, क्योंकि यह वास्तव में टूटी हुई बाहरी शेल कॉल को प्रोत्साहित करने के लिए जारी रखने के लिए समझ में नहीं आता है जो अप्रत्याशित रूप से टूटने का खतरा है तरीके। किसी भी स्थिति में, PowerShell 7 को विरासत Windows PowerShell पर सुधार करने का प्रयास करना चाहिए।

@ स्टीवएल-एमएसएफटी और मैं सहमत था कि हमें इसे # 13068 के पक्ष में बंद करना चाहिए। हम यहां जो कुछ भी छूते हैं वह सिर्फ एक ब्रेकिंग परिवर्तन का बहुत अधिक है, और हमें एक नए ऑपरेटर के साथ समस्या का समाधान करना चाहिए जो ऑप्ट-इन मोड के रूप में कार्य करता है।

मैं पूरी तरह से यह नहीं देखता कि # 13068 इसे कैसे हल करेगा: यदि उस ऑपरेटर को इस उद्देश्य के रूप में पेश किया जाता है कि हमारे पास अभी भी किसी भी मूल निष्पादन योग्य को दिए गए तर्कों के साथ या कुछ स्पष्ट तर्कों के साथ ठीक से कॉल करने का कोई तरीका नहीं है जिसकी सामग्री चर से उत्पन्न होती है।

उदाहरण, @JustinGrote ने उस थ्रेड में दिया वर्तमान में मज़बूती से काम नहीं करता है (यदि तर्क पेलोड में एम्बेडेड उद्धरण संभव है) और उस ऑपरेटर को जोड़ने से कोई भी विकल्प नहीं मिलेगा जो कुछ भी सुधार करता है।

@joeyaiello क्या आप कम से कम इस मुद्दे को तब तक खुला छोड़ सकते हैं जब तक कि ऑपरेटर वास्तव में मौजूद न हो और कोई यह दिखा सके कि उस ऑपरेटर को कुछ भी कैसे सुधार होगा, इस धागे में उल्लेख किया गया था?

ओह और लिनक्स के बारे में भी क्या? यह समस्या विंडोज पर बेवकूफी और अप्रत्याशित है, लेकिन लिनक्स पर यह बहुत कम समझ में आता है, विशेष रूप से जैसे कि लिनक्स पॉवरशेल स्क्रिप्ट का कोई इतिहास नहीं है, जो टूट जाएगा।

इसके लिए एक विशेष ऑपरेटर बनाना एक कमांड-लाइन शेल के लिए बिल्कुल भी मायने नहीं रखता है, क्योंकि इसका मुख्य काम प्रोग्राम लॉन्च करना और उन्हें तर्क देना है। इस काम के लिए system() काम करने वाले नए ऑपरेटर का परिचय देना Matlab की तरह calc.exe को कॉल करने का तरीका पेश करना है क्योंकि इसकी अंकगणित में एक बग है। इसके बजाय क्या किया जाना चाहिए:

• Pwsh टीम एक नए प्रमुख रिलीज के लिए तैयार करती है जो कमांड-लाइन सामान को ठीक करती है, एक अंतर्निहित cmdlet के पीछे वर्तमान व्यवहार को आगे बढ़ाती है।
• स्टॉप-गैप समाधान के रूप में, आगामी pwsh संस्करण में एक अंतर्निहित cmdlet मिलता है जो कमांड-लाइन पासिंग के लिए नए, सही व्यवहार का उपयोग करता है।

वही Start-Process पर लागू होता है। (वास्तव में यह -QuotingBehavior Legacy ... जैसे कुछ विकल्पों के साथ "नए" cmdlet के लिए एक बहुत अच्छा उम्मीदवार है।) # 13089 देखें।

पॉवरशेल इन दो स्थितियों में अलग-अलग व्यवहार क्यों कर रही है? विशेष रूप से, यह असंगत रूप से डबल-कोट्स में रिक्त स्थान वाले आर्ग्स को लपेटता है।

मुझे v.7 में लगातार परिणाम मिलते हैं। तय लग रहा है।

PING 'A \"B'

पिंग अनुरोध मेजबान ए "बी नहीं मिला।

PING 'A\" B'

पिंग अनुरोध मेजबान ए "बी नहीं मिला।

यह निश्चित नहीं है, क्योंकि शब्दशः होस्ट करता है कि ping को देखना चाहिए A \"B और A\" B - _with_ \ वर्ण।

PowerShell, एक शेल के रूप में, _its_ नियमों के अनुसार तर्कों को पार्स करना चाहिए - केवल - और फिर पारदर्शी रूप से सुनिश्चित करें कि लक्ष्य प्रक्रिया वही वर्बिटिम मान देखती है जो पावरशेल के अपने पार्सिंग का परिणाम थे।

वह _other_ गोले - और विंडोज पर चलने वाले वे घटिया प्रोग्राम जो उनके खुद के खोल की तरह काम करते हैं, बोलने के तरीके में, _command line_ को पार्स करने के लिए बस पास की गई व्यक्तिगत दलीलें निकालने के लिए - \ उपयोग करें। चरित्र को यहां चित्र में प्रवेश नहीं करना चाहिए - यह समायोजित करना (केवल विंडोज पर आवश्यक है, यूनिक्स पर आप सीधे एक सरणी के रूप में शब्दशः तर्क पास करते हैं) एक शेल के रूप में पॉवरशेल का काम है, दृश्यों के पीछे _।

एक तरफ के रूप में, पॉवरशेल की तरह ही " _inside '...' _ (एकल-उद्धृत स्ट्रिंग्स) से बचने की आवश्यकता नहीं है, न ही POSIX- संगत गोले जैसे bash : bash से निष्पादित, उदाहरण के लिए, /bin/echo 'A \"B' (समझदारी से) A \"B ( \ को एकल-उद्धृत स्ट्रिंग्स में शाब्दिक के रूप में माना जाता है) - जो निष्पादित कर रहा है PowerShell (अप्रत्याशित रूप से) पैदावार से बहुत ही कमांड
A "B - \ गायब है - यहाँ पर चर्चा की गई समस्याओं का प्रकटीकरण है।

मुझे स्पष्ट करना चाहिए:

• अंततः A "B _verbatim_ पास करने के इच्छुक के दृष्टिकोण से, आपको PowerShell से 'A "B' का उपयोग करने में सक्षम होना चाहिए।

• कमांड लाइन जो पावरस्ले वर्तमान में पर्दे के पीछे का निर्माण करती है, में "A "B" - जिसे लक्ष्य प्रक्रिया A B रूप में देखती है - अर्थात, " _ "..." में अंधा संलग्नक, _embedded_ " बचने के बिना। " का प्रभावी नुकसान हुआ। PowerShell _should_ इस मामले में पीछे के कमांड लाइन में "A \"B" - यानी, एम्बेडेड " \ -सुरक्षा।

• इसी प्रकार, एक ही अंधे बाड़े के पीछे 'A \"B' "A \"B" का बैक-द-सीन कमांड लाइन पर प्रतिनिधित्व किया जाता है, जो कि ऐसा होता है कि _embedded_ \" को _escaped_ में बदल जाता है। " चरित्र, जो लक्ष्य प्रक्रिया इसलिए A "B रूप में देखती है; यही है, _automatic_ बचने की कमी के परिणामस्वरूप एम्बेडेड \ का प्रभावी नुकसान हुआ। PowerShell _should_ इस मामले में पीछे के कमांड लाइन में "A \\\"B" - अर्थात \ और " भागने की आवश्यकता है।

यह निश्चित नहीं है, क्योंकि शब्दशः होस्ट करता है कि ping को देखना चाहिए A \"B और A\" B - _with_ \ वर्ण।

"यह" यहां उद्धृत शिकायत को संदर्भित करता है, जिसे मैं सौभाग्य से पुन: पेश नहीं कर सकता।

@ yecril71pl , मैं देखता हूं: मेरी (गलत) धारणा यह थी कि "असंगत रूप से डबल-कोट्स में रिक्त स्थान रखने वाले आर्गन" से तात्पर्य एम्बेडेड " और \ अक्षर_ से बचने से है। मेरी पिछली टिप्पणी में समझाया गया है - और यह इस मुद्दे की जड़ है।

PowerShell Core में मामूली सुधार हुए हैं जो Windows PowerShell के पास नहीं है; मैं अभी केवल एक के बारे में सोच सकता हूं:

• Windows PowerShell \ : 'A B\' बदल जाता है (टूटा हुआ) "A B\" - PS Core के मामले में अंधा डबल-कोटिंग का उपयोग करता है जो सही ढंग से ( "A B\\" ) संभालता है ।

यह देखते हुए कि यह रेपो केवल पीएस कोर के लिए है, यह ध्यान देने के लिए पर्याप्त है कि पीएस कोर में अभी भी क्या टूटा हुआ है (यह मतभेदों का उल्लेख करने में सहायक हो सकता है _ एक तरफ _ लेकिन यह उस पहलू को स्पष्ट करने के लिए सबसे अच्छा है)।

और यहां तक ​​कि परिदृश्य जो आपको ध्यान में था _is_ अभी भी PS कोर में टूट गया है - लेकिन केवल _if आप तर्क से \ को छोड़ देते हैं:

पास होने पर 'A" B' परिणाम _non_-double-quoted A" B दृश्यों के पीछे है (जबकि 'A\" B' परिणाम "A\" B" - जो भी टूट गया है, जैसा कि चर्चा में है) - केवल अलग ढंग से)।

यह देखते हुए कि यह रेपो केवल पीएस कोर के लिए है, यह ध्यान देने के लिए पर्याप्त है कि पीएस कोर में अभी भी क्या टूटा हुआ है (यह मतभेदों का उल्लेख करने में सहायक हो सकता है _ एक तरफ _ लेकिन यह उस पहलू को स्पष्ट करने के लिए सबसे अच्छा है)।

मेटा एक तरफ: मुझे यह जानना उपयोगी है कि किसी अन्य उपयोगकर्ता की टिप्पणी में उल्लिखित गलत व्यवहार लागू नहीं होता है। बेशक, हम टिप्पणी को केवल इसलिए खारिज कर सकते थे क्योंकि उपयोगकर्ता वर्तमान संस्करण की जांच करने के लिए परेशान नहीं था। कुंआ। अनियंत्रित पत्रकारों को अनियंत्रित किया जा रहा है, यह सुनिश्चित होना अभी भी बेहतर है। IMHO।

कोई तर्क नहीं है, लेकिन ऐसे _asides_ को _प्रोपर फ्रेमिंग और संदर्भ_ प्रदान करना महत्वपूर्ण है, विशेष रूप से एक looooong थ्रेड में जहां मूल टिप्पणी - संदर्भ के लिए आवश्यक - एक लंबे समय पहले पोस्ट की गई थी और वास्तव में, अब _hidden या डिफ़ॉल्ट रूप से (यह कभी दर्द नहीं होता वास्तव में _link_ को मूल टिप्पणी में उद्धृत किया जा रहा है)।

मुझे आश्चर्य है कि अगर इन चर्चाओं से फर्क पड़ता है। स्पष्ट रूप से समिति के निर्णय स्वतंत्र हैं कि समुदाय क्या चाहता है। टैग देखें: Resolution- won't fix. लेकिन चूंकि PowerShell खुला स्रोत (MIT) है, समुदाय इसे एक अलग कांटे में ठीक कर सकता है, और इस PowerShellCommunity ( pwshc ) को संक्षेप में कह सकता है।

यह पिछड़ी अनुकूलता की आवश्यकता को दूर करता है। बाद में PowerShell 8 में, समिति कांटा एकीकृत कर सकती है।

पश्चगामी संगतता के बारे में: PowerShell किसी भी ऑपरेटिंग सिस्टम पर प्रीइंस्टॉल्ड नहीं आती है, और मेरे लिए, PowerShellCommunity स्थापित करने की कठिनाई PowerShell । मैं कुछ भविष्य के 8 संस्करण की प्रतीक्षा करने (या नए ऑपरेटर के साथ कोड को और अधिक जटिल बनाने) के बजाय सामुदायिक संस्करण को स्थापित करना और इसे तुरंत उपयोग करना पसंद करता हूं।

चूंकि समिति ने चीजों को तोड़ने का फैसला किया है, इसलिए यह जानना बेहतर है कि वे कितनी बुरी तरह से टूट गए हैं। मुझे लगता है कि समुदाय Invoke-Native साथ रह सकता है जो सही काम करता है। उनकी इच्छा के विरुद्ध Microsoft के चेहरे को बचाना समुदाय का काम नहीं है।

यह जानना बेहतर है कि वे कितनी बुरी तरह से टूट गए हैं

मैं पूरी तरह से सहमत हूं - भले ही समस्या को समय पर मदद नहीं किया जा सकता है, यह जानना कि चीजें सही कैसे करना है _ सिद्धांत, यदि और जब समय आता है_ महत्वपूर्ण है - भले ही उस समय _never_ किसी दिए गए भाषा के संदर्भ में आता हो।

समुदाय Invoke-Native साथ रह सकता है जो सही काम करता है

स्पष्ट होना:

• Invoke-NativeShell तरह कुछ एक _different यूज़ केस_ को संबोधित करता है - जो कि # 13068 का विषय है - और उस केस के लिए इस तरह का cmdlet _not_ एक स्टॉपगैप है: यह उचित समाधान है - देखें https://ithithub.com/ PowerShell / PowerShell / समस्याएं / 13068 # जारी करना -656781439

• _This_ मुद्दा _PowerShell स्वयं को ठीक करने के बारे में है_ (यह प्लेटफ़ॉर्म-_native_ कार्यक्षमता के बारे में नहीं है), और _stopgap_ इसका समाधान कम-समारोह-प्रदान करना है _opt-in_ - इसलिए फ़ंक्शन iep को जहाज के रूप में निर्मित

Microsoft के चेहरे को बचाना समुदाय का काम नहीं है

मुझे नहीं लगता कि @aminya की चिंता किसी के चेहरे को बचाने के बारे में है - यह एक ऐसे क्षेत्र में मौलिक रूप से टूटे हुए व्यवहार को ठीक करने के बारे में है जो एक शेल का मूल जनादेश है।

उस ने कहा, मुझे यकीन नहीं है कि एक फोर्क के साथ पावरशेल इकोसिस्टम को टुकड़े करना सही तरीका है।

मेरे पास इस समय केवल इस पर प्रतिक्रिया देने का समय नहीं है, लेकिन मुझे लगता है कि यह उचित है, इसलिए मैं फिर से खोल रहा हूं:

क्या आप कम से कम इस मुद्दे को तब तक खुला छोड़ सकते हैं जब तक कि ऑपरेटर वास्तव में मौजूद न हो और कोई व्यक्ति यह दिखा सके कि उस ऑपरेटर को कुछ भी कैसे सुधार होगा, इस धागे में उल्लेख किया गया था?

जैसा कि मैंने संबंधित मुद्दे में कहा है, देशी कॉल ऑपरेटर UX में जटिलता जोड़ता
इसी समय, यहां पूरी चर्चा देशी अनुप्रयोगों के साथ बातचीत को सरल बनाने के बारे में है।

केवल एक चीज जो हमें रोकती है वह यह है कि यह एक परिवर्तन है। हमने कई बार कहा है कि यह बहुत विनाश है, लेकिन चलो इसे तौलना।

आइए एक इंटरैक्टिव सत्र देखें। एक उपयोगकर्ता नए PowerShell संस्करण को स्थापित करेगा और मूल अनुप्रयोगों को लागू करते समय नए व्यवहार की खोज करेगा। वह क्या कहेगा? मैं अनुमान लगाऊंगा कि वह कहेगा - "धन्यवाद - अंत में मैं बस टाइप कर सकता हूं और यह काम करता है!"।

आइए स्क्रिप्ट निष्पादन / होस्टिंग परिदृश्य देखें। किसी व्यवसाय प्रक्रिया को तोड़ सकते हैं (किसी एक मामूली परिवर्तन के साथ भी) किसी भी अनुप्रयोग का नया संस्करण हम हमेशा यह उम्मीद करते हैं और किसी भी अपडेट के बाद हमारी प्रक्रियाओं की जांच करते हैं। यदि हमें कोई समस्या मिलती है, तो हमारे पास कई तरीके हैं:

• अद्यतन रोलबैक करें
• स्क्रिप्ट के लिए फास्ट फिक्स तैयार करें
• एक ऐसी सुविधा को बंद करें जो हमारी स्क्रिप्ट को तब तक तोड़ती है जब तक कि ये चीजें तय नहीं हो जाती हैं या वे स्वयं समय के साथ मर जाते हैं।

_Since संस्करण अद्यतन हमेशा कुछ तोड़ते हैं, अंतिम विकल्प सबसे अच्छा है जो हम कर सकते हैं और स्वीकार करते हैं ।_

(मैं इंगित करना चाहता हूं कि अभी PowerShell Core विंडोज का एक घटक नहीं है और इसलिए सीधे होस्टिंग अनुप्रयोगों को खराब नहीं कर सकता है, केवल स्क्रिप्ट सीधे प्रभावित होती हैं।)

मैं आपको याद दिलाना चाहता हूं कि जेसन ने ऊपर क्या कहा था - यह एक बग फिक्स है।
आइए हम इसे ठीक करें और सभी के लिए सब कुछ सरल करें। उपयोगकर्ताओं को powershell-y काम करने दें।

जैसा कि मैंने संबंधित मुद्दे में कहा है, देशी कॉल ऑपरेटर UX में जटिलता जोड़ता है और यह गलत दिशा है।

जटिलता ❓

आइए एक इंटरैक्टिव सत्र देखें। एक उपयोगकर्ता नए PowerShell संस्करण को स्थापित करेगा और मूल अनुप्रयोगों को लागू करते समय नए व्यवहार की खोज करेगा। वह क्या कहेगा? मैं अनुमान लगाऊंगा कि वह कहेगा - "धन्यवाद - अंत में मैं बस टाइप कर सकता हूं और यह काम करता है!"।

मेरे पास एक अलग परिदृश्य है: नए उपयोगकर्ता PowerShell को एक कोशिश देते हैं, महसूस करते हैं कि यह रहस्यमय तरीके से विफल हो गया है, इसे रीसायकल बिन में स्थानांतरित करें और कभी वापस न आएं। मैं इसे ही करूंगा।

स्क्रिप्ट के लिए फास्ट फिक्स तैयार करें

उपयोगकर्ता स्क्रिप्ट में स्पष्ट मामलों को कवर करने के लिए हमें ऐसा करना चाहिए।

एहसास है कि यह रहस्यमय तरीके से विफल हो जाता है

यहाँ पूरी चर्चा बस इस "रहस्यमय तरीके से विफल" होने से छुटकारा पाने के बारे में है। और इसे सरल बनाने के लिए सबसे अच्छा है लेकिन नई रहस्यमय चीजों को जोड़ना नहीं है।

यहां पूरी चर्चा सिर्फ इससे छुटकारा पाने के बारे में है। और इसे सरल बनाने के लिए सबसे अच्छा है लेकिन नई रहस्यमय चीजों को जोड़ना नहीं है।

हम सीधे निष्पादन योग्य कार्यक्रमों को लागू करने की क्षमता से छुटकारा नहीं चाहते हैं।

पुराने आह्वान cmdline के लिए प्रत्यक्ष नहीं है या तो यह अनुमान लगाने के साथ कि क्या पहले से ही कुछ उद्धृत किया गया है। इसके अलावा, उक्त क्षमता अभी भी -% के साथ बरकरार रहेगी।

इसके अलावा, उक्त क्षमता अभी भी -% के साथ बरकरार रहेगी।

--% को पूर्वनिर्धारित कमांड लाइन की आवश्यकता होती है, इसलिए इसकी उपयोगिता सीमित है।

@ yecril71pl

हम सीधे निष्पादन योग्य कार्यक्रमों को लागू करने की क्षमता से छुटकारा नहीं चाहते हैं।

मुझे लगता है कि @iSazonov का अर्थ है कि छोटी गाड़ी के व्यव्हार से छुटकारा पाना, अर्थात बग को ठीक से ठीक करना (बिना ऑप्ट-इन के बिना अतिरिक्त वाक्यविन्यास), भले ही इसका मतलब है कि मौजूदा वर्कअराउंड को तोड़ना। सही है, @iSazonov?

@ आर्टोरिया 2

पुराने आह्वान cmdline के लिए प्रत्यक्ष नहीं है या तो यह अनुमान लगाने के साथ कि क्या पहले से ही कुछ उद्धृत किया गया है

[_Update_: मैंने उद्धृत पंक्ति को गलत बताया है, लेकिन उम्मीद है कि जानकारी अभी भी रूचि है।]

• आपके पास _guess_ नहीं है, और नियम सरल है:

  • _Only if_ आपका कमांड नाम या पथ _quoted_ - '/foo bar/someutil 'है - और / या जिसमें _variable संदर्भ (या अभिव्यक्तियाँ) हैं - $HOME/someutil - & _re_ired_ है।

• हालांकि आप इस ज़रूरत को दुर्भाग्यपूर्ण मान सकते हैं, यह पॉवरशेल भाषा के बहुत दिल में है, और दो मूलभूत पार्सिंग मोड, तर्क मोड और अभिव्यक्ति मोड के बीच वाक्यात्मक रूप से भेद करने में सक्षम होने की आवश्यकता है।

  • ध्यान दें कि समस्या _external प्रोग्राम_ को कॉल करने के लिए विशिष्ट नहीं है; यदि किसी उद्धृत स्ट्रिंग / चर संदर्भ के माध्यम से निर्दिष्ट करने के लिए देशी PowerShell कमांड को भी आह्वान के लिए & आवश्यकता होती है।

• यदि आप इस सरल नियम को याद नहीं करना चाहते हैं, तो सरल नियम यह है: _always_ & , और आप ठीक हो जाएंगे - यह _not_ की तुलना में कुछ कम सुविधाजनक है, लेकिन किसी भी चीज की आवश्यकता नहीं है (और छोटी है) --% , जो बिल्कुल गलत समाधान है - नीचे देखें)

उक्त क्षमता अभी भी% के साथ बरकरार रहेगी।

[_Update_: मैंने उद्धृत पंक्ति को गलत बताया है, लेकिन उम्मीद है कि जानकारी अभी भी रूचि है।]

नहीं, _this_ समस्या के साथ # 13068 के दुर्भाग्यपूर्ण टकराव के बावजूद, --% - _its_ को कॉल करने की क्षमता, _its_ का उपयोग करके, हमेशा _platform-specific_ syntax - किसी भी तरह से मुद्दे पर हाथ और चर्चा करने के लिए वर्कअराउंड नहीं है। यह केवल इस भ्रम में जोड़ता है ।

--% एक बहुत अलग उपयोग मामला है और, जैसा कि वर्तमान में प्रस्तावित है, इसकी गंभीर सीमाएं हैं; अगर वहाँ कुछ है, तो (या किसी मौजूदा व्यवहार को बदलने के लिए) _operator_ शुरू करने लायक कुछ नहीं है, यह देशी शेल के लिए एक वर्बाइटिम कमांड लाइन को पारित करने की क्षमता है (जो, ज़ाहिर है, आप पहले से ही sh -c '...' साथ खुद को कर सकते हैं) यूनिक्स पर cmd /c '...' , लेकिन अगर यह मुद्दा तय हो जाता है तो केवल तभी मजबूत रूप से, लेकिन एक बाइनरी Invoke-NativeShell / ins cmdlet कार्यान्वयन, जबकि मुख्य रूप से लक्ष्य शेल के विवरण को अलग करना। सीएलआई सिंटैक्स, हाथ में समस्या से बच जाएगा ( System.Diagnostics.ProcessStartInfo.ArgumentList प्रत्यक्ष उपयोग के द्वारा), और इसलिए इसे स्वतंत्र रूप से लागू किया जा सकता है)।

@ yecril71pl

मेरे पास एक अलग परिदृश्य है: नए उपयोगकर्ता PowerShell को एक कोशिश देते हैं, महसूस करते हैं कि यह रहस्यमय तरीके से विफल हो गया है, इसे रीसायकल बिन में स्थानांतरित करें और कभी वापस न आएं। मैं इसे ही करूंगा।

क्या आप स्पष्ट कर सकते हैं: क्या आपको डर है, कि पॉवरशेल का वर्तमान व्यवहार इस अप्रिय उपयोगकर्ता अनुभव को जन्म दे सकता है, या क्या आपको डर है कि प्रस्तावित परिवर्तन उस userexperience की ओर जाता है।

क्योंकि मेरी राय में इस तरह के अनुभव को उत्पन्न करने के लिए पॉवरशेल का वर्तमान व्यवहार बहुत अधिक है। जैसा कि ऊपर कहा गया है: शक्तियों के वर्तमान व्यवहार को बग माना जाना चाहिए।

PowerShell के किसी भी ज्ञान को तोड़े बिना, एक नया उपयोगकर्ता, क्यों तर्कों के साथ आदेश जारी करेगा?

@ yecril71pl बस पूरी तरह से सुनिश्चित होने के लिए: आप "विरूपित" तर्कों के लिए वर्तमान में आवश्यक रूप पर विचार करते हैं, सुझाए गए फिक्स नहीं।

मैं आपके प्रश्न को आपके दमन से उत्पन्न मानता हूं कि मैं एक असाध्य बकवास हूं। यह सही है — लेकिन मैंने यह कल्पना करने की क्षमता को बनाए रखा है कि एक सामान्य यादृच्छिक चैप्टर को क्या माना जाएगा।

@ mklement0
मुझे लगता है, कि @ Artoria2e5 तर्क के सरणी को एकल lpCommandLine स्ट्रिंग में बदलने की बात कर रहा था।

पुराने आह्वान cmdline के लिए प्रत्यक्ष नहीं है या तो यह अनुमान लगाने के साथ कि क्या पहले से ही कुछ उद्धृत किया गया है

क्योंकि जब बुला रहा है

echoargs.exe 'some"complicated_argument'

आप वास्तव में कम या ज्यादा अनुमान लगाते हैं, कि क्या पॉवरशेल some"complicated_argument आसपास उद्धरण जोड़ता है।

उदाहरण 1: अधिकांश अधिकार वाले संस्करणों में
echoarg.exe 'a\" b' और echoarg.exe '"a\" b"' का अनुवाद किया जाएगा
"C:\path\to\echoarg.exe" "a\" b" (परीक्षण किए गए संस्करण 2.0; 4.0; 6.0.0-अल्फा.15; 7.0.1)
लेकिन Win10 पर मेरी डिफ़ॉल्ट शक्तियां (संस्करण 5.1.18362.752) अनुवाद करती हैं
echoarg.exe 'a\" b' से "C:\path\to\echoarg.exe" a\" b और
echoarg.exe '"a\" b"' से "C:\path\to\echoarg.exe" ""a\" b"" ।

उदाहरण 2: पुराने पॉवर्सशेल संस्करण अनुवाद करते हैं
echoarg.exe 'a"b c"' से "C:\path\to\echoarg.exe" "a"b c"" (परीक्षण संस्करण 2.0; 4.0;);
जबकि नए संस्करण अनुवाद करते हैं
echoarg.exe 'a"b c"' से "C:\path\to\echoarg.exe" a"b c" (परीक्षण किए गए संस्करण 5.1.18362.752; 6.0.0-अल्फा.15; 7.0.1)।

जैसा कि व्यवहार स्पष्ट रूप से पहले से ही कई बार बदला गया था, मुझे उम्मीद नहीं है कि अपेक्षित व्यवहार प्राप्त करने के लिए इसे एक बार और क्यों नहीं बदला जा सकता है।

मैं देखता हूं, @TSlivede , स्पष्ट करने के लिए धन्यवाद, और गलत व्याख्या के लिए खेद है, @ Artoria2e5।

वास्तविक समस्या के रूप में: हम समझौते में 100% हैं - वास्तव में, आपको कभी भी यह नहीं सोचना चाहिए कि विंडोज पर पर्दे के पीछे lpCommandLine छोर क्या उपयोग किया जा रहा है; यदि PowerShell ने सही काम किया है, तो किसी को भी नहीं होना चाहिए (किनारे के मामलों को छोड़कर, लेकिन वे PowerShell की गलती नहीं हैं, और ऐसा तब है जब --% (वर्तमान में लागू किया गया) मदद कर सकता है; एक उचित निर्धारण के साथ, कभी नहीं होगा; यूनिक्स जैसे प्लेटफार्मों पर किनारे के मामले हो)।

समस्या को ठीक से ठीक करने के लिए: आपके पास निश्चित रूप से मेरा वोट है (लेकिन मौजूदा वर्कअराउंड टूट जाएगा)।

TL; DR: यह धारणा कि हम Microsoft Windows NT सबसिस्टम में किसी भी प्रोग्राम के तर्क के रूप में किसी भी मूल्य को मज़बूती से पारित कर सकते हैं , इसलिए हमें यह दिखावा करना बंद कर देना चाहिए कि यह हमारा लक्ष्य है। हालांकि, अगर हम तर्क की सीमा पर विचार करते हैं, तो अभी भी बहुत कुछ बचा है।

मूल विंडोज़ निष्पादन को लागू करते समय, हमें मूल उद्धरण को संरक्षित करना चाहिए। उदाहरण:

CMD /CSTART="WINDOW TITLE"

सिस्टम फ़ाइल WINDOW नहीं ढूँढ सकता।

 { CMD /CSTART="WINDOW TITLE" }. Ast. EndBlock. Statements. PipelineElements. CommandElements[1]

StringConstantType

BareWord

मूल्य

/ CSTART = विंडो शीर्षक

StaticType

System.String

सीमा

/ CSTART = "खिड़की की दीवार"

माता-पिता

CMD / CSTART = "खिड़की का रास्ता"

यदि हमने टेम्पलेट के रूप में सीमा ले ली, तो हम कुछ भी नहीं खोएंगे और हम उम्मीद के मुताबिक मूल निष्पादन योग्य कह सकते हैं। एक स्ट्रिंग तर्क का उपयोग करने का तरीका यहां काम करता है, लेकिन मुझे नहीं लगता कि ऐसा करने के लिए तकनीकी रूप से कड़ाई से आवश्यक है, बशर्ते उचित समर्थन पावरशेल के भीतर लागू हो। यह दृष्टिकोण सभी मामलों के लिए काम करेगा।

उद्धरणों के भीतर उद्धरण चिह्न एक दुर्गम समस्या पेश करते हैं क्योंकि ऐसे उपकरण हैं जो बैकस्लैश एस्केप ( TASKLIST "\\\"PROGRAM FILES" ) की व्याख्या करते हैं और उपकरण जो ( DIR "\""PROGRAM FILES" /B ) और उपकरण जो परेशान नहीं करते हैं ( TITLE A " B )। हालाँकि, अगर हमें बचना था, तो सभी आम फ़ाइल प्रबंधन टूल में बैकस्लैश ज़हर के साथ मानक पलायन क्योंकि वे बस उद्धरण चिह्नों का समर्थन नहीं करते हैं और डबल बैकस्लैश \\ अर्थ उनके लिए पूरी तरह से अलग है ( DIR "\\\"PROGRAM FILES" /B प्रयास करें) CMD /CECHO='A " B' ) के लिए प्रदान नहीं कर पाएंगे।

ध्यान दें कि पर्यावरण चर CMD में मूल्यों का प्रतिनिधित्व नहीं करते हैं, वे कोड टुकड़ों का प्रतिनिधित्व करते हैं जिन्हें पर्यावरण चर के रूप में विस्तारित किया जाता है, और अन्य आदेशों के लिए उन्हें तर्क के रूप में व्यवहार करने का कोई प्रावधान नहीं है। CMD सिर्फ किसी भी तरह की वस्तुओं पर काम नहीं करता है, यहां तक ​​कि तार भी नहीं है, जो कि वर्तमान कॉंड्रम का मूल कारण लगता है।

TL; DR: यह धारणा कि हम Microsoft Windows NT सबसिस्टम में किसी भी प्रोग्राम के तर्क के रूप में किसी भी मूल्य को मज़बूती से पारित कर सकते हैं _wrong_ है, इसलिए हमें यह दिखावा करना बंद कर देना चाहिए कि यह हमारा लक्ष्य है।

हालांकि यह लक्ष्य नहीं होना चाहिए? यदि प्रोग्राम द्वारा प्राप्त किए गए तर्कों की व्याख्या नहीं की जा सकती तो यह PowerShell की समस्या नहीं है।

मूल विंडोज़ निष्पादन को लागू करते समय, हमें मूल उद्धरण को संरक्षित करना चाहिए। उदाहरण:

CMD /CSTART="WINDOW TITLE"

क्या आप किसी प्रोग्राम को कॉल करने का सुझाव दे रहे हैं, जो कि इनवॉइस किए गए प्रोग्राम का उपयोग करके पावरशेल से भाषा को गतिशील रूप से बदलना चाहिए? आपने उस उदाहरण को PowerShell में लिखा है, जिसका अर्थ है कि यह निम्नलिखित में से किसी के बराबर होना चाहिए

CMD "/CSTART=WINDOW TITLE"
CMD '/CSTART=WINDOW TITLE'
CMD /CSTART=WINDOW` TITLE

TL; DR: यह धारणा कि हम Microsoft Windows NT सबसिस्टम में किसी भी प्रोग्राम के तर्क के रूप में किसी भी मूल्य को मज़बूती से पारित कर सकते हैं _wrong_ है, इसलिए हमें यह दिखावा करना बंद कर देना चाहिए कि यह हमारा लक्ष्य है।

हालांकि यह लक्ष्य नहीं होना चाहिए? यदि प्रोग्राम द्वारा प्राप्त किए गए तर्कों की व्याख्या नहीं की जा सकती तो यह PowerShell की समस्या नहीं है।

कार्यक्रम CMD तर्क /CECHO=A " B व्याख्या कर सकता है लेकिन PowerShell इसे विकृत किए बिना इसे पारित नहीं कर सकता ।

मूल विंडोज़ निष्पादन को लागू करते समय, हमें मूल उद्धरण को संरक्षित करना चाहिए। उदाहरण:

CMD /CSTART="WINDOW TITLE"

क्या आप किसी प्रोग्राम को कॉल करने का सुझाव दे रहे हैं, जो कि इनवॉइस किए गए प्रोग्राम का उपयोग करके पावरशेल से भाषा को गतिशील रूप से बदलना चाहिए? आपने उस उदाहरण को PowerShell में लिखा है, जिसका अर्थ है कि यह निम्नलिखित में से किसी के बराबर होना चाहिए

CMD "/CSTART=WINDOW TITLE"
CMD '/CSTART=WINDOW TITLE'
CMD /CSTART=WINDOW` TITLE

मैंने यह सुझाव देने की कोशिश की कि, जब Microsoft Windows NT सबसिस्टम के अंतर्गत बाहरी कार्यक्रमों में हस्तक्षेप किया जाता है, तो PowerShell के पास उन तर्कों को एनकोड करने के असंख्य तरीके हैं जो PowerShell के समतुल्य हैं, लेकिन प्राप्त कार्यक्रम के समतुल्य नहीं हैं। कुंद होना और एन्कोडिंग तर्कों के वन ट्रू वे ™ को मजबूर करना, जो उपयोगकर्ता द्वारा वास्तव में उपयोग की जाने वाली व्यवस्था को उद्धृत करने पर ध्यान दिए बिना, इसे हल्का कहने के लिए सहायक नहीं है।

@ yecril71pl मैं आपकी टिप्पणियों से वास्तव में भ्रमित हूं। क्या आप वास्तव में यहाँ प्रस्ताव कर रहे हैं? आपके उपयोग के मामले सभी --% द्वारा कवर किए गए हैं। आपने पहले कहकर इसे खारिज कर दिया

--% को पूर्वनिर्धारित कमांड लाइन की आवश्यकता होती है, इसलिए इसकी उपयोगिता सीमित है।

लेकिन वास्तव में आप --% साथ पर्यावरण चर का उपयोग कर सकते हैं। इसे इस्तेमाल करे:

PS > $env:mytitle='WINDOW TITLE'
PS > cmd --% /CSTART="%mytitle%"

तो मुझे क्या याद आ रही है?

हम वाक्य रचना याद कर रहे हैं CMD /CSTART="$mytitle" , चीजों को लीक बिना ENV: ।

एक भयानक विचार के रूप में, हमारे पास Environment.ExpandEnvironmentVariables को किसी और चीज़ से बदलने का विकल्प है। यूनिक्स वैसे भी कोई मूल कार्यान्वयन नहीं है, और मुझे विश्वास नहीं है कि सी # में फिर से लिखे जाने पर सामान यह प्रक्रिया प्रदर्शन-महत्वपूर्ण हो जाएगा।

चूँकि env var नामों में किसी भी तरह से समान संकेतों की अनुमति नहीं है, %=$a% हमारे पास $a । यह कुछ बहुत ही लचीले (और संभवतः खराब) एक्सटेंशन की अनुमति देते समय किसी भी चीज को तोड़ नहीं सकता है, जैसे कि यह जेएस के टेम्पलेट स्ट्रिंग्स की तरह काम करता है। नर्क, हम %VARNAME=$var% को कुछ प्रकार के फ़ॉलबैक सिंटैक्स के रूप में भी परिभाषित कर सकते हैं।

प्रलेखन नरक के लिए के रूप में यह कारण होगा ... मैं माफी माँगता हूँ।

• हम _not_ को एक पार्सिंग समस्या है।

• हमारे पास जो भी समस्या है वह _how के साथ है। PowerShell ने verbatim, कड़े तर्क दिए हैं जो _its_ के कारण बाह्य (मूल) निष्पादनयोग्य_ पर आधारित हैं:

  • _Windows_ पर, समस्या यह है कि बाहरी निष्पादन योग्य को लागू करने के लिए कमांड लाइन जो पर्दे के पीछे निर्मित होती है, _not_ तर्कों को उद्धृत करने के लिए सबसे व्यापक रूप से उपयोग किए जाने वाले सम्मेलन का पालन करती है , जैसा कि Microsoft C / C ++ कंपाइलर प्रलेखन Parsing C ++ कमांड में विस्तृत

  • वर्तमान में ऐसा नहीं होता है कि एक _different_ कन्वेंशन का उपयोग किया जाता है: संभवतः एक ओवरसाइट के कारण, कमांड लाइन जो निर्मित की जाती है, स्थितिगत रूप से _syntactically मूलभूत रूप से टूटी हुई है, तर्क की बारीकियों के आधार पर, एम्बेडेड दोहरे उद्धरण और रिक्त स्थान के संयोजन से संबंधित है। साथ ही खाली-तर्कों का तर्क दिया।

  • अंततः, समस्या विंडोज पर प्रक्रिया निर्माण की मूलभूत वास्तुकला है: आप एक प्रक्रिया में पास करने के लिए तर्कों को सांकेतिक शब्दों में बदलना करने के लिए मजबूर कर रहे हैं _ एक कमांड लाइन_ - _all_ तर्कों का प्रतिनिधित्व करने वाला एक एकल स्ट्रिंग - उन्हें तर्क के _array_ के रूप में पारित करने के बजाय (जो यह है कि यूनिक्स की तरह प्लेटफार्मों यह कैसे करते हैं)। एक कमांड लाइन को पास करने के लिए _quoting और भागने के नियमों की आवश्यकता होती है। इसे लागू किया जाना चाहिए, और यह अंततः प्रत्येक प्रोग्राम के लिए _up है। कमांड लाइन को कैसे दिया जाए, इसकी व्याख्या कैसे करें। वास्तव में, इस कार्यक्रम को बिना किसी प्रकार के मिनी-शेल के लिए मजबूर करने की आवश्यकता होती है: वे _re-perform_ के कार्य के लिए मजबूर होते हैं जो शेल पहले ही प्रदर्शन कर चुके हैं, जो कि कार्य है जो _shell का केवल_ होना चाहिए (जैसा है) यूनिक्स पर मामला), अर्थात् व्यक्तिगत तर्कों में एक कमांड लाइन पार्स करना। संक्षेप में, यह एक अराजकता है जो तर्क विंडोज पर गुजर रहा है ।

  • व्यवहार में, अराजकता को उक्त सम्मेलन में पालन करने वाले _AST_ कार्यक्रमों द्वारा कम किया जाता है, और विकसित किए जा रहे नए कार्यक्रमों से उस सम्मेलन का पालन करने की अत्यधिक संभावना होती है, क्योंकि मुख्य रूप से कंसोल पर चलने वाले रनटाइम्स इन सम्मेलनों को लागू करते हैं (जैसे कि Microsoft C / C ++ /) .NET रनटाइम्स)। समझदार समाधान इसलिए है:

    • पर्दे के पीछे कमांड लाइन बनाते समय इस सम्मेलन का पालन करें।
    • "दुष्ट" कार्यक्रमों के लिए जो इस सम्मेलन में _not_ का पालन करते हैं - जिसमें विशेष रूप से cmd.exe , बैच फ़ाइलें, और Microsoft उपयोगिताओं जैसे msiexec.exe और msdeploy.exe - स्पष्ट रूप से एक तंत्र प्रदान करते हैं लक्ष्य निष्पादन योग्य को पारित कमांड लाइन को नियंत्रित करना; यह --% , स्टॉप-पार्सिंग प्रतीक प्रदान करता है - यद्यपि बहुत अजीब है ।

  • _Unix_ पर, समस्या यह है कि _a कमांड लाइन का निर्माण all_ पर किया जा रहा है - इसके बजाय, शब्दशः तर्क का सरणी _as-is_ पास किया जाना चाहिए , जो .NET .NET अब समर्थन करता है (v2.1 के बाद से, ProcessStartInfo.ArgumentList ; इसे _always_ ने इसका समर्थन किया है, यह देखते हुए कि - समझदारी से - _ कोई आदेश लाइनें नहीं हैं_, केवल तर्क सरणियाँ, जब एक प्रक्रिया यूनिक्स जैसे प्लेटफार्मों पर बनाई गई है)।

  • एक बार जब हम ProcessStartInfo.ArgumentList , तो यूनिक्स की सभी समस्याएं दूर हो जाती हैं।

इन समस्याओं को ठीक करना @TSlivede के https://github.com/PowerShell/PowerShell-RFC/pull/90 के बारे में है।

Https://github.com/PowerShell/PowerShell-RFC/pull/90#issuecomment -650242411 में मैंने अतिरिक्त रूप से बैच फ़ाइलों की "उग्रता" के लिए स्वचालित रूप से क्षतिपूर्ति का प्रस्ताव रखा है, जो उच्च के लिए CLI प्रवेश बिंदु के रूप में उनके व्यापक उपयोग को देखते हुए दिया है। -अप्रूफ़ाइल सॉफ्टवेयर जैसे एज़्योर (सीएलआई az को बैच फ़ाइल के रूप में लागू किया जाता है, az.cmd )।
इसी तरह, हमें msiexec.exe और msdeploy.exe और शायद अन्य हाई-प्रोफाइल "दुष्ट" Microsoft CLIs के लिए भी ऐसा करने पर विचार करना चाहिए।

मैंने सिर्फ एक मॉड्यूल, Native , ( Install-Module Native -Scope CurrentUser ) प्रकाशित किया है जो उपरोक्त सभी को इसके ie फ़ंक्शन ( i nvoke (बाह्य) e xecutable के लिए छोटा) के माध्यम से संबोधित करता है; iep फ़ंक्शन का पूर्ण कार्यान्वयन ऊपर प्रस्तुत किया

इसमें तर्क पारित करने के निदान के लिए ins ( Invoke-NativeShell ) भी शामिल हैं , जो # 13068, और dbea ( Debug-ExecutableArguments ) - https: // github देखें। com / पॉवरशेल / पॉवरशेल / मुद्दे / 13068 # जारी करने वाला विवरण के लिए -671572939।

दूसरे शब्दों में: ie एक विनीत स्टॉपगैप के रूप में काम कर सकते हैं, जबकि हम इस मुद्दे के ठीक होने का इंतजार करते हैं, बस ie कमांड के रूप में इनवॉइसिंग उपसर्ग द्वारा:

के बजाय:

# This command is currently broken, because the '{ "name": "foo" }' argument isn't properly passed.
curl.exe -u jdoe  'https://api.github.com/user/repos' -d '{ "name": "foo" }'

आप निम्नलिखित का उपयोग करेंगे:

# OK, thanks to `ie`
ie curl.exe -u jdoe  'https://api.github.com/user/repos' -d '{ "name": "foo" }'

CMD /CSTART="WINDOW TITLE" उदाहरण के लिए (जिसका अधिक मुहावरेदार रूप cmd /c start "WINDOW TITLE" , जो काम नहीं करता है):

इसके साथ के रूप में एक ही समस्या सार में है prop="<value with spaces>" के लिए बहस msiexec / msdeploy : PowerShell - उचित - रूपांतरण /CSTART="WINDOW TITLE" में "/CSTART=WINDOW TITLE" , जो, हालांकि cmd.exe मंगलाचरण को तोड़ता है।

इसे हल करने के दो तरीके हैं:

• ins / Invoke-NativeShell ( cmd.exe /c का उपयोग प्रभावी रूप से निहित है ध्यान दें):

  • ins 'START="WINDOW TITLE"'
  • यदि आप _expandable_ string का उपयोग करते हैं, तो आप कमांड स्ट्रिंग में PowerShell मान एम्बेड कर सकते हैं।
    
    
    
    • $title = 'window title'; ins "START=`"$title`""
    
    

• वैकल्पिक रूप से, वर्तमान --% कार्यान्वयन का उपयोग करें, लेकिन इसकी सीमाओं से सावधान रहें:

  • cmd --% /CSTART="WINDOW TITLE"
  • जैसा कि चर्चा की गई है, --% एक समस्याग्रस्त सीमा _PowerShell_ मानों को एम्बेड करने का एकमात्र तरीका _aux का उपयोग करना है। पर्यावरण चर_ और इसे %...% सिंटैक्स के साथ संदर्भित करें:
    
    
    
    • $env:_title = 'window title'; cmd --% /CSTART="%_title%"
    
    
    • इस सीमा से बचने के लिए, --% को हमेशा एक _single_ स्ट्रिंग तर्क के साथ लागू किया जाना चाहिए - जैसे,
      
      cmd --% '/CSTART="WINDOW TITLE"' या cmd --% "/CSTART=`"$title`"" - लेकिन यह पिछड़े संगतता को तोड़ने के बिना नहीं बदला जा सकता है, इसलिए _new_ प्रतीक को पेश करना होगा - व्यक्तिगत रूप से, मुझे एक की आवश्यकता नहीं दिखती है।
    
    

• वे _re-perform_ को उस कार्य के लिए मजबूर करते हैं जो शेल ने पहले ही निष्पादित किया है

मुझे नहीं लगता कि CMD.EXE कमांड लाइन को तर्कों में विभाजित करता है, केवल एक चीज जो आवश्यक है वह यह पता लगाना है कि कॉल करने के लिए कौन सा निष्पादन योग्य है और बाकी केवल कमांड लाइन है जैसा कि उपयोगकर्ता द्वारा लिखा गया है (पर्यावरण चर प्रतिस्थापन के बाद, जो तर्क सीमाओं के लिए किसी भी संबंध के बिना किया जाता है)। बेशक, आंतरिक शेल कमांड यहां अपवाद हैं।

यह संक्षेप में prop="<value with spaces>" msiexec / msdeploy लिए तर्कों के साथ एक ही समस्या है

मैं या तो एक आश्वस्त उपयोगकर्ता नहीं हूं, इसलिए मैंने कुछ ऐसी चीजों को लाना पसंद किया जिनसे मैं अधिक परिचित हूं।

स्पष्ट होना: मेरी पिछली टिप्पणी में दिए गए बिंदुओं पर निम्नलिखित का कोई प्रभाव नहीं है।

मुझे नहीं लगता कि CMD.EXE तर्कों में कमांड लाइन को विभाजित करता है

• यह _explicit_ splitting के बिना दूर हो सकता है जब _external निष्पादक_ (बच्चे की प्रक्रिया में किसी अन्य निष्पादन योग्य द्वारा संचालित कमांड) को कॉल किया जाता है, लेकिन इसे _batch files_ के लिए करना पड़ता है।

• बाहरी निष्पादनों को कॉल करते समय भी इसे तर्क सीमाओं का _aware_ होना चाहिए, ताकि यह निर्धारित किया जा सके कि क्या दिए गए मेटाचैकर (जैसे & ) के पास _syntactic_ फ़ंक्शन है या क्या यह दोहरे-उद्धृत तर्क का हिस्सा है और इसलिए इसका इलाज किया जाना है शाब्दिक के रूप में:

:: OK - the "..." around & tells cmd.exe to use it verbatim
C:\>echoArgs.exe one "two & three"
Arg 0 is <one>
Arg 1 is <two & three>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" one "two & three"

इसके अलावा, cmd.exe _embedded_ " वर्णों को पहचानता है। अगर "" बच गए तो "..." स्ट्रिंग्स में मान्यता प्राप्त है

:: OK - the "" is recognized as an escaped "
C:\>echoArgs.exe "3"" of rain & such."
Arg 0 is <3" of rain & such.>

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "3"" of rain & such."

दुर्भाग्य से, cmd.exe _only_ का समर्थन करता है (Windows-only) "" और अधिक व्यापक रूप से उपयोग किए जाने वाले \" (जो कि PixIX की तरह _shells_ के लिए Unix _exclusively_ उपयोग - नोट: _shells_, न कि _programs_, क्योंकि प्रोग्राम केवल शब्दशः तर्कों के सरणी को देखते हैं जो शेल के पार्सिंग से उत्पन्न होते हैं)।

जबकि विंडोज पर ज्यादातर CLIs _both_ "" और \" , कुछ _only_ \" (विशेष रूप से पर्ल और रूबी) को समझते हैं, और फिर आप मुसीबत में हैं:

:: !! BROKEN: cmd.exe misinterprets the & as *unquoted*, thinks it's the statement-sequencing operator, 
:: !! and tries to execute `such`:
C:\>echoArgs.exe "3\" of rain & such."
Arg 0 is <3" of rain >

Command line:
"C:\ProgramData\chocolatey\lib\echoargs\tools\EchoArgs.exe" "3\" of rain

'such."' is not recognized as an internal or external command,
operable program or batch file.

इसलिए:

• यदि संभव हो तो cmd.exe सीधे कॉल करने से बचें।

  • बाह्य निष्पादकों को सीधे कॉल करें (एक बार यह समस्या ठीक हो जाने पर) या ie (अभी के लिए) के माध्यम से, _PowerShell के_ सिंटैक्स का उपयोग करके।

• यदि आपको cmd.exe कॉल करना है, तो सामान्य सादगी के लिए ins / Invoke-NativeShell और विशेष रूप से, कमांड लाइन में PowerShell चर और अभिव्यक्ति मानों को एम्बेड करना कितना आसान है। ।

  • अभी भी cmd.exe सीधे कॉल करने का एक वैध कारण पाइपलाइन में कच्चे बाइट डेटा के लिए PowerShell के समर्थन की कमी की भरपाई करना है - उदाहरण के लिए इस SO उत्तर को देखें।

मुझे पता है कि मैं यहाँ बहुत सारी फ्लाक्स पकड़ने जा रहा हूँ, और मैं वास्तव में हो रही चर्चा की गहराई की सराहना करता हूँ, लेकिन ... बतख ... क्या किसी के पास वास्तव में वास्तविक दुनिया में मौजूद किसी भी मामले का उदाहरण है ?

यह मेरा तर्क है कि हम वर्तमान में विंडोज तर्क पार्सिंग के साथ मौजूद "अराजकता" को हल करने के लिए पावरशेल में सशक्त नहीं हैं। और इसी तरह के कई कारणों से जो हम समस्या को हल नहीं कर सकते हैं, एक अच्छा कारण है कि विंडोज और वीसी ++ कंपाइलरों ने इस व्यवहार को नहीं तोड़ने के लिए चुना है। यह बड़ा है, और हम केवल नई (और काफी हद तक अनिर्दिष्ट) समस्याओं की एक लंबी लंबी पूंछ बनाने जा रहे हैं यदि हम चीजों को बदलते हैं।

उन उपयोगिताओं के लिए जो पहले से ही क्रॉस-प्लेटफॉर्म और विंडोज और लिनक्स (जैसे डॉकर, के 8, गिट, आदि) के बीच भारी उपयोग में हैं, मुझे यह समस्या वास्तविक दुनिया में दिखाई नहीं देती है।

और उन "दुष्ट" अनुप्रयोगों के लिए जो एक खराब काम करते हैं: वे बड़े पैमाने पर विरासत, विंडोज-केवल उपयोगिताओं हैं।

मैं सहमत हूं कि आपने @ mklement0 का जो वर्णन किया है, वह काफी हद तक एक "सही" समाधान है। मैं अभी नहीं जानता कि वास्तव में चीजों को खराब किए बिना वहां कैसे पहुंचा जाए।

सुंदर मूल usages तोड़:

❯ git commit --allow-empty -m 'this is what we call a "commit message" which contains arbitrary text, often with punctuation'
error: pathspec 'message which contains arbitrary text, often with punctuation' did not match any file(s) known to git
❯ $a = 'this is what we call a "commit message" which contains arbitrary text, often with punctuation'
❯ git commit --allow-empty -m "$a"
error: pathspec 'message which contains arbitrary text, often with punctuation' did not match any file(s) known to git

❯ $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

git.exe एक अच्छी तरह से व्यवहार किया गया अनुप्रयोग है, इसलिए PowerShell में फिक्स सीधा होगा, यद्यपि सभी स्क्रिप्टर्स को अपने स्मार्ट वर्क-अराउंड को वापस करने की आवश्यकता होगी। cmd.exe लिए अनुकूल होना कठिन है और बहुत अधिक विचारशील दृष्टिकोण की आवश्यकता है जो कुछ समस्याओं को हल कर सकता है लेकिन शायद उन सभी को नहीं। जो वास्तव में भयावह है, यह देखते हुए कि पावरशेल एक विंडोज एनटी टूल के रूप में शुरू हुआ। मैं इस प्रश्न को समझता हूं कि _व्हीटर एक वास्तविक जीवन परिदृश्य है जब cmd.exe जैसे एक बीमार व्यवहार की विरासत पावरशेल से इस तरह से कॉल की जाएगी जो इंटरफ़ेस_ में समस्याओं का कारण बनती है। PowerShell ने cmd.exe में अधिकांश कार्यक्षमता को दोहराकर इस समस्या से संपर्क करने का प्रयास किया, ताकि cmd.exe अनावश्यक बनाया जा सके। यह अन्य साधनों के लिए भी संभव है, उदाहरण के लिए MSI को ActiveX के माध्यम से संचालित किया जा सकता है, हालांकि ऐसा करने के लिए काफी ज्ञान की आवश्यकता होती है। तो क्या ऐसा कुछ जरूरी है जो कवर न किया गया हो?

@ पावरशेल / पावरशेल-समिति ने इस पर चर्चा की। हम git उदाहरण की सराहना करते हैं जो स्पष्ट रूप से एक वास्तविक विश्व सम्मोहक उदाहरण दिखाता है। हम इस बात से सहमत थे कि इस तरह के एक ब्रेकिंग बदलाव के प्रभाव को मान्य करने के लिए हमारे पास 7.2 में जल्दी एक प्रायोगिक सुविधा होनी चाहिए। एक अतिरिक्त परीक्षण उदाहरण से पता चलता है कि --% को एक समस्या है, भले ही उसे अनपार्ट किया गया हो:

PS> testexe --% -echoargs 'a b c "d e f " g h'
Arg 0 is <'a>
Arg 1 is <b>
Arg 2 is <c>
Arg 3 is <d e f >
Arg 4 is <g>
Arg 5 is <h'>

यह देशी कमांड पैरामीटर बाइंडर में एक समस्या प्रतीत होती है।

हाँ, धन्यवाद @cspotcode। यह उदाहरण निश्चित रूप से मेरे लिए एक महत्वपूर्ण क्षण था (विशेषकर यह देखते हुए कि मैं वास्तव में वास्तविक दुनिया में एक हिट हूं)।

मैं अभी भी ब्रेकिंग चेंज पहलू के बारे में चिंतित हूं, और यह मेरा ख्याल है कि यह एक प्रयोगात्मक सुविधा के लिए एक उम्मीदवार है जो पावरशेल के कई संस्करणों पर प्रयोगात्मक रह सकता है, और यह बिल्कुल ऐसा कुछ नहीं है जो हमें यकीन है कि अंततः इसे बना देगा।

मुझे आपके RFC, @ mklement0 की अनुमति सूची / "रूज ऐप" पहलू को समझने के लिए और अधिक खुदाई करने की आवश्यकता है, क्योंकि मुझे यकीन नहीं है कि हम उस तरह की सूची बनाए रखने के लिए कितना साइन अप करना चाहते हैं।

@joeyaiello और @ SteveL-MSFT, मुझे पहले एक मेटा अवलोकन बनाने दें:

हालांकि यह देखना अच्छा है कि @cspotcode के उदाहरण ने आपको समस्या का एक _gllook_ प्रदान किया है, आपकी प्रतिक्रियाएँ अभी भी अंतर्निहित समस्या की समझ और सराहना की मूलभूत कमी (मैं बाद की टिप्पणी में इस बात पर बहस करूँगा) की सराहना करता हूं ।

यह एक _personal_ निर्णय नहीं है: मैं पूरी तरह से पहचानता हूं कि बहुत पतले होने के लिए कितना कठिन होना चाहिए और थोड़े समय में बहुत विस्तृत विषयों पर निर्णय लेना होगा।

हालाँकि, यह _structural_ समस्या की ओर इशारा करता है: मेरे लिए ऐसा लगता है कि बड़े पैमाने पर समुदाय की रुकावट के लिए, चर्चा की जा रही समस्याओं की सतही समझ के आधार पर @ PowerShell / powershell-समिति द्वारा नियमित रूप से निर्णय किए जाते हैं।

मेरे लिए, इस मुद्दे पर समिति की प्रतिक्रिया यहाँ पर इस संरचनात्मक समस्या का सबसे परिणामी उदाहरण है।

इसलिए, मैं आपसे इस पर विचार करने के लिए कहता हूं:

विषय-विशेष-विशिष्ट _sub_-समितियों को नियुक्त करने के बारे में जो समिति उस _do_ के साथ परामर्श करती है, उसमें शामिल मुद्दों की आवश्यक समझ है?

क्या आप testexe SteveL-MSFT की सामग्री साझा कर सकते हैं, बस सुनिश्चित करना चाहते हैं!

@TSlivede ने समस्या को agly https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -665125375 में संक्षेप में प्रस्तुत किया है:

दूसरी ओर PowerShell एक शेल होने का दावा करता है (# 1995 तक हल होने तक, मैं यह नहीं कहूंगा कि यह _is_ एक शेल है)

जैसा कि पहले कई बार कहा गया है, एक शेल का मुख्य आदेश बाहरी निष्पादकों को तर्कों के साथ बुलाना है।

PowerShell वर्तमान में इस जनादेश को पूरा करने में विफल रहता है, यह देखते हुए कि एम्बेडेड डबल कोट्स और खाली स्ट्रिंग तर्कों के साथ तर्क सही तरीके से पारित नहीं होते हैं।

जैसा कि पहले कहा गया है, यह विंडोज-ओनली दिनों में एक समस्या से कम हो सकता है, जहां सक्षम बाहरी सीएलआई की कमी शायद ही कभी इस समस्या से सामने आई है, लेकिन ये दिन दूर हो गए हैं, और अगर पावरशेल खुद को एक विश्वसनीय क्रॉस-प्लेटफॉर्म के रूप में स्थापित करना चाहते हैं खोल, यह इस समस्या को संबोधित करना चाहिए।

@cspotcode का git उदाहरण एक अच्छा है; कोई भी निष्पादन योग्य जिसे आप JSON स्ट्रिंग पास करना चाहते हैं - जैसे, curl - एक और:

# On Unix; on Windows, 
#   echoArgs.exe '{ "foo": "bar" }' 
# would show the same problem.
PS> /bin/echo '{ "foo": "bar" }'
{ foo: bar }  # !! Argument was incorrectly passed.

पिछड़ेपन को एक तरफ छोड़कर:

• यूनिक्स पर, समस्या तुच्छ है और _completely_ ने पर्दे के पीछे ProcessStartInfo.ArgumentList का उपयोग करके हल किया है।

• विंडोज पर, यह समस्या तुच्छ है और दृश्यों के पीछे ProcessStartInfo.ArgumentList का उपयोग करके हल किया गया है।

  • किनारे के मामलों ("दुष्ट" सीएलआई) के लिए, ( खराब तरीके से लागू ) --%
  • _Courtesy_ के रूप में, हम --% की आवश्यकता को कम करने के लिए कुछ प्रसिद्ध किनारे के मामलों की भरपाई कर सकते हैं - नीचे देखें।

इसलिए, _स जल्द से जल्द_, निम्नलिखित विकल्पों में से एक बनाना होगा:

• तर्क-पासिंग के काम को सही ढंग से करने के महत्व को महसूस करें और इसे पश्चगामी संगतता की कीमत पर __ उपसर्ग करें।

• यदि पश्चगामी संगतता वास्तव में सर्वोपरि है, तो एक नया ऑपरेटर या एक फ़ंक्शन प्रदान करें जैसे ie फ़ंक्शन Native मॉड्यूल से जो समस्या को ठीक करता है, और इसे बाहरी रूप से आमंत्रित करने का एकमात्र विश्वसनीय तरीका के रूप में प्रचारित करता है निष्पादनयोग्य।

बुरी तरह से टूटी हुई मूलभूत सुविधा को संबोधित करने के लिए एक _experimental_ सुविधा का प्रस्ताव पूर्ण रूप से अपर्याप्त है।

@ SteveL-MSFT

इस समस्या के समाधान के रूप में --% उपयोग पर विचार करना भी मूलभूत रूप से गलत है:

यह एक _Windows-only_ सुविधा है जो केवल "..." उद्धृत करना और %...% -स्टाइल परिवेश-चर संदर्भ जानता है।

यूनिक्स पर, "पार्सिंग को रोकना" की अवधारणा मौलिक रूप से लागू नहीं होती है: _ केवल बाल प्रक्रियाओं को पारित करने के लिए कोई कमांड लाइन_ नहीं है, केवल तर्कों की सारणी।

इस प्रकार, _someone_ को कमांड लाइन को तर्कों में छोड़ना पड़ता है _before_ मंगलाचरण, जिसका निहितार्थ ProcessStartInfo वर्ग में, इसकी .Arguments प्रॉपर्टी के माध्यम से होता है, जो कि Unw का उपयोग कमांड लाइन को पार्स करने के लिए _Windows_ सम्मेलनों का उपयोग करता है। - और इसलिए "..." उद्धृत करता है (एम्बेडेड " रूप में "" या \" ) से बचने के साथ।

--% एक Windows- केवल सुविधा है जिसका एकमात्र वैध उद्देश्य "दुष्ट" सीएलआई को कॉल करना है।

@joeyaiello

Windows और VC ++ कंपाइलर ने इस व्यवहार को नहीं तोड़ने के लिए चुना है।

कुलपति के आदेश को लाने के लिए

यह इस अधिवेशन का पूरी तरह से पालन है , जिसकी ProcessStartInfo.ArgumentList का उपयोग स्वतः ही हमें देगा।

_ यह अकेले कॉल के विशाल बहुमत को कवर करेगा। सभी कॉल को कवर करना असंभव है और वास्तव में पावरशेल की जिम्मेदारी नहीं है ।_

जैसा कि कहा गया है, "दुष्ट" सीएलआई के लिए, जिन्हें उद्धृत करने के गैर-पारंपरिक रूपों की आवश्यकता है, --% का उपयोग किया जाना चाहिए (या ins / Invoke-NativeShell Native मॉड्यूल से; )।

_A शिष्टाचार_ के अनुसार, हम स्वचालित रूप से अच्छी तरह से ज्ञात "दुष्ट" परिदृश्यों के लिए क्षतिपूर्ति कर सकते हैं, अर्थात् बैच फाइलें और कुछ हाई-प्रोफाइल Microsoft CLIs:

• बैच-फ़ाइल का मामला एक सामान्य है, और आसानी से समझाया और संकल्पित किया गया है (उदाहरण के लिए, a&b "a&b" , भले ही इसे उद्धृत करने की आवश्यकता न हो) - यह उपयोग की आवश्यकता को टाल देगा सभी सीएलआई के साथ --% जो अपने प्रवेश बिंदु के रूप में बैच फ़ाइलों का उपयोग करते हैं (जो कि काफी सामान्य है), जैसे कि Azure का az.cmd

• विशिष्ट सीएलआई के लिए हार्ड-कोडिंग अपवादों का विकल्प - जो कि भ्रामक रूप से भ्रमित हो सकता है - पॉवरसेश के पार्सिंग से उत्पन्न तर्कों में निम्नलिखित _पाटन_ का पता लगाना है - <word>=<value with spaces> - और, "<word>=<value with spaces>" पारित करने के बजाय। , जैसा कि वर्तमान में होता है, <word>="<value with spaces>" ; उत्तरार्द्ध "दुष्ट" सीएलआई को संतुष्ट करता है, जबकि सम्मेलन-पालन सीएलआई द्वारा भी स्वीकार किया जा रहा है; उदाहरण के लिए, echoArgs "foo=bar baz" अंततः echoArgs --% foo="bar baz" रूप में एक ही पहला तर्क देखता है

@musm आप TestExe का स्रोत कोड पा सकते हैं ।

GitHub

PowerShell / PowerShell

हर प्रणाली के लिए PowerShell! GitHub पर एक खाता बनाकर PowerShell / PowerShell विकास में योगदान करें।

मुझे लगता है कि डिफ़ॉल्ट रूप से अपवादों को समायोजित करना वर्तमान स्थिति के समान स्थिति में ले जाने वाला है, जहां लोगों को पावरशेल की "सहायकता" को वापस लाने की आवश्यकता है। यदि अपवाद हैं, तो यह स्पष्ट होना चाहिए कि उन्हें लागू किया जा रहा है।

शायद कुछ इस तरह:

# Arguments passed correctly, without regard for the program's ability to handle them
& $program a "" 'c "d e" f'
# Try to pass the arguments intelligently based on the program being called
&[] $program a "" 'c "d e" f'
# Escape the arguments for a batch file, eg) " -> ""
&[bat] $program a "" 'c "d e" f'

मैं वास्तव में इसके लिए वाक्यविन्यास खोजने के लिए संघर्ष कर रहा हूं जो टूटा नहीं है। कम से कम इस तरह की समझ में आता है अगर आप इसे प्रोग्राम को कास्टिंग के रूप में सोचते हैं, लेकिन प्रोग्राम वाले वास्तविक चर को कास्टिंग करने के लिए पेरेंटस को घेरने की आवश्यकता होगी।

इसके अलावा, लोगों को जो भी टूटे हुए व्यवहार के लिए अपवाद जोड़ने की अनुमति है, उन्हें उम्मीद है कि --% की आवश्यकता को समाप्त करना चाहिए। अपवाद वर्ग जो वे पंजीकृत करते हैं, उसके बाद यह निर्धारित करने के लिए एक विधि होगी कि क्या यह कार्यक्रम (बुद्धिमान आह्वान के लिए) पर लागू होता है, और एक बचने की विधि जहां आप बस उस पर कमांड सार वाक्यविन्यास ट्री फेंकते हैं और यह तर्क सरणी / स्ट्रिंग लौटाता है।

• "<word>=<value with spaces>" पास करने के बजाय, जैसा कि वर्तमान में होता है, <word>="<value with spaces>"

कमांड लाइन का निर्माण करने के लिए उपयोग किए जाने वाले उद्धरणों को पावरशेल में कॉल के तरीके का पालन करना चाहिए। इसलिए:

1. एक कॉल जिसमें इसके पाठ में दोहरे उद्धरण नहीं हैं, पूरे मूल्य के आसपास दोहरे उद्धरण चिह्नों को रखना चाहिए।
2. एक कॉल जिसमें दोहरे उद्धरण चिह्नों को बनाए रखा जाना चाहिए जैसा कि स्क्रिप्ट में लिखा गया है _if संभव_।

विशेष रूप से:
| स्क्रिप्ट तर्क | कमांड लाइन |
| ----------------- | ---------------- |
| p=l of v | "p = l का v" |
| p=l` of` v | "p = l का v" |
| p="l of v" | p = "l का v" |
| p="l of v"'a s m' | p = "l of v" a "sm" |
| p="l of v"' s m' | p = "बनाम एलएम" |

अंतिम पंक्ति एक उदाहरण दिखाती है जहां मूल दोहरे उद्धरणों को बनाए रखना संभव नहीं होगा।

मुझे पता है कि मैं यहाँ बहुत सारी फ्लाॅक पकड़ने जा रहा हूँ, और मैं वास्तव में हो रही चर्चा की गहराई की सराहना करता हूँ, लेकिन ..._ ducks _... क्या किसी के पास वास्तव में वास्तविक दुनिया में मौजूद किसी भी मामले का उदाहरण है ?

मैंने पहले ही एक साल पहले इस धागे में इसका उल्लेख किया था (यह अब छिपा हुआ है ...) कि मुझे पॉवर्स में डब्ल्यूएफटी क्षण

rg '"quoted"'

और git बैश में यह नहीं किया।

अब मुझे यह डब्ल्यूटीएफ क्षण कम मिलता है क्योंकि दुख की बात है कि मैंने इस लंबे गीथूब मुद्दे को पाया और पाया कि " Powershel को पूरी तरह से तोड़ दिया गया है। हाल ही में "git.exe" उदाहरण भी बढ़िया है।

ईमानदार होने के लिए, अब मुझे मूल कमांड को कॉल करने के लिए पॉवरशेल का उपयोग करने की हिम्मत भी नहीं होती है जब मुझे पता है कि मैं पैरामीटर के रूप में स्ट्रिंग में " पास कर सकता हूं। मुझे पता है कि मुझे गलत परिणाम या त्रुटि मिल सकती है।

वास्तव में, @ mklement0 ने इसे बहुत अच्छा बताया (इसे कहीं पत्थर में उकेरा जाना चाहिए)

जैसा कि पहले कई बार कहा गया है, एक शेल का मुख्य आदेश बाहरी निष्पादकों को तर्कों के साथ बुलाना है ।
PowerShell वर्तमान में इस जनादेश को पूरा करने में विफल रहता है, यह देखते हुए कि एम्बेडेड डबल कोट्स और खाली स्ट्रिंग तर्कों के साथ तर्क सही तरीके से पारित नहीं होते हैं।
जैसा कि पहले कहा गया है, यह विंडोज-ओनली दिनों में एक समस्या से कम हो सकता है, जहां सक्षम बाहरी सीएलआई की कमी शायद ही कभी इस समस्या से सामने आई है, लेकिन ये दिन दूर हो गए हैं, और अगर पावरशेल खुद को एक विश्वसनीय क्रॉस-प्लेटफॉर्म के रूप में स्थापित करना चाहते हैं खोल, यह इस समस्या को संबोधित करना चाहिए ।

और परिवर्तन को तोड़ने के बारे में।
हाल ही में सहकर्मी ने मुझे लिखा कि मेरी स्क्रिप्ट ने उनकी मशीन पर काम नहीं किया। मैं इसे केवल पॉवर्सल कोर पर चला रहा था और वह इसे विंडोज पॉवर्सशेल पर चला रहा था। विंडोज पॉवर्सशेल पर "बीओएम" और पॉवर्सेल कोर पर बीओएम के बिना Out-File -Encoding utf8 एन्कोडेड फ़ाइल को बदल देता है। यह किसी भी तरह से अप्रचलित उदाहरण है, लेकिन यह दर्शाता है कि पॉवर्सल में पहले से ही सूक्ष्म विराम परिवर्तन हैं और यह अच्छा है क्योंकि हम एक ऐसी भाषा से quirks और सहज व्यवहार को समाप्त कर रहे हैं जो इसके लिए प्रसिद्ध है। यह बहुत अच्छा होगा यदि पॉवर्सल टीम थोड़ी अधिक उदार थी, जब अब ब्रेकिंग परिवर्तन की बात आती है कि हमारे पास क्रॉस प्लेटफॉर्म है पॉवर्सशेल जो कि विंडोज के बाहर शिपिंग है और हमें पता है कि विंडोज पॉवर्सशेल "मेनटेनेंस" मोड में है और हमेशा के लिए उपयोग करने योग्य है आप वास्तव में कुछ पुरानी स्क्रिप्ट को चलाना चाहते हैं जो पॉवर्सशेल के नए संस्करण में टूट गई।

रे: परिवर्तनों को तोड़ने के अंतिम बिंदु - मैं पूरी तरह से सहमत हूं। _Many_ ब्रेकिंग परिवर्तन हैं जो हमने विभिन्न कारणों से सहन किए हैं। हालाँकि, अधिक से अधिक बार ऐसा प्रतीत होता है कि कुछ ब्रेकिंग परिवर्तन केवल वरीयता के कारणों पर आधारित होते हैं और उनके वास्तविक मूल्य के लिए विचार के उचित गुरुत्वाकर्षण को नहीं दिया जाता है।

इस तरह के कुछ बदलाव हैं, जो _Sassively_ किसी भी व्यक्ति के लिए समग्र शेल अनुभव में सुधार करेंगे, जिन्हें काम करने के लिए पावरशेल के बाहर पहुंचने की आवश्यकता है, जो हर समय होता है। यह समय और समय फिर से सहमत हो गया है कि वर्तमान व्यवहार अस्थिर है और पहले से ही बड़े पैमाने पर किसी भी चीज के लिए टूट गया है लेकिन सबसे सरल उपयोग है। और फिर भी, हम अभी भी परिवर्तनों को तोड़ने के लिए इस विकृति का सामना कर रहे हैं, जबकि पहले से स्वीकृत ब्रेकिंग परिवर्तनों के स्कोर भी हैं, जिनमें से कुछ का समान रूप से बड़ा प्रभाव है।

उदाहरण के लिए पूछने वालों के लिए - एक बार के लिए स्टैक ओवरफ्लो पर जाने के लिए एक मिनट का समय लें। मुझे यकीन है कि @ mklement0 में ऐसे उदाहरणों की कोई उपयोगी

जब भी MSFT टीम एक ही बात को बार-बार दोहराती है, तो हम यह सुनिश्चित कर सकते हैं कि वे जितना जानते हैं उससे अधिक सार्वजनिक रूप से कह सकते हैं। हमें उनके आंतरिक अनुशासन का सम्मान करना चाहिए न कि उन पर दबाव डालना चाहिए। _माइबे हम एक समझौता पा सकते हैं। मुझे आशा है कि मेरे पास आलसी प्रवास के साथ वैकल्पिक मार्ग का वर्णन करने के लिए आज समय होगा।

मैं इसे पहचानता हूं, और इसीलिए मैं शायद ही कभी इस पर सवाल उठाता हूं।

हालाँकि, यह एक ओपन सोर्स प्रोजेक्ट है; यदि उन निर्णयों में कोई संभावित दृश्यता नहीं है, तो लोग _will_ अनिवार्य रूप से निराश हो जाते हैं। उस सिक्के के दोनों ओर कास्ट करने का कोई दोष नहीं, बस यहां की स्थिति की वास्तविकता है, आईएमओ। तो, हाँ, एक प्रवास पथ होने से उस दर्द को कुछ हद तक कम किया जा सकता है, लेकिन हमें स्पष्ट नीतियों की आवश्यकता है कि कैसे काम करना है जो चीजों को यथासंभव अधिक से अधिक लोगों के लिए काम करेगा। हालांकि जानकारी की कमी होने पर समझौता करना मुश्किल है।

मैं यह देखने के लिए उत्सुक हूं कि आपने अपनी आस्तीन ऊपर क्या है। 😉

@ mklement0 आप बिलकुल सही हैं, और इतना ही कि मैं अभी आपके मेटा-पॉइंट का जवाब दे सकता हूं। दुर्भाग्य से, ऐसे मामलों में जहां हम इस तरह के एक सवाल का जवाब देने के लिए आवश्यक गहराई के स्तर तक पहुंचने में सक्षम नहीं होते हैं, सुरक्षित दृष्टिकोण अक्सर ब्रेकिंग परिवर्तन को स्थगित करने या अस्वीकार करने के लिए होता है जब तक कि हमारे पास अधिक समय न हो।

मैं परिवर्तनों को तोड़ने के बारे में एक और मेटा-पॉइंट बनाना चाहता हूं, हालांकि: हमारे टेलीमेट्री का तात्पर्य है कि अधिकांश PowerShell 7 उपयोगकर्ता अपने स्वयं के संस्करणों का प्रबंधन नहीं कर रहे हैं। वे एक प्रबंधित वातावरण में स्वचालित स्क्रिप्ट चला रहे हैं जो आरामदायक है जैसे कि अपने उपयोगकर्ताओं को 6.2 से 7.0 में अपग्रेड करना (6.2 उपयोगकर्ताओं में 2-दिन का कूदना 7.0 उपयोगकर्ताओं को 8/3 पर शुरू करना; यह हमारा एकमात्र डेटा बिंदु नहीं है, लेकिन यह अभी एक सुविधाजनक है जो बिंदु बनाता है)। इन उपयोगकर्ताओं के लिए, एक ब्रेकिंग परिवर्तन जो पूरी तरह से काम करने वाली स्क्रिप्ट को एक गैर-कार्यशील स्क्रिप्ट में बदल देता है, अस्वीकार्य है।

मैं समुदाय को इस बात के लिए भी मानता हूं कि मैं ब्रेकिंग परिवर्तनों के प्रभाव के बारे में कैसे सोचता हूं: मौजूदा उपयोग की व्यापकता और ब्रेक की पहचान और आसानी को ठीक करने के खिलाफ ब्रेक की गंभीरता का व्यापार। यह एक मौजूदा स्क्रिप्ट में बहुत प्रचलित है, पहचानने और ठीक करने के लिए भ्रमित करने वाला, और ब्रेकिंग व्यवहार कुल सफलता से लेकर कुल विफलता तक है, इसलिए यहां कुछ भी करने के लिए मेरी चरम मितव्ययिता है।

मुझे लगता है कि यह कहना उचित है कि हम 7.1 में यहां कुछ भी नहीं करने जा रहे हैं, लेकिन मैं निश्चित रूप से इसे 7.2 के लिए एक खोजी प्राथमिकता बनाने के लिए तैयार हूं (यानी हम इस पर चर्चा करने में हमारी समिति के समय से अधिक खर्च करते हैं।)

विषय-विशेष-विशिष्ट उप-समितियों को नियुक्त करने के बारे में जो समिति के साथ परामर्श करती है कि इसमें शामिल मुद्दों की आवश्यक समझ है?

हम इस पर काम कर रहे हैं। मुझे पता है कि मैंने पहले भी कहा है, लेकिन हम बेहद करीब हैं (जैसा कि, मैं ब्लॉग को क्राफ्ट कर रहा हूं और आप शायद जल्द ही कुछ नए लेबल दिखाने जा रहे हैं, जिनके साथ हम खेलेंगे)।

मैं हर किसी के धैर्य की सराहना करता हूं और मैं मानता हूं कि समिति से हर दो सप्ताह में जब लोगों को विचार और चर्चा में भारी मात्रा में विचार आ रहे हैं, तो एक तीखा जवाब मिलना कष्टप्रद है। मुझे पता है कि ऐसा लगता है कि हम चीजों के बारे में गहराई से नहीं सोच रहे हैं, लेकिन मुझे लगता है कि हम अपनी चर्चाओं की गहराई को उतना विस्तार से व्यक्त नहीं कर रहे हैं जितना कि यहां लोग करते हैं। अपने स्वयं के बैकलॉग में, मुझे ब्लॉगिंग विषयों का एक पूरा सेट मिला है, जैसे कि कमेटी के भीतर निर्णय लेने के बारे में मेरे विचार से ब्रेकिंग चेंज एक के आसपास है, लेकिन मैंने कभी भी नीचे बैठने और उन्हें पंप करने का मौका नहीं दिया है। लेकिन मैं यहां देख सकता हूं कि शायद लोगों को इसमें बहुत अधिक मूल्य मिलेगा।

आशा है कि मुझे इस चर्चा में बहुत दूर तक रेल नहीं मिली। मैं नहीं चाहता कि यह मुद्दा पूरी तरह से परियोजना के प्रबंधन के बारे में एक मेटा-इश्यू बन जाए, लेकिन मैं चाहता था कि कुछ समझ में आने वाली निराशा को मैं यहां देख सकूं। मुझे लगता है कि अगले सप्ताह कम्युनिटी कॉल में शामिल होने के लिए हमारे साथ इस बारे में अधिक विस्तार से बात करना चाहता हूं (अपने प्रश्नों और विचारों को यहां जोड़ें और मुझे कॉल में उन्हें संबोधित करना सुनिश्चित होगा)।

मेटा-पॉइंट पर बस एक त्वरित टिप्पणी: मैं विचारशील प्रतिक्रिया की सराहना करता हूं, @joeyaiello।

ब्रेकिंग परिवर्तन की गंभीरता के रूप में: निम्नलिखित बयानों पर लगता है:

क्या किसी के पास वास्तव में वास्तविक दुनिया में मौजूद किसी भी मामले का उदाहरण है

बनाम

यह मौजूदा स्क्रिप्ट्स में बेहद प्रचलित है, पहचानने और ठीक करने के लिए भ्रमित करता है

यदि यह पहले से ही प्रचलित है, तो आवश्यक वर्कअराउंड की अजीबता और अस्पष्टता अंततः इसे ठीक करने के लिए और अधिक कारण हैं, विशेष रूप से यह देखते हुए कि हमें मामलों की संख्या बढ़ने की उम्मीद करनी चाहिए।

मुझे एहसास है कि सभी मौजूदा वर्कअराउंड टूट जाएंगे।

यदि इससे बचना सर्वोपरि है, तो यह पूर्व में सुझाया गया तरीका है:

_new ऑपरेटर या फ़ंक्शन_ प्रदान करें जैसे कि ie फ़ंक्शन Native मॉड्यूल से जो समस्या को ठीक करता है, और व्यापक रूप से इसे बाहरी निष्पादकों को लागू करने के लिए एकमात्र विश्वसनीय तरीका के रूप में प्रचारित करता है।

A _function_ जैसे ie लोगों को _minimal fuss_, _as एक स्टॉपगैप_ के साथ सही व्यवहार करने की अनुमति देता है, _language_ को नए वाक्य-विन्यास तत्व (ऑपरेटर) के साथ बोझ किए बिना, जिसका एकमात्र raison d'être होगा एक विरासत बग के आसपास काम करने के लिए भी तय करने के लिए तोड़ दिया:

• स्टॉपगैप सही व्यवहार (_experimental_ सुविधाओं पर कोई निर्भरता) के लिए _officially approed_ एक्सेस प्रदान करेगा।
• जब तक स्टॉपगैप आवश्यक है, तब तक इसे व्यापक रूप से प्रचारित और उचित रूप से प्रलेखित किया जाना चाहिए।

यदि / जब डिफ़ॉल्ट व्यवहार ठीक हो जाता है:

• फ़ंक्शन को केवल इसे स्थगित करने के लिए संशोधित किया जा सकता है, ताकि इसका उपयोग करने वाले कोड को तोड़ने के लिए न हो।
• अब फ़ंक्शन की आवश्यकता के बिना नया कोड लिखा जा सकता है।

इस तरह के एक समारोह यानी लोगों को एक स्टॉपगैप के रूप में न्यूनतम उपद्रव के साथ सही व्यवहार का चयन करने की अनुमति देगा

हम # 13428 के माध्यम से गोद लेने को सरल बना सकते हैं। हम इसे पारदर्शी रूप से इंजन में @ mklement0 की जांच के साथ इंजेक्ट कर सकते हैं।

@Dabombber

मुझे लगता है कि डिफ़ॉल्ट रूप से अपवादों को समायोजित करना वर्तमान स्थिति के समान स्थिति में ले जाने वाला है, जहां लोगों को पावरशेल की "सहायकता" को वापस लाने की आवश्यकता है। यदि अपवाद हैं, तो यह स्पष्ट होना चाहिए कि उन्हें लागू किया जा रहा है।

जो प्रस्ताव मैं पेश कर रहा हूं, उनमें से अधिकांश कॉल "बस काम" करते हैं - वे विंडोज कमांड लाइन अराजकता से उपयोगी सार हैं जो हमें उपयोगकर्ताओं को ढालने के लिए अपनी पूरी कोशिश करनी चाहिए।

न्यायसंगत धारणा यह है कि यह परिरक्षण _legacy_ निष्पादनों के लिए एक बार का प्रयास है, और यह कि नए बनाए गए Microsoft C / C ++ सम्मेलनों का पालन करेंगे।

हालाँकि, ऐसा करना असंभव है; उन लोगों के लिए जिन्हें स्वचालित रूप से समायोजित नहीं किया जा सकता है, --% ।

निजी तौर पर, मैं नहीं चाहता कि किसी दिए गए उपयोगिता foo foo.bat foo.cmd foo="bar none" तर्कों, विशेष रूप से, "foo=bar none" स्वीकार किए बिना, जो कि सम्मेलन-अनुपालन के लिए निष्पादन योग्य हैं।

और मैं निश्चित रूप से विभिन्न अपवादों, जैसे &[bat] लिए एक अलग सिंटैक्स फ़ॉर्म नहीं चाहता
इसके बजाय, --% कमांड लाइन तैयार करने के लिए (विंडोज-ओनली) कैच-ऑल टूल बिलकुल वैसा ही है जैसा आप इसे पास करना चाहते हैं - जो भी लक्ष्य प्रोग्राम की विशिष्ट, अपरंपरागत आवश्यकताएं हैं।

विशेष रूप से, प्रस्तावित आवास निम्नलिखित हैं:

ध्यान दें:

• जैसा कि कहा गया है, वे _on Windows_ केवल आवश्यक हैं; यूनिक्स पर, सभी समस्याओं को हल करने के लिए ProcessStartInfo.ArgumentList का प्रतिनिधि पर्याप्त है।

• कम से कम उच्च स्तर पर, ये आवास अवधारणा और दस्तावेज़ के लिए आसान हैं।

• ध्यान दें कि उन्हें _after_ PowerShell के सामान्य पार्सिंग में, (Windows-only) अनुवाद-से-प्रक्रिया-कमांड-लाइन चरण में लागू किया जाएगा। अर्थात, PowerShell का अपना पैरामीटर पार्सिंग शामिल नहीं होगा - और _shouldn't_ be , @ yecril71pl।

• तब इन आवासों द्वारा कवर नहीं किए जाने वाले वास्तव में विदेशी मामलों को स्वयं उपयोगकर्ताओं द्वारा नियंत्रित किया जाएगा
  --% - या, Native मॉड्यूल स्थापित करने के साथ, ins / Invoke-NativeShell , जिससे कॉल में PowerShell चर और अभिव्यक्ति मान एम्बेड करना आसान हो जाता है।

  • $ # $ 15 $ # $ # $ $ $ $ $ $ $ $ $ $ $ dbea Debug-ExecutableArguments Native ।

आवास की सूची:

• बैच फ़ाइलों के लिए (जैसा कि नोट किया गया है, इस मामले को स्वचालित रूप से समायोजित करने का महत्व हाई-प्रोफाइल सीएलआई की व्यापकता है जो बैच फ़ाइलों का उपयोग करते हैं _ अपने प्रवेश बिंदु_, जैसे az.cmd Azure के लिए)।

  • सभी तर्कों में एंबेडेड दोहरे उद्धरण, यदि कोई हो, "" ( \" ) के रूप में बच गए हैं।
  • कोई भी तर्क जिसमें कोई स्थान नहीं है, लेकिन या तो दोहरे उद्धरण चिह्नों या cmd.exe मेटाचैटर्स जैसे & को दोहरे उद्धरण चिह्नों में संलग्न किया गया है (जबकि डिफ़ॉल्ट रूप से PowerShell केवल दोहरे उद्धरणों में रिक्त स्थान के साथ तर्क संलग्न करता है); उदाहरण के लिए, PowerShell द्वारा a&b रूप में देखा जाने वाला एक शब्दशः तर्क एक बैच फ़ाइल में पारित कमांड लाइन पर "a&b" रूप में रखा गया है।

• उच्च प्रोफ़ाइल सीएलआई के लिए जैसे msiexec.exe / msdeploy.exe और cmdkey.exe (उनके लिए हार्ड-कोडिंग अपवाद के बिना):

  • किसी भी आह्वान में निम्न रूपों का कम से कम एक तर्क शामिल है जो नीचे वर्णित व्यवहार को ट्रिगर करता है; <word> अक्षरों, अंकों और अंडरस्कोर से बना हो सकता है:

    • <word>=<value with spaces>
    • /<word>:<value with spaces>
    • -<word>:<value with spaces>

  • यदि ऐसा तर्क मौजूद है:

    • सभी तर्कों में एंबेडेड डबल उद्धरण, यदि कोई हो, "" ( \" ) के रूप में बच जाते हैं। - https://github.com/PowerShell/PowerShell/pull/13482#issuecomment -677813167 देखें कि हमें ऐसा क्यों करना चाहिए; इसका मतलब यह है कि दुर्लभ घटना में कि <value with spaces> का _embedded_ " चार्ट है। --% का उपयोग किया जाना चाहिए; जैसे,
      msiexec ... --% PROP="Nat ""King"" Cole"
    • केवल <value with spaces> हिस्सा दोहरे उद्धरण चिह्नों में संलग्न है, न कि तर्क के रूप में एक संपूर्ण (बाद में होने वाला पावरशेल - उचित रूप से - डिफ़ॉल्ट रूप से); उदाहरण के लिए, PowerShell द्वारा foo=bar none रूप में देखा जाने वाला एक शब्दशः तर्क प्रक्रिया की कमांड लाइन पर foo="bar none" रूप में रखा गया है (बजाय "foo=bar none" )।
  • ध्यान दें:
    
    
    
    • यदि लक्ष्य निष्पादन योग्य होता है तो _not_ msiexec CLI हो सकता है, कोई नुकसान नहीं होता है, क्योंकि कन्वेंशन-पालन CLIs समझदारी से <word>="<value with spaces>" और "<word>=<value with spaces>" _equivalent_ का विचार करते हैं, दोनों शब्दशः <word>=<value with spaces> प्रतिनिधित्व करते हैं
    
    
    • इसी तरह, निष्पादन योग्य का अधिकांश हिस्सा "" \" साथ " चार्ट से बचने के लिए स्वीकार करते हैं। पावरशेल के अपने CLI, रूबी और पर्ल (_not_) के उल्लेखनीय अपवाद के साथ। पॉवरशेल सीएलआई को बुलाया जा रहा है, तो आवास कम से कम सार्थक है, लेकिन मुझे लगता है कि रूबी और पर्ल भी मुश्किल कोडिंग करेंगे)। https://github.com/PowerShell/PowerShell/pull/13482#issuecomment -+६७,७८,१३,१६७ शो सभी अनुप्रयोगों का उपयोग करें कि कि CommandLineToArgvW WinAPI समारोह _not_ समर्थन करते हैं "" -escaping।
    
    

विंडोज पर अन्य सभी मामलों को ProcessStartInfo.ArgumentList साथ भी संभाला जा सकता है, जो कि Microsoft C / C ++ कन्वेंशन (जिसका विशेष रूप से \" " -सेस्फ़िंग का अर्थ है) लागू होता है।

ie वर्तमान संस्करण से ( 1.0.7 ) Native मॉड्यूल इन आवासों को लागू करता है (टूटे हुए तर्क को ठीक करने के अलावा) , PowerShell संस्करणों के लिए 3 और ऊपर ( Install-Module Native )।

मैं आपको और सभी को यहां आमंत्रित करता हूं कि इसे अपने पेस के माध्यम से इस दावे का परीक्षण करने के लिए कि यह बाहरी निष्पादन योग्य कॉल के विशाल बहुमत के लिए "बस काम करता है"।

वर्तमान में अपरिहार्य सीमाएँ:

• नोट: ये तकनीकी सीमाएँ ie _function_ के रूप में कार्यान्वित की जा रही हैं, (इंजन में एक उचित निर्धारण ही _not_ में ये समस्याएँ हैं):

  • हालांकि $LASTEXITCODE ठीक से प्रोसेस 'एग्जिट कोड' पर सेट है, $? हमेशा $true समाप्त होता है - उपयोगकर्ता कोड वर्तमान में $? स्पष्ट रूप से सेट नहीं कर सकता है, हालांकि यह क्षमता जोड़ रहा है को ग्रीन-लिट किया गया है - https://github.com/PowerShell/PowerShell/issues/10917#issuecomment -550550490 देखें। दुर्भाग्य से, इसका मतलब है कि आप वर्तमान में ie सार्थक रूप से && और || , && , पाइपलाइन-चेन ऑपरेटरों के साथ नहीं कर सकते हैं ।
    हालाँकि, अगर _Borting_ एक नॉनज़रो एग्ज़िट कोड का पता लगाने पर स्क्रिप्ट वांछित है, तो iee रैपर फ़ंक्शन का उपयोग किया जा सकता है।

  • -- एक तर्क के रूप में हमेशा PowerShell पैरामीटर बाइंडर द्वारा "खाया" जाता है; बस इसे _twice_ पास करने के लिए -- का लक्ष्य निष्पादन योग्य ( foo -- -- बजाय foo -- ) पास करना होगा।

  • , साथ एक निर्विवाद टोकन को उद्धृत किया जाना चाहिए, इसे एक सरणी के रूप में व्याख्या किया जाना चाहिए और कुछ तर्क के रूप में पारित किया जाना चाहिए; उदाहरण के लिए, 'a,b' बजाय a,b ; इसी तरह, -foo:bar (कुछ ऐसा है जो किसी नामित PowerShell तर्क की तरह दिखता है) के रूप में '-foo:bar' (यह आवश्यक नहीं होना चाहिए, लेकिन एक बग के लिए बकाया है: # 6360); इसी तरह '-foo.bar must be passed as ' -foo.bar'` (एक और बग, जो बाहरी कॉलगर्ल्स को भी सीधे कॉल को प्रभावित करता है: # 6291)

• मैं फ़ंक्शन को PowerShell _Core_ में मजबूती से काम करने की उम्मीद करता हूं। समय-समय पर _Windows PowerShell_ में परिवर्तन के कारण, ऐसे किनारे मामले हो सकते हैं जिन्हें ठीक से संभाला नहीं गया है, हालांकि मुझे केवल दो के बारे में पता है:

  • msiexec -स्टाइल सीएलआई के लिए आंशिक-उद्धृत आवास संस्करण 3 और 4 में लागू नहीं किया जा सकता है, क्योंकि ये संस्करण पूरे तर्क को दोहरे उद्धरण चिह्नों के अतिरिक्त सेट में लपेटते हैं; हालांकि यह v5.1 में काम करता है।

  • "" -डिफॉल्ट का उपयोग डिफ़ॉल्ट रूप से, समस्याओं के आसपास काम करने के लिए किया जाता है, लेकिन उन मामलों में जहां \" आवश्यक है (PowerShell CLI, पर्ल, रूबी), एक टोकन जैसे 3" of snow गलती से _3_ तर्कों के रूप में पारित कर दिया गया, क्योंकि सभी विंडोज पॉवरशेल संस्करण दोहरे उद्धरण में इस तरह के तर्क को संलग्न करने की उपेक्षा करते हैं; ऐसा लगता है कि गैर-आरंभिक " वर्णों वाले तर्कों के लिए होता है जो किसी अंतरिक्ष वर्ण से पहले नहीं हैं।

Windows 10 पर PowerShell Core 7.1.0-preview.5 से आउटपुट के साथ उदाहरण:

नोट: dbea ( Debug-ExecutableArguments ) फ़ंक्शन का उपयोग यह वर्णन करने के लिए किया जाता है कि बाहरी निष्पादक / बैच फ़ाइलों द्वारा तर्क कैसे प्राप्त होंगे।

वर्तमान, टूटे हुए तर्क:

• एक कन्वेंशन-कंप्लेंट एप्लिकेशन (डिफ़ॉल्ट रूप से पर्दे के पीछे dbea द्वारा उपयोग किया जाता है):

# Note the missing 2nd argument and the effective loss of embedded double quotes,
# due to the embedded " chars. not having been escaped.
PS> dbea -- 'a&b' '' '{ "foo": "bar" }'

2 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <{ foo: bar }>

Command line (helper executable omitted):

  a&b  "{ "foo": "bar" }"

• एक बैच फ़ाइल कॉलिंग:

-UseBatchFile करने के लिए dbea करने के लिए एक सहायक _batch file_ के बजाय तर्कों को नोट करें।

# Note that only *part of the first argument* is passed and that the `&` is interpreted as cmd.exe's
# statement separator, causing `b` to be run as a command (which fails).
PS> dbea -UseBatchFile -- 'a&b' '' '{ "foo": "bar" }'

1 argument(s) received (enclosed in <...> for delineation):

  <a>

'b' is not recognized as an internal or external command,
operable program or batch file.

• msiexec -स्टाइल CLI, cmdkey.exe कॉल करना:

# The call fails, because `cmdkey.exe` requires the password argument to 
# to be quoted exactly as `/password:"bar none"` (double-quoting of the option value only), 
# whereas PowerShell - justifiably - passes `"/password:bar none"` (double-quoting of the whole argument).
PS> cmdkey.exe /generic:foo /user:foo /password:'bar none'

The command line parameters are incorrect.

ie साथ समस्या को ठीक करना:

dbea कॉल में -ie के उपयोग पर ध्यान दें, जो कि ie का उपयोग चालान के लिए करता है।

• एक कन्वेंशन-कंप्लेंट एप्लिकेशन (डिफ़ॉल्ट रूप से पर्दे के पीछे dbea द्वारा उपयोग किया जाता है):

# OK
# Note that the empty 2nd argument is correctly passed, and that \" is used for embedded "-escaping.
PS> dbea -ie -- 'a&b' '' '{ "foo": "bar" }'

3 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <>
  <{ "foo": "bar" }>

Command line (helper executable omitted):

  a&b "" "{ \"foo\": \"bar\" }"

• एक बैच फ़ाइल कॉलिंग:

# OK
# - `a&b` was enclosed in "...", due to the presence of metacharacter `&`
# - "" is used for escaping of embedded " chars.
# Note that `echo %1`, for instance, prints the argument exactly as passed on the command line, including quoting.
# `echo %~1` strips the surrounding double quotes, but embedded escaped ones still print as "".
# However, if you pass these arguments (`%*`) through to convention-compliant CLIs, they are parsed correctly.
PS> dbea -ie -UseBatchFile -- 'a&b' '' '{ "foo": "bar" }'

3 argument(s) received (enclosed in <...> for delineation):

  <"a&b">
  <"">
  <"{ ""foo"": ""bar"" }">

• msiexec -स्टाइल CLI, cmdkey.exe कॉलिंग:

# The call now succeeds, because `ie` ensure the value-only double-quoting that cmdkey.exe requires.
# (Use `cmdkey /del:foo` to remove the credentials again.)
PS> ie cmdkey.exe /generic:foo /user:foo /password:'bar none'

CMDKEY: Credential added successfully.

यह दिखाने के लिए कि वास्तविक कमांड लाइन में dbea माध्यम से मूल्य-केवल डबल-कोटिंग लागू किया गया था:

PS> dbea -ie -- cmdkey.exe /generic:foo /user:foo /password:'bar none'

  <cmdkey.exe>
  </generic:foo>
  </user:foo>
  </password:bar none>

Command line (helper executable omitted):

  cmdkey.exe /generic:foo /user:foo /password:"bar none"

निम्न कोड डेटा हानि का कारण बनता है:

{ PARAM($A) $A } | OUT-FILE A.PS1
PWSH A.PS1 -A:(1,2)

1

@JamesWTherher में एक प्रस्तावित फिक्स है और यह इस मुद्दे में उठाए गए चिंताओं को संबोधित करता है, तो मान्य है

क्या उस प्रस्तावित फिक्स का पुल अनुरोध है? अगर हम पीआर पर टिप्पणी कर सकते हैं तो अच्छा होगा। क्योंकि इसे ठीक करना IMO का जटिल हिस्सा नहीं था। जटिल हिस्सा यह था कि कैसे पीछे की ओर बढ़े। और यह अच्छा होगा, अगर हम देख सकते हैं कि प्रस्तावित फिक्स कैसे हैंडल करता है ...।

यह सुनने के लिए अच्छा है, @ स्टीव-एमएसएफटी - यहाँ चर्चा की गई _all_ समस्याओं के लिए एक तय है? V7.1 के लिए, आखिर? और मैं दूसरी @TSlivede का अनुरोध करता हूं।

@ yecril71pl , यह एक अच्छी खोज है, हालांकि यह वास्तव में पावरशेल के अपने पार्सिंग से संबंधित है (जिसमें बाह्य निष्पादन के लिए _some_ विशेष-आवरण है), न कि कैसे देशी कमांड लाइन का निर्माण किया जाता है _a__ पार्सिंग (जो कि पहले से चर्चा में आने वाली समस्याओं पर आधारित है) से)।

यूनिक्स पर समस्या का एक और अधिक संक्षिप्त विवरण:

PS> printf '<%s>\n' -a:(1,2,3)
<-a:1>
<2>
<3>

यही है, केवल _first_ सरणी तत्व सीधे -a: जुड़ा था, दूसरों को अलग-अलग तर्क के रूप में पारित किया गया था।

तर्कों के साथ संबंधित समस्याएं हैं, जैसे कि __ PowerShell पैरामीटर, लेकिन नहीं हैं:

एक संबंधित समस्या है जो केवल _PowerShell_ कमांड पर कॉल को प्रभावित करती है जो $args / @args : # 6360

• & { $args.Count; $args } -foo:bar पैदावार 2, '-foo:', 'bar'

# 6291 भी है, जो पावरशेल कमांड और बाहरी निष्पादन दोनों को प्रभावित करता है ( . नोट करें)।

• & { $args.Count; $args } -foo.bar पैदावार 2, '-foo', '.bar'

ध्यान देने वाली एक बात यह है कि नंगेपन के हिस्से के रूप में (...) परिणाम सामान्य रूप से (...) के आउटपुट के रूप में होता है, जो कि पूरी तरह से एक _separate_ तर्क बनता है, इसलिए तथ्य यह है कि पहला तत्व _is_ printf में संलग्न है
& { $args.Count; $args.ForEach({ "$_" }) } foo('bar', 'baz') पैदावार 2, 'foo', 'bar baz' , दूसरा तर्क 'bar', 'baz' की कठोरता है।

जब PowerShell को बाहरी निष्पादन योग्य के लिए -A:(1,2) पास करना पड़ता है, तो यह पता चलता है कि -A: एक स्ट्रिंग है और (1,2) एक सरणी है जिसे '1 2' के रूप में मार्शल्ड किया जाना चाहिए। पॉवरशेल आह्वान के मूल सिंटैक्स को संरक्षित करने की कोशिश करता है, इसलिए, यह सब एक साथ रखकर, हमें 'ए: 1 2' मिलता है, जबकि सही परिणाम 'ए: "1 2" होगा। " यह मेरे लिए मार्शलिंग कोड में एक तुच्छ चूक जैसा दिखता है।

मैं यह नहीं कहूंगा, कि @ yecril71pl की विशिष्ट समस्या पार्सिंग से संबंधित है (हालाँकि मैं सहमत हूँ, कि इस समस्या को "कमांडलाइन में सरणी परिवर्तित करने" से कोई लेना-देना नहीं है, जो इस मुद्दे पर चर्चा की गई है)।

जब PowerShell को बाहरी निष्पादन योग्य के लिए -A: (1,2) पास करना होता है, तो यह पता चलता है कि -ए: एक स्ट्रिंग है और (1,2) एक सरणी है

लगभग: -A: एक नामित पैरामीटर है और सरणी उस पैरामीटर का मान है (परीक्षण करने के लिए: सामने - को हटा दें और आप देखें, कि इसे अलग तरीके से उद्धृत किया गया है)। लेकिन समस्या यह नहीं है, कि सरणी को गलत तरीके से एक स्ट्रिंग में बदल दिया गया है - समस्या यह है कि, मूल निष्पादन योग्य तर्क के लिए (लगभग) हमेशा छपते हैं, तब भी जब $ का उपयोग करते हैं और @ और भले ही सरणी (1,2) जैसे अभिव्यक्ति से उत्पन्न हो।

उदाहरण के लिए टेस्ट printf '<%s>\n' -a:('a b',2) : जैसा कि स्ट्रिंग a b में एक ऐसा स्थान होता है जिसे सही ढंग से उद्धृत किया जाता है, लेकिन जैसे ही 2 अगले सरणी तत्व में होता है और सरणी स्प्लिट होती है, 2 पहले तर्क का हिस्सा नहीं है।

लाइन में 170 शक्तियां वर्तमान तर्क मान के लिए एक एन्यूमरेटर प्राप्त करने की कोशिश करती हैं।

IEnumerator list = LanguagePrimitives.GetEnumerator(obj);

यदि list null , तो शक्तिकल्प सूची के प्रत्येक तत्व को जोड़ता है (संभवतः रिक्त स्थान युक्त होने पर) lpCommandLine में।

तत्वों को डिफ़ॉल्ट रूप से रिक्त स्थान ( लाइन 449 ) के साथ अलग किया जाता है। एकमात्र अपवाद यदि सरणी एक शाब्दिक था
( printf '<%s>\n' -a:1,2 )।
फिर पावरप्ले lpCommandLine में उसी विभाजक का उपयोग करने की कोशिश करता है, जिसका उपयोग स्क्रिप्ट लाइन में किया गया था।

जब मैं तैयार होता हूं तो मुझे एक पीआर की उम्मीद होती है। अगर यह 7.1 में आता है, तो हम इसे ले लेंगे, अन्यथा यह 7.2 होगा। पश्चगामी संगतता वह संबोधित कर रहा है। शायद जो कुछ मदद करेगा उसे लिखने में पेस्टर परीक्षण ( testexe -echoargs का उपयोग करके बनाया जा सकता है, जो build.psm1 से publish-pstesttools का उपयोग करके बनाया जा सकता है)।

मैं तैयार होने पर एक पीआर की उम्मीद करता हूं

यह ठीक यही है, जो मैं बचना चाहता था - कृपया वह कोड दिखाएं जो तैयार नहीं है (PR प्रगति में काम के रूप में चिह्नित करें)।

या कम से कम टिप्पणी करें, वह क्या करना चाहता है।

यह अच्छा होगा यदि हम इस बात पर चर्चा कर सकते हैं कि वह

@TSlivede , ध्यान दें कि चूंकि PowerShell _CLI_ को कहा जाता है - एक बाहरी निष्पादन योग्य - -A:(1,2) पार्स _before_ है, यह जानते हुए कि यह टोकन अंततः _ame_ -A पैरामीटर पर बंध जाएगा - ऐसा पैरामीटर _eventually_ खेलने में आता है। समस्या के लिए आकस्मिक है।

@ yecril71pl :

यह पता लगाता है कि -A: एक स्ट्रिंग है

नहीं, यह पार्स करने के दौरान विशेष आवरण है, क्योंकि यह _ PowerShell पैरामीटर की तरह _look होता है।

PowerShell आदेशों के लिए कॉल करने के लिए यह विशेष आवरण होता है, जो $args करता है (साथ ही वास्तविक घोषित पैरामीटर होने के लिए बाध्य है), लेकिन ऐसा होता है _ बाह्य रूप से बाह्य निष्पादन के लिए _ (सामान्य रूप से एक अलग से जुड़ा रहता है) लेकिन केवल संग्रह के मामले में इसका _first_ तत्व)।

यदि आप -- पहले से पास करते हैं, तो आप वास्तव में इस विशेष आवरण से बाहर निकल सकते हैं, लेकिन, निश्चित रूप से, यह -- भी पास होगा, जो केवल _PowerShell_ कमांड के लिए कॉल के लिए निकाला जाता है:

PS> printf '<%s>\n' -- -a:(1,2,3)
<-->   # !! not removed
<-a:>
<1>    # array elements are *all* now passed as indiv. arguments, because (...) output is separate (splatted) argument
<2>
<3>

यदि तर्क _does't_ एक PowerShell पैरामीटर की तरह दिखता है, तो सामान्य व्यवहार ( (...) से आउटपुट एक अलग तर्क बन जाता है) बाहरी निष्पादकों के लिए भी किक करता है (एक _array_ के सामान्य व्यवहार के साथ, बिखर जाने अर्थात बाहरी-निष्पादन योग्य मामले में व्यक्तिगत तर्क)।

# Note: No "-" before "a:" -> output from `(...)` becomes separate argument(s)
PS> printf '<%s>\n' a:(1,2,3)
<a:>
<1>
<2>
<3>

इस व्यवहार को लागू करने के लिए _consistently_ समझ में आता है - एक (...) अभिव्यक्ति एक भाग के रूप में _always_ एक अलग तर्क बनना चाहिए - # 13488 देखें।

सरणी _stringified_ के साथ एकल तर्क '-A:1 2 3' पास करने के लिए, (n निहित) _expandable string_ का उपयोग करें, जिस स्थिति में आपको (...) _and_ - के बजाय $(...) आवश्यकता होगी - आश्चर्यजनक रूप से - वर्तमान में भी "..." :

PS> printf '<%s>\n' "-a:$(1,2,3)"  # quotes shouldn't be needed; `-a:"$(1,2,3)"` would work too.
<a:1 2 3> # SINGLE argument with stringified array.

इस मामले में आपको _shouldn't_ को भी "..." आवश्यकता है - यह फिर से आवश्यक है कि टोकन से संबंधित विसंगतियों के कारण _look_ जैसे पैरामीटर (जो सामान्य रूप से _both_ PowerShell और बाहरी-निष्पादन योग्य कॉल पर लागू होते हैं - # 13489 देखें); यदि वे नहीं करते हैं, तो आपको बोली की आवश्यकता नहीं है:

# Anomaly due to looking like a parameter: $(...) output becomes separate argument
PS> Write-Output -- -a:$(1,2,3)
-a:
1
2
3

# Otherwise (note the absence of "-"): no quoting needed; treated implicitly like 
# "a:$(1,2,3)"
PS> Write-Output -- a:$(1,2,3)
a:1 2 3  # SINGLE argument with stringified array.

तर्क मोड में यौगिक टोकन की दुनिया एक जटिल एक है, जिसमें कई विसंगतियां हैं - # 6467 देखें।

@ SteveL-MSFT

अपने वर्तमान रूप में, testexe -echoArgs केवल उन व्यक्तिगत तर्कों को छापते हैं जो .NET कमांड निष्पादन योग्य कच्ची कमांड लाइन (विंडोज पर) से पार्स करते हैं, न कि रॉ कमांड लाइन से।

इसलिए यह बैच फ़ाइलों के लिए चयनात्मक उद्धरण के साथ आवास का परीक्षण नहीं कर सकता है और msiexec -स्टाइल सीएलआई - यह मानते हुए कि इस तरह के आवास को लागू किया जाएगा, जिसकी मैं दृढ़ता से सिफारिश करता हूं; उदाहरण के लिए, आप यह सत्यापित नहीं कर पाएंगे कि PROP='foo bar' को PROP="foo bar" रूप में पारित किया गया था, मूल्य भाग के चारों ओर दोहरे-उद्धरण के साथ।

हालाँकि, कच्ची कमांड लाइन को प्रिंट करने के लिए, testexe को .NET _Core_ निष्पादन योग्य नहीं होना चाहिए, क्योंकि .NET Core _recreates एक काल्पनिक कमांड लाइन_ है जो एम्बेडेड " लिए हमेशा \" -सुरिंग का उपयोग करता है। " वर्ण।, भले ही "" का उपयोग किया गया था, और आम तौर पर ईमानदारी से प्रतिबिंबित नहीं होता है कि कौन से तर्क दोहरे-उद्धृत थे और जो नहीं थे - पृष्ठभूमि के लिए, https://github.com/ देखें डॉटनेट / रनटाइम / इश्यू / 11305 # जारीकरण -674554010

केवल एक .NET _Framework_- संकलित निष्पादन योग्य Environment.CommandLine में सही कमांड लाइन दिखाता है, इसलिए testexe को उस तरह से संकलित करना होगा (और (वैकल्पिक रूप से) कच्ची कमांड लाइन प्रिंट करें)।

बैच फ़ाइलों के लिए आवास का परीक्षण करने के लिए, एक अलग परीक्षण _batch_ फ़ाइल की आवश्यकता होती है, यह सत्यापित करने के लिए कि 'a&b' "a&b" और 'a"b' "a""b" रूप में पारित हो, के लिए उदाहरण।

.NET फ्रेमवर्क के लिए @ mklement0 संकलन संभव नहीं होने जा रहा है और शायद सही व्यवहार पाने के लिए .NET फ्रेमवर्क के तहत चलने की आवश्यकता होगी। हमने जानबूझकर पीएस रेपो से बाहर के सभी मूल कोड संकलन को हटा दिया है, और मुझे नहीं लगता कि हम इसे वापस जोड़ना चाहते हैं ... एक विकल्प पूर्व-निर्मित देशी टेस्टीओ है (जिसे विंडोज, मैकओएस के लिए संकलित करना होगा, और विभिन्न लिनक्स डिस्ट्रोस (अलग-अलग अल्पाइन की तरह)। टेस्टिउ लिखना आसान है, इसे प्रकाशित करने के लिए सभी काम करने में समय लगेगा ...

वैकल्पिक रूप से, क्या हम केवल लिनक्स / macOS के लिए एक साधारण बैश स्क्रिप्ट पर आर्गन का उत्सर्जन कर सकते हैं?

#!/bin/bash
for i; do
   echo $i
done

और विंडोज पर एक बैच फ़ाइल के साथ कुछ इसी तरह।

एक .js स्क्रिप्ट के साथ नोड का उपयोग करने के बारे में कैसे?

console.log(process.execArgv.join('\n') या जो भी स्ट्रिंग आपको संभालती है
उत्पादन अच्छा लग करना चाहते हैं?

@ cspotcode , कच्ची कमांड लाइन प्राप्त करने के लिए हमें एक WinAPI कॉल की आवश्यकता है।

@ SteveL-MSFT:

विंडोज पर , आप अपने सीएलआई के माध्यम से _Windows PowerShell_ के संकलन को सौंप सकते हैं, जो कि मैं dbea हूं; यहां एक सरल उदाहरण है जो एक .NET _Framework_ निष्पादन योग्य का उत्पादन करता है जो कच्ची कमांड लाइन (केवल), ./rawcmdline.exe गूँजता है:

powershell.exe -noprofile -args ./rawcmdline.exe -c {

  param([string] $exePath)

  Add-Type -ErrorAction Stop -OutputType ConsoleApplication -OutputAssembly $exePath -TypeDefinition @'
using System;
static class ConsoleApp {
  static void Main(string[] args) {
    Console.WriteLine(Environment.CommandLine);
  }
}
'@

}

नमूना कॉल:

PS> ./rawcmdline.exe --% "a&b" PROP="foo bar"
"C:\Users\jdoe\rawcmdline.exe"  "a&b" PROP="foo bar"

_Batch file_ के लिए, जो अपने तर्कों को प्रतिध्वनित करता है, dbea भी मांग पर एक बनाता है ।

यूनिक्स पर , एक सरल शेल स्क्रिप्ट, जैसा कि आपकी टिप्पणी में दिखाया गया है, वास्तव में पर्याप्त है, और आप एक तदर्थ स्क्रिप्ट का उपयोग भी कर सकते हैं

@ पॉवरशेल / पॉवरशेल -कमेटी ने आज इस पर चर्चा की, हम आर्ग्स के अरै को वापस स्ट्रिंग में समेटता है और बस पास कि नई सरणी में ProcessStartInfo में आता है (यह सुनिश्चित करने के लिए कुछ कोड है कि पैरामीटर नाम और मान उचित रूप से मेल खाते हैं)। इसके अलावा, हम स्वीकार करते हैं कि हमें विशेष मामले ज्ञात आदेशों के लिए एक अनुमति की आवश्यकता हो सकती है जो अभी भी प्रस्तावित परिवर्तन के साथ विफल हो जाते हैं और यह कुछ ऐसा है जिसे बाद में जोड़ा जा सकता है।

उन लोगों के लिए, जिन पर ध्यान नहीं दिया जा सकता है: पीआर प्रकाशित किया गया है (डब्ल्यूआईपी के रूप में) और पहले से ही चर्चा की जा रही है: https://github.com/PowerShell/PowerShell/pull/13482

PS, @ स्टीवएल-एमएसएफटी, विंडोज पर कच्ची कमांड लाइन प्राप्त करने के बारे में: बेशक, विंडोज पावरस्ले / .NET _Framework_ के संकलन को प्रत्यायोजित करने का एक विकल्प मौजूदा (_- मंच) कंसोल को बढ़ाने के लिए है (प्लेटफॉर्म-सशर्त) पी / इनवॉइस कॉल GetCommandLine() WinAPI फ़ंक्शन के लिए, जैसा कि नीचे दिखाया गया है।

using System;
using System.Runtime.InteropServices;

namespace demo
{
  static class ConsoleApp
  {
    [DllImport("kernel32.dll")]
    private static extern System.IntPtr GetCommandLineW();

    static void Main(string[] args)
    {
      Console.WriteLine("\n{0} argument(s) received (enclosed in <...> for delineation):\n", args.Length);
      for (int i = 0; i < args.Length; ++i)
      {
        Console.WriteLine("  <{0}>", args[i]);
      }

      // Windows only: print the raw command line.
      if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
      {
        Console.WriteLine("\nCommand line:\n\n  {0}\n", Marshal.PtrToStringUni(GetCommandLineW()));
      }

    }

  }

}

@ SteveL-MSFT

पश्चगामी संगतता वह संबोधित कर रहा है।

मुझे लगता है कि यह आपके बाद के स्पष्टीकरण से निहित है कि ProcessStartInfo.ArgumentList (_verbatim_ के तर्क का एक _collection_ यूनिक्स के रूप में उपयोग करने के लिए है और इसका अनुवाद MS C / C ++ - कन्वेंशन-कंप्लांट कमांड लाइन द्वारा किया गया है। ) का उपयोग किया जाना चाहिए, लेकिन मुझे स्पष्ट रूप से बताएं:

• इस समस्या को ठीक से, एक बार और सभी के लिए, _ पश्चगामी संगतता के लिए कोई भी रियायतें देता है।

• @JamesWTherher का पीआर इस लेखन के रूप में सही रास्ते पर है, केवल समस्या यह है कि खाली तर्क अभी भी पारित नहीं हुए हैं ।

  • एक बार जो संबोधित किया जाता है, फिक्स _Unix_ पर पूरा होता है - लेकिन CLIs के लिए _Windows_ (नीचे देखें) पर महत्वपूर्ण आवास का अभाव है।

हमें विशेष मामले ज्ञात आदेशों के लिए एक अनुमति की आवश्यकता हो सकती है जो अभी भी प्रस्तावित परिवर्तन के साथ विफल हो जाते हैं और यह कुछ ऐसा है जिसे बाद में जोड़ा जा सकता है।

मेरा आपसे आग्रह है कि इसे बाद में बंद न करें ।

_Allowlist_ (विशिष्ट निष्पादन के लिए विशेष-आवरण) के बजाय, सामान्य सामान्य नियम इस स्थान को नियंत्रित कर सकते हैं , @TSlivede के साथ कुछ और चर्चा के बाद ऊपर से परिष्कृत।

ये आवास, जो केवल Windows पर _needed हैं:

• विंडोज पर काम करने के लिए बड़ी संख्या में कॉल ठीक से करेंगे।

• प्रस्तावित about_Native_Calls सहायता विषय में अवधारणा और दस्तावेज़ करना आसान है।

• लागू करने के लिए सीधे हैं - यहाँ एक सबूत-की अवधारणा पॉवरशेल में लिखी गई है, परीक्षणों के साथ ।

विशेष रूप से, ये हैं:

• यूनिक्स की तरह, ProcessStartInfo.ArgumentList का उपयोग डिफ़ॉल्ट रूप से किया जाता है - सिवाय इसके कि निम्न स्थितियों के _one या both_ मिलते हैं, _ कौन सी प्रक्रिया में कमांड लाइन का निर्माण मैन्युअल रूप से किया जाना चाहिए (और ProcessStartInfo.Arguments रूप में सौंपा गया है) वर्तमान में):

  • एक बैच फ़ाइल ( .cmd , .bat ) या cmd.exe सीधे कहा जाता है:
  • उस घटना में, _embedded_ " "" ( \" बजाय) के रूप में बच जाते हैं, और अंतरिक्ष-कम तर्क जिसमें निम्नलिखित cmd.exe मेटाचैटर्स होते हैं डबल-उद्धृत (सामान्य रूप से, केवल तर्क _ रिक्त स्थान_ डबल-उद्धृत हो जाते हैं): " & | < > ^ , ; - यह बैच फ़ाइलों को कॉल करने के लिए मज़बूती से काम करेगा, जो महत्वपूर्ण है, क्योंकि कई हाई-प्रोफाइल CLIs फ़ाइलों को _entry के रूप में उपयोग करते हैं points_।

  • स्वतंत्र रूप से (और संभवतः इसके अलावा), यदि कम से कम एक तर्क जो रेगेक्स से मेल खाता है
    '^([/-]\w+[=:]|\w+=)(.*? .*)$' मौजूद है, ऐसी सभी दलीलें _valial_ को केवल _value भाग के आसपास दोहरे-लागू करना चाहिए (जो : या = अनुसरण करता है)

    • जैसे, PowerShell शब्दशः द्वारा देखे गए msiexec.exe / msdeploy.exe और cmdkey.exe तर्क।
      FOO=bar baz और /foo:bar baz / -foo:bar baz की प्रक्रिया कमांड लाइन पर रखी जाएगी:
      foo="bar baz" या /foo:"bar baz" / -foo:"bar baz" _any_ CLIs जिन्हें खुश करने की इस शैली की आवश्यकता होती है।

  • शब्दशः \ तर्कों में वर्णों को MS C / C ++ सम्मेलनों के अनुसार संभाला जाना चाहिए।

इन आवासों द्वारा _is't_ को क्या कवर किया गया है:

• msiexec.exe (और संभवतः msdeploye.exe भी) _only_ "" _embedded_ " । , जो उपरोक्त नियम _not_ को कवर करेगा - सिवाय अगर आप एक बैच फ़ाइल या cmd /c माध्यम से कॉल करते हैं।

  • यह काफी कम होना चाहिए (जैसे,
    msiexec.exe /i example.msi PROPERTY="Nat ""King"" Cole" ), लेकिन यह शायद इस तथ्य के कारण भी दुर्लभ हो जाता है कि misexec चालान आमतौर पर एक स्थापना के अंत का इंतजार करने के लिए _ हस्त तुल्यकालिक_ होते हैं, जिस स्थिति में आप किसी एक में समस्या से बच सकते हैं दो तरीके:
  • cmd /c start /wait msiexec /i example.msi PROPERTY='Nat "King' Cole' - cmd.exe (तब) कॉल पर भरोसा करते हुए "" -सर्जिंग ट्रिगर करना
  • Start-Process -Wait msiexec '/i example.msi PROPERTY="Nat ""King"" Cole"' - -ArgumentList ( -Args ) का पैरामीटर प्रक्रिया कमांड लाइन के रूप में शब्दशः के माध्यम से एकल स्ट्रिंग तर्क को पारित करता है (भले ही यह पैरामीटर काम करने के लिए कैसे माना जाता है - देखें # 5576)।

• कोई अन्य गैर-पारंपरिक सीएलआई जिसके लिए उपरोक्त आवास पर्याप्त नहीं हैं - मैं व्यक्तिगत रूप से किसी के बारे में नहीं जानता हूं।

दिन के अंत में, हमेशा वर्कअराउंड होता है: cmd /c माध्यम से कॉल करें, या, गैर-कंसोल अनुप्रयोगों के लिए, Start-Process माध्यम से, या --% ; अगर हम ins ( Invoke-NativeShell ) cmdlet प्रदान करते हैं, तो यह एक और विकल्प है; dbea ( Debug-ExecutableArguments cmdlet echoArgs.exe -समान क्षमताओं के साथ, लेकिन बैच फ़ाइलों के लिए मांग पर भी, _diagnose_ समस्याओं में भी मदद करेगा।

ब्रेकिंग चेंज बनाम ऑप्ट-इन के मार्ग के लिए:

• क्या प्रायोगिक विशेषता के रूप में इसे लागू करने का मतलब है कि यदि पर्याप्त रुचि दिखाई गई है कि यह _default_ व्यवहार बन जाएगा और इसलिए एक (nontrivial) ब्रेकिंग राशि में राशि होगी?

• क्या आप यह सुनिश्चित कर सकते हैं कि इस प्रायोगिक विशेषता को व्यापक रूप से प्रचारित किया जाता है, इसके महत्व को देखते हुए?

  • प्रायोगिक विशेषताओं के बारे में एक सामान्य चिंता यह है कि पूर्वावलोकन संस्करणों में उनका उपयोग अक्सर _unwitting_ किया जा सकता है, यह देखते हुए कि _all_ प्रयोगात्मक सुविधाओं को डिफ़ॉल्ट रूप से चालू किया जाता है। हम निश्चित रूप से चाहते हैं कि लोग इस सुविधा के बारे में जानें और इसका उपयोग करें।