मुझे यह विचार पसंद है और यह उपयोगी लगता है, लेकिन लगता है कि यह कहीं अधिक उपयोगी होगा (मैं विशेष रूप से एक डीएसएल के मामले में सोच रहा हूं) अगर मुझे एक भी स्ट्रिंग विस्तार मिल सकता है। इसलिए यदि मैंने अपने PS में cmd.exe संगत स्ट्रिंग बनाया है, तो मेरे पास cmd.exe को स्ट्रिंग वर्बेटिम करने का एक तरीका है। शायद

&n -command $string

यह संभावित रूप से मुझे अपने दुभाषिया को भी निर्दिष्ट करने देगा:

&n -shell /bin/sh -command $string
या
&n -shell cmd.exe -command $string

नाम / ऑपरेटर के संदर्भ में, "&" है! उपयोग में? शबंग में समानता है ("#!")।

$! एक अच्छा सुझाव है!

शेल को केवल कमांड के रूप में निर्दिष्ट करके निर्दिष्ट किया जा सकता है:

&! /bin/sh -c blah

$var विस्तार उस समस्या को पैदा करता है जिसमें $ मूल कमांड / शेल को पारित करने के लिए शाब्दिक होने की आवश्यकता हो सकती है। जिन समस्याओं से बचने की कोशिश करता है उनमें से एक यह है कि लोगों को यह पता लगाने की आवश्यकता है कि सब कुछ ठीक से कैसे बचना है। यदि आपको चर विस्तार की आवश्यकता है, तो आप हमेशा कर सकते हैं:

$mycommand = "/bin/sh ls"
Invoke-Expression "&! $mycommand"

हालाँकि, ऐसे मामलों में जहां आप देशी कमांड के साथ पॉवरशेल को मिक्स करना चाहते हैं, संभवतः वर्तमान सिंटैक्स का उपयोग करना सबसे अच्छा है और बस इस बात से अवगत रहें कि मुझे उस उन्नत उपयोग पर विचार करने के साथ ही सही तरीके से भागने की क्या आवश्यकता है।

$mycommand = "/bin/sh ls"
Invoke-Expression "&! $mycommand"

मुझे विश्वास नहीं हो रहा है कि आपने सिर्फ iex का सुझाव दिया है। :-)

@essentialexch कुछ समय है जहाँ यह उचित है :)

ध्यान दें कि उदाहरण में, उम्मीद है कि उपयोगकर्ता ने निष्पादित करने से पहले $mycommand की सामग्री को ठीक से सत्यापित किया है!

बढ़िया राइटअप और आपके द्वारा बताई गई समस्याओं के लिए एक समाधान निश्चित रूप से आवश्यक है।
मैं खुद --% बारे में नहीं जानता था और दुर्भाग्य से इसे देखकर कभी याद नहीं किया। इसलिए प्रस्तावित &n ऑपरेटर समान खोज समस्याओं से पीड़ित हो सकते हैं और एक चरित्र के साथ एक प्रतीक को जोड़ना मेरे लिए स्वाभाविक नहीं लगता है (और यह सी प्रिंटफ बयानों में% f की याद दिलाता है)। चूँकि यह वैसे भी एक ब्रेकिंग बदलाव है, क्या कोई कारण है कि यह && उदाहरण के लिए नहीं हो सकता है?
हो सकता है कि जिस क्षेत्र को आप निष्पादित करना चाहते हैं, उसे चिह्नित करने के लिए कोष्ठक (या डबल ब्रेसेस?) जैसी किसी चीज़ का उपयोग करना अधिक सहज होगा। उदाहरण: & [ wsl ls ] | less

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

$command = 'linter'
$myargs = @(
    '-config'
    'linterconfig.path'
)
if ($Test) {$myargs += 'test'}
& $command <strong i="7">@myargs</strong>

तो यह सशर्त और मेरे लिए व्हाट्सएप के मामले में सबसे अच्छा तरीका है

@bergmeister मैं मूल रूप से && रूप में सोचता था, क्योंकि यह & के समान है जिसे आज बहुत से लोग जानते हैं। हालांकि, && एक पाइपलाइन श्रृंखला ऑपरेटर होने के कारण भ्रम हो सकता है कि यह क्या करना चाहिए। मुझे वर्तमान में &! सुझाव पसंद हैं।

@JustinGrote , इसका उपयोग जारी नहीं रखने का कोई कारण नहीं है। &! सिंटैक्स वास्तव में उन मामलों के लिए है, जहां आप बस काटना और चिपकाना चाहते हैं या कुछ तर्क देते हैं कि पॉवरशेल सिंटैक्स के साथ संघर्ष और नहीं करना चाहते हैं या ठीक से बचना नहीं जानते हैं

ओह यार, मुझे याद है कि एक दशक पहले ब्रूस और जेसन के साथ इस बारे में चर्चा हुई थी। मेरी आंत की भावना यह है कि किसी अन्य ऑपरेटर का आविष्कार करना यहां अनावश्यक लगता है। मुझे पता है कि इस धागे पर कुछ लोगों ने --% बारे में नहीं सुना है, लेकिन मैं जितना सोचता हूं, उससे कहीं ज्यादा दांव पर लगाऊंगा। क्या गलत है:

# run ls in wsl, return results to powershell, then pipe to wsl again, to grep.
& wsl ls | wsl grep -i "foo"  

#  the entire pipeline right of wsl will run in wsl. 
& --% wsl ls | grep -i "foo"

किसी ने यह सुझाव क्यों नहीं दिया? यह तार्किक रूप से --% कहीं और का उपयोग करने के लिए संगत है "यह कहने के लिए कि इसके बाद सब कुछ विशेष शक्तियों के उपचार के बिना पारित किया जाना है।"

@ अच्छी तरह से एक के लिए, वह आदेश काम नहीं करता है क्योंकि आपको इसे उस कमांड के साथ प्रस्तुत करना होगा जिसे आप चलाना चाहते हैं, क्या आप कार्यक्षमता को जोड़ने का सुझाव दे रहे हैं?

यह थोथा वही करता है जो अपेक्षित है:
function Invoke-LiteralCommand ($command) {Invoke-Expression "& $command --% $args"}

Invoke-LiteralCommand ping -W 200 www.google.com | grep icmp

@JustinGrote हाँ, मुझे पता है कि यह अब काम नहीं करता है :) मैं सुझाव दे रहा हूं कि &n _ &! या जो भी बात की जा रही है। यह सिर्फ मेरे लिए अधिक समझ में आता है: & कॉल है और --% को पावरशेल पार्सिंग दबा रहा है; साथ में वे कुछ नया जोड़ने की तुलना में सुसंगत और अधिक खोज योग्य हैं। मुझे "कॉल" और "कॉल मूल" ऑपरेटर होने का विचार पसंद नहीं है।

मैंने अंतर दिखाने के लिए अपने उदाहरण का विस्तार किया है।

@oising मैं एक नए ऑपरेटर के साथ बहुत अच्छा होगा, हालांकि यह "नई शक्तियां उपयोगकर्ता जो बैश जानता है" के लिए बहुत अधिक टाइप करने वाला है जो मुझे लगता है कि इसका मतलब होगा।

@oising मैं एक नए ऑपरेटर के साथ बहुत अच्छा होगा, हालांकि यह "नई शक्तियां उपयोगकर्ता जो बैश जानता है" के लिए बहुत अधिक टाइप करने वाला है जो मुझे लगता है कि इसका मतलब होगा।

हर्गिज नहीं। यह PowerShell उपयोगकर्ता के लिए है जो PowerShell / cmd.exe / bash के बीच के जटिल उद्धरण नियमों को नहीं समझता है। जैसा कि शीर्षक शीर्षक "देशी को कॉल करता है", देशी निष्पादनयोग्य को कॉल करने के लिए।

@oising मैं एक नए ऑपरेटर के साथ बहुत अच्छा होगा, हालांकि यह "नई शक्तियां उपयोगकर्ता जो बैश जानता है" के लिए बहुत अधिक टाइप करने वाला है जो मुझे लगता है कि इसका मतलब होगा।

हर्गिज नहीं। यह PowerShell उपयोगकर्ता के लिए है जो PowerShell / cmd.exe / bash के बीच के जटिल उद्धरण नियमों को नहीं समझता है। जैसा कि शीर्षक शीर्षक "देशी को कॉल करता है", देशी निष्पादनयोग्य को कॉल करने के लिए।

सच है, या हम में से उन लोगों के लिए जो उनके बारे में बिल्कुल नहीं सोचते हैं।

हाँ मैं @oising के साथ हूँ। यह अवधारणा मौजूद है, यह सिर्फ अपर्याप्त रूप से अपर्याप्त है। अगर हम कुछ नया पूरी तरह से लागू करने जा रहे हैं तो हम पुराने सिंटैक्स को हटाने / हटाने से बेहतर हैं।

मुझे लगता है कि अक्सर इन विचारों को आवाज दी जाती है, न कि उनके वास्तविक लक्ष्य जनसांख्यिकीय को पर्याप्त वजन दिया जाता है। यदि उपयोगकर्ता मौजूदा तरीकों को खोजने के लिए _already_ संघर्ष कर रहे हैं, और मौजूदा तरीकों की कमी है जब वे पाए जाते हैं, तो यह एक है) प्रलेखन में सुधार के लिए एक कॉल है, और बी) मौजूदा ऑपरेटरों की वास्तविक कार्यक्षमता में सुधार करता है।

इसके बजाय हमें एक अजीब विकल्प मिलता है c) जिसे किसी तरह पिछले मुद्दों को संबोधित करना है, जबकि _another_ ऑपरेटर जो अभी प्रलेखन पर भरोसा कर रहा है, जो पहले से

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

पहला सवाल मैं तब करता हूं जब लोगों को पता चलता है कि कुछ करने के 5 तरीके हैं "क्यों 2-3 तरीके हैं जो सचमुच एक ही काम करते हैं, लेकिन साथ ही साथ काम नहीं करते हैं", और मेरा जवाब हमेशा की तरह यह है - - PS टीम _way_ है, जो पिछले एक दशक से सब कुछ सुनिश्चित करने पर केंद्रित है ++ अभी भी काम करता है, जब कार्यक्षमता जोड़ने / सुधारने की कोशिश कर रहा है। यहां हम इसे फिर से देखते हैं, हमारे पास मौजूदा लेकिन अपर्याप्त कार्यान्वयन हैं जिन्हें संशोधन और सुधार की आवश्यकता है, और प्रस्तावित समाधान एक और संभावित अपूर्ण कार्यान्वयन जोड़कर पूल को और मैला करना है।

हम जो कुछ भी शुरू करते हैं उसे पूरा करना चाहिए, फिर से एक और कार्यान्वयन शुरू नहीं करना चाहिए, आईएमओ।

मेरा मानना ​​है कि अगर हम कुछ यूनिक उपयोग के मामलों में इस्तेमाल कर रहे हैं, तो हमें इस पर विचार करना शुरू करना चाहिए या भाषा के मानकीकरण पर विचार करना चाहिए।

आखिरी बात जो मैं चाहूंगा वह भ्रम है कि क्या करना है और क्या करना है। अपनी पूर्णता में।

मैं 3 परिदृश्यों पर विचार करूंगा:

1. पूर्ण विस्तार - वर्तमान पावरशेल व्यवहार।
2. पूर्ण शाब्दिक - कि ओपी में प्रस्तावित है।
3. आंशिक विस्तार - wsl ls $path अभी भी काम करता है

मुझे आश्चर्य है कि कहाँ @ mklement0 टिप्पणियाँ? :-)

मैंने सोचा था कि इस धागे को पढ़ने के शुरू में; महान विचार! लेकिन टिप्पणियों को पढ़ने के बाद यह मुझे सोचने लगा। मैंने हमेशा & कमांड को 'PS मानकों के योग्य नहीं' पाया है और कुछ मुझे 'PERL days' (ugh) की याद दिलाता है। एक और गैर-मानक PS कमांड (संज्ञा-क्रिया नहीं होना) का परिचय देने से मदद नहीं मिलेगी। पुनश्च।

मैं -% पैरामीटर के बारे में नहीं जानता था। मैं समाधान के रूप में @JustinGrote के समान सिद्धांत का उपयोग करता हूं।

पीएस शेल में कमांड काटना / चिपकाना कभी भी मेरी मुख्य 'चीज' नहीं रहा।
क्या हम उन देशी कमांडों को पावरशेल के साथ बदलने के लिए बेहतर नहीं होंगे?
Cmd.exe को पूरी तरह से बदलने के लिए पथ बनाएं ...

मैं मौजूदा कमांड में सुधार करने के लिए वोट करता हूं। और - वास्तव में -% और उपयोग पर कुछ प्रलेखन में सुधार

@iSazonov उपयोग मामला @ स्टीवएल-एमएसएफटी प्रस्ताव कर रहा है कि 'कट पेस्ट' परिदृश्य है। आंशिक विस्तार चीजों को और अधिक कठिन बना देगा जो मुझे लगता है (चीजों के एएसटी पक्ष पर)

"#!" के तुरंत बाद और फिर "!#"। "और!"

हम शायद टोकन में कार्य करने के लिए टोकन एक्सेलेरेटर जोड़ने के लिए देख सकते हैं। यह निम्नलिखित के उपयोग के लिए अनुमति देगा।

Iex -l
या इनवोक-एक्सप्रेशन-लिटरल जो गुजरने से पहले पार्स करना बंद कर देता है।

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

उदाहरण के लिए Get-Help और कुछ भी नहीं दिखाता है। और हमें इसके बारे में_ऑपरेटरों में देखना होगा।

हालाँकि, call_operator के लिए ऐसे अनूठे मामले हैं जिन्हें दस्तावेज़ नहीं मिला है।
& modulename {कमांड}
आपको एक मॉड्यूल में गुंजाइश बनाने की अनुमति देता है। और मुझे यकीन है कि कुछ और भी हैं। लेकिन इस पर खोज इतनी कम है कि मूल दस्तावेज के भीतर इसे खोजना मुश्किल हो जाता है। और समुदाय इसे केवल JSnover के माध्यम से जानता है और एक बात उसने हमें शांत चीजें दिखा दी।

मेरा मानना ​​है कि इस पर जो कुछ भी तय किया गया है वह पूरी तरह से ध्यान में रखने की जरूरत है कि यह "फीचर" एक नए उपयोगकर्ता के दृष्टिकोण से कैसा है, और ध्यान रखें कि नए उपयोगकर्ता Powershell 5 पर इसका उपयोग करने की कोशिश करेंगे, इसके नए के बिना pwsh कोर जानने के लिए नहीं तो खोज बहुत कम है।

मुझे मौजूदा व्यवहार को बदलना अच्छा लगेगा, लेकिन PowerShell में इस तरह के मौलिक एपीआई को बदलने से बहुत सारी चीजें टूट जाएंगी। हम संभवतः एक कॉन्फ़िगरेशन के साथ माइग्रेट करने पर विचार कर सकते हैं।

पीएस 6 जीए जाने से पहले चीजों को एक बार फिर सीधे तोड़ना संभव हो सकता है, लेकिन ईमानदारी से, तब भी यह पिछड़े संगतता के लिए एक गंभीर खतरा होगा (पायथन के print() फ़ंक्शन के विपरीत नहीं)।

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

Cmdline arg पासिंग के साथ सिंक्रोनस इनवोकेशन के लिए, मैं चार प्रकार के तर्क पास कर रहा हूँ:

• वर्तमान व्यवहार, जो विरासत बन जाएगा, जो विंडोज पर CommandLineToArgvW अधीन है और अप्रत्याशित परिणाम हैं
• डिफ़ॉल्ट व्यवहार, जिसे उनके अभिव्यक्ति मूल्य से तर्क पारित करना चाहिए लेकिन सामान्य नंगे टोकन नियमों को लागू करना चाहिए, ताकि > और | अलग-अलग कमांड जैसी चीजें हों। इस मोड में, मूल्य एक उपप्रकार अभिव्यक्ति से लेता है जो Write-Host $val द्वारा प्रदर्शित किया जाना चाहिए
• शब्दशः व्यवहार, जहाँ सभी टोकन को नंगे तार के रूप में व्याख्या की जाती है जब तक कि भागने के टोकन को नहीं देखा जाता है। यह आज --% करने वाला है, लेकिन आदर्श रूप में केवल एक ही अंत टोकन होगा जिसे --% ... %-- तरह एक ही पंक्ति में एम्बेड किया जा सकता है
• बैश रीडलाइन व्यवहार, जहां एक वैकल्पिक, श-उन्मुख एस्केपिंग लॉजिक लागू किया जाता है, जिससे सरल संगतता की अनुमति मिलती है

मुझे लगता है कि दूसरे व्यवहार को एक प्रयोगात्मक विशेषता के रूप में पेश करके और फिर उन्हें स्वैप करके पहले व्यवहार को धीरे-धीरे चरणबद्ध किया जाना चाहिए।

दूसरे और तीसरे व्यवहार में &! और &# या शायद +% ... -% या कुछ जैसे अपने स्वयं के बंधन हो सकते हैं। लेकिन वर्बेटिम मोड के लिए, मुझे लगता है कि एक महत्वपूर्ण पहलू भागने के टोकन को सरल बनाना होगा ताकि अधिक टोकन वर्बेटिम ले जाए। एक हेरेडोक के समान।

यदि अनुरोध केवल कॉपी-पेस्ट परिदृश्य को संबोधित करने के लिए है, जैसे "इस ऑपरेटर के बाद कोई भी पाठ सामग्री ओएस के" डिफ़ॉल्ट शेल "को निष्पादित करने के लिए कॉल करेगी।" shell द्वारा इसे स्पष्ट रूप से क्यों नहीं कहेंगे?
`` `Powerhell
PS> शेल wsl ls | कम से
PS> (शेल wsl ls * .txt) | सलेक्ट-स्ट्रिंग हैलो

यह फोर्थ / एपीएल शैली में क्रिप्टिक ऑपरेटरों की तुलना में अधिक खोज योग्य और पठनीय है।

मैं बिल्कुल नहीं देखता कि यह कैसे # 1995 को हल करेगा: https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -653174261 देखें

इसके अलावा, WSL के साथ समस्या wsl.exe (देखें https://github.com/PowerShell/PowerShell/issues/12975#issuecomment-650353021) के व्यवहार की समस्या है।
(ठीक है, इसमें पॉवरशेल की समस्या है, लेकिन यह # 1995 है)

ओह, और क्या यह लगभग https://github.com/PowerShell/PowerShell/issues/12975 का डुप्लिकेट नहीं है? क्योंकि मैं अनिवार्य रूप से ज्यादातर दोहरा सकता हूं, मैंने वहां जो उल्लेख किया है:

@bitcrazed

समस्या यह है कि कमांड-लाइन को प्राप्त कमांड / स्क्रिप्ट को पास करने के लिए कमांड-लाइन के एक हिस्से का परिसीमन करने की क्षमता की कमी एक ऐसी चीज है जो उपयोगकर्ताओं को हर समय यात्रा करती है।

"वर्बेटिम को पारित करने के लिए कमांड-लाइन के हिस्से" से आपका क्या मतलब है? क्या आपका मतलब है 1. वर्णों के कुछ अनुक्रम को शब्दशः निष्पादित करने के लिए पास करें, जैसे कि निष्पादन योग्य को अपने तर्क सरणी के एक तत्व में वर्णों का यह क्रम है (उदाहरण के लिए उन वर्णों को `argv [1]` में [मुख्य में उपलब्ध है ] (https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=vs-2019#command-line-arguments)) या क्या आपका मतलब है 2. सम्मिलित करना वर्णों के कुछ अनुक्रम में 'क्रिएटप्रोसेसर' के [`lpCommandLine 'पैरामीटर (https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi-nf-processthreadsapi-createprocessw#parameters) पर शब्दशः क्रिया करते हैं। - यदि आपका मतलब (1.) है, तो यह अनिवार्य रूप से पहले से ही काम करता है:

PS /home/User> /bin/echo 'cd / && ls . | cowsay'
cd / && ls . | cowsay
PS /home/User>

(Https://github.com/PowerShell/PowerShell/issues/1995 में चर्चा की गई एम्बेड किए गए उद्धरणों की समस्या को छोड़कर) कोई यह तर्क दे सकता है कि एक-पंक्ति-यहां-स्ट्रिंग को जोड़ने से कुछ usecases में सुधार होगा, लेकिन मुझे लगता है कि यह वास्तव में इस मुद्दे की बात नहीं है। जैसा कि यह पहले से ही अधिक या कम काम करता है, मैं मानता हूं, आप का मतलब है (2.) --- यदि आपका मतलब है (2.), तो मुझे उस पर कुछ हद तक नाटकीय तरीके से अपनी राय बताएं: कृपया कृपया न जोड़ें इसके लिए विशेष वाक्यविन्यास। यह मूल रूप से क्या है - `%` ने ऐसा करने की कोशिश की, जिसे कभी भी लागू नहीं किया जाना चाहिए था। मैं इसके खिलाफ इतनी दृढ़ता से क्यों हूँ? 1. यह एक Windows केवल समस्या है, इसलिए वाक्यविन्यास जोड़ने का मतलब होगा कि Windows पर शक्तियां लिनक्स पर अलग वाक्यविन्यास है। (या वाक्यविन्यास का समर्थन किया जाएगा, लेकिन पूरी तरह से व्यर्थ है, क्योंकि वर्तमान में यह `-%` के लिए मामला है) 2. यदि Microsoft द्वारा प्रकाशित विंडोज पर मुख्य कमांडलाइन शेल में प्रथम श्रेणी की सुविधा (विशेष वाक्यविन्यास के माध्यम से) एक cmdlet) निष्पादन योग्य कॉल करने के लिए जो सामान्य [कमांडलाइन पार्सिंग नियमों] का पालन नहीं करता है (https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view) -2019 # पार्सिंग-सी-कमांड-लाइन-दलीलें) (यदि उपकरण विशिष्ट नियमों का पालन करता है, तो आपको आवश्यकता नहीं है (2.), आप आमतौर पर बेहतर उपयोग (1.) कर सकते हैं, तो यह कमांड लाइन के लेखकों को प्रोत्साहित करता है। उपकरण, इन नियमों का पालन नहीं करने के लिए, जो केवल ["विंडोज कमांड लाइन अराजकता" बिगड़ती है] (https://stackoverflow.com/a/4094897/2770331)। कम लोग ठेठ नियमों का पालन करते हैं, कठिन यह प्रोग्रामेटिक रूप से बाह्य निष्पादन को कॉल करना है या आमतौर पर क्रॉस प्लेटफ़ॉर्म कोड लिखना है, इसलिए मुझे निश्चित रूप से लगता है, उन प्रोग्राम लेखकों को उन विशिष्ट नियमों का पालन करने के लिए प्रोत्साहित किया जाना चाहिए। 3. मुझे पूरी तरह से संदेह है, कि यह एक सामान्य उपयोग-मामला है> और यह सिर्फ एक मुद्दा नहीं है जो WSL को प्रभावित करता है: यह विंडोज टर्मिनल के wt कमांड-लाइन इनवोकेशन, और कई अन्य टूल को भी प्रभावित करता है। क्या आप कुछ उदाहरण जोड़ सकते हैं, जहां ऐसी समस्याएं होती हैं? क्योंकि WSL के मामले में, मैं कहूँगा कि WSL के कमांडलाइन का पार्सिंग बस [टूटा हुआ] है (https://github.com/Microsoft/WSL/issues/1746) (समस्या `bash.exe` के बारे में थी, लेकिन स्थिति यह है डिफ़ॉल्ट रूप से डिफ़ॉल्ट मामले में `wsl.exe`) के साथ बेहतर नहीं है - मैं हर उपकरण पर विचार करूंगा, जो कि विशिष्ट [कमांडलाइन पार्सिंग नियमों] का पालन नहीं करता है (https://docs.microsoft.com/en-us/ cpp / cpp / main-function-command-line-args? view = vs-2019 # पार्सिंग-सी-कमांड-लाइन-दलीलें) टूटी हुई हैं, लेकिन WSL का डिफ़ॉल्ट व्यवहार IMHO भी ठीक से प्रलेखित नहीं है ... मैंने कहा "डिफ़ॉल्ट" "व्यवहार का` wsl.exe` टूट गया है - इस प्रतिक्रिया को लिखते समय, मैंने देखा, कि `wsl.exe` वास्तव में` -`` का उपयोग करते समय अपेक्षित रूप से व्यवहार करने लगता है:

PS C:\> wsl -e bash -c 'cd / && ls . | cowsay'
 _______________________________________
/ acct bin boot cache cygdrive data dev \
| etc home init lib lib64 lost+found    |
| media mnt opt proc root run sbin snap |
\ srv sys tmp usr var                   /
 ---------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
PS C:\>

तो इस स्पष्ट usecase के लिए केवल एक चीज गायब है, जो किसी भी अन्य सामान्य exe के रूप में पार्स किए गए कमांडलाइन तर्कों के साथ डिफ़ॉल्ट शेल को कॉल करने के लिए `wsl.exe` के लिए एक पैरामीटर है।

"कमांड-लाइन के एक हिस्से को प्राप्त कमांड / स्क्रिप्ट के लिए वार्बाटिम पास करने" के बारे में केवल एक चीज, जो इस ऑपरेटर के साथ बेहतर होगी, इसका अर्थ ऊपर (2) होगा, और जैसा कि उल्लेख किया गया है, मुझे लगता है कि उस दिशा में विकास हो रहा है। खराब।

यदि आप सभी करना चाहते हैं तो एक शॉर्टकट है जो मौजूदा कमांड लाइनों को कॉपी और पेस्ट करता है, तो आप एक cmdlet (जैसे Invoke-Shell नहीं जोड़ते हैं, जो linux पर bash -c और cmd /c को कॉल करते हैं खिड़कियाँ?
तब आप बस कर सकते थे

Invoke-Shell @'
whatever existing comandline containg '"quotes"' or whatnot
'@

यदि यह एक पंक्ति होना चाहिए, तो एक-लाइन-यहां-स्ट्रिंग सिंटैक्स जोड़ें, लेकिन कृपया एक विशेष ऑपरेटर को लागू न करें, जो ठीक से नहीं पाया जा सकता है और बस सब कुछ जटिल करता है।

और कृपया इसके लिए # 1995 का त्याग न करें!

+10 अंक शब्द "sigil" का उपयोग करने के लिए।

&! बनाम shell बारे में अच्छी बात यह है कि "शेल" एक सामान्य अंग्रेजी शब्द है, इसलिए लोगों के पास शेल नाम का एक मौजूदा कमांड हो सकता है। (वास्तव में, मेरे पास "शेल" नाम का एक फ़ंक्शन और "एन" नाम का एक फ़ंक्शन है (इसलिए मुझे &n पसंद नहीं है)।

@oising : & --% अच्छा है, प्रस्तावित सुविधा के एक्सप्रेस उद्देश्यों में से एक को छोड़कर इसका मतलब यह है कि | कुछ ऐसा हो जाता है जो देशी शेल को दिया जाता है; ऐसा कुछ & --% के लिए की तुलना में foo $blah --% more args , मुझे लगता है कि विस्मयकारी मिलेगा ... क्या हुआ अगर तुमने किया था & $foo --% more args | blah ? इस प्रकार मेरी राय में, प्रस्तावित &! अलग-अलग है जो इसे एक अलग ऑपरेटर होने का वारंट करता है। (दूसरा तरीका: प्रस्तावित कार्यक्षमता संबंधित है, लेकिन & और --% संयोजन से अलग है।)

यह सुविधा "नए PowerShell उपयोगकर्ता जो बैश जानता है" और "उपयोगकर्ता जो सभी जटिल उद्धरण / नियमों से बचना नहीं जानता है" के लिए अधिक है। यह उपयोगकर्ताओं के सबसे विशेषज्ञ के लिए भी है, जो बस सब कुछ के साथ जाने और बेला के बिना StackOverflow से एक कमांड कॉपी / पेस्ट करना चाहते हैं। यह मेरे लिए काफी हद तक होता है - एक उत्पाद जिस पर मैं काम करता हूं, उसके बारे में बहुत सारे दस्तावेज हैं कि चीजों को कैसे करना है, और लिंगुआ फ्रैंका cmd.exe कमांड है - इसलिए मुझे% VARIABLE_REERENENCES% इत्यादि को ठीक करने के लिए जाना होगा ।; &! टाइप करना और फिर चिपकाना इतना अच्छा होगा। वास्तव में अगर इसे लागू किया जाता है, तो मैं शायद इसे "स्टैकऑवरफ्लो ऑपरेटर" के रूप में संदर्भित करूंगा। : डी

@ vexx32 : यह "उन सभी को कॉल करने के लिए एक रिंग नहीं है" कॉल ऑपरेटर; सामान्य समस्या के समाधान के लिए टूलबॉक्स में सिर्फ एक और उपकरण। मुझे नहीं लगता कि हमें इस एक के लिए जगह बनाने के लिए मौजूदा उपकरणों से छुटकारा पाना चाहिए; वे अलग-अलग काम करते हैं। मैं समझता हूं कि जब टूलबॉक्स में एक हथौड़ा, एक पेचकश, एक ड्रिल, एक प्रभाव ड्रिल, और एक नेलगन होता है, तो नए उपयोगकर्ता अभिभूत महसूस कर सकते हैं ... लेकिन इस तथ्य के बावजूद कि वे एक या एक से अधिक के माध्यम से "एक पोके वाली बात को पोक करने के लिए" हैं। चीजें ", वे एक पेशेवर के लिए अमूल्य हैं; सभी विभिन्न (हालांकि संबंधित) स्थितियों में उपयोग किया जाता है।

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

चाहे एक नए ऑपरेटर के माध्यम से &! या कुछ Invoke-Shell कमांड हो, मेरे पास दूसरों की तरह इतनी मजबूत भावनाएं नहीं हैं ... मुझे लोगों की सहानुभूति है कि शिकायत करने वालों के लिए खोज करना मुश्किल है, आदि लेकिन मुझे वास्तव में &! की मर्यादा पसंद है।

@jazzdelightsme यह "टूलबॉक्स में एक और उपकरण" नहीं है जितना कि "एक पेचकश के लिए एक और अविश्वसनीय रूप से विशिष्ट पेचकश लगाव है जो पहले से ही लगभग 3-5 है जो वर्तमान में पहले से ही _okay_ हैं और मेरी राय में सुधार करने के लिए खड़े हो सकते हैं"।

@jazzdelightsme "विंडोज़ केवल" भाग शायद उस मुद्दे से अधिक संबंधित था जहां मैंने मूल रूप से उस कथन को पोस्ट किया था - हां ठीक है, यह उस मुद्दे का एक सटीक डुप्लिकेट नहीं है।

यदि # 1995 को छोड़ नहीं दिया गया है और यहां मांगी गई सुविधा को विशेष सिंटैक्स के माध्यम से नहीं बल्कि एक कमांडलेट (या शायद एक लाइन के लिए नया सिंटैक्स के माध्यम से हल किया गया है, जो कि इस विशेष मामले के लिए हर जगह काम नहीं करता है) तो मैं वास्तव में इसके पक्ष में हूं इस कार्यक्षमता को जोड़ना। (या शायद "पक्ष में नहीं" लेकिन "यह मेरे लिए पूरी तरह स्वीकार्य है")

एक अन्य विचार: यदि यह मुद्दा वास्तव में पूर्ण कमांड्स की प्रतिलिपि बनाने और चिपकाने के बारे में है जो देशी गोले के लिए थे, तो शायद PsReadLine एक कमांड को बैश या cmd स्टाइल से पावरशेल करने के लिए मोटे तौर पर ट्रांसलेट कर सकता है। यदि किसी कमांड को निष्पादित करने की कोशिश करते समय एक पार्सिंग त्रुटि होती है, तो अनुवाद को एक विशेष कुंजी संयोजन या स्वचालित रूप से ट्रिगर किया जा सकता है।

इससे उपयोगकर्ताओं को सिंटशेल के सिंटैक्स को सिखाने का अतिरिक्त लाभ होगा।

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

लेकिन मैं समझ सकता था कि यह एहसास करने के लिए सिर्फ थोड़ा जटिल था।

@jazzdelightsme ने StackOverflow operator , जिसने मुझे बहुत तंग किया, हालांकि यह बहुत सच है

@ स्टीवएल-एमएसएफटी नहीं, मैंने इस बारे में किसी से बात नहीं की; मैं स्वतंत्र रूप से "स्टैकओवरफ़्लो ऑपरेटर" पर पहुंचा। एक्सडी

@jazzdelightsme

... प्रस्तावित सुविधा के एक्सप्रेस प्रयोजनों में से एक को छोड़कर इसका मतलब है कि | कुछ ऐसा हो जाता है जो देशी खोल में पारित हो जाता है; ऐसा कुछ नहीं जो आपको PowerShell पार्सिंग में वापस लाए।

मुझे यकीन नहीं है कि आपने मेरा सुझाव समझ लिया है; आप जो कह रहे हैं वह स्पष्टतः मैं क्या कह रहा हूं। मुझे कुछ रणनीतिक रूप से पूंजीगत संकेतों के साथ अधिक क्रियाशील होने दें: डी

# NON-OPTIMAL SOLUTION: run "ls" in wsl, return results to powershell, then pipe to wsl again, to "grep."
& wsl ls | wsl grep -i "foo"  

# NEW SOLUTION: the entire pipeline/string, INCLUDING THE PIPE SYMBOL, right of wsl will be executed in wsl. 
& --% wsl ls | grep -i "foo"

# NEW SOLUTION: the entire pipeline AS ABOVE is sent to WSL, then the results are returned to powershell
# and piped, in powershell, to foreach-object
(& --% wsl ls | grep -i "foo") | % { "match {0}" -f $_ }

# NEW SOLUTION: allow placing --% beyond first argument
# pass everything right of --% to the command in $wsl 
$wsl = gcm wsl
& $wsl --% ls | grep -i "foo"

# or

& wsl --% ls | grep -i "foo"

# NEW SOLUTION: execute multiline pasted code without powershell parsing.
& --% @'
(pasted multiline code)
@'

मुझे यहां क्या समझ नहीं आ रहा है? यदि पाइप --% बाद दिखाई देता है तो यह सिर्फ एक और गूंगा चरित्र है: एक तर्क। ऑपरेटर पूर्वता के साथ कोई जुड़ाव नहीं है। यदि एक नेस्टेड पाइप लाइन या सब-डेप्रिसिशन में निहित है, तो फिर से पॉवरशेल के लिए पार्स करना शुरू करें।

क्या होगा अगर आपने & $ foo -% अधिक args | blah?

खैर, यह $foo में तर्क को निष्पादित करने का प्रयास करेगा और "more" , "args" , "|" और "blah" जो कुछ भी माना जाएगा; $foo चाहता है। नियम मुझे काफी सरल लगते हैं, लेकिन माना जाता है कि मैं लंबे समय से पॉवरशेल / मोनड का उपयोग कर रहा हूं। यह किसी भी अन्य तर्क की तरह & & $foo --% ... व्यवहार नहीं करता --% रूप में एक बड़ा ब्रेकिंग परिवर्तन नहीं है। इसलिए जब तक हम इस सतर्कता का इस्तेमाल कहीं और नहीं करते, तब तक हमें सुरक्षित रहना चाहिए।

विचार?

मैंने --% आंशिक रेखा मूल्यांकन, बहुस्तरीय मूल्यांकन और परिवर्तनीय स्थिति को कवर करने के लिए, उपरोक्त कई संपादन किए। सभी नए सिगिल, ऑपरेटरों या अजीब वाक्यविन्यास को पेश किए बिना। मेरा मानना ​​है कि वह इसे कवर करता है। केवल एक चीज है: क्या पार्सर इसे संभाल सकता है? आपको क्या लगता है @lzybkr @JamesWTruher @BrucePay ?

सुन, सुन, @TSlivede।

मुझे कुंद करने के लिए क्षमा करें, लेकिन हम इन मुद्दों के बारे में बात कर रहे हैं:

क्या यह मुद्दा जादुई सोच के लिए राशि का प्रस्ताव करता है:
यह अशुभ, स्वाभाविक रूप से समस्याग्रस्त "स्टॉप-पार्सिंग सिंबल", --% , जो अपने वर्तमान स्वरूप में सीमित उपयोग _on Windows_ (देखें https://github.com/MicrosoftDocs-PowerShell- डॉक्स / मुद्दे / 6149) और _Unix जैसे प्लेटफार्मों पर लगभग बेकार है (देखें https://github.com/MicrosoftDocs/PowerShell-Docs/issues/4963)।
--% को कभी भी लागू नहीं किया जाना चाहिए, और न ही इस प्रस्ताव को प्रस्तुत किया जाना चाहिए।

जादुई सोच दो विचारों का एक उलझन से भरा हुआ संगम है:

• (ए) "मैं कुछ बाहरी कार्यक्रमों के लिए अंतरिक्ष-अलग टोकन को पारित करना चाहता हूं, बिना किसी नंगे पासवर्ड की अनुमति के, बिना शेल मेटाचैकर जैसे & या | ।" - https://github.com/PowerShell/PowerShell/issues/12975#issuecomment-646276628 देखें

  • बेशक, इस तरह की सुविधा इस तरह के आदेशों का उपयोग करने के साथ बाधाओं पर होती है _ पाइपलाइन का एक हिस्सा _ या पाइपलाइन-चेनिंग ऑपरेटरों_ ( && और || ) के साथ, और एक ही पंक्ति पर अतिरिक्त आदेश रखने के साथ भी। ; बाद

• (बी) "मैं चाहता हूं कि मेरी कमांड लाइन उस तरीके का इलाज करे जिसका उपयोग मैं उस शेल से करता हूं जिसे मैं सामान्य रूप से उपयोग करता हूं (या शेल जिसके लिए कमांड लाइन मूल रूप से लिखी गई थी)", जो निश्चित रूप से, _is_ वर्णों के उपयोग के अधीन नहीं है जैसे & या | मेटाचैटर्स के रूप में व्याख्या की जा रही है और इसलिए _syntactic_ अर्थ है।

  • बिंदु में मामला: न तो cmd और न ही /bin/sh (या किसी भी POSIX- जैसे शेल जैसे कि bash ) wsl ls | less इस तरह से स्वीकार करेंगे कि ls , | , और less _verbatim_ के माध्यम से wsl - वे सभी _ _quoted_ | _theirir और पाइप प्रतीक के रूप में व्याख्या करेंगे।

ये विचार एक-दूसरे पर हैं, और अलग-अलग समाधानों की आवश्यकता है - जिनमें से किसी के लिए विशेष वाक्यविन्यास की आवश्यकता नहीं है:

• (A) का समाधान _abandon_ के लिए है और विचार के बजाय _PowerShell का स्वयं, मौजूदा सिंटैक्स_ का उपयोग करना है ताकि यह सुनिश्चित हो सके कि मेटाचैकर्स का उपयोग _verbatim_ - किया जाता है, जो अनिवार्य रूप से _quotat_ या _esformation_ ,:

  • या तो: नंगे पासवर्ड (उद्धरणों में टोकन नहीं हैं) जिसमें मेटाचैकर्स होते हैं _as a__: wsl ls '|' less
  • या: ` -चेक मेटाचैकर्स _individually_ नंगे पासवर्ड में: wsl ls `| less
  • या: तर्कों को पारित करने के लिए एक _array [चर] _ का उपयोग करें _verbatim_: $wslArgs = 'ls', '|', 'less'; wsl $wslArgs
  • बेशक, # 1995 प्रदर्शित करता है कि, अफसोस की बात है, यह दृष्टिकोण है और हमेशा टूट गया है जब यह उन तर्कों की ओर आता है जिनके पास _embedded_ " _when को बाह्य प्रोग्रामों को कॉल करना होता है - - _this को संबोधित करने की जरूरत है__ नीचे देखें

• (B) का हल वास्तव में _call है जिसे मैं आमतौर पर use_ करता हूं, कमांड लाइन _as सिंगल स्ट्रिंग_ पास करता है।

  • जैसा कि @TSlivede सुझाव देता है, एक Invoke-Shell cmdlet जिसे आप कमांड लाइन पास करते हैं _ एक सिंगल स्ट्रिंग_ और जिसे _platform- देशी शेल_ कहते हैं वह समाधान है - और हमारे पास पहले से ही वर्बिसिम स्ट्रिंग्स ( '...' लिए वाक्यविन्यास है। @'<newline>...<newline>'@
  • मेरी सिफारिश है कि इसे यूनिक्स-जैसे प्लेटफार्मों पर Invoke-NativeShell , और /bin/sh - न कि bash - कॉल करें।
    
    
    
    • इसके अतिरिक्त, मेरा सुझाव है कि एक रसीद उपनाम के रूप में ins को परिभाषित किया जाए।
    
    
  • यह दृष्टिकोण --% और हाथ में प्रस्ताव के साथ सभी वैचारिक समस्याओं को हल करता है:
    
    
    
    • यह बहुत स्पष्ट करता है कि जहां कमांड देशी शेल में जाती है (_ए सिंगल स्ट्रिंग_ होने के कारण) समाप्त होती है, और यह एक रेगुलर पॉवरशेल पाइपलाइन में Invoke-NativeShell / ins कॉल की अनुमति देता है। अस्पष्टता के बिना PowerShell पुनर्निर्देशन।
    
    
    • आप कमांड लाइन में _PowerShell_ वैरिएबल मान (कुछ ऐसा है जो --% नहीं कर सकते हैं) को एम्बेड करने के लिए आप वैकल्पिक रूप से _expandable_ string ( "...." या इसके स्ट्रिंग संस्करण) का उपयोग कर सकते हैं।
    
    

चूँकि जो शक्तियाँ समाप्त हो चुकी हैं, # 1995 को तय नहीं किया जा सकता है कि पिछड़े पिछड़ेपन को तोड़ा जा सकता है - आखिरकार, सभी मौजूदा वर्कआर्ड टूट जाएंगे, https://github.com/PowerShell/PowerShell/issues/1995##uecomment-562334606 - देखें सबसे अच्छी बात यह है कि हम सिंटैक्स के साथ उचित व्यवहार में ऑप्ट-इन का समर्थन कर सकते हैं जो जितना संभव हो उतना उपयुक्त है, ताकि आपके व्यवहार से बाहर निकलने के लिए अपने रास्ते से बाहर होने के दर्द को कम से कम किया जाए जो हमेशा होना चाहिए था चूक।

इसलिए: विशेष सिंटैक्स जैसे &! केवल ऑप्ट-इन के रूप में प्रदान किया जाना चाहिए ताकि बाहरी कार्यक्रमों के तर्क को उचित रूप से प्राप्त किया जा सके, ताकि # 1995 के RFC में प्रस्तावित व्यवहार के आधार पर लगाया जा सके । https://github.com/PowerShell/PowerShell-RFC/pull/90। यदि भविष्य में पॉवरशेल संस्करण को कभी पिछड़ी संगतता को तोड़ने की अनुमति दी जाती है, तो यह & साथ प्रत्यक्ष आह्वान / मंगलाचरण है जो इस व्यवहार को प्रदर्शित करना चाहिए।

एक उपयोगकर्ता के दृष्टिकोण से, इसका मतलब है: मुझे केवल इतना करना है कि _PowerShell_ के सिंटैक्स आवश्यकताओं को पूरा करना है - https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -640711192 देखें - और मैं PowerShell पर भरोसा कर सकता हूं लक्ष्य कार्यक्रम के माध्यम से परिणामी शब्दशः टोकन को मजबूत रूप से पास करें - _थिस किसी भी शेल का एक मुख्य जनादेश है, जिसे PowerShell ने बाहरी प्रोग्रामों के संबंध में अफसोसजनक रूप से कभी संतुष्ट नहीं किया है।

उदाहरण के लिए, निम्नलिखित कमांड - जो वर्तमान में _not_ काम करता है जैसा कि (जब सीधे या & -साथ यह डॉक्स मुद्दा देखें) - तब काम करना चाहिए:

PS> &! bash -c 'echo "one two"'
one two   # Currently (invoked with & instead of &! or with neither) prints only 'one', 
          # because PowerShell passes the entire argument (brokenly) as  "echo "one two"",
          # which the target program sees as *2* verbatim arguments `echo one` and `two`

वर्तमान / पुराने PowerShell संस्करणों में वर्कअराउंड की तलाश करने वालों को एक साधारण फ़ंक्शन मिल सकता है जो https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -30333359 (https: // पर चर्चा की गई सीमाओं) पर अधिकांश उपयोग के मामलों को कवर करेगा। github.com/PowerShell/PowerShell/issues/1995#issuecomment-649560892), और https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606 पर अधिक विस्तृत संस्करण।

पुनश्च: (केवल प्रतीक-आधारित नहीं) ऑपरेटरों की खोज समस्या एक अलग समस्या है जो अपने आप में अच्छी तरह से संबोधित करने योग्य है: समाधान _enhance Get-Help को ऑपरेटर लुकअप की अनुमति देने के लिए है - # 11339 देखें, जो भी एक अंतरिम समाधान के लिए लिंक।

चूँकि जो शक्तियां यह निष्कर्ष निकालती हैं कि # 1995 को निश्चित नहीं किया जा सकता है, पिछड़े हुए अनुकूलता को तोड़ा जा सकता है - आखिरकार, सभी मौजूदा कार्य-खंड टूट जाएंगे, # 1995 (टिप्पणी) देखें - सबसे अच्छी बात यह है कि हम ऑप्ट-इन का समर्थन कर सकते हैं एक वाक्यविन्यास के साथ उचित व्यवहार जो जितना संभव हो उतना संक्षिप्त है, ताकि अपने व्यवहार से बाहर निकलने के दर्द को कम करने के लिए उस व्यवहार को प्राप्त करें जो हमेशा डिफ़ॉल्ट होना चाहिए।

@ mklement0 मुझे लगता है कि ऑप्ट-इन https://github.com/PowerShell/PowerShell/issues/1995 का एक हिस्सा था और इसे अस्वीकार कर दिया गया था। तो मेरे लिए यह इच्छाधारी सोच जैसा लगता है। क्या मै गलत हु?

@AndrewSav , हमने मूल रूप से केवल कॉन्फ़िगरेशन या वरीयता चर के माध्यम से ऑप्ट-इन पर चर्चा की।

हालाँकि, @joeyaiello ने https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -653164987 में निम्नलिखित बात कही, जब उन्होंने मुद्दा बंद कर दिया (जोर जोड़ा):

हम यहां जो कुछ भी छूते हैं, वह सिर्फ एक ब्रेकिंग परिवर्तन का बहुत अधिक है, और हमें एक नए ऑपरेटर के साथ समस्या का समाधान करना चाहिए

एक नया ऑपरेटर _is_ एक प्रकार का ऑप्ट-इन है, लेकिन एक अप्रमाणिक है, मुझे उम्मीद है (हालांकि इसके लिए आवश्यकता दुर्भाग्यपूर्ण है, लेकिन यह पिछड़ी संगतता की कीमत है)।

जबकि यह प्रस्ताव # 1995 को भी स्पष्ट रूप से हल करता है, यह नहीं बताता है कि इसका उद्देश्य (मुख्य रूप से) _other_ गोले के सिंटैक्स को समायोजित करना है। यह देखते हुए कि दोनों समस्याएं हल करने लायक हैं, स्वतंत्र रूप से, मेरा प्रस्ताव यह था:

• चलिए एक नए ऑपरेटर का परिचय देते हैं, लेकिन इसका उपयोग केवल # 1995 (https://github.com/PowerShell/PowerShell-RFC/pull/90 के माध्यम से) को ठीक करने के लिए करते हैं, अर्थात PowerShell के _own_ (गैर-अन्य-शेल-इम्यूलेटिंग) को ठीक करने के लिए बाहरी कार्यक्रमों को पास करने वाले तर्क को संभालना।

  • नए कोड को हमेशा बाहरी कार्यक्रमों को कॉल करते समय & बजाय &! (या जो भी रूप हम तय करते हैं) का उपयोग करना चाहिए (आप इसे बाहरी कार्यक्रमों के लिए & के रूप में चित्रित कर सकते हैं) ।
  • _PowerShell_ कमांड को कॉल करते समय, &! को & तरह कार्य करना चाहिए (अब कभी कोई समस्या नहीं थी), जिससे &! के लगातार उपयोग को सक्षम किया जा सके।

• पुन: उपयोग-कमांड-लाइन्स-फ्रॉम-अदर-शेल की समस्या को हल करने के लिए, आइए एक उपयुक्त Invoke-NativeShell / ins cmdlet प्लेटफ़ॉर्म-उपयुक्त देशी शेल ( cmd /c को कॉल करें , /bin/sh -c यूनिक्स जैसे प्लेटफार्मों पर) कमांड लाइन के साथ एक _single string_ के रूप में पारित किया गया।

  • सरलतम मामले में, कमांड लाइन में ' मौजूद होने के साथ, एक नियमित एकल-उद्धृत स्ट्रिंग काम करेगा; उदाहरण के लिए:

    ins 'ls | बिल्ली

  • ' वर्तमान के साथ, वे या तो _doubled_ हो सकते हैं; उदाहरण के लिए:

    ins 'गूंज' 'हाय' | बिल्ली

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

    ins @ '
    गूंज 'हाय' | बिल्ली-एन
    '@

  • इसके अतिरिक्त, _expandable_ (प्रक्षेप) स्ट्रिंग ( "..." या @"<newline>...<newline>"@ ) का उपयोग करके, आपके पास मूल शेल में उत्तीर्ण स्ट्रिंग में _PowerShell_ चर को शामिल करने का विकल्प होता है (कुछ ऐसा है जो --% समर्थन नहीं करता है):

    $ फू = 'हाय'
    ins @ "
    गूंज '$ फू' | बिल्ली-एन
    "@

  • ध्यान दें:

    • Invoke-NativeShell cmdlet cmd /c / /bin/sh -c कॉल्स के आसपास एक काफी पतला आवरण होगा, जिसे आप स्पष्ट रूप से सीधे स्वयं बना सकते हैं, लेकिन इसमें वह लाभ है जिसकी आपको आवश्यकता नहीं है विशिष्ट निष्पादन योग्य नाम और कमांड-लाइन पासिंग सिंटैक्स को जानें।
    • संभावित रूप से लाभकारी साइड इफेक्ट के रूप में, आप -OutVariable जैसे सामान्य मापदंडों का उपयोग करने में सक्षम होंगे, और यह सोच सकते हैं कि -Error* पैरामीटर _stderr_ पर कार्य करें (हालांकि, समरूपता के लिए, Invoke-Command भी चाहिए, जो कि एक परिवर्तन होगा)।
      
      
      
      • चूँकि POSIX जैसे गोले -c साथ _multiple_ तर्कों का समर्थन करते हैं - सबसे पहले कोड को निष्पादित करने के लिए, और बाद वाले लोग उस कोड को पास करने के लिए तर्क देते हैं, जिसकी शुरुआत $0 (!) से होती है - उदा bash -c 'echo $@' _ 1 2 3 - वैकल्पिक अतिरिक्त तर्कों का भी समर्थन किया जाना चाहिए।
      
      
      • चूँकि प्लेटफ़ॉर्म-देशी शेल को कॉल किया जा रहा है, cmd और sh बीच मूलभूत अंतर के कारण, इस तरह की कॉल्स परिभाषा _not_ पोर्टेबल द्वारा होती हैं।यही कारण है कि PowerShell के _own_ तर्क-पासिंग (# 1995) को ठीक करना इतना महत्वपूर्ण है, क्योंकि यह तब बाहरी कार्यक्रमों को लागू करने का एक विश्वसनीय, सही-प्लेटफ़ॉर्म तरीका प्रदान करता है।
      
      

पहेली का अंतिम टुकड़ा _documentation_ है।

https://github.com/MicrosoftDocs/PowerShell-Docs/issues/5152 बाहरी कार्यक्रमों को कॉल करने के बारे में एक वैचारिक सहायता विषय लिखने का एक लंबा प्रस्ताव है (उदाहरण के लिए, about_Native_Calls ), जिसे एक ही स्थान पर, चाहिए कवर _all_ पहलू जो बाहरी कार्यक्रमों को कॉल करने के लिए प्रासंगिक हैं; एक तरफ जो पहले से ही कवर किया गया है (अतिरिक्त मेटाचैटर के कारण सिंटैक्स नुकसान, एक कच्ची बाइट पाइपलाइन की अनुपस्थिति, पावरशेल त्रुटि से निपटने के लिए गैर-एकीकरण, ...), हाथ में मुद्दों पर भी चर्चा की जानी चाहिए:

• एम्बेडेड " (और _empty_ तर्क) के साथ तर्क कैसे पारित हो रहे हैं (उम्मीद है कि जल्द ही होने वाली है) पिछले संस्करणों (वर्तमान में एक अलग प्रस्ताव, https://github.com/MicrosoftDocs/PicShell-Docs में चर्चा की गई) में टूट गया है / मुद्दों / 2361), और उस के आसपास कैसे काम करें (मैनुअल \ -शरीर या # 1995 के सहायक कार्यों में से एक का उपयोग, जिनमें से एक पर्याप्त रूप से सीधे विषय में शामिल होने के लिए पर्याप्त है)।

• कैसे केवल &! का उपयोग मूल (बाहरी) निष्पादन योग्य को कॉल करने के लिए किया जाना चाहिए, ताकि उचित तर्क-पास सुनिश्चित हो सके।

• कैसे Invoke-NativeShell / ins का उपयोग कमांड लाइनों को निष्पादित करने के लिए किया जा सकता है _ प्लेटफ़ॉर्म-देशी शेल_ के लिए लिखित है।

दिलचस्प है, आज उपयोगकर्ता कर सकते हैं:

1. प्रत्यक्ष आह्वान
2. & ऑपरेटर
3. प्रारंभ प्रक्रिया

यह बिल्कुल स्पष्ट नहीं है कि उपयोगकर्ताओं को उपयोग करना चाहिए।

टूटे हुए व्यवहार को ठीक करने के बाद उपयोगकर्ताओं में निम्नलिखित विशेषताएं होंगी:

1. प्रत्यक्ष आह्वान
2. & ऑपरेटर
3. प्रारंभ प्रक्रिया
4. और! ऑपरेटर
5. स्टार्ट-ProcessV2

क्या यह ping 127.0.0.1 चलाने के लिए शेल के लिए बहुत अधिक नहीं है?

हाँ, यह मेरा मुख्य चिंता है कि अभी तक एक और ऑपरेटर @iSazonov को जोड़ने के साथ। यह पहले से ही भ्रमित है, और यह मदद नहीं करेगा। दस्तावेज़ीकरण केवल पहेली का एक हिस्सा है। यहां तक ​​कि अगर हमारे पास सभ्य दस्तावेज हैं, तो यह तथ्य कि इसे करने के लिए अलग-अलग तरीके हैं, जिनमें से प्रत्येक थोड़ा अलग व्यवहार करता है, हमेशा भ्रम पैदा करेगा।

यदि हम UX के बारे में परवाह करते हैं, तो हमें अभी और अधिक जोड़ने के लिए मौजूदा मामलों में सुधार करने का विकल्प होना चाहिए।

यदि हम UX के बारे में परवाह करते हैं, तो हमें अभी और अधिक जोड़ने के लिए मौजूदा मामलों में सुधार करने का विकल्प होना चाहिए।

जो आप नहीं कर सकते क्योंकि आप पिछड़े संगत होना चाहिए। मुझे लगता है कि हम हलकों में जा रहे हैं। https://github.com/PowerShell/PowerShell/issues/1995 वह था और इसे उसी कारण से बंद कर दिया गया था।

@iSazonov :

मार्गदर्शन की मौजूदा कमी को दूर करने की जरूरत है, भले ही हम एक नए ऑपरेटर का परिचय न दें:

• बड़े पैमाने पर, प्रस्तावित about_Native_Calls विषय के माध्यम से

• Start-Process विषय विशेष रूप से, जिसमें वर्तमान में किसी भी मार्गदर्शन का अभाव है जब वह उपयोग करना उचित है - https://github.com/MicrosoftDocs/PowerShell-Docs/issues/6239 देखें

संक्षेप में संक्षेप में कहें:

• _Console_ (टर्मिनल) कार्यक्रमों को लागू करने के लिए Start-Process उपयोग न करें (जब तक - जो केवल विंडोज पर उपलब्ध है - आप उन्हें चलाना चाहते हैं _ एक नई विंडो_)।

• & माध्यम से प्रत्यक्ष आह्वान और मंगलाचरण _equivalent_ हैं; (स्क्रिप्ट ब्लॉक को एक तरफ छोड़कर), & केवल कभी भी _syntactic_ कारणों के लिए आवश्यक है, जब भी कमांड का नाम या पथ _quoted_ और / या _variable Reference_ होता है।

टूटे हुए व्यवहार को ठीक करने के बाद उपयोगकर्ताओं में निम्नलिखित विशेषताएं होंगी:
प्रत्यक्ष आह्वान

• & ऑपरेटर
• प्रारंभ प्रक्रिया
• और! ऑपरेटर
• स्टार्ट-ProcessV2

• नहीं, कोई Start-ProcessV2 , बस एक _new पैरामीटर_, -IndividualArguments - https://github.com/PowerShell/PowerShell/issues/5576#issuecommentment -552124719 देखें

• हां, &! (या जो भी प्रतीक हम तय करेंगे) होगा, लेकिन यह प्रभावी रूप से _supersedes दोनों & और प्रत्यक्ष मंगलाचरण (कम से कम _external कार्यक्रमों के लिए), लेकिन आप इसका उपयोग करने में सक्षम होंगे _all_ कमांड फॉर्म के साथ) - जिसे संवाद करना आसान होना चाहिए।

क्या यह ping 127.0.0.1 चलाने के लिए शेल के लिए बहुत अधिक नहीं है?

ping 127.0.0.1 काम करना जारी रखेगा, लेकिन यदि आप bash -c 'echo "one two"' काम करना चाहते हैं, तो आपको उपयोग करना होगा
&! bash -c 'echo "one two"'

यह दुर्भाग्यपूर्ण है, लेकिन - यह देखते हुए कि सीधे मंगलाचरण / & व्यवहार _नोट नहीं होना चाहिए - यह मुझे सबसे अच्छा समाधान के रूप में प्रभावित करता है।

सौभाग्य से, यह याद रखने का एक सरल नियम है: _ यदि आप बाह्य कार्यक्रमों के लिए पूर्वानुमानित तर्क चाहते हैं, तो &! _ का उपयोग करें

ऑप्ट-इन - कॉन्फ़िगरेशन के वैकल्पिक रूप ( powershell.config.json माध्यम से) या एक प्राथमिकता चर - बहुत अधिक समस्याग्रस्त हैं:

• वरीयता चरों की डायनामिक स्कोपिंग अनजाने में ऑप्ट इन-लिगेसी कोड लागू करना आसान बना देती है जो इसके लिए डिज़ाइन नहीं किया गया था - देखें https://github.com/PowerShell/PowerShell/issues/1995#ississecomment-650262164

• विन्यास सत्र के रूप में एक पूरे पर लागू होता है, जिससे ऑप्ट-आउट असंभव हो जाता है।

• दोनों मामलों में, कार्रवाई की आवश्यकता है कि एक विशिष्ट कॉल से _separate_ है, और किसी दिए गए कॉल को देखकर आपको यह नहीं बताएगा कि यह कैसे व्यवहार करेगा - इसके विपरीत, &! कोई संदेह नहीं छोड़ता है कि कौन सा व्यवहार सुनिश्चित करेगा।

अंतिम उपयोगकर्ता के लिए, यह बहुत ही भयानक लगता है जैसे कि हमने एक कैलकुलेटर लॉन्च किया और इसके अलावा ऑपरेशन के लिए 5 बटन पाए। 😄

अगर हम इसे इतना सुधारना चाहते हैं कि हम इस तरह की जटिलताओं के लिए तैयार हैं, तो शायद यह एक ब्रेकिंग चेंज (प्रत्यक्ष मंगलाचरण और & ) को स्वीकार करने के लिए पर्याप्त है ताकि व्यवहार को सरल बनाया जा सके और V8.0 जारी किया जा सके।

यदि हमारी इच्छा इतनी मजबूत नहीं है, तो डायग्नोस्टिक्स ( prog.exe param1 param2 -Whatif और स्टार्ट-प्रोसेस-व्हाट्सएफ़ के लिए) को पर्याप्त रूप से सुधारना संभव है ताकि यह प्रदर्शित हो कि testargs प्रोग्राम क्या प्रदर्शित करता है और कैसे के लिए सिफारिशें भागने के लिए सही ढंग से प्रदर्शन करने के लिए।

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

@iSazonov :

तब शायद यह एक ब्रेकिंग चेंज (प्रत्यक्ष आह्वान और & के लिए) को स्वीकार करने के लिए पर्याप्त है ताकि व्यवहार को सरल बनाया जा सके और V8.0 जारी किया जा सके

आपके पास निश्चित रूप से _my_ वोट है - लेकिन क्या वे शक्तियां इस योजना का समर्थन करती हैं ? [_update_ - # 13129 देखें]
यदि हम इस परिमाण में परिवर्तन करते हैं, तो हम अंत में सभी ऐतिहासिक सामानों से निपट सकते हैं - # 6745 देखें

अगर हम इसे इतना बेहतर बनाना चाहते हैं

इसे बहुत अधिक करने के दो अच्छे कारण हैं:

• टूटी हुई दलील के कारण वर्षों से चली आ रही पीड़ा को समाप्त करने के लिए - जैसा कि # 1995 तक स्पष्ट है, कई संबंधित मुद्दे और अनगिनत स्टैक ओवरफ्लो प्रश्न।

• क्योंकि - जैसा कि पहले भी कई बार कहा जा चुका है - तर्कों के साथ बाहरी कार्यक्रमों को बुलाना किसी भी शेल_ का _core जनादेश है।

ऐतिहासिक रूप से, विंडोज़-केवल दिनों में, सक्षम बाहरी सीएलआई की कमी ने उन्हें ठीक से कम समस्याग्रस्त फोन करने में असमर्थता जताई, और जो उपयोगकर्ता पावरशेल (केवल पावरस्ले-देशी कमांड को कॉल करते हैं) को दर्द महसूस नहीं हुआ। लेकिन निश्चित रूप से समय बदल गया है:

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

यहां तक ​​कि अगर एक अनुमति-से-ब्रेक-बैकवर्ड-संगतता v8.0 होता है (उंगलियां पार की जाती हैं), तो इसकी रिहाई एक लंबे समय से दूर हो सकती है, और हमें _also_ को एक अंतरिम समाधान की आवश्यकता है।

प्रलेखन में प्रस्तावित वृद्धि की जितनी जरूरत है, मुझे नहीं लगता कि वे अकेले आसानी से दर्द को कम कर सकते हैं, आसानी से उपलब्ध रनटाइम समाधान की कमी के लिए।

मुझे लगता है कि ऑपरेटर बदसूरत है, लेकिन एक गैर-तोड़ने वाला समाधान _nentitates_ अतिरिक्त सिंटैक्स (टाइप करने के लिए), जो भी कुछ भी हो।

&! जो कम बदसूरत है, टाइप करना आसान है, और "प्रदूषण" नहीं करता है भाषा को अंतर्निहित नाम के साथ संक्षिप्त नाम के साथ शिप करना है, जैसे iep फ़ंक्शन ( मैं nvoke- ई xternal पी rogram) जो सभी समस्याओं को मास्क करता है, यहां दिखाया गया
(ध्यान दें कि हम पहले से ही ऐसे कार्यों को शिप करते हैं जो या तो अन्य कार्यक्षमता को लपेटते हैं (जैसे, pause ) या cmd.exe उपयोगकर्ताओं (जैसे, cd.. [sic]) को समायोजित करते हैं।)

इस प्रकार, bash -c 'echo "one two"' ठीक से काम करने के लिए, आप iep bash -c 'echo "one two"' कॉल करेंगे
या, शायद अधिक यथार्थवादी परिदृश्य का उपयोग करने के लिए:

# Pass JSON to an external utility (Unix example)
# Without `iep`, the embedded double quotes are lost and *broken JSON* is passed.
iep /bin/echo '{ "foo": "bar" }'

फिर, हम अंततः पिछड़े अनुकूलता को संरक्षित करने के लिए सेवा में _compromise_ के बारे में बात कर रहे हैं - यह अनिवार्य रूप से अंतिम उपयोगकर्ताओं के लिए एक उपद्रव है।

डायग्नोस्टिक्स (prog.exe param1 param2 -Whatif और Start-Process -WhatIf के लिए समान) में सुधार करें ताकि यह प्रदर्शित हो कि कौन सा टेस्सरग कार्यक्रम प्रदर्शित करता है और कैसे सही ढंग से बचने के लिए प्रदर्शन करता है।

चूंकि प्रत्यक्ष / & -आधारित आह्वान एक cmdlet कॉल नहीं है और सभी तर्कों को पास-थ्रू तर्कों के रूप में माना जाता है, -WhatIf को एक आम पैरामीटर मात्रा के रूप में एक टूटने वाले परिवर्तन के रूप में माना जाता है (हालांकि संभावना नहीं है कि) व्यवहार में है)।

यदि आप इस तरह के बदलाव को स्वीकार करना चाहते हैं, तो हम ऑप्ट-इन के रूप में -DoItRight स्विच (या प्रतीक-आधारित एक, --% ) का समर्थन कर सकते हैं। निश्चित व्यवहार - और यह मुझे iep -प्रिफ़िक्स / &! दृष्टिकोण से भी बदतर बनाता है।

(एक नॉन-ब्रेकिंग डायग्नोस्टिक विकल्प, मुझे लगता है, Invoke-Command बढ़ाना होगा, जो वर्तमान में -WhatIf समर्थन नहीं करता है - हालांकि, अगर हम सही तरीके से एक प्रलेखित ऑप्ट-इन प्रदान करते हैं व्यवहार, मुझे नहीं लगता कि यह करने लायक है।)

मैं @iSazonov से सहमत @ mklement0 ने एक ब्रेकिंग रिलीज के इंतजार में कहा कि ठीक से तय किया गया यह एक बहुत बहुत लंबा समय हो सकता है, और हम में से बहुत से ASAP को समाधान की सख्त जरूरत है। सभी के लिए मैं देख सकता हूं, वर्तमान में सबसे अच्छा समाधान सिर्फ उपयोग करना है
https://github.com/PowerShell/PowerShell/issues/1995#issuecomment -562334606 सही है?

@ mklement0 मुझे यकीन नहीं है कि एक iep /

@ बढ़ती :

स्पष्ट होने के लिए: लिंक्ड iep फ़ंक्शन # 1995 को ठीक करता है, न कि _this_ प्रस्ताव मुख्य रूप से है (जो मुझे लगता है कि _not_ लायक है, जैसा कि ऊपर तर्क दिया गया है ), हालांकि ध्यान दें कि ओपी में उल्लिखित इरादा है _also_ हल # 1995।

1995 बाहरी कार्यक्रमों पर तर्क पारित करने के लिए _PowerShell_ के सिंटैक्स (अन्य शेल के नहीं) पर भरोसा करने में सक्षम होने के बारे में है, जैसा कि अपने स्वयं के पार्सिंग_ के बाद PowerShell द्वारा शब्दशः देखा गया है।

PowerShell का स्वयं का पार्सिंग ठीक है, और जब तक आप _PowerShell_ कमांड पर तर्क पास नहीं करते हैं, तब तक कोई समस्या नहीं है।

इसके विपरीत, _external प्रोग्रामों के लिए तर्क पारित करना बुरी तरह से टूट गया है, और यही iep फिक्स है।

यह त्रुटिपूर्ण _re-quoting और तर्कों के बचने के कारण टूट गया है_ दृश्यों के पीछे_, जब कमांड लाइन का अंततः उपयोग किया जाता है।
https://github.com/PowerShell/PowerShell-RFC/pull/90 एक उचित फ़िक्स (पिछड़ी अनुकूलता को संभालने के तरीके पर समझौता, और कुछ छोटे सवालों के जवाब अभी तक दिए जाने का प्रस्ताव है) का प्रस्ताव करता है, कि इसके मूल पर निर्भर करता है हाल ही में हमारे लिए उचित री-कोटिंग और भागने के लिए System.Diagnostics.ProcessStartInfo.ArgumentList शुरुआत की (हम पावरस्ले के स्वयं के पार्सिंग से उत्पन्न तर्कों का संग्रह पास करते हैं) - जो, संयोगवश, केवल कभी आवश्यक है _on Windows_; जब आप प्रक्रिया स्टार्टअप पर तर्क पास करते हैं, तो यूनिक्स पर, समझदारी से, _there कोई कमांड लाइन नहीं है (शेल के बाहर): आप एक सरणी के रूप में, केवल तर्क-वितर्क पास करते हैं।

संक्षेप में:

• एक अंतर्निहित फ़ंक्शन के रूप में iep प्रदान करना एक कम-समारोह स्टॉपगैप ऑप्ट-इन होगा, जो बाहरी कार्यक्रमों को पारित करने के लिए उचित तर्क पेश करता है, जब तक कि एक उचित निर्धारण - एक ब्रेकिंग परिवर्तन के संदर्भ में - लागू नहीं किया जा सकता

• Invoke-NativeShell ( ins ) cmdlet उचित समाधान है - स्टॉपगैप नहीं - _a विभिन्न शेल के_ (देशी शेल की) कमांड लाइनों को कॉल करने का एक तरीका प्रदान करने के लिए, _its और सिंटैक्स का उपयोग करके - ऊपर देखें ।

वर्तमान में, ऐसे मामले हैं जहां पायल कमांड को काटना और चिपकाना पायथन में अपेक्षित रूप से चलाने में विफल रहता है। जाओ पता लगाओ। यह उन सभी कटर-और-पेस्टर्स के लिए एक बड़ा नुकसान होना चाहिए। मुझे लगता है कि अजगर के पास इसके लिए एक विशेष ऑपरेटर होना चाहिए।

मुझे यकीन नहीं है कि आपने मेरा सुझाव समझ लिया है; आप जो कह रहे हैं वह स्पष्टतः मैं क्या कह रहा हूं। मुझे कुछ रणनीतिक रूप से पूंजीगत संकेतों के साथ अधिक क्रियाशील होने दें: डी

# NEW SOLUTION: the entire pipeline AS ABOVE is sent to WSL, then the results are returned to powershell
# and piped, in powershell, to foreach-object
(& --% wsl ls | grep -i "foo") | % { "match {0}" -f $_ }

मुझे यहां क्या समझ नहीं आ रहा है? यदि पाइप --% बाद दिखाई देता है तो यह सिर्फ एक और गूंगा चरित्र है: एक तर्क। ऑपरेटर पूर्वता के साथ कोई जुड़ाव नहीं है। यदि एक नेस्टेड पाइप लाइन या सब-डेप्रिसिशन में निहित है, तो फिर से पॉवरशेल के लिए पार्स करना शुरू करें।

विचार?

आप जो याद कर रहे हैं वह बाहरी कार्यक्रम के तर्क के रूप में एक बंद कोष्ठक को पारित करने की आवश्यकता है। यह एक सामान्य DWIM दृष्टिकोण है - लेकिन PowerShell HAL नहीं है।

सभी की विस्तृत प्रतिक्रिया, सभी के लिए धन्यवाद। यहां खुद के रूप में बोलते हुए। इससे पहले कि मैं नटखट किरकिरा हो, कुछ uber-अंक:

• मैं अभी भी एक vNext / 8.0 के साथ बोर्ड पर नहीं हूं जो सामान की एक पूरी नई रोशनी को तोड़ने का फैसला करता है। पश्चगामी संगतता मायने रखती है। मुझे पता है कि यह दर्दनाक है, और मैं एक ऐसी दुनिया में रहना चाहता हूं, जहां हम वापस जा सकते हैं और हर गलती को सुधार सकते हैं जो कि PowerShell ने कभी बनाया है, कई अनजाने में। लेकिन बहुसंख्यक PS उपयोगकर्ता यहाँ मुद्दों में नहीं लटक रहे हैं, SO एज मामलों में घुटने के गहरे हैं। उन्होंने 4-10 वर्षों के लिए उसी वर्कअराउंड को कॉपी / पेस्ट किया है, वे जरूरी नहीं जानते कि यह क्यों काम करता है, और वे परवाह नहीं करेंगे कि अपग्रेड पर उनकी स्क्रिप्ट टूटने पर हम "गलतियों को ठीक कर रहे थे"। वे बस जानते हैं कि "अपडेटिंग पीएस ने मुझे तोड़ दिया है, और मैं अपडेट पर भरोसा नहीं कर सकता हूं", और फिर हम और भी अधिक उपयोगकर्ताओं को अपने अपडेट और अपनाने को धीमा कर देते हैं।
• मुझे लगता है कि इस मुद्दे में कुछ लोग इस मुद्दे में कई अलग-अलग आशाओं और इच्छाओं को पेश कर रहे हैं, या इसे या तो / या अन्य सुधारों के रूप में देख सकते हैं। मुझे एहसास है कि मैंने इसे 1995 में बंद कर दिया था, और मुझे इसके लिए खेद है (हालांकि मैं कहूंगा, मुझे अभी भी यकीन नहीं है कि विशेष रूप से निश्चित रूप से तय किया जा सकता है, लेकिन हम इस पर एक कठिन नज़र रखेंगे), लेकिन यह वास्तव में एक "ट्रैप डोर" समाधान है जो नए और अनुभवी दोनों उपयोगकर्ताओं को निराशा माउंट करने के बिना जल्दी से एक बाँध से बाहर निकाल देता है। हम अभी भी घर के पीएस पार्सिंग पक्ष के लिए फिक्स के बारे में लंबी अवधि की बातचीत कर सकते हैं ताकि हम हर चीज के लिए सही मायने में क्रॉस-प्लेटफॉर्म समाधान की पेशकश कर सकें।

अब, टिप्पणियों के रूप में मैंने पढ़ा:

• मैं #! साथ संरेखित करने की प्रस्तावित इच्छा के बारे में चिंतित हूं (या तो &! या $! , डिफ़ॉल्ट मामले में, उपयोगकर्ता संभवतः दुभाषिया निर्दिष्ट नहीं करने जा रहे हैं .अगर मैं $! net <stuff> , net.exe कुछ करना चाहता हूँ, तो मेरी दुभाषिया नहीं है। और गैर-विंडोज पर, "देशी" करने के लिए अभी भी sh / bash / जो कुछ भी करना है, उसे पारित करना है। बाइनरी को पास किया जा रहा है। जैसे मैं पायथन को *.py स्ट्रिंग में $! /usr/bin/python *.py या यहां तक ​​कि $! python *.py चाहता हूं। मैं चाहता हूं कि बैश को ग्लोबिंग और फिर हाथ करना चाहिए। मैचों की सूची python ।
• जैसा कि @oising ने सुझाव दिया है, मैं ऑपरेटर के रूप में --% पक्ष में हूं, फ्रंट में उपयोग किए जाने के लिए अतिभारित। डिस्कवरबिलिटी एक समस्या है, और यह देखते हुए कि हम इस एक की खोज पर काम करने में पहले से ही 10 साल हैं ( यह अब Google-सक्षम है! मेरा कहना है कि हम बस उसी के साथ चलते हैं। (मैं एक था जिसने @ स्टीवएल-एमएसएफटी बनाया था) इसे वैकल्पिक विचार के रूप में उनके प्रस्ताव पर रखें)। प्रश्न, हालांकि: क्या हमें यहां & कॉल ऑपरेटर की भी आवश्यकता है? क्यों न केवल --% native.exe do /some $stuff साथ लाइन शुरू करें?
• @rjmholt : मुझे आपकी टिप्पणी यहाँ पूरी तरह से समझ में नहीं आई, लेकिन यह मेरा लेना है कि हमें मौजूदा --% व्यवहार के साथ कुछ भी नहीं बदलना चाहिए जहाँ यह निष्पादन योग्य के बाद आता है, लेकिन मुझे लगता है कि हम आपका "नया" कर सकते हैं व्यवहार "जहां निष्पादन योग्य से पहले आता है।

• इसे @jazzdelightsme से पढ़ें और मैं सशक्त रूप से सहमत हूं:

  यह उपयोगकर्ताओं के सबसे विशेषज्ञ के लिए भी है, जो बस सब कुछ के साथ जाने और बेला के बिना StackOverflow से एक कमांड कॉपी / पेस्ट करना चाहते हैं।

  मेरे दिमाग में, यह परिदृश्य का एक बड़ा पहलू है, संभवतः सबसे बड़ा। यह सिर्फ एसओ नहीं है, या तो, यह वेब के चारों ओर से डॉक्स है जो मान लेते हैं कि आप बैश जैसे शेल में हैं।

• इस बात पर ध्यान दिए बिना कि क्या # 1995 जैसी चीजें ठीक हो जाती हैं, इसका मतलब यह है कि ए) उस तरह के अजीब किनारे के मामलों की एक लंबी पूंछ है, और बी) वे लोगों को तोड़ने के बिना ठीक करना बहुत मुश्किल है। यह उन सभी के लिए जरूरी नहीं है, लेकिन हमने पिछले कुछ वर्षों में इसे काफी हिट किया है, यह मेरे लिए स्पष्ट है कि हमें "ट्रैप डोर" की आवश्यकता है ताकि लोगों को बालों वाली स्थितियों से बाहर निकाला जा सके, जहां वे गोता नहीं लगाना चाहते हैं हमारे नेस्टेड बचने का खरगोश की मांद (केवल वहाँ # 1995 की तरह एक बग है खोजने के लिए है कि उन्हें काम कर रहे एक बार भी वे जानते हैं कि वे क्या जानते हुए भी कर रहे हैं करने से रोकता है)।

टिप्पणियों की समीक्षा करने में, मुझे लगता है कि दो खुले प्रश्न हैं जिनका हमें अभी भी उत्तर देने की आवश्यकता है:

1. क्या हम PowerShell में कमांड सेपरेटर और उनके बाद सब कुछ पार्स करना जारी रखते हैं, या कमांड सेपरेटर भी देशी शेल में वर्बेटिम पास कर देता है?
   मैं कहता हूं कि हमें देशी शेल के लिए सब कुछ पास करना चाहिए क्योंकि वर्तमान में ऐसा कुछ है जो आप नहीं कर सकते हैं, और एक अग्रणी पैतृक के @oising समाधान में समाधान हो सकता है कि हम अभी भी पाइप, पाइप लाइन चेन, आदि का समर्थन कर सकते हैं। , यदि आप देशी और पीएस पार्सिंग को मिलाना / मेल करना चाहते हैं (हालांकि मैं पार्सर के करीब लोगों से कुछ राय लेना चाहता हूं)।
2. ऑपरेटर क्या है?
   जैसा कि ऊपर उल्लेख किया गया है, मुझे --% क्योंकि इसे पहले से ही "बस वही करें जो यह काम करता था" ऑपरेटर के रूप में एक प्रतिष्ठा मिली है, और हमें कुछ भी नया करने के लिए खोज पर रीसेट करना होगा। मैं @ mklement0 जैसे तर्कों को समझता हूं कि, यदि हम ऐसा करते हैं, तो हम --% का तकनीकी अर्थ बदल रहे हैं (और @ SteveL-MSFT ने मेरे लिए भी यह तर्क दिया है), लेकिन मुझे नहीं लगता जंगली लोगों में से ज्यादातर लोग "यह वह करते हैं जो वह cmd में करते थे" के संदर्भ में --% बारे में सोच रहे हैं। मुझे नहीं लगता कि ऑपरेटर की परिभाषा में इस धारणा को संहिताबद्ध करने के लिए यह एक खिंचाव है "देशी शेल यहां क्या करता है"।

मूल रूप से, दूसरे परिदृश्य के बारे में सोचा कि हम समर्थन करना चाहते हैं या नहीं।

विंडोज पर, cmd (प्रभावी रूप से) PATH लुकअप में वर्तमान निर्देशिका को शामिल करता है। हालाँकि, PowerShell के लिए आवश्यक है कि उपयोगकर्ता किसी भी EXEs को निष्पादित करने के लिए ./ पूर्व भुगतान करें (या PATHEXT में कुछ भी) यदि वर्तमान निर्देशिका PATH ।

तो मेरा खुला सवाल है: क्या हम वास्तव में पूरी कमांड स्ट्रिंग cmd को सौंपना चाहते हैं? मैं चाहता हूं कि यदि हम वास्तव में इस ऑपरेटर के साथ कॉपी / पेस्ट परिदृश्य को प्रकाश में लाना चाहते हैं, तो इसका जवाब है कि हां, कुछ तृतीय-पक्ष डॉक्स / ट्यूटोरियल आवश्यक रूप से विस्तार नहीं करते हैं कि वे उन टूल को कैसे डालते हैं जो वे उपयोग करने की अपेक्षा करते हैं। PATH । यह शायद ज्यादा मायने नहीं रखता है, लेकिन मैं इसे यहाँ दोहराना चाहता था।

• मैं अभी भी एक vNext / 8.0 के साथ बोर्ड पर नहीं हूं जो सामान की एक पूरी नई रोशनी को तोड़ने का फैसला करता है।

हाँ, मैं नहीं जानता कि कैसे आप इन समस्याओं को ठीक करने के लिए अविश्वसनीय रूप से कठिन तरीके से समस्या निवारण के बिना ठीक करते हैं इसके अलावा मैं y'all के बारे में नहीं जानता, लेकिन यहां तक ​​कि मैं इन सभी जटिल बाइंडर / पार्सर मतभेदों को कई संस्करणों के लिए लिखते समय हथकंडा नहीं करना चाहता।

आमतौर पर अगर मैं अन्य लोगों के लिए परिवर्तन को तोड़ने के खिलाफ बहस कर रहा हूं। हालांकि, ऐसा लगता है कि शायद आईटीटी में मौजूद लोगों के लिए भी यह एक पीआईटीए होगा।

• जैसा कि @oising ने सुझाव दिया है, मैं ऑपरेटर के रूप में --% पक्ष में हूं, जो कि फ्रंट में उपयोग किए जाने के लिए अतिभारित है। (...) क्यों न केवल --% native.exe do /some $stuff साथ लाइन शुरू करें?

मुझे वास्तव में पसंद है। आदर्श रूप में CreateProcess / exec जितना संभव हो सके (प्लस nix env var हैंडलिंग और इन / आउट पुनर्निर्देशन या कंसोल अनुलग्नक)। या शायद cmd.exe / bash पूरी तरह से गिर रहा है।

मैं रखने पर अटक नहीं कर रहा हूँ & के सामने --% या तो। मैं कम से कम अपने सिर में एक निर्देश / ऑपरेटर की तरह कच्चे --% का इलाज करने के विचार को सही ठहरा सकता हूं। बहुस्तरीय के बारे में क्या? --% @" और "@ को var विकल्प और उप-संदर्भों के लिए अनुमति दें, और एकल उद्धरण @' और '@ शाब्दिक रूप से पारित करने के लिए? यहाँ तार के बिना, यह केवल एक पंक्ति है?

जैसे @oising ने सुझाव दिया, मैं ऑपरेटर के रूप में -% के पक्ष में हूं

मेरे लिये कार्य करता है।

प्रश्न, हालांकि: क्या हमें यहां & कॉल ऑपरेटर की भी आवश्यकता है?

जब तक मैं अभी भी --% & $computedPathToNativeExe foo;@workspace कर सकता हूं तब तक मेरे द्वारा ठीक है। हमें इसके साथ कॉल ऑपरेटर का उपयोग करने में सक्षम होने की आवश्यकता है।

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

माना।

मुझे नहीं लगता कि ऑपरेटर की (-%) परिभाषा में इस धारणा को संहिताबद्ध करने के लिए यह एक खिंचाव है "देशी शैल यहाँ क्या करती है"।

भी सहमत!

इसके अलावा, शायद यह निष्पादन योग्य सत्र (# 3316) के लिए परिभाषित निष्पादन योग्य से पहले env var को परिभाषित करने की सुविधा में प्राप्त करने का एक तरीका है:

--% JEKYLL_ENV=production jekyll build

सिर्फ एक विचार।

@rkeithhill , call native operator साथ विचार यह है कि लाइन को PowerShell द्वारा संसाधित नहीं किया गया है और वर्बेटिम को ओएस के "डिफ़ॉल्ट शेल" में भेजा गया है। तो इस मामले में, आपका पहला उदाहरण --% & $computerPathToNativeExe foo;@workspace काम नहीं करेगा। आपको वर्तमान पद्धति का उपयोग करना होगा और उचित रूप से बच निकलना होगा। दूसरा मामला --% JEKYLL_ENV=productoin jekyll build बस काम करना चाहिए।

लाइन को PowerShell द्वारा संसाधित नहीं किया गया है और वर्बेटिम को ओएस के "डिफ़ॉल्ट शेल" में भेजा गया है

ठीक है, जो उचित लगता है। हालाँकि यह --% JEKYLL_ENV=productoin jekyll build सिर्फ Linux / macOS पर काम करेगा लेकिन विंडोज पर नहीं - कम से कम PowerShell की मदद के बिना, सही नहीं?

@rkeithhill वर्तमान में प्रस्तावित है जो कभी भी विंडोज पर काम नहीं करेगा क्योंकि यह ओएस "डिफ़ॉल्ट" शेल पर निर्भर करता है। PowerShell द्वारा किसी प्रक्रिया के लिए env var घोषित करने के लिए, उस पर चर्चा करने के लिए हमारे पास एक अलग मुद्दा है।

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

जहां $foo एक शाब्दिक फ़ाइल नाम है और $PWD WSL के भीतर वर्तमान निर्देशिका है। ध्यान दें कि पहले उदाहरण में, आपको PowerShell के भीतर WSL के बजाय && से बचना होगा।

$foo और $PWD sh द्वारा मूल्यांकन किए जाने वाले चर संदर्भ हैं।

PowerShell में ऐसे निष्पादन से आउटपुट को पाइप करने के लिए, उपयोगकर्ता को परिणामों को पहले एक चर में संग्रहीत करना आवश्यक है:

$out = --% ls *.txt
$out | select-string hello

ध्यान दें कि वर्तमान & कॉल ऑपरेटर के विपरीत, आप किसी भी PowerShell सिंटैक्स का उपयोग नहीं कर सकते, इसलिए:

--% $commandline

$commandline शाब्दिक अर्थ ( cmd तहत) या शेल विस्तार के बाद ( sh तहत) निष्पादित करने का प्रयास करेंगे। PowerShell उस चर को हल करने का प्रयास नहीं करेगा।

&n टाइप करने के बाद बस पेस्ट करके कट और पेस्ट की समस्या हल हो जाती है।

--% बाद बस चिपकाने से

wsl लिए उपरोक्त उदाहरण जैसा दिखेगा:

कौनसा?

चूंकि --% बाद सभी तर्कों को "डिफ़ॉल्ट" शेल में पारित किया गया है, पॉवरशेल में पाइपलाइनिंग का समर्थन करने के लिए, आपको एक चर का उपयोग करने की आवश्यकता होगी:

यह एक पुनरावृत्ति है।

अगर हम कुछ उपयोगी जोड़ने जा रहे हैं तो मैं एक धुरी का प्रस्ताव रखूंगा।

क्यों हम एक साहसी शाब्दिक की तरह कुछ नहीं कर सकते हैं

@! ""! @

इसलिए हमारे पास ऐसा करने का वास्तविक तरीका हो सकता है -% के बजाय जिसके पास मुद्दों की अपनी मेजबानी भी है।

कम से कम इस तरह से हम इस मुद्दे को "बेहतर" डिजाइन रणनीति के साथ दफन कर सकते हैं।
और इन एज मामलों के लिए खोज करने के लिए About_Strings में बैठना चाहिए जहां इसे हल किया जाना चाहिए।

सिर्फ एक विचार।

मैं यह देखने में विफल रहता हूं कि कैसे @!"…"!@ Invoke-NativeShell @"…"@ से बेहतर है। क्या हम PowerShell को अधिक ब्रेनफक-लाइक बनाने की कोशिश कर रहे हैं?

@ yecril71pl

मैं यह देखने में विफल रहता हूं कि कैसे @!"…"!@ Invoke-NativeShell @"…"@ से बेहतर है। क्या हम PowerShell को अधिक ब्रेनफक-लाइक बनाने की कोशिश कर रहे हैं?

मेरा मानना ​​है, कि @ romero126 का मतलब एक ऑनलाइन हेस्टिंग्रिंग शाब्दिक सुझाव देना था, जैसे कि कोई लिख सकता है

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@

के बजाय

Invoke-NativeShell @"
complicated native command with "quotes" and | pipe
"@

यदि इस तरह के एक ऑनलाइन हेरिंगिंग पर विचार किया जाएगा, तो मैं @"""…"""@ और @'''…'''@ जैसे सिंटैक्स का उपयोग करने का सुझाव दूंगा, यह IMO @!"…"!@ टाइप करना आसान होगा।

@ romero126 क्या आप स्पष्ट कर सकते हैं कि आपका क्या मतलब है?

@ yecril71pl उन त्रुटियों को पकड़ने के लिए धन्यवाद, फिक्स के साथ शीर्ष संदेश को अपडेट किया।

यह अनिर्दिष्ट है कि क्या --% कमांड लाइन के रूप में या बैच फ़ाइल के रूप में निष्पादित होगा।

मेरा मानना ​​है, कि @ romero126 का मतलब एक ऑनलाइन हेस्टिंग्रिंग शाब्दिक सुझाव देना था, जैसे कि कोई लिख सकता है

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@

के बजाय

Invoke-NativeShell @"
complicated native command with "quotes" and | pipe
"@

यदि इस तरह के एक ऑनलाइन हेरिंगिंग पर विचार किया जाएगा, तो मैं @"""…"""@ और @'''…'''@ जैसे सिंटैक्स का उपयोग करने का सुझाव दूंगा, यह IMO @!"…"!@ टाइप करना आसान होगा।

@ romero126 क्या आप स्पष्ट कर सकते हैं कि आपका क्या मतलब है?

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

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

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

त्वरित उदाहरण:

# For this scenario let @!"<text>"!@ be our HereString Verbatim

Invoke-NativeShell @!"complicated native command with "quotes" and | pipe"!@
# or
Invoke-NativeShell @!"
Complicated native command with "quotes" and pipe and <tabs>
"!@

#or 
$r = @!"
complicated native command with custom arguments: {0}
"!@ -format "foo"
Invoke-NativeShell $r

यह इस टिप्पणी के दूसरे भाग में @ mklement0 कवर के मुद्दे को संबोधित नहीं करता है। इस तथ्य का तथ्य यह है कि हम कभी भी प्रत्येक कॉमैंड के लिए एक स्ट्रिंग नहीं दे सकते हैं; कई मामलों में उन्हें अलग होना पड़ता है।

मेरा मानना ​​है कि यदि हम स्ट्रिंग्स में लचीलेपन को "लगभग कच्चे" अप्रकाशित डेटा को संभालने के लिए जोड़ते हैं तो हमारे पास इस पॉप अप के बारे में समस्या नहीं होगी।

यह ' और @' लिए है।

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

मूल आदेश तार का एक क्रम लौटाते हैं। @!" की क्षमता एक स्टेपल बनने की क्षमता है जो अचिंत्य दिखता है।

मेरा मानना ​​है कि यदि हम स्ट्रिंग्स में लचीलेपन को "लगभग कच्चे" अप्रकाशित डेटा को संभालने के लिए जोड़ते हैं तो हमारे पास इस पॉप अप के बारे में समस्या नहीं होगी।

यह ' और @' लिए है।

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

मूल आदेश तार का एक क्रम लौटाते हैं। @!" की क्षमता एक स्टेपल बनने की क्षमता है जो अचिंत्य दिखता है।

मुझे लगता है कि आप भ्रमित हैं। बिंदु के साथ मैं बना रहा था।
एकल उद्धरण और डबल उद्धरण केवल $ चर का विस्तार करते हैं या नहीं। यह स्वचालित रूप से वर्णों से नहीं बचता है। यह मुझे सीमित भी करता है इसलिए मैं अब इसके परिभाषित चरित्र का उपयोग नहीं कर सकता। इसलिए इसके बजाय अब ठीक से काम करने के लिए। मुझे अभी भी उन पात्रों से बचना होगा जो पूरे बिंदु है कि हमें एक को शामिल करने की आवश्यकता क्यों है! कमान।

यदि आपके पास एक बेहतर उपाय है तो मैं सभी कानों के पास हूं। मेरा मानना ​​है कि यह एक जोड़ने की तुलना में अधिक धार मामलों को हिट करता है!

एकल उद्धरण और डबल उद्धरण केवल $ चर का विस्तार करते हैं या नहीं। यह स्वचालित रूप से वर्णों से नहीं बचता है। यह मुझे सीमित भी करता है इसलिए मैं अब इसके परिभाषित चरित्र का उपयोग नहीं कर सकता। इसलिए इसके बजाय अब ठीक से काम करने के लिए। मुझे अभी भी उन पात्रों से बचना होगा जो पूरे बिंदु है कि हमें एक को शामिल करने की आवश्यकता क्यों है! कमान।

आपको किन पात्रों से बचना होगा और क्यों?

@ romero126 अब मैं उलझन में हूँ कि आप क्या कह रहे हैं। क्या आप जानते हैं, कि शक्तियाँ यहाँ एक स्ट्रिंग है ?

मैंने पहले सोचा था, कि आप पावर स्ट्रिंग्स के सिंटैक्स पर विचार कर सकते हैं यहाँ स्ट्रिंग्स कष्टप्रद है (कम से कम मुझे कभी-कभी गुस्सा आता है, कि शुरुआत और अंत में एक नई रूपरेखा होनी चाहिए ...), लेकिन अब मुझे यकीन नहीं है कि क्या आप कह रहे हैं, क्या आप स्पष्ट कर सकते हैं?

@TSlivede , यहां-स्ट्रिंग्स पर वाक्यगत रूप से कुछ हद तक बोझिल होने पर सहमत हुए।

एक मौजूदा प्रस्ताव है, # 2337, जो सुधारों का प्रस्ताव करता है, और जब यह समापन परिसीमन को अनुमति देने पर केंद्रित होता है, तो @lzybkr भी Rust-like _single-line _ (- https: // github ) में भिन्नता प्रस्तावित करता है

# `ins` is `Invoke-NativeShell`
ins @' python -c 'print("hi")' | cat -n '@

भागने की आवश्यकता को _multiple_ ' @ साथ जोड़कर टाला जाएगा, आवश्यकतानुसार (जैसे, @'' can use @' here ''@ ।

दूसरे शब्दों में: यह PowerShell स्ट्रिंग शाब्दिकों के लिए एक सामान्य वृद्धि होगी, जो हर जगह उपयोग करने योग्य है, जो Invoke-NativeShell रूप में अच्छी तरह से लाभान्वित होगा।

यह देखते हुए कि # 2337 मुख्य रूप से कुछ और पर केंद्रित है, मैंने # 13204 में एक

भागने की जरूरत से बचना होगा

मैंने इसे इस धागे में कई बार देखा है।

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

आज का सबसे प्राकृतिक रूप एकल-उद्धृत स्ट्रिंग्स है:

• ' : एकल-उद्धरण टोकन प्रारंभ करें
• ' : एकल-उद्धरण टोकन समाप्ति
• '' : एकल-उद्धृत स्ट्रिंग के भीतर एक शाब्दिक एकल उद्धरण लिखें

मुझे लगता है कि हम इसके बावजूद भागने की बात कर रहे हैं:

• --% ऑपरेटर अपने मोड से बाहर निकलने के कई तरीके परिभाषित करता है ( | , && , || , ; , newline) और अनुमति देता है इसके भीतर (उनके ' वर्णों को अलग करते हुए)
• Herestrings और सह उनमें से एक सरणी के बजाय एक स्ट्रिंग तर्क का समाधान करते हैं

निष्पादन योग्य आह्वान के लिए तर्क पारित करना चाहते हैं, जिसका मतलब है कि हम वास्तव में एक सरणी सिंटैक्स के बारे में बात कर रहे हैं:

• सरणी कैसे शुरू करें (शब्दशः आरंभ करें)
• सरणी को अलग कैसे करें (नए निष्पादन योग्य के लिए एक तर्क पास करें)
• कैसे अंत सरणी (अंत शब्दशः मोड)

(यह * nix पर एक मूल अवधारणा है, क्योंकि exec एक सरणी की उम्मीद है। विंडोज पर, मुझे लगता है कि हम एक सरणी लेने के लिए मजबूर हैं, इसे एक विशेष स्ट्रिंग सिंटैक्स पर क्रमबद्ध करें और CommandLineToArgvW माध्यम से इसे पारित करें।

इसका मतलब है कि हमें दो भागने की जरूरत है:

• सरणी विभाजक शाब्दिक
• सरणी का अंत शाब्दिक है

उदाहरण के लिए, मान लें कि:

• --% कमांड नई वर्बटीम सिंटैक्स बनने से पहले
• हम वाक्य रचना को कैसे समाप्त करते हैं? newline और ; शायद?
• हम अलग-अलग तर्क कैसे देते हैं? शायद?

फिर सवाल हैं:

• हम एक शाब्दिक ; या न्यूलाइन कैसे पास करते हैं?
• हम एक शाब्दिक कैसे पास करते हैं?

एक देशी कमांड लाइन एक सरणी नहीं है। यह या तो एक स्ट्रिंग या एएसटी है। चूंकि PowerShell को देशी गोले में एएसटी के बारे में कुछ भी नहीं पता है, केवल एक स्ट्रिंग बनी हुई है।

एक देशी कमांड लाइन एक सरणी नहीं है। यह या तो एक स्ट्रिंग या एएसटी है

आपने इस दावे के लिए कोई आधार नहीं दिया है।

यहां पर PowerShell एक कमांड के लिए एएसटी बनाता है (किसी भी प्रकार का, क्योंकि यह रनटाइम तक नहीं जानता है कि कमांड कब हल होता है)

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System/anM.Automation/engine/parser/Parser.cs#L6391 -L6634

ध्यान दें कि कमांड एलिमेंट्स (मापदंडों और तर्कों सहित) को एक ऐरे में जोड़ा जाता है।

आप इसे PowerShell में इस तरह से देख सकते हैं:

> { ping 192.168.0.1 }.Ast.EndBlock.Statements[0].PipelineElements[0].CommandElements

StringConstantType : BareWord
Value              : ping
StaticType         : System.String
Extent             : ping
Parent             : ping 192.168.0.1

StringConstantType : BareWord
Value              : 192.168.0.1
StaticType         : System.String
Extent             : 192.168.0.1
Parent             : ping 192.168.0.1

इस सरणी को यहां अभिव्यक्तियों में संकलित किया गया है:

https://github.com

और फिर यहाँ एक पाइपलाइन मंगवाने के लिए पास किया जाता है (नोटिस Expression.NewArrayInit(typeof(CommandParameterInternal[]), pipelineExprs) है जहाँ तर्क पारित किए जाते हैं):

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/Src/anystem.Automation/engine/parser/Compiler.cs#L3798 -L3805805

रनटाइम पर, संकलित अभिव्यक्तियों को चलाने पर, यह इस पद्धति का कॉल बन जाता है, जो इस कॉल से होकर गुजरता है जो यह तय करता है कि कमांड प्रोसेसर को क्या करना है:

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System/anystem.Automation/engine/runtime/Operations/MiscOps.cs#L293L3123

आखिरकार, जब पाइपलाइन को बुलाया जाता है, तो वह तर्क सरणी NativeCommandParameterBinder का उपयोग करके मूल कमांड के लिए बाध्य होती है:

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/System.anit.Automation/engine/NativeCommandParameterBinder.cs#L69 -L137137

वह तर्क सरणी लेता है, जिसमें एएसटी मेटाडेटा शामिल है जैसे कि प्रत्येक तर्क के लिए किस प्रकार के स्ट्रिंग का उपयोग किया गया था, और NativeCommandProcessor में तर्क आह्वान के लिए एक नया स्ट्रिंग बनाता है:

https://github.com

ऐसा इसलिए किया जाता है क्योंकि .NET चालान वर्तमान में हम प्रोसेस इन्वोकेशन के लिए उपयोग करते हैं। यह पुराने "सिंगल स्ट्रिंग में सभी तर्क" के बजाय .NET कोर में नया है जो आपको एक अरै पास करने की अनुमति देता है और .NET इंवोकेशन को फिर से बनाने देता है। एक मंच विशिष्ट तरीके से जरूरत के रूप में।

लेकिन हम उस एपीआई का उपयोग करते हुए एक कार्यान्वयन विवरण है। उदाहरण के लिए, हम fork / exec सीधे * nix पर कॉल कर सकते हैं, जैसे हम यहाँ करते हैं:

https://github.com/PowerShell/PowerShell/blob/f82f74d89811e91613a7450e536d652c5d8f784e/src/powershell-Program.cs#L268 -L330

ध्यान दें कि यहां exec एक सरणी है - हमने ऐसा इसलिए किया क्योंकि यह syscall के लिए तर्कों को पारित करने का सबसे सरल और सीधा तरीका है, जो अंततः एक शब्दशः तर्क वाक्य रचना का लक्ष्य है।

@rjmholt :

_Functually_, सभी आवश्यकताओं को पहले से ही मौजूदा स्ट्रिंग-शाब्दिक रूपों द्वारा कवर किया गया है, _ अगर आप मूल स्ट्रिंग को एक सिंगल स्ट्रिंग के रूप में पास करते हैं, जिसे मैं दृढ़ता से अनुशंसा करता हूं, एक नए Invoke-NativeShell / ins cmdlet के माध्यम से।

यहां शुरुआती बिंदु _सिंगल स्ट्रिंग_ के रूप में है, न कि एक सरणी: यह एक _entire कमांड लाइन_ है - लक्ष्य शेल्बी पर पार्स किए जाने के लिए - और यह PowerShell में इसे प्रतिबिंबित करने के लिए सबसे अधिक समझ में आता है - जैसे कि अजीब रूप से --% जैसे कुछ के साथ

वह सब Invoke-NativeShell करना है जो एकल स्ट्रिंग को पास करने के लिए है जिसमें पूरी मूल-शेल कमांड लाइन अपने सीएलआई के माध्यम से देशी शेल में है:

• यूनिक्स पर, इसका मतलब है: स्ट्रिंग को पास-के रूप में, _as पूरे_, तर्क के दूसरे तत्व के रूप में _array_ exec ( -c के साथ प्रथम तर्क-सरणी तत्व, और /bin/sh पारित किया गया) printf "'%s'" foo | cat -n कमांड के साथ एकल स्ट्रिंग की शब्दशः सामग्री गुजरती है ( .ArgumentList का उपयोग नोट करें, .Arguments ; ' की दोहरीकरण केवल इस उदाहरण की एक कलाकृति है):

  • $psi = [Diagnostics.ProcessStartInfo]::new('/bin/sh'); $psi.ArgumentList.Add('-c'); $psi.ArgumentList.Add('printf "''%s''" foo | cat -n'); [Diagnostics.Process]::start($psi).WaitForExit()

• विंडोज पर, इस का मतलब है: समायोजित करने के लिए cmd के quirks, भरने lpCommandLine के तर्क CreateProcess (के साथ इस प्रकार lpApplicationName का मूल्य माना पर्यावरण चर ComSpec , जो cmd.exe को इंगित करता है: "/c " + cmdLine , जहां cmdLine पूरे कमांड-लाइन स्ट्रिंग के रूप में है; एक सरल उदाहरण के साथ .NET शब्दों में व्यक्त किया गया है, जहां echo a^&b & ver एक स्ट्रिंग की शब्दशः सामग्री है जिसमें से गुजरने के लिए कमांड लाइन है:

  • $psi = [Diagnostics.ProcessStartInfo]::new($env:ComSpec); $psi.Arguments = '/c ' + 'echo a^&b & ver'; [Diagnostics.Process]::start($psi).WaitForExit()
    
    
    
    • @ yecril71pl , यह आपके प्रश्न के उत्तर का तात्पर्य है कि क्या कमांड-प्रॉम्प्ट या बैच-फ़ाइल शब्दार्थ का उपयोग किया जाना है: यह पूर्व है, जैसा कि अन्य स्क्रिप्टिंग भाषाओं द्वारा भी उपयोग किया जाता है, जैसे पायथन os.system() ; (शायद दुर्भाग्यपूर्ण) निहितार्थ यह है कि आप % वर्णों से बच नहीं पाएंगे, और for लूप वैरिएबल्स का उपयोग % (जैसे, %i %%i %i बजाय %%i ); और यह कि आपको लूप-बॉडी कमांड @ के साथ उन्हें गूंजने से रोकने के लिए होना चाहिए (जैसे, for %i in (*.txt) do <strong i="56">@echo</strong> %i )।
    
    

यह प्रक्रिया अंत उपयोगकर्ता_ के लिए _transparent होगी, ताकि उन सभी पर ध्यान केंद्रित करने की आवश्यकता है जो देशी-शेल कमांड लाइन _verbatim_ को पारित करने के लिए है, केवल _PowerShell के_ स्ट्रिंग-शाब्दिक वाक्यविन्यास आवश्यकताओं को पूरा करने की आवश्यकता है:

ins @'<newline>...<newline>'@ के फॉर्म के साथ, आप पहले से ही _can_ अपनी मूल-शेल कमांड लाइनों का उपयोग इस रूप में करते हैं: ऊपर देखें कि विभिन्न मौजूदा स्ट्रिंग-शाब्दिक रूपों का उपयोग कैसे किया जा सकता है, जो - _interpolating_ की उपलब्धता के कारण यहाँ स्ट्रिंग फॉर्म ( @"<newline>...<newline>"@ ) - साथ ही कमांड लाइन में _PowerShell_ चर और अभिव्यक्तियों का उपयोग करने की क्षमता शामिल है (ऐसा करने में असमर्थता --% की प्रमुख कमियों में से एक है)।

मेरी पिछली टिप्पणी का प्रस्ताव कच्चे स्ट्रिंग शाब्दिक_ का एक सामान्य रूप है, जो इस प्रस्ताव से _separate है (और इसका पार्सिंग तर्क अच्छी तरह से परिभाषित है); हालाँकि, जैसा कि कहा गया है, Invoke-NativeShell कॉल तब _more सुविधाजनक_ होगा।

इसके बजाय कि आप पहले से क्या कर सकते हैं ( Invoke-NativeShell / ins कमांड):

# ALREADY WORKS: Literal here-string
ins @'
python -c 'print("hi")' | cat -n
'@

प्रस्तावित नई सिंगल-लाइन कच्चे शाब्दिक के साथ आप इसे सरल बना सकते हैं:

# PROPOSED, more convenient syntax: new raw literal.
ins @' python -c 'print("hi")' | cat -n '@

यदि इस नए कच्चे स्ट्रिंग-शाब्दिक वाक्य-विन्यास की बारीकियों पर बहस करने की आवश्यकता है, तो कृपया हमें इसे # 13204 में करें, यहाँ नहीं।

इसलिए मूल इरादे को समझने के प्रस्ताव को फिर से प्रस्तुत करते हुए, मैं देखता हूं कि यह वास्तव में /bin/sh -c '<command>' + cmd संस्करण के लिए एक बेहतर वाक्यविन्यास के साथ-साथ प्रत्येक लक्ष्य शेल के लिए एक विशेष स्ट्रिंग एस्केप लॉजिक के साथ पूछ रहा है। मैंने एक विशेष वाक्य रचना और पार्सर और देशी कमांड प्रोसेसर के साथ काम करने के लिए अपनी प्रारंभिक अवधारणा को आधार बनाया था, और .NET के ProcessStartInfo.Arguments संपत्ति को उद्धरण पास के संदर्भ में सही तरीके से उपयोग करना बहुत मुश्किल था ।

लेकिन वास्तव में Arguments स्ट्रिंग सिर्फ शब्दशः से होकर गुजरती है । तो हम सभी को सीधे इस तरह के एक स्ट्रिंग पास करने की जरूरत है।

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

@Rjmholt की टिप्पणी पर कुछ टिप्पणियाँ https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -660231641

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

मैं सहमत हूं और मुझे नहीं लगता कि यहां एक स्ट्रिंग स्ट्रिंग सिंटैक्स पूरी तरह से बचने की आवश्यकता से बच सकती है।

-% ऑपरेटर अपने मोड से बाहर निकलने के कई तरीकों को परिभाषित करता है (!, &&, ||,;, newline) और इसके भीतर तार (उनके 'अक्षर) को हटाने की अनुमति देता है

--% बात करते समय, क्या आप मौजूदा --% स्विच की बात कर रहे हैं? यदि हां, तो अपनी टिप्पणी में यह स्पष्ट करना बेहतर है, क्योंकि अब --% को कॉल ऑपरेटर बनाने का प्रस्ताव है।

निष्पादन योग्य आह्वान के लिए तर्क पारित करना चाहते हैं, जिसका मतलब है कि हम वास्तव में एक सरणी सिंटैक्स के बारे में बात कर रहे हैं:

प्रस्ताव मूल शेल (श या सीएमडी) को कॉल करने और कॉल ऑपरेटर --% बाद शाब्दिक रूप से पारित करने के लिए है, जैसे sh -c ... । इसलिए यह शक्तियां नहीं हैं जो तर्कों को निष्पादन योग्य के रूप में पारित करती हैं। उस स्थिति में, मुझे लगता है कि हमें _an array syntax_ की आवश्यकता नहीं है, है ना?

हम वाक्य रचना को कैसे समाप्त करते हैं? newline और; शायद?
हम अलग-अलग तर्क कैसे देते हैं? 'स्पेस' हो सकता है?

मुझे लगता है कि वर्बिटिम पार्सिंग नईलाइन पर समाप्त होती है। तर्क के भाग के रूप में एक नई पंक्ति में पास होने के लिए, \n उपयोग करें, ठीक उसी तरह जैसे आप सीधे मार खाते हैं।

एक देशी कमांड लाइन एक सरणी नहीं है। यह या तो एक स्ट्रिंग या एएसटी है

आपने इस दावे के लिए कोई आधार नहीं दिया है।

यहां पर PowerShell एक कमांड के लिए एएसटी बनाता है (किसी भी प्रकार का, क्योंकि यह रनटाइम तक नहीं जानता है कि कमांड कब हल होता है)

यदि यह प्रस्ताव लागू हो जाता है, तो यह एक विशेष निर्माण पेश करेगा जहां पावरशेल एएसटी का निर्माण बिल्कुल नहीं करेगा।

यह सुनकर खुशी हुई, @rjmholt

.NET के पास इसके लिए कुछ तर्क हैं जिन्हें हम फिर से लागू करने के लिए मजबूर होंगे

मुझे नहीं लगता कि वास्तव में हमें कुछ भी फिर से लागू करने की आवश्यकता है, जैसा कि मेरे पिछले टिप्पणी शो में कमांड: विंडोज पर, .Arguments -कमांड-स्ट्रिंग-थ्रू पास-थ्रू WinAPI के लिए; यूनिक्स पर, तर्क बनाने के लिए .ArgumentList का उपयोग करें _array_ जिसका उपयोग सीधे exec साथ किया जाता है।

यदि यह प्रस्ताव लागू हो जाता है, तो यह एक विशेष निर्माण पेश करेगा जहां पावरशेल एएसटी का निर्माण बिल्कुल नहीं करेगा।

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

_Functually_, सभी आवश्यकताओं को पहले से ही मौजूदा स्ट्रिंग-शाब्दिक रूपों द्वारा कवर किया गया है, _ अगर आप मूल स्ट्रिंग को एक सिंगल स्ट्रिंग के रूप में पास करते हैं, जिसे मैं दृढ़ता से अनुशंसा करता हूं, एक नए Invoke-NativeShell / ins cmdlet के माध्यम से।

मैं व्यक्तिगत रूप से Invoke-NativeShell cmdlet विचार पसंद करता हूं, कुछ मायनों में कॉल ऑपरेटर --% । इस विचार के बारे में मैंने जो मुख्य चिंता सुनी वह यह है कि यह --% + Ctrl + v से अधिक टाइपिंग है और यहाँ स्ट्रिंग को इंटरपोल करने से शाब्दिक-स्ट्रिंग उपयोगकर्ता के लिए एक और बोझ है (_I व्यक्तिगत रूप से ins लगता है) --% _) टाइप करना आसान है।

इस विचार के बारे में मैंने जो मुख्य चिंता सुनी है वह यह है कि यह --% + Ctrl + v से अधिक टाइपिंग है और यहाँ स्ट्रिंग को इंटरपोल करने से शाब्दिक-स्ट्रिंग उपयोगकर्ता के लिए एक और बोझ है (_I व्यक्तिगत रूप से ins लगता है) --% _) टाइप करना आसान है।

शायद PSRL मदद कर सकता है। चिपकाने वाले रास्तों को घेरने के लिए एक प्रमुख हैंडलर के मुद्दे के समान, पीएसआरएल CommandAst पढ़ सकता है, देखें कि यह ins और ठीक से चिपकाए गए स्ट्रिंग से बच सकते हैं।

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

ज़रूर लेकिन पेड़ तुच्छ होगा। यह उन आदेशों के अर्थ को प्रतिबिंबित नहीं करेगा जिन्हें निष्पादित किया जाना है।

Cmd.exe प्रक्रिया शुरू करें

यह सुनकर खुशी हुई, @ daxian-dbw
विचार से प्यार है, @ निष्ठा से ।

यहाँ स्ट्रिंग को अलग करने से शाब्दिक यहाँ-स्ट्रिंग को विभक्त करना उपयोगकर्ता के लिए एक और बोझ है

मुझे लगता है कि यह एक _plus_ है, क्योंकि - --% - @"<newline>...<newline>"@ आपको सीधे देशी कमांड लाइन में _PowerShell_ चर और भावों के मूल्यों को शामिल करने की अनुमति देता है।

बेशक, यह मानता है कि है कि उपयोगकर्ताओं को बीच का अंतर जानना के एकल-कोटेड (शब्दशः) और डबल-कोटेड (interpolating) तार और चयनात्मक के बारे में ` -escaping की $ , लेकिन मुझे लगता है कि यह एक महत्वपूर्ण है (उन्नत) विकल्प है।

कट-एंड-पेस्ट उपयोगकर्ताओं की मदद करने के लिए, प्रस्तावित PSReadLine सुविधा को @'<newline>...<newline>'@ (शब्दशः) के लिए डिफ़ॉल्ट होना चाहिए।

अंततः, हम ऐसी मानसिकता को बढ़ावा नहीं देना चाहते हैं जहाँ उपयोगकर्ताओं को PowerShell की अद्वितीय वाक्यविन्यास आवश्यकताओं को जानने और समझने की आवश्यकता नहीं है - इसके बजाय, हम उनकी समझ को बढ़ावा देना चाहते हैं, जिससे वे __ की शक्ति प्राप्त करें।

लेकिन उपयोगकर्ताओं को PowerShell के _own_ सिंटैक्स का उपयोग करने के लिए प्रोत्साहित करने के लिए, जो परिभाषा _cross-platform_ द्वारा है, यह अनुमानित रूप से काम करना चाहिए ।
उस अंत तक, # 1995 को निश्चित रूप से

संक्षेप में:

• --% _ ।

• Invoke-NativeShell ( ins ) प्रस्तावित --% ऑपरेटर की सभी सीमाओं से बचा जाता है और "ट्रैप डोर" समाधान प्रदान करता है जिसका उल्लेख

• --% को अपने मूल _argument_ फॉर्म में ही रहना चाहिए, और _Windows-only_ सुविधा (जो यह _effectively_ है, भले ही _technically_ है) नहीं रहनी चाहिए - दूसरे शब्दों में - किसी भी बदलाव की आवश्यकता नहीं है।

  • एक बार # 1995 तय हो जाने के बाद, --% का एकमात्र उद्देश्य Windows_ पर मामलों को समायोजित करना होगा: आपको msiexec जैसे प्रोग्रामों को चलाने के लिए पारित कमांड लाइन के स्पष्ट उद्धरण को नियंत्रित करने की आवश्यकता होगी। इंट्रा-तर्क उद्धरण के बहुत विशिष्ट रूप।

अन्य सुविधाओं मैं वास्तव में पुनश्च v7.x में चाहते हैं में से एक एक देशी आदेश गलत कोड के साथ बाहर निकलने मेरी स्क्रिप्ट बंद करो, की तरह करने की क्षमता है set -e के रूप में इस पर चर्चा की आरएफसी । यदि इसका समाधान Invoke-NativeCommand , तो क्या Invoke-NativeShell साथ भ्रमित हो जाएगा?

बस फिल्म को थोड़ा आगे खेलने की कोशिश कर रहा हूं क्योंकि जितना मैं कॉल देशी फीचर चाहता हूं, मैं वास्तव में चाहता हूं कि मेरी बिल्ड और टेस्ट स्क्रिप्ट्स त्रुटि हो, जब कॉल करने के लिए msbuild, cl, cmake, Conan, npm, आदि और उन मूल आदेशों के साथ बाहर निकलें हर समय $ LASTEXITCODE की जाँच करने के लिए याद किए बिना एक गैर-शून्य निकास कोड। यदि कार्यान्वयन केवल एक और वरीयता चर के माध्यम से है जैसे $PSNativeCommandInErrorActionPreference तो मुझे लगता है कि देशी शेल के आह्वान को प्रभावित करेगा - यह एक मूल "कमांड" और सभी है?

इस विचार के बारे में मैंने जो मुख्य चिंता सुनी है वह यह है कि यह --% + Ctrl + v से अधिक टाइपिंग है और यहाँ स्ट्रिंग को इंटरपोल करने से शाब्दिक-स्ट्रिंग उपयोगकर्ता के लिए एक और बोझ है (_I व्यक्तिगत रूप से ins लगता है) --% _) टाइप करना आसान है।

शायद PSRL मदद कर सकता है। चिपकाने वाले रास्तों को घेरने के लिए एक प्रमुख हैंडलर के मुद्दे के समान, पीएसआरएल CommandAst पढ़ सकता है, देखें कि यह ins और ठीक से चिपकाए गए स्ट्रिंग से बच सकते हैं।

लेकिन क्या बारे में:

$c = gcm ins
& $c ...

PSRL एक कठिन समय को पहचानने वाला है कि वहां क्या हो रहा है। इसे स्टेटफुल करना होगा, अलियास इन्स को इनवॉइस-नेटिवशेल हल करना होगा, फिर यह पता लगाना होगा कि आप कमांडिनफो को कॉल करना चाहते हैं, फिर आर्ग्स को डिमुनिज करें? मैं वास्तव में, विशेष रूप से एक नकली कमांड को आवरण करने के विचार को नापसंद करता हूं।

यहाँ स्ट्रिंग को अलग करने से शाब्दिक यहाँ-स्ट्रिंग को विभक्त करना उपयोगकर्ता के लिए एक और बोझ है

मुझे लगता है कि यह एक _plus_ है, क्योंकि - --% - @"<newline>...<newline>"@ आपको सीधे देशी कमांड लाइन में _PowerShell_ चर और भावों के मूल्यों को शामिल करने की अनुमति देता है।

मैं आपको @ mklement0 का अनुसरण नहीं कर रहा हूं। ऐसा करने के लिए --% क्यों नहीं सिखाया जा सकता है? मैंने पहले ही इसे उपयोग के मामले के रूप में दिया था।

मैं वास्तव में, विशेष रूप से एक नकली कमांड को आवरण करने के विचार को नापसंद करता हूं।

यहाँ कोई नकली कमांड नहीं है, केवल एक bona fide cmdlet, Invoke-NativeShell , जो ins ।

gcm ins ( Get-Command ins ) ins alias के बारे में [System.Management.Automation.AliasInfo] इंस्टेंस के रूप में जानकारी प्रदान करेगा, जिसे आप बाद में & पास कर सकते हैं मंगलाचरण के लिए

इसलिए, आपका उदाहरण बिलकुल ठीक काम करेगा - यह सिर्फ इतना है कि अगर आप gcm ( Get-Command ) का उपयोग करते हैं, तो आपको उपयुक्त स्ट्रिंग-शाब्दिक वाक्यविन्यास _yourself_ को बाहर निकालना होगा, उदाहरण के बिना _optional सुविधा कमांड scaffolding_ जो PSRL _could_ प्रदान करती है, यदि @SeeminglyScience का सुझाव लागू होता है:

$c = gcm ins
& $c @'
python -c 'print("hi")' | cat -n
'@

या, यदि # 13204 में प्रस्तावित नए कच्चे स्ट्रिंग-शाब्दिक वाक्यविन्यास को लागू किया जाता है:

$c = gcm ins
& $c @' python -c 'print("hi")' | cat -n '@

बेशक, अगर आप पावरशेल के स्ट्रिंग शाब्दिक के वाक्य विन्यास से परिचित हैं, तो एक नियमित एकल-उद्धृत स्ट्रिंग भी करेगा: बस कुल '...' स्ट्रिंग के अंदर एम्बेडेड ' को दोगुना करें:

$c = gcm ins
& $c 'python -c ''print("hi")'' | cat -n'

ऐसा करने के लिए --% क्यों नहीं सिखाया जा सकता है?

• --% क्लोजिंग सीमांकक की कमी है, जो इसे पॉवर्सशेल पाइपलाइनों में उपयोग करने से रोकता है, जो एक अस्वीकार्य प्रतिबंध है (ध्यान दें कि (...) संलग्नक _not_ एक विकल्प है, क्योंकि इसका मतलब है कि सभी आउटपुट का फ्रंट-कलेक्शन। मेमोरी में लाइनों के बजाय _streaming_ प्रसंस्करण)।

• यूनिक्स पर, --% _both_ का समर्थन नहीं कर सकते हैं (एकतरफा) $ एक PowerShell मेटाचैकर _and_ के रूप में एक POSIX- शेल मेटाचैकर के रूप में।

दोबारा: वहाँ _no_ के लिए औचित्य है और PowerShell में _different शेल के सिंटैक्स_ को जूता करने का कोई लाभ नहीं है - देशी-शेल कमांड लाइन _as a string_ पास करें, ins , और सभी वैचारिक समस्याएँ दूर हो जाएँगी।

आह्वान-मूलनिवासी का तात्पर्य है कि PowerShell देशी शेल नहीं है। क्या यह धारणा हमेशा सही है और हमेशा रहेगी?

@ उपयोग के मामले में किसी को README या कुछ और से एक देशी कमांड को कॉपी और पेस्ट करना है। यदि वे ins SPACE CTRL + v टाइप करने से अधिक जटिल कुछ कर रहे हैं

@ mklement0

लेकिन उपयोगकर्ताओं को PowerShell के _own_ सिंटैक्स का उपयोग करने के लिए प्रोत्साहित करने के लिए, जो परिभाषा _cross-platform_ द्वारा है, यह अनुमानित रूप से काम करना चाहिए ।
उस अंत तक, # 1995 को निश्चित रूप से

यह ins / --% सही पर चर्चा से अलग है? यदि आप असहमत हैं, तो आप स्पष्ट कर सकते हैं कि नया कमांड / वाक्यविन्यास प्रभावित क्यों होगा?

@SeeminglyScience , हाँ, यह अलग है, लेकिन यह इस धागे में स्पष्ट नहीं है।
एकमात्र कारण # 1995 कभी भी यहां आया है कि यह मूल रूप से इस मुद्दे के पक्ष में बंद हो गया था (हालांकि सौभाग्य से फिर से खुल गया), और यहां ओपी अभी भी कहता है कि यह मुद्दा इसे ठीक कर देगा ("यह इन मुद्दों को भी हल करना चाहिए:") ।
इसलिए, मैं उस ins / --% _not_ पता # 1995, पर जोर देना चाहता था, जिसके लिए तत्काल स्वयं की आवश्यकता होती है।
(केवल तभी जब PowerShell का अपना तर्क सही तरीके से काम कर रहा हो, क्या हम अच्छे विवेक में सलाह दे सकते हैं कि उपयोगकर्ता पूरी तरह से सीखें और PowerShell के अपने सिंटैक्स को गले लगाएं - जो हमें करना चाहिए।)

@ SP3269 , हम उस पुल को पार कर सकते हैं जब हम इसे प्राप्त करेंगे we

परन्तु गंभीरता से:

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

विकल्प के रूप में:

• Invoke-[System]DefaultShell सबसे सटीक नाम होगा (हालांकि यह स्पष्ट रूप से लागू नहीं होगा, PowerShell को कभी भी सिस्टम का डिफ़ॉल्ट शेल बनना चाहिए), लेकिन "देशी" पावरशेल दुनिया में आमतौर पर अधिक इस्तेमाल किया जाने वाला शब्द है।

• Invoke-LegacyShell का विंडोज़ पर कुछ औचित्य है, लेकिन मुझे नहीं लगता कि यूनिक्स उपयोगकर्ता उस शब्द पर बहुत अधिक दया करेंगे।

मुझे लगता है कि मैं यहां सभी के इरादों, विचारों और मुद्दों पर नज़र रखने की कोशिश कर रहा हूं, इस भ्रम को दूर करने की शुरुआत कर रहा हूं। ऐसा लगता है कि हम ( @ mklement0 और I, कम से कम) इसे एक ही वैचारिक समस्या के दो अलग-अलग विचारों के दो अलग-अलग समाधानों के रूप में देख रहे हैं। मैं जो सुझाव दे रहा था, वह --% का उपयोग _parser_ के संकेत के रूप में कर रहा था कि जिस तरह से चीजों को कॉल & ऑपरेटर के साथ संयोजन के रूप में पार्स किया जाता है (जरूरी नहीं कि --% स्टैंडअलोन का उपयोग करके)। दूसरी ओर, माइकल को पॉवरशेल के अपने आंतरिक देशी कमांड ब्रोकर और तर्क पार्सर को बदलने के लिए ins को एक ड्रॉप-इन cmdlet के रूप में देखा जा रहा है, और पावरस्लेयर के पार्सर को बदलने के लिए नहीं देख रहा है, इसके बजाय, का उपयोग करते हुए / यहाँ। -उपयोग किए गए मापदंडों को पकड़ने के लिए (जो मैं कह रहा हूं कि --% भी उपयोग किया जा सकता है।)

-% में एक समापन सीमांकक की कमी है, जो इसे पॉवर्सशेल पाइपलाइनों में उपयोग करने से रोकता है

यह बिंदु मुझे बिल्कुल नहीं मिलता है। यह ins / invoke-nativecommand की तुलना में समापन परिसीमन का अभाव नहीं है। यदि आपको एलएचएस से परिसीमन या फ़ीड करने की आवश्यकता है, तो यहां-स्ट्रिंग्स का उपयोग करें, अन्यथा इसे एक एकल कथन माना जाता है।

जो भी रास्ता चुना जाता है, उसके बावजूद ऐसा लगता है कि कमांडलाइन को भेजने के लिए एक देशी शेल चुनने की आवश्यकता होगी। मेरा सुझाव है कि हम विंडोज पर पर्यावरण चर COMSPEC उपयोग करें (चूक %systemroot%\system32\cmd.exe ) और SHELL लिनक्स पर ( /bin/bash लिए चूक) - यदि शेल ' t अस्तित्व में है, हमें /bin/sh लक्ष्य रखना चाहिए (जो कि ज्यादातर मामलों में वैसे भी काटने के लिए सहानुभूति है।)

-% में एक समापन सीमांकक की कमी है, जो इसे पॉवर्सशेल पाइपलाइनों में उपयोग करने से रोकता है

यह बिंदु मुझे बिल्कुल नहीं मिलता है। यह ins / invoke-nativecommand की तुलना में समापन परिसीमन का अभाव नहीं है। यदि आपको एलएचएस से परिसीमन या फ़ीड करने की आवश्यकता है, तो यहां-स्ट्रिंग्स का उपयोग करें, अन्यथा इसे एक एकल कथन माना जाता है।

मूल रूप से आप cmd --% /c someapp | someOtherApp जैसी चीजों को कॉल नहीं कर सकते हैं और cmd को पाइपलाइन संभाल सकते हैं; PowerShell अभी भी एक पाइपलाइन की व्याख्या करता है (और कुछ अन्य चीजें जैसे && और || जो अन्यथा यूनिक्स लोगों के लिए उपयोगी होगी) के रूप में पावरस्लेक टोकन होने के बजाय इसे मूल निवासी के हिस्से के रूप में पारित करने के बजाय। तर्क स्ट्रिंग।

और लिनक्स पर शेल ( /bin/bash लिए चूक)

नहीं: यूनिक्स जैसे प्लेटफार्मों पर _system_ खोल _invariably_ /bin/sh ।
यह किसी दिए गए _user_ इंटरेक्टिव शेल ( $env:SHELL में परिलक्षित) से अलग है - लेकिन, दुर्भाग्य से, वर्तमान में नहीं तो _PowerShell_ उपयोगकर्ता का शेल है, # 12150 देखें), जो कि (a) विन्यास योग्य है और (b) अक्सर _defaults__ /bin/bash , लेकिन वह भी एक दिया नहीं है, जैसा कि हाल ही में macOS द्वारा प्राप्त किया गया है, जो नए उपयोगकर्ताओं के लिए डिफ़ॉल्ट इंटरेक्टिव शेल के रूप में /bin/zsh को परिवर्तित कर रहा है।

मेरा सुझाव है कि हम विंडोज पर पर्यावरण चर COMSPEC करें

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

अन्य सुविधाओं मैं वास्तव में पुनश्च v7.x में चाहते हैं में से एक एक देशी आदेश गलत कोड के साथ बाहर निकलने मेरी स्क्रिप्ट बंद करो, की तरह करने की क्षमता है set -e के रूप में इस पर चर्चा की आरएफसी । यदि इसका समाधान Invoke-NativeCommand , तो क्या Invoke-NativeShell साथ भ्रमित हो जाएगा?

बस फिल्म को थोड़ा आगे खेलने की कोशिश कर रहा हूं क्योंकि जितना मैं कॉल देशी फीचर चाहता हूं, मैं वास्तव में चाहता हूं कि मेरी बिल्ड और टेस्ट स्क्रिप्ट्स त्रुटि हो, जब कॉल करने के लिए msbuild, cl, cmake, Conan, npm, आदि और उन मूल आदेशों के साथ बाहर निकलें हर समय $ LASTEXITCODE की जाँच करने के लिए याद किए बिना एक गैर-शून्य निकास कोड। यदि कार्यान्वयन केवल एक और वरीयता चर के माध्यम से है जैसे $PSNativeCommandInErrorActionPreference तो मुझे लगता है कि देशी शेल के आह्वान को प्रभावित करेगा - यह एक मूल "कमांड" और सभी है?

हमारे पास उस उद्देश्य के लिए Start-NativeExecution हमारे build मॉड्यूल में हैं।

मैंने देखा है। यदि आप बाद में प्रभावी रूप से एक गैर-शून्य निकास कोड पर फेंकना चाहते हैं तो आप Start-NativeExecution Invoke-NativeShell साथ कैसे संयोजित करेंगे? मैं वास्तव में आशा करता हूं कि PR # 3523 जैसा कुछ इस कॉल देशी फीचर के साथ बनाता है क्योंकि मैं चाहता हूं कि दोनों एक साथ काम करें। मुझे लगता है कि अगर कॉल को मूल हवाओं को cmdlet (Invoke-NativeShell बनाम -%) के रूप में लागू किया जा रहा है, तो -ErrorAction Stop को एक गैर-शून्य निकास कोड पर फेंकने (त्रुटि को समाप्त करने) के लिए लागू किया जा सकता है।

-% में एक समापन सीमांकक की कमी है, जो इसे पॉवर्सशेल पाइपलाइनों में उपयोग करने से रोकता है

यह बिंदु मुझे बिल्कुल नहीं मिलता है। यह ins / invoke-nativecommand की तुलना में समापन परिसीमन का अभाव नहीं है। यदि आपको एलएचएस से परिसीमन या फ़ीड करने की आवश्यकता है, तो यहां-स्ट्रिंग्स का उपयोग करें, अन्यथा इसे एक एकल कथन माना जाता है।

मूल रूप से आप cmd --% /c someapp | someOtherApp जैसी चीजों को कॉल नहीं कर सकते हैं और cmd को पाइपलाइन संभाल सकते हैं; PowerShell अभी भी एक पाइपलाइन की व्याख्या करता है (और कुछ अन्य चीजें जैसे && और || जो अन्यथा यूनिक्स लोगों के लिए उपयोगी होगी) के रूप में पावरस्लेक टोकन होने के बजाय इसे मूल निवासी के हिस्से के रूप में पारित करने के बजाय। तर्क स्ट्रिंग।

हां, मैं वर्तमान व्यवहार @ vexx32 को समझता --% के वर्तमान व्यवहार के बारे में बात नहीं कर रहे हैं (कम से कम मैं नहीं हूं) - हम इसे बढ़ाने के बारे में बात कर रहे हैं, नहीं? मुझे ऐसा क्यों लगता है कि हम सभी एक-दूसरे के यहाँ बात कर रहे हैं? :)

जैसा कि मैंने कहा था, ऊपर का रास्ता, हम & --% साथ काम करने के लिए बढ़ा सकते यह संभव हो सके । मुझे यह भी लगता है कि हमें तर्क के साथ एक शेल के स्पष्ट देशी क्रियान्वयन के बारे में स्पष्ट होने की आवश्यकता है। यह भ्रम का एक निरंतर स्रोत है - यहां तक ​​कि अनुभवी विंडोज़ उपयोगकर्ताओं के लिए - कि किसी भी तरह cmd.exe (एक शेल) को अन्य निष्पादन योग्य "रन" करने की आवश्यकता है; यही बात linux / osx पर भी लागू होती है।

हां, मैं _current_ व्यवहार @ vexx32 को समझता --% के _current_ व्यवहार के बारे में बात नहीं कर रहे हैं (कम से कम मैं नहीं हूँ) - हम इसे बढ़ाने के बारे में बात कर रहे हैं, नहीं? मुझे ऐसा क्यों लगता है कि हम सभी एक-दूसरे के यहाँ बात कर रहे हैं? :)

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

मैंने देखा है। यदि आप बाद में प्रभावी रूप से एक गैर-शून्य निकास कोड पर फेंकना चाहते हैं तो आप Start-NativeExecution Invoke-NativeShell साथ कैसे संयोजित करेंगे? मैं वास्तव में आशा करता हूं कि PR # 3523 जैसा कुछ इस कॉल देशी फीचर के साथ बनाता है क्योंकि मैं चाहता हूं कि दोनों एक साथ काम करें। मुझे लगता है कि अगर कॉल को मूल हवाओं को cmdlet (Invoke-NativeShell बनाम -%) के रूप में लागू किया जा रहा है, तो -ErrorAction Stop को एक गैर-शून्य निकास कोड पर फेंकने (त्रुटि को समाप्त करने) के लिए लागू किया जा सकता है।

वर्तमान में यह Start-NativeExecution { Invoke-NativeShell <strong i="10">@whatever</strong> } ।

यह बिंदु मुझे बिल्कुल नहीं मिलता है। यह ins / invoke-nativecommand की तुलना में समापन परिसीमन का अभाव नहीं है। यदि आपको एलएचएस से परिसीमन या फ़ीड करने की आवश्यकता है, तो यहां-स्ट्रिंग्स का उपयोग करें, अन्यथा इसे एक एकल कथन माना जाता है।

Invoke-NativeShell _need_ किसी भी समापन परिसीमन को नहीं करता है क्योंकि यह एक नियमित कमांड है, जबकि --% का आतंक नहीं है।

और लिनक्स पर शेल ( /bin/bash लिए चूक)

नहीं: यूनिक्स जैसे प्लेटफार्मों पर _system_ खोल _invariably_ /bin/sh ।

मुझे लगता है कि बात एक निष्पादन योग्य स्क्रिप्ट फ़ाइल बनाने और इसे चलाने के बराबर होनी चाहिए, जो ऑपरेटिंग सिस्टम के लिए सही शेल चुनने के कार्य को दर्शाता है और हमें परेशान नहीं होना चाहिए। सहित, अगर यह #! शुरू होता है, तो यह हो।

Invoke-NativeShell पीछे का विचार देशी शेल के _CLI_ के आसपास एक सुविधा आवरण प्रदान करना है।

• यूनिक्स पर, यह पूरी तरह से पर्याप्त है, और एक सहायक स्क्रिप्ट फ़ाइल बनाने से न केवल अतिरिक्त ओवरहेड का परिचय होता है, लेकिन फिर $0 (स्क्रिप्ट फ़ाइल पथ) में एक यादृच्छिक मूल्य की रिपोर्ट करता है, जबकि CLI के माध्यम से यह भविष्यवाणी /bin/sh और किसी अन्य तर्क के साथ कोड-तर्क का पालन करके भी स्पष्ट रूप से सेट किया जा सकता है (जैसे, sh -c 'echo $0' foo )

  • (एक तरफ के रूप में: शेलबंग लाइन #!/bin/sh साथ एक शेल स्क्रिप्ट बनाने का अर्थ है कि पूरे रास्ते से सिस्टम शेल को लक्षित करना स्पष्ट रूप से /bin/sh सीधे

• विंडोज पर, एक बैच फ़ाइल के माध्यम से निष्पादन _would_ फायदे लाता है (लेकिन सिस्टम शेल का पता लगाने के कार्य को प्रस्तुत करने के लिए नहीं, जो $env:ComSpec अनुमानित रूप से करता है), क्योंकि यह % बचने के साथ समस्याओं से बचाएगा। और for ऊपर उल्लिखित व्यवहार।

उत्तरार्द्ध को एक शिष्टाचार के रूप में संबोधित करने के लिए (ताकि उपयोगकर्ताओं को अपने स्वयं के ऑक्स। बैच फ़ाइलों को लिखना न पड़े), वैचारिक स्पष्टता के लिए, हम एक की पेशकश कर सकते हैं
-AsBatchFile एक _opt-in_ के रूप में स्विच करें।

उस ने कहा, अगर आम सहमति है कि कट-एंड-पेस्ट के लिए इस्तेमाल किए जाने वाले सार्वजनिक cmd कमांड लाइनों के बहुमत को _batch-file_ शब्दार्थ के साथ लिखा गया है ( %%i %i बजाय लूप वेरिएबल के रूप में % %% रूप में बचने की क्षमता, शायद हमेशा एक ऑक्स का उपयोग करके। बैच फ़ाइल _on Windows_ (यूनिक्स पर CLI के साथ चिपकाते समय) बेहतर समाधान है - मुझे इस बारे में दृढ़ता से महसूस नहीं होता है, लेकिन इसे स्पष्ट रूप से प्रलेखित करना होगा, विशेष रूप से यह दिया गया है कि इसका अर्थ है कि अन्य स्क्रिप्टिंग भाषाओं से भिन्न व्यवहार प्रदर्शित करना।

@rkeithhill

मेरे लिए, आपके द्वारा लिंक की गई मूल-निवासी-त्रुटियों RFC को केवल # 1995 के रूप में संबोधित करने के लायक है:

दोनों PowerShell में बाहरी कार्यक्रमों (मूल उपयोगिताओं) को प्रथम श्रेणी के नागरिकों (जितना संभव हो सके वैचारिक रूप से) बनाने की दिशा में आवश्यक कदमों का प्रतिनिधित्व करते हैं, _ जो कि उन्हें हमेशा होना चाहिए_।

प्रथम श्रेणी के नागरिक होने का अर्थ है: _direct_ मंगलाचरण ( & लिए केवल _syntactic_ कारणों, स्थितिजन्य रूप से), न कि _via a cmdlet_।
दूसरे शब्दों में: कभी भी Invoke-NativeCommand cmdlet या Start-NativeExecution cmdlet नहीं होना चाहिए।

(एक तरफ के रूप में: Start-NativeExecution का नाम गलत है, क्योंकि build मॉड्यूल में कई कार्य हैं; Start संकेत _asynchronous_ ऑपरेशन, जबकि इनमें से अधिकांश फ़ंक्शन _synchronous_ हैं - के बारे में चर्चा देखें Start-Sleep https://github.com/MicrosoftDocs/PowerShell-Docs/issues/444) पर।

इसलिए, Invoke-NativeShell को किसी विशेष विचार की आवश्यकता नहीं है: PowerShell, जैसा कि पहले से ही है, मूल-शेल निष्पादन योग्य प्रक्रिया द्वारा रिपोर्ट किए गए निकास कोड के आधार पर $LASTEXITCODE सेट करेगा ( cmd / sh ) आह्वान किया गया।

फिर RFC में प्रस्तावित तंत्र उस पर कार्य करेगा, क्योंकि यह सीधे लागू किए गए निष्पादन योग्य पर कार्य करेगा (जैसे, यदि $PSNativeCommandErrorAction = 'Stop' सेट किया जाता है, तो $LASTEXITCODE nonzero होने पर स्क्रिप्ट-समाप्ति त्रुटि उत्पन्न होगी। )

(जल्दी से एक तरफ - यह चर्चा यहाँ नहीं है: जैसा कि एक _per-call_ तंत्र के लिए: कुछ इस तरह
/bin/ls nosuch || $(throw 'ls failed) काम करता है, जैसा कि /bin/ls nosuch || $(exit $LASTEXITCODE) (POSIX शेल के /bin/ls nosuch || exit ); # 10967 चर्चा करता है कि हम दुर्भाग्यवश $(...) (व्याकरण में बड़े बदलाव के बिना) से क्यों नहीं बच सकते; इसी तरह, $LASTEXITCODE स्पष्ट रूप से संदर्भित करने की आवश्यकता को शायद टाला नहीं जा सकता।)

(एक तरफ के रूप में: शेलबंग लाइन #!/bin/sh साथ एक शेल स्क्रिप्ट बनाने का मतलब है कि पूरे रास्ते से सिस्टम शेल को ठीक से /bin/sh सीधे लागू करना)।

वह नहीं है जो मैं कहना चाहता था। मैं यह कहना चाहता था कि PowerShell को यह जानने की आवश्यकता नहीं है कि डिफ़ॉल्ट शेल क्या है क्योंकि ऑपरेटिंग सिस्टम में यह सुविधा है। लिनक्स में यह पता चलता है कि निष्पादन योग्य स्क्रिप्ट को कैसे निष्पादित किया जाए यदि यह #! से शुरू नहीं होता है या इसके साथ शुरू होता है कुछ और, जैसे #!/usr/bin/env python और Windows को पता है कि .CMD स्क्रिप्ट को क्या करना है, इसलिए हमें %COMSPEC% 'n'stuff या तो IMHO में नहीं देखना चाहिए। विंडोज़ अन्य स्क्रिप्ट को भी निष्पादित कर सकता है लेकिन यह स्क्रिप्ट फ़ाइल के विस्तार पर आधारित है, इसलिए यह स्पष्ट रूप से इस मामले पर लागू नहीं होता है।

फिर से, Invoke-NativeShell जनादेश को मूल शेल का _CLI_ कहा जाना चाहिए, न कि पर्दे के पीछे सहायक स्क्रिप्ट फ़ाइलों (साइड इफेक्ट्स के साथ) बनाना (अलग-अलग कारणों को छोड़कर, जैसा कि ऊपर चर्चा की गई

सिस्टम शेल को दृढ़ता से निर्धारित करने के संबंध में, यहां हल करने के लिए कोई समस्या नहीं है: यूनिक्स पर /bin/sh हार्ड-कोडिंग पूरी तरह से उपयुक्त है, जैसा कि विंडोज पर $env:ComSpec सलाह दे रहा है।

नहीं, सिस्टम-कॉल स्तर पर यूनिक्स प्लेटफार्मों को _not_ पता नहीं है कि एक निष्पादन योग्य सादे-पाठ फ़ाइल को कैसे निष्पादित किया जाए? कि आप अभी भी _can_ ऐसी फ़ाइलों को लागू करते हैं, POSIX जैसे गोले की एक सुविधा है: वे exec कोशिश करते हैं, फिर _fall ऐसी फ़ाइलों की व्याख्या करने के लिए _ _ them_for के लिए लिखते हैं; वह है, यह जो भी POSIX जैसा शेल होता है, जो फ़ाइल को निष्पादित करते हुए समाप्त होता है - जबकि PowerShell बस _fails_, क्योंकि यह इस शिष्टाचार वापसी को लागू नहीं करता है (आपको Program 'foo' failed to run: Exec format error मिलेगा)।

कहने की जरूरत नहीं है, इसलिए ऐसी स्क्रिप्ट बनाने के लिए बीमार है।

नहीं, सिस्टम-कॉल स्तर पर यूनिक्स प्लेटफार्मों को _not_ पता नहीं है कि एक निष्पादन योग्य सादे-पाठ फ़ाइल को कैसे निष्पादित किया जाए? कि आप अभी भी _can_ ऐसी फ़ाइलों को लागू करते हैं, POSIX जैसे गोले की सुविधा है: वे exec कोशिश करते हैं, फिर _fall back_ को ऐसी फ़ाइलों की व्याख्या करने के लिए लिखते हैं, जैसे कि __ वह है, यह जो भी POSIX जैसा शेल होता है, जो फ़ाइल को निष्पादित करते हुए समाप्त होता है - जबकि PowerShell बस _fails_, क्योंकि यह इस शिष्टाचार को लागू नहीं करता है (आपको Program 'foo' failed to run: Exec format error मिलेगा)।

csh POSIX की तरह नहीं है और यह exec नंगे स्क्रिप्ट पर विफल नहीं होता है। यह sh । तो perl ।

मुझे आशा है कि यह स्पष्ट है कि यह मेरी बात बनाता है: यह प्रत्येक खोल के लिए __ है जो तय करना है कि क्या करना है, और विभिन्न गोले / स्क्रिप्टिंग भाषाएं अलग-अलग काम करती हैं; पावरशेल वर्तमान में बस विफल हो जाता है - अगर इसे एक विकल्प बनाना था, और आप चाहते थे कि /bin/sh , तो हम एक वर्ग में वापस आ गए हैं: /bin/sh मान लिया जाना चाहिए।

मुझे आशा है कि यह स्पष्ट है कि यह मेरी बात बनाता है: यह प्रत्येक खोल के लिए __ है जो तय करना है कि क्या करना है, और विभिन्न गोले / स्क्रिप्टिंग भाषाएं अलग-अलग काम करती हैं; पावरशेल वर्तमान में बस विफल हो जाता है - अगर इसे एक विकल्प बनाना था, और आप चाहते थे कि /bin/sh , तो हम एक वर्ग में वापस आ गए हैं: /bin/sh मान लिया जाना चाहिए।

exec perl में एक सीधा सिस्टम कॉल है, perl इसे किसी भी तरह से संशोधित नहीं करता है। विशेष रूप से, यह दुभाषिया_ नहीं करता है।

बेशक, यह मानता है कि उपयोगकर्ता एकल-उद्धृत (वर्बटिम) और दोहरे-उद्धृत (प्रक्षेप) स्ट्रिंग्स के बीच के अंतर को जानते हैं और चुनिंदा ` $ का -सुरक्षा करते हैं, लेकिन मुझे लगता है कि यह एक महत्वपूर्ण है (उन्नत) विकल्प है।

शायद यह सिर्फ मेरे लिए है, लेकिन मैं एक -f लिए एक हजार " का व्यापार करूंगा।

@ yecril71pl

पर्ल में निष्पादन एक प्रत्यक्ष प्रणाली कॉल है, पर्ल इसे किसी भी तरह से संशोधित नहीं करता है। विशेष रूप से, यह दुभाषिया का चयन नहीं करता है।

यह सच नहीं हो सकता है अगर यह #! लाइन के बिना स्क्रिप्ट के साथ काम करता है। Linux पर निष्पादित syscall #! बिना काम नहीं करता है, क्योंकि कोई भी आसानी से परीक्षण कर सकता है:

user@Programming-PC:/tmp/exec_test$ ls
test.c  testscript
user@Programming-PC:/tmp/exec_test$ cat test.c
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv) {
  char *binaryPath = "./testscript";

  execl(binaryPath, binaryPath, NULL);

  perror("Error");

  return 0;
}
user@Programming-PC:/tmp/exec_test$ gcc test.c -o testexecutable
user@Programming-PC:/tmp/exec_test$ chmod +x testscript 
user@Programming-PC:/tmp/exec_test$ cat testscript 
echo test from script
user@Programming-PC:/tmp/exec_test$ #works from shell:
user@Programming-PC:/tmp/exec_test$ ./testscript 
test from script
user@Programming-PC:/tmp/exec_test$ #doesn't work via exec syscall:
user@Programming-PC:/tmp/exec_test$ ./testexecutable 
Error: Exec format error
user@Programming-PC:/tmp/exec_test$ vim testscript 
user@Programming-PC:/tmp/exec_test$ cat testscript 
#!/bin/sh
echo test from script
user@Programming-PC:/tmp/exec_test$ #exec syscall works with #! line:
user@Programming-PC:/tmp/exec_test$ ./testexecutable 
test from script
user@Programming-PC:/tmp/exec_test$ uname -a
Linux Programming-PC 4.4.0-176-generic #206-Ubuntu SMP Fri Feb 28 05:02:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
user@Programming-PC:/tmp/exec_test$ 

संपादित करें: मैंने अभी देखा, कि अगर आप मैन पेज के अनुसार लाइब्रेरी फंक्शन execlp उपयोग करते हैं:

यदि किसी फ़ाइल के हेडर को मान्यता नहीं दी गई है (त्रुटि ENOEXEC के साथ प्रयास किया गया (2) विफल रहा), तो ये फ़ंक्शन फ़ाइल के पथ के साथ शेल (/ बिन / श) को इसके पहले तर्क के रूप में निष्पादित करेंगे। (यदि यह प्रयास विफल हो जाता है, तो आगे कोई खोज नहीं की जाती है)

हालाँकि, यह "linux" की विशेषता नहीं है, लेकिन ग्नू c लाइब्रेरी की - और फिर से मैन पेज के अनुसार यह स्पष्ट रूप से / बिन / श का उपयोग करता है और कुछ उपयोगकर्ता-योग्य शेल का नहीं। ( posix/execvpe.c ( new_argv[0] = (char *) _PATH_BSHELL; ) के स्रोत में और sysdeps / जेनेरिक / paths.h) - मुझे नहीं पता कि कौन सा शीर्ष लेख है इस्तेमाल किया ...) ( #define _PATH_BSHELL "/bin/sh" ))

हालाँकि, यह "linux" की विशेषता नहीं है, लेकिन ग्नू c लाइब्रेरी की - और फिर से मैन पेज के अनुसार यह स्पष्ट रूप से / बिन / श का उपयोग करता है और कुछ उपयोगकर्ता-योग्य शेल का नहीं। ( posix/execvpe.c ( new_argv[0] = (char *) _PATH_BSHELL; ) के स्रोत में और sysdeps / जेनेरिक / paths.h) - मुझे नहीं पता कि कौन सा हेडर है इस्तेमाल किया ...) ( #define _PATH_BSHELL "/bin/sh" ))

चूंकि यह sysdeps/**/linux से आता है, यह एक लिनक्स चीज है। यह सामान्य बात भी हो सकती है, लेकिन यह बहुत ही कमनीय है - जाहिर है कि स्थानीय रूप से नहीं बल्कि प्रति ओएस।

हां, मैं _current_ व्यवहार @ vexx32 को समझता --% के _current_ व्यवहार के बारे में बात नहीं कर रहे हैं (कम से कम मैं नहीं हूँ) - हम इसे बढ़ाने के बारे में बात कर रहे हैं, नहीं? मुझे ऐसा क्यों लगता है कि हम सभी एक-दूसरे के यहाँ बात कर रहे हैं? :)

तो --% को समायोजित करने के लिए वर्तमान पिच यह है कि यदि यह वह जगह है जहां कमांड का नाम आमतौर पर होगा, तो इसके दाईं ओर सब कुछ पार्स _as is_ (एक नई पंक्ति तक) है और सीधे bash / cmd को भेजा जाता है। यहां कोई भी पावरस्लाइम सिंटेक्स नहीं है, जैसे यहां-स्ट्रिंग्स और क्या नहीं क्योंकि तब इसमें सभी समान समस्याएं हैं जो --% और वर्तमान में देशी कमांड प्रोसेसर है।

ओह प्रभु ... क्या हर कोई मुझे ट्रोल करने की कोशिश कर रहा है? 😄 नहीं, पैट्रिक - यदि आप पॉवरशेल एक्सप्रेशन का उपयोग करना चाहते हैं, तो यहां --% साथ स्ट्रिंग्स का उपयोग करें। यदि आप मल्टीलाइन चाहते हैं, तो यहां-स्ट्रिंग्स का उपयोग करें। यदि आप चर प्रतिस्थापन के बिना मल्टीलाइन चाहते हैं, तो आप यहां एकल-उद्धरण का उपयोग कर सकते हैं।

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

संपादित करें: अंतिम शब्द

इस आइटम का शीर्षक "कॉल देशी ऑपरेटर है।" जब हम पहले से ही कॉल ऑपरेटर & एक बर्बाद मौका देखते हैं और हमारे पास पहले से ही एक टोकन है जो मूल आदेशों, --% तर्कों से निपटने के लिए डिज़ाइन किया गया था। अभी, & --% का उपयोग करना मान्यता प्राप्त नहीं है और इस तरह एक ब्रेकिंग परिवर्तन की शुरुआत नहीं होगी, हमें इस परिदृश्य को सक्षम करने और इसे यहां चर्चा की जा रही समस्याओं को ठीक करने के लिए विशिष्ट व्यवहार देने का निर्णय लेना चाहिए।

यदि आप पॉवरशेल एक्सप्रेशन का उपयोग करना चाहते हैं, तो यहाँ --% साथ स्ट्रिंग्स का उपयोग करें। यदि आप मल्टीलाइन चाहते हैं, तो यहां-स्ट्रिंग्स का उपयोग करें।

ऑपरेटर की बात यह है कि यह शाब्दिक रूप से किसी भी PowerShell सिंटैक्स को पार्स नहीं करता है। यहाँ ऐसी कोई बात नहीं है। एकल उद्धृत स्ट्रिंग स्थिरांक जैसी कोई चीज नहीं है। यह "पाठ को दाईं ओर भेजें" जैसा कि "सही" के लिए अभिव्यक्ति का मूल्यांकन न करें, स्ट्रिंग में कनवर्ट करें और इसे मूल्य भेजें "

उदाहरण के लिए, यदि आपके पास यह था:

--% @'
echo my native command
'@

यह अनुवाद होगा:

cmd.exe /c "@'"
echo my native command
'@

सिवाय आपको एक पार्सर त्रुटि मिलेगी क्योंकि '@ सिर्फ एक उद्धृत स्ट्रिंग की शुरुआत होगी जिसमें @ शामिल है ।

मुझे लगता है कि शायद आप कार्यान्वयन को अलग तरह से चित्रित कर रहे हैं ताकि यह कमोबेश एक ही चीज़ ins , लेकिन ऊपर वर्तमान पिच --% लिए चर्चा की जा रही है।

यह भी ध्यान देने योग्य है कि यह मौजूदा कार्यक्षमता भी काम करता है। यह उदाहरण ज्यादातर उसी तरह काम करता है:

cmd /c --% @'
echo my native command
'@

मैं दोहराता हूँ:

अभी, का उपयोग कर & के साथ -% मान्यता प्राप्त नहीं है / अपरिभाषित नहीं है और इस तरह से एक परिवर्तन नहीं शुरू होगा, हमें इस परिदृश्य को सक्षम करने और इसे यहाँ चर्चा की जा रही समस्याओं को ठीक करने के लिए विशिष्ट व्यवहार देने का निर्णय लेना चाहिए।

मुझे यह पता भी स्पष्ट वर्तनी करते हैं: यहां-तार का पालन करने की अनुमति दें --% जब साथ प्रयोग किया &

हह वह एक बड़ा ऊफ है - हाँ, मैं चूक गया, क्षमा करें @oising।

उस विचार के बारे में मुझे लगता है कि कुछ संदर्भों में --% मतलब रोकना और "मूल तर्क बंधन में एक बेहतर काम करना" होना थोड़ा भ्रमित करना होगा (इसी तरह यह Invoke-NativeShell काम करने के साथ होगा।

गहरी पुनः exec , @TSlivede खुदाई के लिए धन्यवाद। मुझे संक्षेप में बताने की कोशिश करें और इसलिए उम्मीद है कि इस स्पर्शरेखा को बंद करें; लिनक्स और macOS दोनों पर लागू होता है:

यूनिक्स पर exec नामक कोई सिस्टम (या लाइब्रेरी) फ़ंक्शन नहीं है, उनके नाम में exec साथ संबंधित कार्यों का केवल एक _family_ है (उनमें से अधिकांश एक उपसर्ग के रूप में)।

• _System_ फ़ंक्शंस ( man अनुभाग 2 ), execve इसके दिल में, _fail_ जब आप किसी शबंग-कम स्क्रिप्ट को निष्पादित करने का प्रयास करते हैं।

• _Library_ फ़ंक्शन के बीच, जो सिस्टम फ़ंक्शंस पर_बिल्ट करते हैं_ ( man अनुभाग 3 - man 3 exec ), केवल उन्हीं के पास p ("पथ" के लिए), मैं मान लें कि पास-टू-द-सिस्टम-शेल फ़ॉलबैक (जैसे, execlp ) है।

  • इन कार्यों के लिए GNU पुस्तकालय कार्यान्वयन हार्ड-कोड /bin/sh , जैसा कि @TSlivede ने दिखाया है, जबकि सिर्फ sh का उपयोग करते हैं, और sh पर भरोसा करते हैं $env:PATH (हालांकि, उत्सुकता से, man पेज /bin/sh बताता है)।

जैसा कि कहा गया है, _direct निष्पादन के लिए प्रमुख POSIX- जैसे गोले ( bash , dash , ksh , और zsh ) कागज़-कम स्क्रिप्ट निष्पादित करने के लिए वापस आते हैं _themselves_, जिसका अर्थ है कि वे exec लाइब्रेरी फ़ंक्शंस के बीच फ़ॉलबैक वेरिएंट का उपयोग नहीं करते हैं; इसके विपरीत, perl की अपनी पसंद के लिए exec फ़ंक्शन को कमबैक पर भरोसा करना था; इसी तरह, प्रमुख POSIX जैसे गोले के exec _builtins_, bash को छोड़कर, कमबैक पर निर्भर करते हैं।

चूंकि यूनिक्स में पर्दे के पीछे एक स्क्रिप्ट फ़ाइल का उपयोग अनावश्यक है, हम सिस्टम शेल पथ के बारे में समान धारणा बना सकते हैं जैसे कि फ़ॉलबैक लाइब्रेरी फ़ंक्शंस, और मैं /bin/sh sh के लिए

POSIX कल्पना के बावजूद अनिवार्य करता है :

• /bin/sh मान लेना सुरक्षित है, क्योंकि यह _de facto_ standard लोकेशन है, कम से कम इसलिए नहीं है क्योंकि पोर्टेबल Unix शेल लिखना _noubitates_ sh उल्लेख अपने पूर्ण पथ द्वारा किया जाता है, यह देखते हुए कि वह शील्ड लाइनों का समर्थन केवल _full, शाब्दिक_ पथ ( #!/bin/sh )।

• इसके विपरीत, sh $env:PATH पता लगाने पर निर्भर होना एक सुरक्षा जोखिम हो सकता है, यह देखते हुए कि $env:PATH को एक अलग sh आह्वान करने के लिए हेरफेर किया जा सकता है।

इसी तरह का जोखिम cmd.exe $env:ComSpec cmd.exe माध्यम से पता लगाने पर लागू होता है, इसलिए शायद बेहतर तरीका GetSystemDirectory WinAPI फ़ंक्शन को कॉल करना है और \cmd.exe को जोड़ना है। इसका परिणाम (हमें वैसे भी कमबैक की जरूरत है, अगर $env:ComSpec घटित न हो)।

/bin/sh मान लेना सुरक्षित है, क्योंकि यह _de facto_ standard लोकेशन है, कम से कम नहीं है क्योंकि पोर्टेबल यूनिक्स शेल _noubitates_ लिखते हुए sh इसके पूर्ण पथ से उल्लेख करते हुए, यह देखते हुए कि वह शील्ड लाइनों का समर्थन केवल _full, शाब्दिक_ पथ ( #!/bin/sh )।

आम तौर पर आप #!/usr/bin/env sh (सिस्टम स्क्रिप्ट को छोड़कर) कहते हैं।

• आम तौर पर, आप _d't_: googling "#! / Bin / sh" के बारे में 3,900,000 मैचों में पैदावार, "#! / Usr / bin / env sh" पैदावार के बारे में 34,100 मैच।

• आम तौर पर, आप _shouldn't_: आप अनुमानित रूप से _the_ सिस्टम शेल को लक्षित करना चाहते हैं, /bin/sh , न कि sh उपयोगिता $env:PATH में पहले आने के लिए होती है।

एक निष्पादन योग्य नाम sh को लक्षित करने का एकमात्र कारण सबसे कम-सामान्य-भाजक-मान-पॉसिक्स-सुविधाएँ-केवल _system_ शेल, अर्थात् /bin/sh लक्षित करना है।

आम तौर पर, आप _d't_: googling "#! / Bin / sh" के बारे में 3,900,000 मैचों में पैदावार, "#! / Usr / bin / env sh" पैदावार के बारे में 34,100 मैच।

उपयोगकर्ता स्क्रिप्ट के लिए वेब खोज को सीमित करने का कोई तरीका नहीं है, खासकर जब से कई उपयोगकर्ता स्क्रिप्ट को निष्पादन योग्य चिह्नित नहीं किया जाता है, और यहां तक ​​कि अगर वे हैं, तो वे execlp पर भरोसा कर सकते हैं; लेकिन फिर भी यदि अधिकांश उपयोगकर्ता स्क्रिप्ट ने कहा कि, हमें _normal_ के लिए _customary_ नहीं लेना चाहिए। PowerShell द्वारा चलाई जाने वाली स्क्रिप्ट उपयोगकर्ता स्क्रिप्ट हैं; जब उपयोगकर्ता कोई शेल चाहते हैं, तो वे sh , /bin/sh , जब तक कि वे पागल नहीं होते।

@oising

देशी-शेल कमांड लाइन _as को सिंगल स्ट्रिंग_ (जो भी स्ट्रिंग (-लिटरल) फॉर्म में सबसे आसान है) पास करना, और _only_ सिंगल स्ट्रिंग के रूप में (यूनिक्स के लिए अतिरिक्त, पास-टू-कमांड-लाइन तर्क के लिए सहेजें) केवल) ऊपर चर्चा की गई) - यह मानते हुए कि आप इससे सहमत हैं - आम जमीन की तरह लगता है।

कमांड लाइन को _single string_ के रूप में पास करना इसके लिए आवश्यक है:

• ऐसी कॉल को _PowerShell_ पाइपलाइन में शामिल करने में सक्षम होने के नाते।
• देशी-शेल कमांड लाइन में _PowerShell चर और अभिव्यक्ति_ को शामिल करने में सक्षम होने के नाते।

एक एकल स्ट्रिंग पास करना एक _direct वैचारिक अभिव्यक्ति_ है जो कॉल करेगा; इसके विपरीत, किसी भी तरह से सीधे PowerShell के साथ एक अलग शेल के सिंटैक्स को शामिल करने की कोशिश करना _ _ _ के साथ (वैकल्पिक रूप से नंगे-शब्द) तर्कों से अकल्पनीय समस्याएं आती हैं, जिसके परिणामस्वरूप मूलभूत सीमाओं के साथ एक भ्रामक समझौता होता है, जो मौजूदा --% पहले से ही अवतार लेता है।

जब आप तर्क दे सकते हैं कि यह तब महत्वपूर्ण नहीं है जब हम उस एकल-स्ट्रिंग कमांड लाइन को पास करने के लिए एक _operator_ या _cmdlet_ चुनते हैं (_discoverability_ के प्रश्नों के लिए सहेजें), मुझे दोनों & उपयोग के बारे में वैचारिक चिंता है --% ( & ):

• चिंता फिर से & : अगर हमें कमांड लाइन वाले एक - उद्धृत - स्ट्रिंग को पास करने की आवश्यकता है, तो हम प्रभावी रूप से _expression_ मोड में काम कर रहे हैं, जबकि & वर्तमान में _argument_ मोड का अर्थ है (जिसका अर्थ है: _indateral_ तर्क, केवल आवश्यक होने पर उद्धृत)। इसलिए, & की भागीदारी भ्रामक है।

• चिंता --% है, केवल स्टॉप-पार्सिंग प्रतीक के रूप में --% मूल और muddled शब्दार्थ के बारे में है; यह विशेष रूप से भ्रमित करने वाला होगा यदि --% स्टॉप-पार्सिंग प्रतीक के रूप में _argument_ मोड में संचालित हो (जैसे
  & /bin/ls --% dir1 dir2 ), जबकि & --% _expression_ मोड में संचालित (जैसे & --% '/bin/ls dir1 dir2 >out.txt' )

मुझे एक कदम पीछे ले जाने और वर्तमान में लागू --% , स्टॉप-पार्सिंग प्रतीक की जांच करें:

यह दो अंततः असंबंधित समस्याओं को हल करने का प्रयास था (केवल उस समय विंडोज):

• (ए) एक उपयोग का मामला जो अन्य प्लेटफार्मों पर भी लागू होता है: मुझे _command lines_ का पुनः उपयोग करने के लिए cmd.exe / मूल शेल के रूप में लिखा गया है, इसलिए मुझे उन्हें PowerShell के सिंटैक्स के लिए अनुकूलित करने की आवश्यकता नहीं है।

• (b) हमेशा Windows- केवल एक समस्या: मुझे एक _rogue CLI_ (जो कि एक _single_ बाहरी कंसोल एप्लिकेशन को कॉल करता है) को कॉल करने की आवश्यकता होती है, जिसमें पॉवरशेल के जेनेरिक पीछे के दृश्यों को फिर से उद्धृत करने की आवश्यकता नहीं होती है। , मुझे कमांड लाइन को शिल्प करने की अनुमति देकर अंततः ऐसे CLIs _verbatim_ के लिए WinAPI को पारित किया गया। (समस्या विवरण को इस सीमा तक सीमित करने के लिए कि PowerShell का पुन: उद्धरण आम तौर पर ठीक से काम करता है, जिसके पास यह कभी नहीं है - यह # 1995 का विषय है)।

--% को हल करने के प्रयास के रूप में लागू किया गया था, दोनों (ए) और (बी) के समाधान के प्रयास, और अंत में न तो समस्या को ठीक से हल करते हैं:

• इसे (ए) के समाधान के रूप में विज्ञापित किया गया था, लेकिन वास्तव में इसकी गंभीर सीमाएँ हैं, क्योंकि _ केवल cmd exe सुविधा है जो इसका अनुकरण करती है %...% -स्टाइल पर्यावरण-चर संदर्भ_ का विस्तार है:

  • यह केवल कभी एक _single_ cmd कमांड का समर्थन करता है, यह देखते हुए कि | (और)
    && और || , भले ही वे उस समय लागू नहीं किए गए थे) अव्यवस्थित रूप से पास-टू- cmd भाग को समाप्त कर देते हैं।

  • A _single_ & - जो cmd s-कमांड सेपरेटर है - _is_ से होकर गुजरा है, लेकिन उसने भी _not_ को मल्टी-कमांड सपोर्ट नहीं दिया है, क्योंकि - cmd isn 'के बाद से t वास्तव में शामिल है - & _verbatim को लक्ष्य प्रोग्राम_ में पारित किया गया है; जैसे
    echoArgs.exe --% a & b a प्रतिध्वनित नहीं होता है, फिर b आह्वान करता है, यह शब्दशः तर्क a , & , और b पारित करता है से echoArgs ।

  • cmd बच चरित्र ( ^ ) बिना किसी तर्क के सम्मानित नहीं किया जाता है।

  • एक कोरोलरी के रूप में, मौजूदा पर्यावरण चर को संदर्भित करने वाले %...% टोकन _invariably_ विस्तारित हैं; ^ माध्यम से इसे रोकने का प्रयास ठीक से काम नहीं करता है (जैसे
    echoArgs.exe Don't expand %^USERNAME% , जिसमें cmd रोकता विस्तार _and स्ट्रिप्स ^ _, बरकरार रखती है ^ जब के रूप में PowerShell से कहा जाता है echoArgs.exe --% Don't expand %^USERNAME%

• (बी) के समाधान के रूप में, यह छोटा हो गया:

  • जैसे (a) उपयोग, कमांड में _PowerShell_ वैरिएबल्स और एक्सप्रेशंस को समाहित करने की क्षमता नहीं है - सिवाय इसके कि आप पहले अजीब तरह से परिभाषित करते हैं। पर्यावरण_ चर_ जिसे आप तब %...% --% बाद संदर्भित करते हैं; जैसे
    $env:FOO='foo'; echoArgs.exe --% %FOO%!

जैसा कि यहां चर्चा की गई है (ए) का उचित समाधान Invoke-NativeShell / ins ।

(बी) के लिए उचित समाधान होगा:

• --% समर्थन केवल _first_ तर्क के रूप में विशेष रूप से करें
• और, ins साथ की तरह, इसके लिए _ सिंगल स्ट्रिंग_ का अनुसरण करने की आवश्यकता होती है, जो पास-थ्रू कमांड लाइन _as a__ को पूरा करता है, फिर से _PowerShell_ वैरिएबल और स्ट्रिंग इंटरपोलेशन के तरीके (या स्ट्रिंग के निर्माण के अन्य तरीके)
• जैसे msiexec --% "/i installer.msi INSTALLLOCATION=`"$loc`"" , $loc 'c:\foo\bar none' , वर्बटिम कमांड लाइन में परिणाम होगा /i installer.msi INSTALLLOCATION="c:\foo\bar none" से गुजरना, msiexec की गैर-संतोषजनक आवश्यकता को पूरा करना। <prop>=<value> तर्कों में केवल <value> भाग को ही डबल-उद्धृत किया जाता है।

हालांकि यह _convenient_ नहीं है, यह अराजकता के लिए एक मजबूत समाधान के लिए भुगतान करने की कीमत है जो विंडोज पर गुजरने वाले कमांड-लाइन-आधारित तर्क है।

@ mklement0 रोगी और विचारशील उत्तर (हमेशा की तरह) के लिए धन्यवाद।

इसलिए, मैं तहे दिल से सहमत हूं;

(बी) के लिए उचित समाधान होगा:

• समर्थन -% पहले तर्क के रूप में विशेष रूप से
• और, इन्स के साथ की तरह, इसे एक एकल स्ट्रिंग द्वारा पालन करने की आवश्यकता होती है, जो पास-थ्रू कमांड लाइन को एक पूरे के रूप में गठित करता है,> - फिर से PowerShell चर और अभिव्यक्ति को शामिल करने की क्षमता के साथ स्ट्रिंग इंटरपोलेशन (या अन्य तरीकों से) स्ट्रिंग का निर्माण)
  
  
  
  • जैसे msiexec -% "/ i इंस्टॉलर .msi INSTALLLOCATION = "$loc " ", जिसमें $ लोक 'c: foobar none' से युक्त होगा, जिसके परिणामस्वरूप शब्दशः कमांड लाइन / i इंस्टॉलर .msi INSTALLLOCATION =" c: foobar कोई नहीं "के माध्यम से पारित हो रहा है, msiexec की गैर-जरूरी आवश्यकता को पूरा करता है=केवल तर्कभाग डबल-उद्धृत किया जाना चाहिए।
  
  

यह वह है जिसे मैं (ए) और (बी) दोनों के लिए एक सामान्यीकृत समाधान के रूप में उजागर करने की कोशिश कर रहा हूं, सिवाय इसके कि मुझे अभी भी वास्तव में ऐसा नहीं मिला है (ए) को हल करने के लिए एक स्वतंत्र समस्या के रूप में मौजूद होना चाहिए? क्या मैं वास्तव में संघर्ष कर रहा हूँ अगर (b) & लिए _specifically_ लागू किया जाता है, तो वह कवर (a) भी क्यों नहीं कर सकता है? उदा। ins ... देता है कि & cmd --% ... नहीं हो सकता है? और यह & --% को एक तर्क के रूप में पारित करने की अनुमति नहीं देने के अलावा एक अन्य परिवर्तन नहीं होगा (जो हास्यास्पद रूप से असंभव लगता है।) बोनस जिसे आपको कॉमस्पेक, शेल के बारे में चिंता करने की ज़रूरत नहीं है। जो कुछ भी। कॉल करने वाले को फैसला करने दें।

@ पावरशेल / पावरशेल-समिति ने इसकी समीक्षा की:

• यह वास्तविक उपयोग प्रतिक्रिया प्राप्त करने के लिए एक प्रयोगात्मक सुविधा होगी; हम अभी भी वास्तविक सतर्क के लिए खुले हैं; हम PR समीक्षा में /bin/sh बनाम /bin/env sh को सुरक्षित रखते हैं
• हम --% साथ एक नए ऑपरेटर के रूप में विशेष रूप से "स्टैक्वोवरफ़्लो" परिदृश्य के लिए आगे बढ़ेंगे, जहां उपयोगकर्ता पावरशेल में कमांड-लाइन को काटता है और पेस्ट करता है और इसे बस काम करना चाहिए (निश्चित रूप से, नए ऑपरेटर ने इसे पहले किया था। )
• एक Invoke-NativeShell cmdlet इस प्रस्ताव से अलग है और इसे PowerShellGallery में समुदाय द्वारा प्रकाशित किया जा सकता है; इसके अलावा, यहां एक स्ट्रिंग की आवश्यकता होती है, जो उपयोगकर्ता अनुभव की समस्या को समय से पहले जानने के बिना इसे यहां स्ट्रिंग के रूप में लपेटने के लिए हल नहीं करता है
• हम --% स्विच में परिवर्तन नहीं करना चाहते हैं जहाँ मौजूदा उपयोगकर्ता उस व्यवहार पर निर्भर हो सकते हैं
• जिन उपयोगकर्ताओं को --% स्विच की तरह स्ट्रीमिंग व्यवहार की आवश्यकता होती है, उन्हें उस स्विच का उपयोग जारी रखना चाहिए और विशेष वर्णों से बचना चाहिए
• उपयोगकर्ताओं को --% (या किसी भी समाधान) के बारे में जानने के लिए अभी भी एक खोज समस्या है
• हम वर्तमान में PSReadLine में बदलाव को मनोरंजक नहीं बना रहे हैं ताकि चिपके हुए कंटेंट को संशोधित किया जा सके क्योंकि यहां उपयोगकर्ता के इरादे की भविष्यवाणी करने की कोशिश की जा रही है
• हम ऐसे कई समाधानों को नहीं देख रहे हैं जो यहां स्ट्रिंग-बनाम गैर-स्ट्रिंग (विस्तार) परिदृश्यों के लिए अनुमति देते हैं; उदा & --% बनाम --%

मैं यह भी जोड़ना चाहता हूं कि @ स्टीवएल-एमएसएफटी के बावजूद और मैं इसे खोलने के रूप में एक ही समय में # 1995 को बंद कर रहा हूं, यह वास्तव में उस समस्या का एक निश्चित समाधान के रूप में संचार करने का हमारा इरादा नहीं था।

यह मेरा विचार है कि इस विशेष सुविधा का लाभ # 1995 के प्रभाव से कहीं अधिक महत्वपूर्ण है। मुझे लगता है कि गैर-पीएस प्रबुद्ध टूल के लिए बहुत सारे स्टैकऑवरफ्लो उदाहरण और डॉक्स उदाहरण हैं जो लोग कट (पेस्ट करना चाहते हैं) (स्वयं शामिल हैं)।

इसके अलावा पॉवरशेल की अपनी भाषा के भीतर उचित रूप से भागने की इच्छा है, लेकिन मैं लोगों को जंगली वातावरण में # 1995 को हिट नहीं देख रहा हूं (लेकिन मैं इस पर अधिक विस्तार करूंगा)।

• हम एक नए ऑपरेटर के रूप में --% साथ आगे बढ़ेंगे

इसे बाहर खींचने के लिए क्षमा करें, और मैं अतिरिक्त चर्चा की तलाश में नहीं हूं, लेकिन ऑपरेटर किस तरह का है? (मैं मुख्य रूप से वाक्य रचना में रुचि रखता हूं।)

$a = --% find . -iname *$pdf -print0 | xargs -0 ls -ltr

पाइप किसे मिलता है? क्या होता है $ ? & , && , और || ।

क्या शर्तों के तहत, यदि कोई हो, तो --% एक पीएस पाइप में प्रयोग करने योग्य होगा जो आगे बढ़ेगा?

धन्यवाद।

इसे बाहर खींचने के लिए क्षमा करें, और मैं अतिरिक्त चर्चा की तलाश में नहीं हूं, लेकिन ऑपरेटर किस तरह का है? (मैं मुख्य रूप से वाक्य रचना में रुचि रखता हूं।)

एएसटी वार यह संभवतः तकनीकी रूप से एक ऑपरेटर नहीं होगा, लेकिन यह स्वयं एएसटी प्रकार है। यदि इसे ऑपरेटर के रूप में लागू किया जाता है, तो यह एक अपर ऑपरेटर होगा।

$a = --% find . -iname *$pdf -print0 | xargs -0 ls -ltr

पाइप किसे मिलता है? क्या होता है $ ? & , && , और || ।

स्ट्रिंग find . -iname *$pdf -print0 | xargs -0 ls -ltr रूप में भेजा जाएगा देशी खोल के लिए है। $a अभी भी आबाद होंगे, इसलिए आप अगली पंक्ति के पाइप में कुछ कर सकते हैं।

क्या शर्तों के तहत, यदि कोई हो, तो --% एक पीएस पाइप में प्रयोग करने योग्य होगा जो आगे बढ़ेगा?

यदि ~ पहले कमांड एलिमेंट स्लॉट में ~ यह एक स्टेटमेंट की शुरुआत में है, तो शायद नहीं। यह नए सिंटैक्स के ड्रा में से एक है। यदि पहले स्लॉट में नहीं है ~ शुरू में, यह आज की तरह काम करता रहेगा।

(@ daxian-dbw @ स्टीवएल-एमएसएफटी यदि इनमें से कोई भी गलत है तो कृपया सही करें ❤️)

@ निश्चय ही सही है

अगर पहले कमांड एलिमेंट स्लॉट में, शायद नहीं। यह नए सिंटैक्स के ड्रा में से एक है। यदि पहले स्लॉट में नहीं है, तो यह आज की तरह काम करना जारी रखेगा।

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

मुझे लगता है कि स्ट्रीमिंग व्यवहार इस विशेषता के लिए एक विचार नहीं है क्योंकि यह मुख्य रूप से "स्टैकओवरफ़्लो" परिदृश्य के लिए है। इसलिए मुझे लगता है कि हम बेहतर सिर्फ --% एक विशेष वक्तव्य को आश्चर्यजनक बना देंगे, ताकि यह स्पष्ट हो कि यह _PowerShell_ पाइपलाइनों के साथ काम नहीं करेगा।

आह मुझे पता था कि एक कारण था कि "कमांड एलिमेंट स्लॉट" गलत था। मैं एक बयान की शुरुआत में था। मैं इसे ठीक कर दूँगा, धन्यवाद!

अपस्ट्रीम कमांड से आउटपुट को bash खिलाया नहीं जा सकता

क्या _upstream_ का मतलब _us_ है? मुझे लगता है कि कर सकते हैं: 'ls' | bash । नहीं बल्कि संभव करने के लिए एक अजीब बात है।

इस बारे में @jpsnover के साथ चर्चा कर रहे शरणार्थी के रूप में #! प्रस्ताव दिया। इस मामले में, आप सिर्फ टाइप करेंगे:

#!/bin/sh ls | grep foo
#!sh | grep foo

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

एक वैकल्पिक ऋण चिह्न वाक्यविन्यास उधार लेने के लिए हो सकता है:

powershell ```bash ls | grep foo ```

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

इस मामले में, यह संभावित रूप से काम कर सकता है:

powershell $a = ```bash ls | grep foo ``` | select-string bar

@ स्टीवएल-एमएसएफटी मार्कडाउन सिंटेक्स बहुत मायने रखता है। यदि हम निर्दिष्ट करने में सक्षम हैं। अन्य प्रकार जैसे कि अजगर या शायद विस्तार से?

शेबंग #! मौजूदा टिप्पणियों के साथ हस्तक्षेप करेगा।

यह मुझे बड़े पैमाने पर लगता है, दोनों को पार्स करने में और उपयोगकर्ताओं के लिए वास्तव में _use_ को संभालने के लिए।

और हाँ, हमें लोगों को लाइनों के साथ भ्रमित करने की आवश्यकता नहीं है कि _should_ टिप्पणियों के रूप में टिप्पणियों के रूप में बाहर न हों। #Requires पहले से ही अजीब तरह से किनारा कर रहा है, शेबंग पर एक पूर्ण विंडोज लोगों को भ्रमित करने के लिए जा रहा है, और शायद लिनक्स के लोग भी।

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

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

मैं सचमुच इनलाइन C # के लिए पूछना बंद नहीं करूंगा, हालांकि मुझे पता है कि यह एक बुरा विचार है।

मार्कडाउन सिंटैक्स मनमाने भाषा कोड का परिचय नहीं देता है क्योंकि एम्बेडेड स्क्रिप्ट एक बच्चे की प्रक्रिया में चलेगा। आप @' के अंदर मनमाना भाषा कोड रख सकते हैं और कुछ भी बुरा नहीं होता है।

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

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

मैं सिंगल-लाइन सामान को छोड़ना पसंद करूंगा। विदेशी कोड द्वीप प्रमुख होने चाहिए, अन्यथा किसी को समझ नहीं आएगा कि क्या चल रहा है।

@ yecril71pl मैं खुद उस ओर

टीम चर्चा में और जेफरी के साथ भी, हमें पॉवरशेल स्क्रिप्ट के भीतर अन्य भाषाओं को चलाने के इच्छुक लोगों के खिलाफ नहीं होना चाहिए।

बिल्कुल 100%, लेकिन इसका मतलब यह नहीं है कि इसे सीधे भाषा में बनाया जाना चाहिए।

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

यह पहले से ही यहाँ-तार के साथ किया जा सकता है? क्या आप इस बारे में थोड़ा विस्तार से बता सकते हैं कि मौजूदा तरीकों से क्या लाभ होता है?

इसके अलावा अजगर और मारपीट पर रोक क्यों? C #, CIL, C ++ क्यों नहीं?

लोगों को ऐसा करने की आवश्यकता नहीं है। वे पसंद करने पर उस स्क्रिप्ट को PowerShell में पोर्ट करने का निर्णय ले सकते हैं। यह सिर्फ उपयोगकर्ताओं को सामान प्राप्त करने के लिए पावरशेल में कटौती और पेस्ट करने में सक्षम होने के लिए एक विकल्प प्रदान करता है।

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

वास्तव में हालांकि यह इस विषय के मूल विषय से काफी अलग अवधारणा है जिसमें बहुत व्यापक निहितार्थ हैं। मैं इसके लिए एक नया मुद्दा बनाने की सलाह दूंगा।

यह पहले से ही यहाँ-तार के साथ किया जा सकता है? क्या आप इस बारे में थोड़ा विस्तार से बता सकते हैं कि मौजूदा तरीकों से क्या लाभ होता है?

एक सार्वभौमिक कोड संपादक उन्हें पता लगाने और उन्हें उचित रूप से सजाने में सक्षम होगा, जबकि @' साथ कुछ भी नहीं होना है क्योंकि संपादक को पता नहीं है कि अंदर क्या है।

इसके अलावा अजगर और मारपीट पर रोक क्यों? C #, CIL, C ++ क्यों नहीं?

क्योंकि वे स्क्रिप्टिंग लैंग्वेज नहीं हैं?

एक सार्वभौमिक कोड संपादक उन्हें पता लगाने और उन्हें उचित रूप से सजाने में सक्षम होगा, जबकि @' साथ कुछ भी नहीं होना है क्योंकि संपादक को पता नहीं है कि अंदर क्या है।

एक संपादक बता सकता है कि bash -c @' में कोड बाड़ के रूप में आसानी से बैश होता है। साथ ही चुनौतीपूर्ण भाग यह निर्धारित नहीं कर रहा है कि कोड का एक भाग किस भाषा का है, यह भाषा सर्वर और सिंटैक्स हाइलाइटर्स की जुगलबंदी है। महत्वपूर्ण समय और प्रयास निवेश के बिना काम करने का एकमात्र तरीका यह अनिवार्य रूप से इसे प्रस्तुत करना होगा जैसे कि यह यहां एक स्ट्रिंग था।

क्योंकि वे स्क्रिप्टिंग लैंग्वेज नहीं हैं?

C # और C ++ दोनों में स्क्रिप्ट ओरिएंटेड सबसेट है। यहां तक ​​कि अगर वे नहीं, "स्क्रिप्टिंग भाषा" कोई वास्तविक परिभाषा के साथ व्यक्तिपरक है। यह समावेशी के लिए निश्चित सीमा के रूप में सहायक नहीं है और इसे नहीं माना जाएगा।

C # और C ++ दोनों में स्क्रिप्ट ओरिएंटेड सबसेट है। यहां तक ​​कि अगर वे नहीं, "स्क्रिप्टिंग भाषा" कोई वास्तविक परिभाषा के साथ व्यक्तिपरक है।

एक भाषा एक (स्टैंड-अलोन) स्क्रिप्टिंग भाषा है, जब आप सामान्य रूप से interpet options… script arguments… कॉल करते हैं और कॉल को छोड़कर कुछ भी नहीं होता है जो कि इसे छोड़ने का इरादा था, अस्थायी सामान और निजी दुभाषिया को छोड़कर। इसका अर्थ यह भी है कि इसे चलाने के लिए आम तौर पर दुभाषिया की एक प्रति की आवश्यकता होती है। ऐसी एम्बेडेड स्क्रिप्टिंग भाषाएं हैं जिन्हें आप इस तरह नहीं चला सकते हैं।

@SeeminglyScience

यह पहले से ही यहाँ-तार के साथ किया जा सकता है? क्या आप इस बारे में थोड़ा विस्तार से बता सकते हैं कि मौजूदा तरीकों से क्या लाभ होता है?

लोग आज यहां स्ट्रिंग्स का उपयोग कर सकते हैं या वे देशी कमांड्स को दिए गए सभी तर्कों से बच सकते हैं यदि वे यह पता लगा सकते हैं कि इसे सही कैसे प्राप्त किया जाए। यहां आशय यह है कि नए उपयोगकर्ताओं के लिए कट-एंड-पेस्ट (स्टैकओवरफ़्लो) परिदृश्यों के लिए इसे सरल बनाया जाए।

इसके अलावा अजगर और मारपीट पर रोक क्यों? C #, CIL, C ++ क्यों नहीं?

यहां समर्थित परिदृश्यों को मूल कमांड पर भेजे गए पाठ का एक ब्लॉक है। किसी भी भाषा का समर्थन किया जा सकता है अगर वह उस सम्मेलन का समर्थन करता है। एक अस्थायी स्रोत फ़ाइल बनाने का कोई प्रस्ताव नहीं है और इसे संकलित किया गया है।

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

इस बात की कोई उम्मीद नहीं है कि आपको मिश्रित भाषा सिंटैक्स रंग मिल जाएगा। किसी अन्य भाषा की कोई भी नेस्टेड स्क्रिप्ट सिर्फ नीरस होगी।

वास्तव में हालांकि यह इस विषय के मूल विषय से काफी अलग अवधारणा है जिसमें बहुत व्यापक निहितार्थ हैं। मैं इसके लिए एक नया मुद्दा बनाने की सलाह दूंगा।

प्रस्तावित कार्यान्वयन मूल मुद्दे से अलग है, लेकिन समस्या वही है जो कट-एंड-पेस्ट और "जस्ट वर्क" परिदृश्य है।

लोग आज यहां स्ट्रिंग्स का उपयोग कर सकते हैं या वे देशी कमांड्स को दिए गए सभी तर्कों से बच सकते हैं यदि वे यह पता लगा सकते हैं कि इसे सही कैसे प्राप्त किया जाए। यहां आशय यह है कि नए उपयोगकर्ताओं के लिए कट-एंड-पेस्ट (स्टैकओवरफ़्लो) परिदृश्यों के लिए इसे सरल बनाया जाए।

सही है लेकिन यह वास्तव में आसान कैसे है? मुझे लगता है कि यह व्यक्तिपरक है, लेकिन ये मुझे अलग नहीं लगते हैं:

~~~ powershell
$ a = `` `बैश
खोजो। -iname * $ pdf -print0 | xargs -0 एलएस-टाइप

~~~

vs

```powershell
$a = bash -c @'
   find . -iname *$pdf -print0 | xargs -0 ls -ltr
'@

वे इस अपवाद के साथ लगभग एक ही लगते हैं कि बाद में जो कुछ होने जा रहा है उसमें काफी स्पष्ट है।

यहां समर्थित परिदृश्यों को मूल कमांड पर भेजे गए पाठ का एक ब्लॉक है। किसी भी भाषा का समर्थन किया जा सकता है अगर वह उस सम्मेलन का समर्थन करता है। एक अस्थायी स्रोत फ़ाइल बनाने का कोई प्रस्ताव नहीं है और इसे संकलित किया गया है।

वैसे C # को अस्थायी स्रोत फ़ाइल की आवश्यकता नहीं होगी। शायद CIL या तो नहीं (C ++ के बारे में कोई विचार नहीं)। किसी भी तरह से हालांकि एक निष्पादक (जैसे bash / अजगर / cmd) को कॉल करने के लिए एक कोड बाड़ कड़ाई से सिंथेटिक चीनी है, जो मुझे भ्रमित कर रहा है। कोड बाड़ का अर्थ भाषा समर्थन imo है।

इस बात की कोई उम्मीद नहीं है कि आपको मिश्रित भाषा सिंटैक्स रंग मिल जाएगा। किसी अन्य भाषा की कोई भी नेस्टेड स्क्रिप्ट सिर्फ नीरस होगी।

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

प्रस्तावित कार्यान्वयन मूल मुद्दे से अलग है, लेकिन समस्या वही है जो कट-एंड-पेस्ट और "जस्ट वर्क" परिदृश्य है।

निष्पक्ष लेकिन हम पहले से प्रस्तावित समाधानों पर चर्चा करने में पहले से ही 145 टिप्पणियाँ हैं। खासकर जब से यह धागा पहले से ही एक निष्कर्ष पर पहुंच गया है, तो आप संभवतः एक नए, समर्पित धागे में बहुत अधिक भागीदारी देखेंगे।

वैसे C # को अस्थायी स्रोत फ़ाइल की आवश्यकता नहीं होगी। शायद CIL या तो नहीं (C ++ के बारे में कोई विचार नहीं)। किसी भी तरह से हालांकि एक निष्पादक (जैसे bash / अजगर / cmd) को कॉल करने के लिए एक कोड बाड़ कड़ाई से सिंथेटिक चीनी है, जो मुझे भ्रमित कर रहा है। कोड बाड़ का अर्थ भाषा समर्थन imo है।

मैं बस इस पर @SeeminglyScience की टिप्पणी प्रतिध्वनित करना चाहता हूं। हम लाइब्रेरी Microsoft.CodeAnalysis.CSharp.Scripting साथ संकलन को शामिल किए बिना C # स्क्रिप्ट चला सकते

आप कह सकते हैं कि PowerShell में कोड फ़ेंसिंग सिंटैक्स एक देशी कमांड को कॉल करने के लिए है, जो सैद्धांतिक रूप से इसकी अनुमति देता है:

    ```c:\mypath\MyArbitraryExe
        args to my arbitrary executable
    ```

लेकिन तब यह उपयोगकर्ताओं की मार्कडाउन से स्थापित समझ से अलग है, जिसे

जो सैद्धांतिक रूप से यह अनुमति देता है

आप स्क्रिप्ट को अंदर रखते हैं, तर्कों के नहीं, और स्क्रिप्ट इनपुट स्ट्रीम के बराबर है। इसके अलावा, यदि यह एसओ सहायता प्रदान करने के लिए है, तो पूर्ण पथ की अनुमति नहीं दी जानी चाहिए।

आप स्क्रिप्ट को अंदर रखते हैं, तर्कों के नहीं, और स्क्रिप्ट इनपुट स्ट्रीम के बराबर है

स्क्रिप्ट बैश / cmd / अजगर के लिए तर्क है।

इसके अलावा, यदि यह एसओ सहायता प्रदान करने के लिए है, तो पूर्ण पथ की अनुमति नहीं दी जानी चाहिए।

फिर इसे इस उदाहरण के लिए स्विच करें:

~ powershell$ a = ipconfig /all ~

या पहले पथ के लिए मनमाना exe जोड़ें।

आप स्क्रिप्ट को अंदर रखते हैं, तर्कों के नहीं, और स्क्रिप्ट इनपुट स्ट्रीम के बराबर है

स्क्रिप्ट बैश / cmd / अजगर के लिए तर्क है।

उनमें से कोई भी एक स्क्रिप्ट को स्थिति संबंधी तर्क के रूप में पारित करने की अनुमति नहीं देता है। CMD भी बैच फ़ाइल की अनुमति नहीं देता है।

इसके अलावा, यदि यह एसओ सहायता प्रदान करने के लिए है, तो पूर्ण पथ की अनुमति नहीं दी जानी चाहिए।

फिर इसे इस उदाहरण के लिए स्विच करें:

$ a = `` `ipconfig
/सब

वह काम नहीं करेगा।

लगता है जैसे हम इस मार्कडाउन विचार के लिए काम करने के लिए बहुत ही मनमाने आधार पर बहुत सारे विशेष मामलों को बना रहे हैं।

इसके अलावा, मार्कडाउन में इसका मुख्य कारण सिंटैक्स हाइलाइटिंग के लिए भी समर्थित है। अगर हम भाषा में ऐसा कुछ जोड़ते हैं तो यह एक निरंतर अनुरोध होगा।

यह एक प्रभावी उपाय नहीं है।

इस बारे में @jpsnover के साथ चर्चा कर रहे शरणार्थी के रूप में #! प्रस्ताव दिया

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

अगर कोई किसी के साथ बेहतर तरीके से पेश आया है अब सुविधा द्वारा भेज दिए जाने के बाद। मुझे नहीं लगता कि #! या मार्कडाउन दृष्टिकोण "अन-पॉवरशेल-मिलावटी" कमांड लाइन स्ट्रिंग को मूल निर्वासन में आपूर्ति करने के लिए एक बेहतर समाधान है। शायद मुझे इसे इस्तेमाल करने की कोशिश करने की ज़रूरत है लेकिन मेरी शुरुआती प्रतिक्रिया है ... उम, ईव।

_ यदि हम (और पॉवरशेल) जानते हैं कि हम एक देशी निष्पादन योग्य चलाते हैं, तो हमें "देशी ऑपरेटर को कॉल करने" की आवश्यकता क्यों है?

यदि PowerShell इनपुट स्ट्रिंग को पार्स करता है और CommandAst प्राप्त करता है तो PowerShell कमांड की खोज करता है।
यदि कमांड एक देशी कमांड है, तो PowerShell, NativeCommandProcessor पर स्थित है।
हम उस मामले के लिए नए (प्रयोगात्मक NativeCommandProcessor) को लागू कर सकते हैं, जो Ast की सीमा को फिर से पार्स कर देगा (ताकि इनपुट स्ट्रिंग हो) ताकि OS निष्पादन नियम के रूप में मूल निष्पादन योग्य नाम / पथ और बाकी स्ट्रिंग को तर्क या तर्क के रूप में प्राप्त किया जा सके।

यदि कोई उपयोगकर्ता शेल से कॉपी-पेस्ट चाहता है तो उसे "cmd" लिखना चाहिए"या" बैश"- जो संपादन के बिना काम करेगा।
यदि कोई उपयोगकर्ता एक देशी कमांड लाइन को कॉपी-पेस्ट करना चाहता हैg++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 तरह भी काम करेगा।

यदि कोई उपयोगकर्ता शेल से कॉपी-पेस्ट चाहता है

हमारे पास इसके लिए Get-/Set-Clipboard ।

उस मामले के लिए जो Ast सीमा को फिर से पार्स करेगा (जो कि इनपुट स्ट्रिंग है) ताकि मूल निष्पादन योग्य नाम / पथ और बाकी स्ट्रिंग को तर्क या तर्क के रूप में OS नियमों द्वारा प्राप्त किया जा सके।

यहाँ मेरी सोच यह है कि आप ऐसा कर रहे हैं:

• अक्षम्य रूप से कमांड एएसटी पार्स, केवल एक स्ट्रिंग के रूप में बाद में हद तक वापस लाने के लिए और मूल एएसटी को दूर फेंक दें, या
• आप एएसटी लेते हैं और इसे वापस एक स्ट्रिंग (वर्तमान NativeCommandProcessor करता है) में सुधार करने की कोशिश करते हैं, लेकिन ऐसा करने में चीजें खो जाएगी

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

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

इसलिए:

--% ps -o pid,args -C bash | awk '/running_script/ { print $1 }'

के रूप में टोकन होगा:

--% ps -o pid,args -C bash | awk '/running_script/ { print $1 }'
|-||-----------------------------------------------------------|
 |                                  \
Native call operator        Invocation to be passed to native shell

(ध्यान दें कि हम मूल शेल में --% बाद भी सीधे स्पेस भेजते हैं, क्योंकि स्ट्रिंग --% तुरंत बाद शुरू होती है)

फिर इस टोकन को बहुत ही साधारण एएसटी में लपेटा जाता है, जैसे:

// We need to carefully work out what AST this inherits from
// This syntax has almost no interoperability with PowerShell by design,
// so can't implement fields like redirections or backgrounding faithfully.
// But in order to participate in pipelines and similar, would need to extend a more concrete class
public class NativeCallInvocationAst : StatementAst
{
    public string NativeInvocation { get; }
}

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

हालांकि यह सब लागू करने योग्य लगता है, मेरे मन में कुछ प्रश्न हैं:

• देशी खोल विन्यास योग्य है? यदि नहीं, तो हम इसे कैसे उचित ठहराते हैं? यदि ऐसा है, तो क्या यह वाक्यविन्यास (वाक्यविन्यास को जटिल करना) के हिस्से के रूप में स्पष्ट होना चाहिए, या वरीयता चर के रूप में लागू किया जाना चाहिए (इसे खोजना और प्रबंधित करना कठिन है)?
• क्या ऐसा कार्यान्वयन खोज योग्य है और लोगों को भ्रमित नहीं करेगा? क्या यूजर्स समझ पाएंगे कि पावरशेल यहां कितना कम चल रहा है, या जब वे | या & या यहां तक ​​कि स्ट्रिंग्स का उपयोग करते हैं तो क्या हो रहा है?
• यहां सिंगल-लाइन वर्बटीम स्ट्रिंग द्वारा कितने परिदृश्य सेवित किए जा रहे हैं? क्या हम यह पता लगाने के लिए इसे लागू करने जा रहे हैं कि कई लोग मल्टी-लाइन इनवोकेशन चाहते हैं? क्या इन बाधाओं को जोड़ने के लिए एक ही उद्धरण से बचने के लिए कुछ करने से बचने की आवश्यकता है?
• यह बिल्कुल नई भाषा वाक्य रचना के लिए एक बहुत विशिष्ट परिदृश्य की तरह लगता है। यदि हम एक नया शब्दशः स्ट्रिंग सिंटैक्स बना रहे हैं, तो हम इसे सीधे देशी आह्वान की अवधारणा पर क्यों जोड़ रहे हैं? यदि हम एक नया आह्वान तंत्र बना रहे हैं, तो हम इसे सीधे अन्य गोले की अवधारणा पर क्यों जोड़ रहे हैं? अच्छी वाक्य रचना और अच्छी भाषा के निर्माण, दोनों वाक्य रचना और कार्यात्मक रूप से, और भाषा में बहुत अधिक सेंकना न करने की कोशिश करते हैं (बजाय उपयोगकर्ता को उनके कार्यक्रम के रूप में इकट्ठा करने के लिए तत्वों का एक मंच प्रदान करते हैं) - क्या हमारा प्रस्तावित देशी कॉल सिंटैक्स बार से मिलता है एक नए प्राथमिक वाक्यविन्यास के लिए कार्यक्रमों में रचना की जाए? क्या कोई बेहतर वैकल्पिक तरीका है जो हम इस समस्या को एक सरल तरीके से हल कर सकते हैं, लेकिन फिर भी हमें बिल्डिंग ब्लॉक को अछूता रखने की अनुमति देता है ताकि उन्हें अन्य समस्याओं को हल करने के लिए तैयार किया जा सके?
• क्या अन्य गोले या अन्य भाषाएँ इस पर अमल करेंगी या पहले से ही हैं? सिंटैक्स स्तर पर, या किसी अन्य स्तर पर? यदि हां, तो कैसे?

यहाँ मेरी सोच यह है कि आप ऐसा कर रहे हैं

@rjmholt CommandAst के पास इनपुट स्ट्रिंग के साथ

हालाँकि यह लागू हो जाता है, मुझे लगता है कि हमें परीक्षण करने के लिए उपयोग मामलों के एक सेट की आवश्यकता है। मुझे निम्नलिखित का "प्रस्ताव" दें:

• केस 1 का उपयोग करें: मैं नियमों के हवाले / भागने के बारे में जाने बिना काम करने के लिए एकल एक्सल शाब्दिक (कोई प्रक्षेप नहीं) आह्वान चाहता हूं जैसे: g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 । इसके लिए वर्तमान कार्य-आस-पास यह पता लगाने के लिए है कि क्या बोली जाती है e..g: g++ timer.cpp '@conanbuildinfo.args' -o timer --std=c++11 अधिक जटिल उदाहरण में कई पंक्तियों में फैली कमांड लाइनें शामिल हो सकती हैं जैसे:

tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz \
    --exclude=/proc \
    --exclude=/lost+found 

वर्तमान वर्कअराउंड ( \ लिए स्वैप बैकटिक) जैसे:

tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz `
    --exclude=/proc `
    --exclude=/lost+found

• केस 1 ए का उपयोग करें: मुझे काम करने के लिए पीएस इंटरपोलेशन के साथ एक एकल निर्वासन चाहिए जैसे: g++ $CppFile @conanbuildinfo.args -o timer --std=c++11 । इसके लिए वर्तमान काम-आस-पास यह पता लगाने के लिए है कि क्या (सिंगल या डबल) और क्या ई से बचना है ..g: g++ $CppFile '@conanbuildinfo.args' -o timer --std=c++11 अधिक जटिल उदाहरण में कई लाइनों में फैली कमांड लाइनें शामिल हो सकती हैं जैसे:

tar -cvpzf "/share/Recovery/Snapshots/${ComputerName}_`$(date +%Y%m%d).tar.gz" \
    --exclude=/proc \
    --exclude=/lost+found 

वर्तमान वर्कअराउंड, डबल-उद्धरण पहले arg, \ लिए backtick स्वैप करें और `$ (दिनांक + ...) की शुरुआत में $ बच जाएं।

• केस 2 का उपयोग करें: मैं एक अन्य शेल में शाब्दिक विडंबनाबद्ध कमांड निष्पादित करना चाहता हूं जैसे: ps -o pid,args -C bash | awk '/running_script/ { print $1 }' और wsl ls $foo && echo $PWD । _मुझे यकीन नहीं है कि यह पिछले एक से एक अलग उपयोग के मामले की जरूरत है ।_ वर्तमान काम के आसपास के लिए bash कमांड उद्धृत करना है जैसे: bash -c 'ps -o pid,args -C bash | awk ''/-bash/ { print $1 }''' । इस उपयोग के मामले में बहु-तार तार शामिल हो सकते हैं जैसे:

ps -o pid,args -C bash | \
awk '/running_script/ { print $1 }'

• केस 2 ए का उपयोग करें: मैं कुछ पीएस इंटरपोलेशन के साथ एक अन्य शेल में एक पाइपलाइड कमांड निष्पादित करना चाहता हूं - क्या यह उपयोग का मामला है?

• केस 3 का उपयोग करें: मुझे काम करना जारी रखने के लिए npm run $scriptName आवश्यकता है अर्थात चरों को इंटरपोल करें । (यह निहित हो सकता है और कहा जाने की आवश्यकता नहीं है)।

एक सवाल है कि क्या interpolating स्ट्रिंग्स यानी g++ $CppFile @conanbuildinfo.args -o timer --std=c++11 लिए मामलों का उपयोग किया जाना चाहिए या क्या हम उस पर केवल पंट करते हैं और कहते हैं कि वर्तमान भागने के नियम इसे कवर करते हैं?

ये संभवतया सही (या सभी) मामलों का उपयोग नहीं करते हैं, लेकिन मुझे लगता है कि दस्तावेज़ों के उपयोग के मामलों में मददगार होगा और इस सुविधा के बारे में चर्चा करते समय उन्हें संदर्भित करने में सक्षम होगा अन्यथा यह वास्तव में कैसे पता चलेगा कि सुविधा वास्तव में पता नहीं है (या नहीं) ) ग्राहक मामलों का उपयोग करते हैं।

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

@rkeithhill क्या आप अपनी पिछली पोस्ट में पूर्णता के लिए मौजूदा वर्कअराउंड जोड़ सकते हैं?

@ उठते हुए , मैं भी आपकी

क्या ins ... उस & cmd --% ... नहीं दे सकता है?

--% अपने वर्तमान में, _parameter_ (प्रतीक) फ़ॉर्म - जिसका व्यवहार मैं मानता हूं कि हम बनाए रखना चाहते हैं - का उपयोग cmd /c --% लिए नहीं किया जा सकता, क्योंकि यह _multi-command_ cmd समर्थन नहीं करता है ^ बची हुई चार के रूप में।), यह देखते हुए कि पहले | _PowerShell_ के पाइप ऑपरेटर के रूप में व्याख्या की जाएगी और & को वर्बेटिम पास किया गया है।
वही यूनिक्स पर लागू होगा, जहां --% आम तौर पर पास-पास बेकार है, और sh -c पूरी तरह से विफल रहता है, क्योंकि sh कमांड लाइन को _single_ तर्क (जैसे, sh -c --% echo hi एक खाली लाइन देता है, क्योंकि echo अकेले कमांड के रूप में निष्पादित होता है)।

ins , इसकी आवश्यकता के साथ पास-थ्रू कमांड लाइन को सीमांकित करके _as एक एकल string_ इन समस्याओं को हल करता है, और, जैसा कि कहा गया है, _PowerShow_ चर और अभिव्यक्ति मूल्यों को शामिल करने के लिए स्ट्रिंग प्रक्षेप के उपयोग की भी अनुमति देता है।

और उत्तरार्द्ध हमें यह बताता है कि क्यों प्रस्तावित --% _statement_ एक _-अंत वाली स्ट्रीट_ है :

• वहाँ _no संक्रमण पथ_ को preexisting कमांड लाइन निष्पादित करने से _exactly is_ के रूप में _PowerShell_ चर और अभिव्यक्ति मानों को शामिल करना है।

  • एकमात्र - अस्पष्ट और बोझिल - इसे प्राप्त करने का तरीका _auxiliary पर्यावरण चर को परिभाषित करना है_ जो कि ब्याज के पावरशेल मूल्यों को संग्रहीत करता है और आप तब संदर्भ ( %...% $... ) के साथ (उचित रूप से प्राप्त कर सकते हैं) मूल कमांड लाइन।

• आपके पास एक बड़ा PowerShell पाइपलाइन में --% बयान को शामिल करने में सक्षम नहीं होने की अजीबता है।

  • ध्यान दें कि देशी शेल को कॉल करने के लिए वैध _non_ कट-एंड-पेस्ट कारण हैं, जहां आप इस एकीकरण की उम्मीद कर सकते हैं; विशेष रूप से, _raw byte data_ के माध्यम से (एक मध्यवर्ती) पाइपलाइन से गुजरना और एक नई लाइन के बिना _strings भेजना_ मूल पाइप के उपयोग की आवश्यकता है - वास्तविक जीवन के उदाहरण के लिए इस SO उत्तर को देखें।

• --% _parameter_ का यूनिकनेस पर वास्तव में बेकार होना भी अजीब बात है, जो एक विषम विषमता का परिचय देता है: यदि --% _statement_ Unter के साथ भी काम करता है, तो --% _parameter_ क्यों नहीं। ? (जैसे,
  /bin/echo --% 'hi "noon"' वर्बेटिम 'hi noon' (अपेक्षित hi "noon" बजाय), echo _two_ तर्क प्राप्त करने के कारण, शब्दशः 'hi और noon' , एकल उद्धरण के साथ डेटा और दोहरे उद्धरण छीन लिए गए)।

ins , --% स्टेटमेंट के लिए सुझाए गए विकल्प के रूप में, आदर्श रूप से बस एक _convenience आवरण_ cmd /c और sh -c , लेकिन यह वास्तव में संक्षिप्त हो गया है:

• यूनिक्स पर कम से कम _temporately_, जब तक # 1995 तय नहीं हो जाता, क्योंकि sh -c '...' सीधे वर्तमान में एम्बेडेड " साथ तर्क को ठीक से पारित नहीं करता है।

• विंडोज पर _Invariably_, क्योंकि आपको कमांड लाइन पास करने की जरूरत है _as-is_ से cmd lpCommandLine CreateProcess (जो --% पैरामीटर नहीं हो सकता है) _one_ कमांड तक सीमित होने के कारण); वैकल्पिक रूप से कमांड लाइन को _single string_ के रूप में पास करने की कोशिश कर रहा है, जो "..." में संलग्न है, फिर से # 1995 के कारण मजबूती से काम नहीं करता है।

_Argument_ पासिंग की परेशानियों से बचने के लिए कमांड लाइन प्रदान करने से बचा जा सकता है _via stdin_ (जो ins और भी समर्थन कर सकता है), यानी _pipe_ को शेल एग्जीक्यूट के लिए कमांड लाइन / स्क्रिप्ट टेक्स्ट:

• यूनिक्स पर, यह ठीक काम करता है, क्योंकि _stdin_ से sh कोड पास करना अनिवार्य रूप से _script file_ को क्रियान्वित करने के लिए समान है (बस sh -c '<code>' is ):

PSonUnix> @'
echo '{ "foo": "bar" }' | cat -n
'@ | sh

     1  { "foo": "bar" }

• काश, विंडोज पर cmd इस तरह के इनपुट को अच्छी तरह से संभाल नहीं करता है: यह अपने लोगो को प्रिंट करता है और त्वरित स्ट्रिंग के साथ, निष्पादन से पहले प्रत्येक कमांड को गूँजता है:

PSonWin> 'date /t & ver' | cmd

Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\jdoe>date /t & ver
Sun 07/26/2020

Microsoft Windows [Version 10.0.18363.836]

C:\Users\jdoe>

अफसोस की बात है, PowerShell खुद भी इसी तरह के अनैतिक व्यवहार को प्रदर्शित करता है: # 3223 देखें

जैसे sh और सभी प्रमुख POSIX जैसे गोले ( dash , bash , ksh , zsh ), अधिकांश स्क्रिप्टिंग _do_ ठीक से जैसे कि python , node , ruby , और perl जैसे स्टडी-अस-स्क्रिप्ट इनपुट का समर्थन करें।

PS> 'print("hi")' | python

hi

_PowerShell_ चर और अभिव्यक्ति मानों को शामिल करने के लिए, आपके पास फिर से स्ट्रिंग प्रक्षेप / संघनन का उपयोग करने का विकल्प है:

PS> $foo = 'bar'; "print(`"$foo`")" | python

bar

या दुभाषिया के तर्क-पासिंग फीचर का उपयोग करना:

PS> @'
import sys
print(sys.argv[1])
'@ | python - bar

bar

मुझे आशा है कि उपरोक्त यह स्पष्ट करता है कि सभी में विशेष वाक्यविन्यास के लिए _no_ की आवश्यकता है - न तो --% कथन, न ही #! कथन, और न ही मार्कडाउन कोड ब्लॉक - जिनमें से सभी में फिर से कमी होगी PowerShell स्क्रिप्ट से मानों को शामिल करने की क्षमता।

देशी शेल के विन्यास के लिए उपयोग करने के लिए: पूर्वानुमान के लिए, मुझे नहीं लगता कि हमें एक प्रस्ताव देना चाहिए; जो उपयोगकर्ता एक अलग शेल को लक्षित करना चाहते हैं, वे केवल उस शेल के विशिष्ट निष्पादन योग्य के लिए कमांड लाइन को पाइप कर सकते हैं या, # 1995 तय होने के बाद, इसे एक तर्क के रूप में पास करें।

• एक डिबेटेबल वेरिएशन /bin/bash ( /bin/sh ) के साथ (अयोग्य) कमबैक के साथ) को लक्षित करने के लिए है - जबकि कोई यह उम्मीद करेगा कि प्रकाशित कमांड लाइनें केवल POSIX- अनिवार्य विशेषताओं पर निर्भर हों, Bash-isms के साथ कमांड लाइन (गैर- POSIX सुविधाएँ जो /bin/sh कार्यान्वयनों के समर्थन की उम्मीद नहीं कर सकती हैं) bash की व्यापकता को देखते हुए, वहाँ होने की संभावना है।

@joeyaiello

यह मेरा विचार है कि इस विशेष सुविधा का लाभ # 1995 के प्रभाव से कहीं अधिक महत्वपूर्ण है।

मुझे यह मनमौजी लगता है कि हम इस कट-एंड-पेस्ट फीचर को बनाने में जितना प्रयास करते हैं - मुख्य रूप से _interactive_ सुविधा के लिए - एक (अजीब, सुविधा-सीमित) प्रथम श्रेणी के नागरिक, जबकि पावरस्ले की मौलिक अक्षमता खाली पास करने के लिए एम्बेडेड " चार्ट के साथ तर्क और तर्क।

लेकिन मैं लोगों को जंगली एन मास में # 1995 को मारते हुए नहीं देख रहा हूं

मैं करता हूं, और जिन कारणों के लिए

फिर, मैं एक शेल का तर्क दूंगा

# On Unix
PS> /bin/echo '{ "foo": "bar" }'

{ foo: bar }

@rjmholt CommandAst के पास इनपुट स्ट्रिंग के साथ

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

वर्तमान PowerShell के साथ पार्स नहीं करता है:

--% my_command "\" "

पर्स, लेकिन रिक्त स्थान से विभाजित होने से गलत परिणाम मिलता है:

--% my_command "\"    "\"

(हमें स्ट्रिंग में 4 स्थान भेजना चाहिए, लेकिन PowerShell एक सरणी में दो तारों को अलग-अलग देखता है)

@rjmholt , आपकी टिप्पणी के निचले भाग में सभी महान प्रश्न, जो मुझे फिर से सुझाव देते हैं कि सही उत्तर है: विशेष वाक्यविन्यास की कोई आवश्यकता नहीं है।

मैंने इस प्रश्न को संबोधित किया है कि अपनी पिछली टिप्पणी में देशी शेल का उपयोग करने योग्य क्या है, लेकिन इसके लिए:

क्या अन्य गोले या अन्य भाषाएँ इस पर अमल करेंगी या पहले से ही हैं? सिंटैक्स स्तर पर, या किसी अन्य स्तर पर? यदि हां, तो कैसे?

मुझे किसी भी अन्य भाषा के बारे में पता नहीं है, जो वाक्यविन्यास स्तर पर _explicit delimiters_ को नियोजित किए बिना और _interpolation_ की अनुमति के बिना हुई है।
उदाहरण के लिए, perl में शेल कमांड चलाने के लिए `...` , इसलिए आप उदाहरण के लिए, यूनिक्स पर स्क्रिप्ट से निम्न कमांड को चला सकते हैं:
my $foo='/'; print `ls $foo | cat -n`

मुख्य पहलुओं में स्पष्ट परिसीमाओं का उपयोग और कॉलर से मूल्यों को शामिल करने की क्षमता है - ये दोनों --% बयान के लिए वर्तमान प्रस्ताव से गायब हैं।

जैसा कि पहले कहा गया है, हम _could_ इस दृष्टिकोण का उपयोग एक नए _operator_ (या किसी प्रकार के सीमांकक-आधारित, वैकल्पिक रूप से सिंटैक्सिंग में करते हैं) के लिए करते हैं, लेकिन मुझे नहीं लगता कि यह इसके लायक है, इसे दिया गया है
ins "ls $foo | cat -n" (या यहां-स्ट्रिंग संस्करण के साथ) अतिरिक्त जटिलता के साथ भाषा को बोझ किए बिना करेंगे।

perl एक (उचित) सिंटैक्स-स्तरीय समाधान प्रदान करता है -लेकिन यह स्वयं एक शेल_ नहीं है, लेकिन शेल कॉल को यथासंभव सुविधाजनक बनाना चाहता है।

इसके विपरीत, हम _are_ एक शेल (भी), और शेल-स्टाइल इनवोकेशन _directly_ प्रदान करते हैं, बिना किसी अतिरिक्त सिंटैक्स के (यद्यपि वर्तमान में त्रुटिपूर्ण - # 1995 देखें)।
विभिन्न शेल के_ इनवॉइस को यथासंभव आसान बनाने के लिए विशेष सिंटैक्स प्रदान करना अनावश्यक लगता है।

@iSazonov

_ यदि हम (और पॉवरशेल) जानते हैं कि हम एक देशी निष्पादन योग्य चलाते हैं, तो हमें "देशी ऑपरेटर को कॉल करने" की आवश्यकता क्यों है?

यदि PowerShell इनपुट स्ट्रिंग को पार्स करता है और CommandAst प्राप्त करता है तो PowerShell कमांड की खोज करता है।
यदि कमांड एक देशी कमांड है, तो PowerShell, NativeCommandProcessor पर स्थित है।
हम उस मामले के लिए नए (प्रयोगात्मक NativeCommandProcessor) को लागू कर सकते हैं, जो Ast की सीमा को फिर से पार्स कर देगा (ताकि इनपुट स्ट्रिंग हो) ताकि OS निष्पादन नियम के रूप में मूल निष्पादन योग्य नाम / पथ और बाकी स्ट्रिंग को तर्क या तर्क के रूप में प्राप्त किया जा सके।

यदि कोई उपयोगकर्ता शेल से कॉपी-पेस्ट चाहता है, तो उसे "cmd" या "बैश" लिखना चाहिए - जो संपादन के बिना काम करेगा।
यदि उपयोगकर्ता कॉपी-पेस्ट करना चाहता है, तो एक देशी कमांड लाइन g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 तरह भी काम करेगी।

लेकिन प्रतीक्षा करें कि आप कभी भी देशी कमांड के साथ किसी भी PowerShell वाक्यविन्यास का उपयोग करने में सक्षम नहीं होंगे यदि हमने वह सब किया? तो जैसे sc.exe query $serviceName $serviceName एक शाब्दिक स्ट्रिंग के रूप में होगा?

लेकिन प्रतीक्षा करें कि आप कभी भी देशी कमांड के साथ किसी भी PowerShell वाक्यविन्यास का उपयोग करने में सक्षम नहीं होंगे यदि हमने वह सब किया? तो जैसे sc.exe query $serviceName शाब्दिक स्ट्रिंग के रूप में $serviceName पास होगा?

--% विकल्प उस आवश्यकता को संबोधित करने के लिए अभिप्रेत नहीं है।

sc.exe query $serviceName &"<cmd>" द्वारा संभाला जाता है

--% विकल्प उस आवश्यकता को संबोधित करने के लिए अभिप्रेत नहीं है।

sc.exe query $serviceName &"<cmd>" द्वारा संभाला जाता है

हां, मुझे यकीन नहीं है कि @iSazonov का जिक्र है। मैं पढ़ रहा हूँ कि जैसे कि वे एक सामान्य बदलाव का सुझाव दे रहे हैं कि कैसे देशी कमांड के लिए पैरामीटर बाध्यकारी काम करता है।

हां, मुझे यकीन नहीं है कि @iSazonov का जिक्र है। मैं पढ़ रहा हूँ कि जैसे कि वे एक सामान्य बदलाव का सुझाव दे रहे हैं कि कैसे देशी कमांड के लिए पैरामीटर बाध्यकारी काम करता है।

भगवान, मुझे आशा नहीं है।

भगवान, मुझे आशा नहीं है।

कभी कभी जब आप अमूर्त विचार मंथन कर रहे हैं तो स्पष्ट के बारे में भूलना आसान है। मेरा मतलब है कि हम सभी इसे पढ़ते हैं और तुरंत ही यह सोचने लगते हैं कि यह कितना टूट जाएगा।

या मुझे कुछ स्पष्ट याद आ रहा है और यह बिल्कुल भी प्रस्तावित नहीं है and

@essentialexch , स्पष्ट होना, पुनः:

sc.exe query $serviceName &"<cmd>" द्वारा संभाला जाता है

& "<cmd>" केवल तभी काम करता है जब <cmd> मूल्यांकन केवल एक आदेश _name या path_ के लिए हो, _not तर्कों सहित - अलग-अलग, व्यक्तिगत रूप से तर्क पारित किए जाने चाहिए - और उन्हें se "...." चर संदर्भों का विस्तार करने के लिए उद्धरण (जैसे,
$exe = 'findstr'; & "where.exe $exe" डिजाइन द्वारा विफल; & "where.exe" $exe होना चाहिए (दोहरे उद्धरण यहां वैकल्पिक हैं; यदि छोड़ा गया है, तो & तब भी बहुत अधिक है)

हां, मुझे यकीन नहीं है कि @iSazonov का जिक्र है। मैं पढ़ रहा हूँ कि जैसे कि वे एक सामान्य बदलाव का सुझाव दे रहे हैं कि कैसे देशी कमांड के लिए पैरामीटर बाध्यकारी काम करता है।

मेरा प्रस्ताव # 1995 (परिवर्तन को तोड़ने के साथ) को ठीक करना है। कारण प्रक्षेप काम नहीं करता है। क्योंकि यह अंतिम प्रस्ताव नहीं है - यह डेमो करता है कि हम मिनटों में कैसे तय कर सकते हैं। और यह मुख्य रूप से डेमो है कि हमें @ mklement0 के रूप में भी कॉल मूल ऑपरेटर की आवश्यकता नहीं है।

पर्स, लेकिन रिक्त स्थान से विभाजित होने से गलत परिणाम मिलता है:

@rjmholt हां, लेकिन मुझे लगता है कि आप इस विचार को पकड़ते हैं।
CommandAst का पहला बच्चा StringConstantExpressionAst है, जो देशी कमांड के साथ BareWord है। हम CommandAst Extent से नंगे शब्द को काट सकते हैं और ast-s बदलाव के बिना पैरामीटर सूची प्राप्त कर सकते हैं। लेकिन हम पैरामीटर सूची भी रखने के लिए नए ast जोड़ सकते हैं।
मैं स्पष्टीकरण के लिए एक समय बिताता हूं क्योंकि नीचे मैं चर्चा को संक्षेप में प्रस्तुत करना चाहता हूं और मुझे लगता है कि हमें कुछ वृद्धि को लागू करने की आवश्यकता होगी जो जटिल दिखती है, लेकिन मुझे लगता है कि उन्हें पिछड़े अनुकूलता के लिए सरल और __w आसान ऑप्ट-आउट लागू किया जा सकता है।

मेरा मानना ​​है कि प्रारंभिक प्रस्ताव के @ स्टीव-एमएसएफटी के इरादे ब्रेकिंग बदलाव से बचने के लिए थे।
मैं @TSlivede और @ mklement0 से सहमत हूं कि इस चर्चा से पता चला है कि नए सिंटैक्स की ज़रूरत नहीं है क्योंकि यह # 1995 और # 12975 जैसी सभी _fundamental_ समस्याओं को हल नहीं करता है। दूसरी ओर, यह भाषा में जटिलता जोड़ता है, जबकि हम चाहते हैं, इसके विपरीत, मूल अनुप्रयोगों के लिए _simplify_ काम करते हैं।

__ आगे बढ़ने का एकमात्र तरीका ब्रेकिंग परिवर्तन या अधिक करना है ।__ (उसके बाद, एक नया ऑपरेटर या cmdlet कुछ परिदृश्यों में भी उपयोगी हो सकता है।)

हमें उपयोग के मामलों और उपयोगकर्ता की उम्मीदों के सारांश के साथ शुरू करना चाहिए।
ऊपर @rkeithhill का शानदार पोस्ट देखें

1. उपयोगकर्ता इंटरपोलेशन को सक्षम / अक्षम करना चाहते हैं।
   पॉवरशेल में पहले से ही सिंगल / डबल कोट्स के साथ स्ट्रिंग्स / यहां-स्ट्रिंग्स हैं।
   हमारा लक्ष्य यह समझना है कि इसे कैसे लागू / परिष्कृत किया जाए।

2. उपयोगकर्ता किसी भी निष्पादन योग्य या शेल को चलाना चाहते हैं

   • किसी भी निष्पादन योग्य - कमांड ऐप नाम से शुरू होती है और तर्कों का अनुसरण करती है
     
     
     
     • प्रक्षेप के साथ / बिना
     
     
     • सिंगल लाइन पर / मल्टी लाइन पर
     
     
   • शेल शायद एक विशेष मामला है क्योंकि तर्क (s) एक _script_ है
     
     
     
     • कॉपी-पेस्ट परिदृश्य में उपयोगकर्ता प्रक्षेप नहीं चाहते हैं और सिंगल और मल्टी लाइन चाहते हैं
     
     
     • स्क्रिप्ट परिदृश्य में उपयोगकर्ता प्रक्षेप को अक्षम / अक्षम करना चाहते हैं और सिंगल और मल्टी लाइन चाहते हैं
     
     

   विचार:
   इससे हमें लगता है कि कॉपी-पेस्ट परिदृश्य व्यवहार डिफ़ॉल्ट होना चाहिए।
   लाइन टर्मिनेटर निष्पादन योग्य (बैश में, `पॉवरशेल में) पर निर्भर करते हैं। इससे हमें लगता है कि:
   (1) एक शेल स्पष्ट रूप से किसी भी निष्पादन योग्य के रूप में कहा जाना चाहिए,
   (2) शायद किसी भी बहुस्तरीय लाइन के साथ निष्पादन को एक शेल के माध्यम से बुलाया जाना चाहिए या हमें एक विशेष पार्सिंग (टर्मिनेटर को हटाने और भागने के साथ मुद्दे पर वापस आने वाली तर्क सूची का निर्माण करना होगा)
   (3) हम PSReadline में कॉपी-पेस्ट परिदृश्य को संबोधित कर सकते हैं। यह बफ़र को सही PowerShell कमांड में बदल सकता है।

3. उपयोगकर्ता सिंगल लाइन और मल्टीलाइन चाहते हैं।

   • शायद हमें पहले चर्चा किए गए अनुसार कुछ परिदृश्यों को संबोधित करने के लिए सिंगल-लाइन के लिए यहां-स्ट्रिंग्स को बढ़ाने की आवश्यकता है।
   • देखें 2 - (2) - हमेशा मल्टीलाइन के लिए एक शेल का उपयोग करें या एक विशेष पार्सिंग को लागू करें

मैं अधिक लिखना नहीं चाहता क्योंकि @TSlivede और @ mklement0 पहले से अपने विचारों और निष्कर्षों को अपडेट कर सकते थे लेकिन जो अब परिवर्तन (एस) को स्वीकार करने पर आधारित हो सकते हैं। मैं नया मुद्दा खोलने (और सभी बच्चों को बंद करने) के लिए कहूंगा , सभी उपयोग के मामलों की गणना करें (@

मैं केवल यह जोड़ना चाहता हूं कि हम इनवोक-शेल (इनवोक-नेटिवशेल), टेस्ट-आर्ग्यूमेंट्स (जैसे echoargs.exe की तरह उपयोगकर्ता गोद लेने को सरल बनाने के लिए नए cmdlets पर विचार कर सकते हैं, यह दर्शाने के लिए कि मूल ऐप उपयोगकर्ताओं के लिए मदद करता है और उपयोगकर्ताओं के लिए मदद दिखाता है, Convert-Arguments ( उपयोगकर्ता इनपुट को सही बची दलीलों में बदलना)।

पुनश्च: जैसा कि मैंने ऊपर एकल लाइन व्यवहार दिखाया था, आसानी से रन टाइम में पिछड़े संगतता के लिए ऑप्ट-आउट किया जा सकता है।

लाइन टर्मिनेटर निष्पादन योग्य (बैश में, `पॉवरशेल में) पर निर्भर करते हैं।

\ bash में एक लाइन टर्मिनेटर नहीं है।

कारण प्रक्षेप काम नहीं करता है। क्योंकि यह अंतिम प्रस्ताव नहीं है - यह डेमो करता है कि हम मिनटों में कैसे तय कर सकते हैं। और यह मुख्य रूप से डेमो है कि हमें @ mklement0 के रूप में भी कॉल मूल ऑपरेटर की आवश्यकता नहीं है।

उसी तरह जिस तरह हम कुछ ही मिनटों में सभी कीड़े को ठीक कर सकते हैं यदि हम सिर्फ रेपो को हटा दें। यह एक बहुत बड़ा ब्रेक है जिसे आप प्रस्तावित कर रहे हैं। यहां तक ​​कि अगर सिर्फ एक काल्पनिक मैं नहीं देखता कि यह कैसे उपयोगी है।

यहां तक ​​कि अगर सिर्फ एक काल्पनिक मैं नहीं देखता कि यह कैसे उपयोगी है।

@SeeminglyScience ऐसा लगता है कि हम विभिन्न संदर्भों में हैं। मैं कहता हूं कि हम एकल परिवर्तन के रूप में सिंगल लाइन देशी कॉल के लिए एक फिक्स लागू कर सकते हैं लेकिन पार्सर को तोड़ने के बिना। दूसरे शब्दों में, हम भी मक्खी पर व्यवहार को बदल सकते हैं, चाहे कोई भी नया व्यवहार लागू हो।

दूसरे शब्दों में, हम भी मक्खी पर व्यवहार को बदल सकते हैं, चाहे कोई भी नया व्यवहार लागू हो।

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

@iSazonov

_ यदि हम (और पॉवरशेल) जानते हैं कि हम एक देशी निष्पादन योग्य चलाते हैं, तो हमें "देशी ऑपरेटर को कॉल करने" की आवश्यकता क्यों है?

यदि PowerShell इनपुट स्ट्रिंग को पार्स करता है और CommandAst प्राप्त करता है तो PowerShell कमांड की खोज करता है।
यदि कमांड एक देशी कमांड है, तो PowerShell, NativeCommandProcessor पर स्थित है।
हम उस मामले के लिए नए (प्रयोगात्मक NativeCommandProcessor) को लागू कर सकते हैं, जो Ast की सीमा को फिर से पार्स कर देगा (ताकि इनपुट स्ट्रिंग हो) ताकि OS निष्पादन नियम के रूप में मूल निष्पादन योग्य नाम / पथ और बाकी स्ट्रिंग को तर्क या तर्क के रूप में प्राप्त किया जा सके।

यदि कोई उपयोगकर्ता शेल से कॉपी-पेस्ट चाहता है, तो उसे "cmd" या "बैश" लिखना चाहिए - जो संपादन के बिना काम करेगा।
यदि उपयोगकर्ता कॉपी-पेस्ट करना चाहता है, तो एक देशी कमांड लाइन g++ timer.cpp @conanbuildinfo.args -o timer --std=c++11 तरह भी काम करेगी।

मैं इस बात की पुष्टि करना चाहता हूं कि आपके द्वारा इसका क्या मतलब है: क्या आप बाहरी निष्पादनयोग्य को कॉल करते समय अनिवार्य रूप से सभी पावरसैल सिंटैक्स को अनदेखा करने का सुझाव दे रहे हैं?

विशेष रूप से: क्या आप सुझाव दे रहे हैं, उदाहरण के लिए चल रहा है

/bin/echo (1..5)

अधिकार में अब 1 2 3 4 5 नहीं डालेंगे, लेकिन इसके बजाय शाब्दिक (1..5) उत्पादन करना चाहिए?

अगर वास्तव में आप जो सुझाव दे रहे हैं, तो मुझे कहना होगा: मुझे लगता है कि यह एक भयानक विचार है।

यही कारण है कि नहीं सरल काम करता है (बाहरी निष्पादनयोग्य अब व्यवहार करते वाक्य रचना आंतरिक cmdlets से भिन्न हो) और यह भी शामिल नहीं है # 1995 IMHO के साथ कुछ करने की जरूरत ...

@rjmholt
ऊपर से :

• क्या अन्य गोले या अन्य भाषाएँ इस पर अमल करेंगी या पहले से ही हैं? सिंटैक्स स्तर पर, या किसी अन्य स्तर पर? यदि हां, तो कैसे?

केवल एक चीज, जो मेरे दिमाग में आती है, वह ! ऑपरेटर होगी :

चल रहा है ipython outputs में !ps -'fax' || true :

  261 pts/0    Sl     0:00          \_ /usr/bin/python /usr/bin/ipython
  311 pts/0    S      0:00              \_ /bin/bash -c ps -'fax' || true
  312 pts/0    R      0:00                  \_ ps -fax

( पीएस तर्कों के आसपास उद्धरण नहीं दिखाते हैं , लेकिन ps -'fax' || true को वास्तव में बैश करने के लिए एक एकल तर्क के रूप में दिया गया है)

हालाँकि, यह सुविधा अभी भी उस आदेश ( {pyvar} ) में अजगर चर के प्रक्षेप की अनुमति देती है।

और @ mklement0 के उदाहरण के समान, ipython केवल इसे लागू करता है

क्योंकि यह स्वयं एक खोल नहीं है

अगर ipython केवल python syntax की अनुमति देगा तो यह शेल के रूप में बहुत उपयोगी नहीं होगा, इसलिए वे इस वाक्यविन्यास को आगे के कमांड को bash के रूप में प्रयोग करने योग्य होने के लिए bash करने की अनुमति देते हैं। Powershell दूसरी ओर दावों पर, एक खोल होने के लिए (# 1995 हल किया जाता है जब तक, मैंने ऐसा नहीं है कि यह एक खोल है) तो यह अन्य गोले फोन करने के लिए एक विशेष वाक्य रचना को जोड़ने के लिए काफी अजीब होगा।

अगर ऐसा कुछ होता है जो वास्तव में कार्यान्वित किए गए कारण (उम्मीद के मुताबिक नहीं) के लिए है, तो मैं "कॉल शेल ऑपरेटर" के रूप में --% बजाय ! का उपयोग करने का सुझाव दूंगा।

! कुछ लोगों का अनुमान हो सकता है (क्योंकि वे जानते हैं कि ! उस उद्देश्य के लिए ipython से है (या vim कमांड मोड से) और less या ftp )

दूसरी ओर --% मुश्किल से टाइप किया जाता है, अनुमान लगाया जाना संभव नहीं है और सबसे महत्वपूर्ण: --% का वर्तमान उपयोग मेरी राय में बहुत कम है "पास के सामान को दूसरे शेल" के साथ व्यवहार। वर्तमान --% cmd सिंटैक्स के बिल्कुल एक तत्व का अनुकरण करता है: चर प्रतिस्थापन (और यहां तक ​​कि पूरी तरह से नहीं)। यह बच चार्ट ^ समर्थन नहीं करता है, फ़ाइलों को पुनर्निर्देशन की अनुमति नहीं देता है, और इसी तरह। केवल एक चीज के बारे में वर्तमान में कुछ हद तक उपयोगी --% में शब्दशः सामग्री पारित करने की क्षमता है lpCommandLine - लेकिन यह है कि कुछ है जो प्रस्तावित "कॉल खोल ऑपरेटर" पर अच्छा नहीं है।

प्रस्तावित "कॉल शेल ऑपरेटर" और मौजूदा --% बीच एक और अंतर (जो पहले ही उल्लेख किया गया था): एक पाइप पर समाप्त होता है, दूसरा नहीं - नए उपयोगकर्ताओं के लिए बहुत भ्रामक। ! दूसरी तरफ | सभी अनुप्रयोगों में शेल के लिए मैंने अब तक परीक्षण किया (ipython, vim, less, ed, आदि)।

HELP about_Logical_Operators -S

हाँ, ! स्वयं समस्याग्रस्त है क्योंकि यह भाषा में एक तार्किक निषेध ऑपरेटर है।

वैकल्पिक प्रस्तावों में से एक BTW &! - एक "कॉल देशी / शेल" ऑपरेटर की तरह।

काश @TSlivede ने "उम्मीद नहीं" भाग पर अधिक जोर दिया होता, जब उन्होंने कहा कि "अगर ऐसा कुछ होता है जो वास्तव में लागू किए गए किसी कारण से (उम्मीद है कि नहीं)"

• कोई भी ऑपरेटर / कथन _ व्यक्तिगत तर्क के साथ_ I-want-to-use-PowerShell-values-of-native-command-line समस्या को आसानी से हल कर सकता है, यह देखते हुए कि $ का उपयोग _both_ में परिवर्तनशील सजग के रूप में किया जाता है PowerShell और POSIX जैसे गोले।

• पूरे देशी कमांड लाइन के आसपास कोई भी ऑपरेटर / स्टेटमेंट _without स्पष्ट सीमांक_ से जहां-जहां-जहां-जहां या हो सकता है, आपकी समस्या का समाधान नहीं हो सकता है।

@ पावरशेल / पावरशेल-समिति ने आज इस पर चर्चा की। इस बिंदु पर, प्रारंभिक समस्या कथन पर कोई समझौता नहीं दिखता है और न ही कैसे हल करने के लिए एक डिज़ाइन है, इसलिए हमें विश्वास नहीं है कि हम इसे 7.1 w / एक स्थिर डिजाइन में प्राप्त कर सकते हैं।

@ पावरशेल / पावरशेल-समिति ने आज इस पर चर्चा की। इस बिंदु पर, प्रारंभिक समस्या कथन पर कोई समझौता नहीं दिखता है और न ही कैसे हल करने के लिए एक डिज़ाइन है, इसलिए हमें विश्वास नहीं है कि हम इसे 7.1 w / एक स्थिर डिजाइन में प्राप्त कर सकते हैं।

182 टिप्पणियाँ!

इस पर कुछ बेहतरीन चर्चा हुई है! मैं इस मुद्दे पर किसी भी नई टिप्पणी की निगरानी करना जारी रखूंगा। हम अभी भी इस मुद्दे से स्वतंत्र PSGallery को प्रकाशित Invoke-NativeCommand प्रकार के cmdlet को लागू करने के लिए समुदाय को प्रोत्साहित करते हैं।

मुझे लगता है कि यह दुर्भाग्यपूर्ण है, जब आपके पास इसे छोड़ने के लिए https://github.com/PowerShell/PowerShell/issues/13068#issuecomment -662732627 पर बहुत ही उपयोगी समाधान था। मुझे पता है कि आप आम सहमति चाहते हैं, लेकिन कभी-कभी एक समझौता सबसे अच्छा होता है जो हो सकता है। नहीं, यह सही नहीं है, लेकिन एक-लाइनर एसओ समाधान बेहद उपयोगी होगा। कम से कम इस एक व्यक्ति की राय में।

@essentialexch स्पष्ट होने के लिए, हमारे पास PowerShell टीम में भी आम सहमति नहीं है

चूंकि यह स्थगित है कि सहायकों के कार्यान्वयन के बारे में क्या

हम इनवोक-शेल (इनवोक-नेटिवशेल), टेस्ट-आर्ग्यूमेंट्स (जैसे echoargs.exe जैसे कि उपयोगकर्ता को ऐप प्राप्त करने और उपयोगकर्ताओं के लिए मदद दिखाने के लिए), कन्वर्ट-तर्क (उपयोगकर्ता इनपुट परिवर्तित करने के लिए) के लिए नए गोद लेने पर विचार कर सकते हैं। सही बच गए तर्क)।

मुझे लगता है कि टेस्ट-तर्क बहुत उपयोगी हो सकते हैं।

मैंने अभी एक मॉड्यूल प्रकाशित किया है, Native , ( Install-Module Native -Scope CurrentUser ) जो मैं आप सभी को कोशिश करने के लिए आमंत्रित करता हूं और जिनकी आज्ञा मैं नीचे उपयोग कर रहा हूं ; ऊपर उल्लिखित सांख्यिक उपयोग के मामले ऊपर हैं ।

यदि हम कभी भी वैचारिक कोहरे को साफ करना चाहते हैं, तो मुझे लगता है कि हमें उपयोग के मामलों को अलग तरह से फ्रेम करने की जरूरत है।
_N की उन्हें पार्सिंग_ में किसी भी बदलाव की आवश्यकता होती है।

केस का उपयोग करें [देशी-शेल कॉल]:

आप एक _indirect कमांड_ (केस 1 का उपयोग करें) या पूरे _multi- कमांड कमांड लाइन_ (केस 2 का उपयोग करें) को लिखना चाहते हैं, प्लेटफॉर्म-देशी शेल_ (इस मुद्दे) के लिए लिखा गया है:

• चूंकि आप एक अलग शेल के सिंटैक्स का उपयोग कर रहे हैं, आप कमांड (लाइन) को पास कर रहे हैं। एक सिंगल स्ट्रिंग_ को लक्ष्य शेल में, _it_ को पार्स करने के लिए; PowerShell का स्ट्रिंग प्रक्षेप, पास किए गए स्ट्रिंग (उपयोग केस 2a) में PowerShell मान एम्बेड करने की क्षमता प्रदान करता है।
• ins ( Invoke-NativeShell ) इन उपयोग मामलों को कवर करता है।

# Use case 1: Single executable call with line continuation, on Unix.
@'
tar -cvpzf /share/Recovery/Snapshots/$(hostname)_$(date +%Y%m%d).tar.gz \
    --exclude=/proc \
    --exclude=/lost+found 
'@ | ins

# Use case 2: Entire Bash command line (also with line continuation)
@'
ps -o pid,args | awk \
  '/pwsh/ { print $1 }'
'@ | ins

# Use case 2a: Entire Bash command line (also with line continuation) with string interpolation.
# Note the double-quoted here-string and the need to escape the $ that is for Bash as `$
$fields = 'pid,args'
@"
ps -o $fields | awk \
  '/pwsh/ { print `$1 }'
"@ | ins

# Alternative to use case 2a: pass the PowerShell value *as a pass-through argument*,
# which allows passing the script verbatim.
# Bash sees the pass-through arguments as $1, ... (note that the `awk` $1 is unrelated).
@'
ps -o $1 | awk \
  '/pwsh/ { print $1 }'
'@ | ins - 'pid,args'

यहां स्ट्रिंग-सिंटैक्स सबसे सुविधाजनक नहीं है (इसलिए इन-लाइन संस्करण को लागू करने का सुझाव - # 13204 देखें), लेकिन आप इसका उपयोग करने के लिए _have_ नहीं करते हैं; शब्दशः आदेशों के लिए, आप '...' उपयोग कर सकते हैं, जिसके लिए केवल _doubling_ एम्बेडेड ' , यदि मौजूद हो।

इसके अलावा, यहाँ "StackOverflow ऑपरेटर" के लिए एक

यदि आप अपने $PROFILE फ़ाइल में निम्नलिखित PSReadLine कुंजी का हैंडलर लगाते हैं, तो आप Alt-v का उपयोग करने के लिए एक शब्दशः स्ट्रिंग के साथ ins का उपयोग कर पाएंगे। जिसमें वर्तमान क्लिपबोर्ड पाठ चिपकाया जाता है।कॉल दर्ज करें।

# Scaffolds an ins (Invoke-NativeShell) call with a verbatim here-string
# and pastes the text on the clipboard into the here-string.
Set-PSReadLineKeyHandler 'alt+v' -ScriptBlock {
  [Microsoft.PowerShell.PSConsoleReadLine]::Insert("@'`n`n'@ | ins ")
  foreach ($i in 1..10) { [Microsoft.PowerShell.PSConsoleReadLine]::BackwardChar() }
  # Comment the following statement out if you don't want to paste from the clipboard.
  [Microsoft.PowerShell.PSConsoleReadLine]::Insert((Get-Clipboard))
}

मामले का उपयोग करें [प्रत्यक्ष निष्पादन योग्य कॉल]:

आप _PowerShell_ के सिंटैक्स का उपयोग करके _ind बाहरी तर्क के साथ _single बाहरी निष्पादन योग्य_ कॉल करना चाहते हैं (केस 1 ए और 3 का उपयोग करें)।

• यह किसी भी खोल का एक मुख्य जनादेश है, और यह महत्वपूर्ण है कि यह मजबूती से काम करे।

  • आपको PowerShell पर भरोसा करने में सक्षम होने के लिए किसी भी तर्क से गुजरने में सक्षम होना चाहिए जो _its_ parsing _as-is_ के परिणामस्वरूप लक्ष्य निष्पादन योग्य है। यह वर्तमान में ऐसा नहीं है - # 1995 देखें ।

• इसके लिए आपको _PowerShell के_ सिंटैक्स और _its_ तर्क-विधा मेटाचैकर्स को समझना होगा।

  • आपको इस बात की जानकारी होनी चाहिए कि ` का उपयोग पलायन चरित्र के रूप में और लाइन निरंतरता के लिए किया जाता है।

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

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

जब हम # 1995 के ठीक होने की प्रतीक्षा कर रहे हैं, ie ( i nvoke (external) e xecutable) के लिए, अंतर को भरता है, बस सीधे कॉल करने के लिए; जैसे, निम्नलिखित कॉल के बजाय:

# 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" }'

Native मॉड्यूल echoArgs.exe लिए कुछ के साथ आता है, dbea ( Debug-ExecutableArguments ) कमांड; विंडोज पर नमूना आउटपुट:

# Note the missing first argument, the missing " chars., and the erroneous argument boundaries.
PS> dbea '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
7 argument(s) received (enclosed in <...> for delineation):

  <a&b>
  <3 of snow Nat>
  <King>
  <Cole c:\temp>
  <1\ a>
  <">
  <b>

Command line (helper executable omitted):

  a&b 3" of snow "Nat "King" Cole" "c:\temp 1\\" "a \" b"

-UseIe ( -ie ) स्विच का उपयोग करके, आप dbea को ie माध्यम से तर्क पारित करने के लिए बता सकते हैं, जो दर्शाता है कि यह समस्याओं को हल करता है:

# OK, thanks to -UseIe
PS> dbea -UseIe '' 'a&b' '3" of snow' 'Nat "King" Cole' 'c:\temp 1\' 'a \" b'
6 argument(s) received (enclosed in <...> for delineation):

  <>
  <a&b>
  <3" of snow>
  <Nat "King" Cole>
  <c:\temp 1\>
  <a \" b>

Command line (helper executable omitted):

  "" a&b "3\" of snow" "Nat \"King\" Cole" "c:\temp 1\\" "a \\\" b"

नोट: एक बार # 1995 तय हो जाने के बाद, ie की आवश्यकता नहीं है; आगे की अनुकूलता के हित में, ie का पता लगाने के लिए डिज़ाइन किया गया है और स्वचालित रूप से एक निर्धारण के लिए स्थगित कर दिया गया है; वह यह है कि एक बार फिक्स होने के बाद, ie अपने वर्कअर्स को लागू करना बंद कर देंगे और प्रभावी रूप से प्रत्यक्ष / & कॉल की तरह कार्य करेंगे।

मामले का उपयोग करें [प्रत्यक्ष दुष्ट विंडोज निष्पादन योग्य कॉल]:

दो मुख्य समस्याएं हैं, जो केवल _Windows पर उत्पन्न होती हैं:

• आप एक "दुष्ट" निष्पादन योग्य का आह्वान कर रहे हैं जिसमें उन आवश्यकताओं को गया है जो सबसे व्यापक रूप से इस्तेमाल किए जाने वाले सम्मेलन से अलग हैं ; उदाहरण के लिए, msiexec.exe और msdeploy.exe लिए prop="<value with spaces>" msdeploy.exe आवश्यकता होती है ठीक उसी तरह उद्धृत करने के लिए - केवल _value_ भाग के आसपास - भले ही "prop=<value with spaces>" - संपूर्ण का उद्धरण हो। तर्क - _should_ समतुल्य होना (उत्तरार्द्ध वही है जो PowerShell - उचित रूप से - पर्दे के पीछे करता है)।

• आप _a बैच फ़ाइल_ को _an तर्क के साथ लागू कर रहे हैं जिसमें रिक्त स्थान नहीं हैं, लेकिन इसमें cmd.exe metacharacters_ जैसे & , ^ , या | ; उदाहरण के लिए:

  • .\someBatchFile.cmd 'http://example.org/a&b'

  • PowerShell - justifiably - पास http://example.org/a&b _unquoted_ (क्योंकि कोई एम्बेडेड व्हाट्सएप नहीं है), लेकिन इससे बैच-फ़ाइल इनवोकेशन टूट जाता है, क्योंकि cmd.exe - अनुचित रूप से - विषयों के तर्क एक बैच फ़ाइल में पास किए जाते हैं वही पार्सिंग शासन जो शाब्दिक के रूप में स्वीकार करने के बजाय cmd.exe अंदर लागू होगा।

  • नोट: बैच फ़ाइलों का उपयोग करते हुए _directly_ कार्यान्वयन कार्यक्षमता संभवत: कम हो रही है, उन्हें _CLI प्रविष्टि बिंदुओं के रूप में उपयोग करना अभी भी बहुत आम है, जैसे कि Azure के az CLI, जो बैच फ़ाइल के रूप में " az.cmd लागू किया जाता है।

नोट: ie स्वचालित रूप से बैच फ़ाइलों के लिए और msiexec.exe और msdeploy.exe लिए इन परिदृश्यों को संभालता है, इसलिए _AST_ कॉल के लिए किसी अतिरिक्त प्रयास की आवश्यकता नहीं होनी चाहिए ; हालाँकि, _all_ "दुष्ट" निष्पादन योग्यों का अनुमान लगाना असंभव है।

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

• यह देखते हुए कि cmd.exe , एक कमांड लाइन पर तर्कों की अपनी व्याख्या को लागू करने के बाद, _does_ निर्दिष्ट उद्धरण को संरक्षित करते हैं, आप विंडोज पर ins कॉल को सौंप सकते हैं:

  • ins '.\someBatchFile.cmd "http://example.org/a&b"'
  • यदि आप _expandable_ string का उपयोग करते हैं, तो यह आपको PowerShell मान को कमांड स्ट्रिंग में एम्बेड करने में सक्षम बनाता है।
    
    
    
    • $url = 'http://example.org/a&b'; ins ".\someBatchFile.cmd `"$url`""
    
    

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

  • .\someBatchFile.cmd --% "http://example.org/a&b"'
  • यह देखते हुए कि कैसे --% लागू किया जाता है, PowerShell मूल्यों को एम्बेड करने का एकमात्र तरीका है - अजीब रूप से - एक _aux को परिभाषित करना। पर्यावरण चर_ और इसे %...% सिंटैक्स के साथ संदर्भित करें:
    
    
    
    • $env:url = 'http://example.org/a&b'; .\someBatchFile.cmd --% "%url%"
    
    

गलती संभालना

लंबित https://github.com/PowerShell/PowerShell-RFC/pull/88 बाहरी (मूल) निष्पादनों के साथ बेहतर त्रुटि-हैंडलिंग एकीकरण लाएगा।

इस बीच, स्क्रिप्ट-समाप्ति त्रुटि के रूप में नॉनज़ेरो एग्जिट कोड के इलाज के लिए Native मॉड्यूल दो विशेषताओं वाले एड-हॉक ऑप्ट-इन के लिए :

• ins -e / -ErrorOnFailure स्विच का समर्थन करता है, जो एक त्रुटि फेंकता है यदि $LASTEXITCODE देशी शेल के कॉल के बाद नॉनज़रो है।

• iee के लिए एक आवरण समारोह है ie कि तुलनात्मक रूप से एक त्रुटि फेंकता है तो $LASTEXITCODE बाहरी निष्पादन करने के लिए कॉल के बाद अशून्य है।

मॉड्यूल के साथ जहाज करने वाले आदेशों के लिए कई सूक्ष्मताएं हैं।
काफी व्यापक टिप्पणी-आधारित सहायता उन्हें पर्याप्त रूप से कवर करती है।

यदि हम कभी भी वैचारिक कोहरे को साफ करना चाहते हैं, तो मुझे लगता है कि हमें उपयोग के मामलों को अलग तरह से फ्रेम करने की जरूरत है।

महान! मैंने पहले जो पोस्ट किया था वह सिर्फ लोगों को अधिक और बेहतर उपयोग के मामले बनाने के बारे में सोचने के लिए मिला था।

मुझे ins ( Invoke-NativeShell ) के कुछ महत्वपूर्ण पहलुओं को स्पष्ट करना चाहिए जो मैंने पहले प्रस्तावित किए हैं, से भिन्न हैं; उद्देश्य bash की सर्वव्यापीता के लिए खाता था और प्लेटफार्मों भर में एक निरंतर सीएलआई प्रदान करना था।

• यूनिक्स पर , मैंने बैश की सर्वव्यापकता को देखते हुए /bin/bash बजाय /bin/sh कॉल करने का निर्णय लिया है, लेकिन आप -UseSh ( -sh साथ -UseSh /bin/sh का उपयोग करने का विकल्प चुन सकते हैं -sh ) ( /bin/sh भी /bin/bash मौजूद नहीं होने की संभावना नहीं है)

  • मंगलाचरण रूपों और प्लेटफार्मों में एक सुसंगत अनुभव के हित में, मैंने $0 , मंगलाचरण नाम सेट करने की क्षमता छिपाई है; वह है, कोई भी पास-थ्रू तर्क $1 से शुरू होता है, जो इस बात के अनुरूप है कि जब आप पाइप लाइन से स्क्रिप्ट को पाइप करते हैं, और उपयोगकर्ता क्या अपेक्षा करते हैं:

# Script as argument
PSonUnix> ins 'echo $# arguments; echo "[$1] [$2]"' one two
2 arguments
[one] [two]

# Script via pipeline; note the "-" to signal that the script is piped.
PSonUnix> 'echo $# arguments; echo "[$1] [$2]"' | ins - one two
2 arguments
[one] [two]

# As an aside: script as argument, with pipeline input *as data*:
PSonUnix> 'one', 'two' | ins 'cat -n'
     1  one
     2  two

• विंडोज पर मुझे तकनीकी कारणों से पर्दे के पीछे एक अस्थायी _batch file_ का उपयोग करना था, लेकिन मुझे लगता है कि बैच-फाइल सिंटैक्स का उपयोग अंततः बेहतर विकल्प है ( %%i बजाय %i for लूप चर, % %% रूप में बचने की क्षमता।

  • बैच फ़ाइल का उपयोग भी यूनिक्स पर पास-थ्रू तर्कों के लिए समर्थन सक्षम करता है:

# Script as argument
PSonWin> ins 'echo [%1] [%2]' one two
[one] [two]

# Script via pipeline; note the "-" to signal that the script is piped.
PSonWin> 'echo [%1] [%2]' | ins - one two
[one] [two]