Powershell: क्या हम उपयोग कर सकते हैं | अगली पंक्ति पर एक निरंतरता चरित्र के रूप में?

एक स्क्रिप्ट में - हाँ, लेकिन यह पुराने स्कूल को कंसोल में राइट-क्लिक या Alt+e,p पेस्ट का उपयोग करने की क्षमता को तोड़ देगा क्योंकि एंटर करने के बाद, आपके पास एक पूर्ण कमांड लाइन होगी।

संबंधित चर्चा #2819

मुझे इंटरैक्टिव सत्र के लिए खराब यूएक्स दिखाई देता है: पहले NewLine पार्सर अगले NewLine प्रतीक्षा करेगा या | या NewLine तक रिक्त स्थान छोड़ देगा - यह उपयोगकर्ता को भ्रमित करेगा .

स्क्रिप्ट के लिए यह अनुरोध है कि हम एक निरंतरता वर्ण `(बैकटिक) को समय से हटा दें क्योंकि हम हमेशा टाइप कर सकते हैं:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

पार्सर पहले से ही अन्य जगहों पर ऐसा करता है।

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

@lzybkr स्पष्ट रूप से पार्सर को समझने में सक्षम होने का मतलब यह नहीं है कि लोग _must_ इस तरह से कई लाइनें लिखते हैं - कई लोगों ने ऊपर के रूप में स्ट्रॉस्ट्रप शैली को अपनाया है, या यहां तक ​​​​कि "अपनी लाइन पर ब्रेस" और अन्य स्टाइल चीजें जो चिपकाने को तोड़ती हैं (विशेषकर जब से PSReadLine ने राइट-क्लिक के साथ गड़बड़ी की और Ctrl+V काम किया)। इससे कोई फर्क नहीं पड़ना चाहिए।

@iSazonov अंतःक्रियात्मक रूप से, यदि आप एंटर दबाते हैं, तो यह प्रतीक्षा नहीं करेगा, यह बस इसे चलाने जा रहा है। ठीक वैसे ही जैसे अब ऊपर else है। आप इसे कंसोल पर टाइप करने के लिए shift + enter हिट कर सकते हैं (जब आपके पास PSReadLine हो)।

PSReadline राइट-क्लिक के साथ गड़बड़ नहीं करता है, हालांकि एक कोने का मामला है जहां एक TAB वर्ण किसी चीज़ तक फैलता है, इसमें w/o PSReadline नहीं होगा - लेकिन इसका इससे अधिक लेना-देना है कि मल्टी-लाइन इनपुट कैसे काम नहीं कर रहा है अपेक्षित है यदि आप PSReadline का उपयोग नहीं करते हैं।

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

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

राइट-क्लिक-पेस्ट कुछ आधुनिकीकरण का उपयोग कर सकता है, पूरे क्लिपबोर्ड बफर को कंसोल में चिपका रहा है जैसे कि आपने शिफ्ट + प्रत्येक पंक्ति में प्रवेश किया था और फिर इसे इस तरह चला रहा था। इस मुद्दे पर विचार किए बिना भी मुझे लगता है कि यह अपने आप में उपयोगी होगा - आपने कितनी बार राइट-क्लिक-पेस्ट किया है जो बिल्कुल सही नहीं था (पार्स त्रुटियां) और त्रुटि संदेशों का एक गुच्छा देखा, शायद कुछ आदेशों के साथ छेड़छाड़ कि निष्पादित? आप जो पेस्ट कर रहे थे, उसके आधार पर यह काफी हानिकारक हो सकता है (ओह, कि cd कमांड ठीक से पार्स नहीं हुआ, इसलिए जब मैं del *.* -r -fo कमांड निष्पादित हुआ तो मैं अपनी वर्तमान सी: \ निर्देशिका में रहा। ..) यह बेहतर होगा यदि राइट-क्लिक-पेस्ट ने वास्तव में पूरे ब्लॉक को चिपका दिया, और पावरशेल पहले से ही निष्पादन पक्ष पर अच्छी तरह से संभालता है।

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

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

केवल कहने के लिए: लाइन निरंतरता वर्णों के बिना लाइन की शुरुआत में पावरशेल समर्थन पाइपलाइनों के लिए +1, और राइट-क्लिक-पेस्ट को ठीक करने का अनुरोध ताकि इंटरैक्टिव उपयोग और स्क्रिप्टिंग अनुभव के बीच बेहतर स्थिरता हो।

राइट क्लिक पॉवरशेल फीचर नहीं है, यह एक कॉनहोस्ट फीचर है। Conhost हमेशा यह नहीं मान सकता कि सिमुलेटिंग टाइपिंग वर्तमान कंसोल प्रक्रिया के साथ कुछ समन्वय के बिना पेस्ट के बराबर है।

हां। यह राइट-क्लिक पेस्ट को अजीब बना सकता है। ठीक उसी तरह else करता है।

यह कई पाइपों के साथ कमांड (कंसोल और फाइलों दोनों में) को और अधिक पठनीय बना देगा और जैसा कि पहले बताया गया है, बिल्कुल वही समस्या है जो प्रॉम्प्ट में निष्पादित होने पर/अन्य करता है।

अब तक | एक पंक्ति के अंतिम चरित्र के रूप में एक निरंतरता चरित्र के रूप में काम किया है। यह परिवर्तन विशेष रूप से क्या लाता है यदि यह पिछले व्यवहार को काम करना बंद कर देता है

मेरे आईपैड से भेजे गए

8 मार्च 2017, 17:04 पर, माइकल टी लोम्बार्डी < [email protected] [email protected] > ने लिखा:

यह कई पाइपों के साथ कमांड (कंसोल और फाइलों दोनों में) को और अधिक पठनीय बना देगा और जैसा कि पहले बताया गया है, बिल्कुल वही समस्या है जो प्रॉम्प्ट में निष्पादित होने पर/अन्य करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 पर https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD ।

क्या इस बदलाव के लिए जरूरी है कि एक | अभी भी एक नई लाइन की शुरुआत में EOL _साथ ही_ पर एक निरंतरता वर्ण नहीं हो सकता है? मुझे इसकी उम्मीद नहीं होगी।

@RichardSiddaway यह पठनीयता के बारे में है - यह कई बार प्रथाओं और स्टाइल रेपो में लाइन-रैपिंग के बारे में चर्चा में आया है। कुछ लोग पहले से ही इस तरह लिख रहे हैं, बस लाइन के अंत में बैकटिक्स का उपयोग कर रहे हैं।

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

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

बनाम

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

@jaykul इंडेंटेशन के ऊपर आपके उदाहरण में दृश्य तीक्ष्णता के दृष्टिकोण से उतना ही उपयोगी है। पाइप प्रतीक सिर्फ एक अतिरिक्त (और IMO अनावश्यक) संकेतक प्रतीत होता है।
अपना उदाहरण दिया, क्या यह आपको उतना ही आकर्षित करता है?

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

मेरी नज़र में, यह काफी समझ में आता है:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

यह इंडेंटेशन है जो मदद करता है (और इस तरह मैं इसे आमतौर पर लिखता हूं)

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

मैं स्पष्ट रूप से पाइप को पहले चरित्र के रूप में पसंद करता हूं, जैसा कि आपके पहले उदाहरण में, @JamesWTruher (यद्यपि पाइप और कमांड के पहले वर्ण के बीच एक ही स्थान के साथ) - यह एक सतत पाइपलाइन का एक बहुत स्पष्ट और स्पष्ट दृश्य संकेतक देता है . कोड पर स्क्रॉल करते समय इंडेंटेशन एक समान, लेकिन कम स्पष्ट, अनुमान देता है।

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

PS> dir
>

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

PS> dir
>
>

ठीक है - | sort Length और रिटर्न हिट करें।

PS> dir
>
>
> | sort Length
>

और फिर भी कुछ नहीं होता है क्योंकि _still_ एक निरंतरता टोकन हो सकता है, इसलिए इसे अभी भी एक नई लाइन के लिए सुनना होगा। अब आप कहते हैं 'मैं इसके साथ कर रहा हूं - यह काम नहीं करता है, चलो बस तारीख प्राप्त करें'। आप Get-Date टाइप करें और रिटर्न हिट करें। याय - आपको आउटपुट मिलता है। लेकिन यह Get-Date । नहींं - आपने अंततः dir | sort Length कमांड को पूरा कर लिया है, इसलिए यह वह आउटपुट है जिसे आप देख रहे हैं। इस बीच, कमांड रीडर अब आपके द्वारा Get-Date शुरू की गई कमांड को पूरा करने की प्रतीक्षा कर रहा है। या पूरी बात सिर्फ एक त्रुटि हो सकती है।

यह किसी भी उपयोगकर्ता के लिए एक भयानक इंटरैक्टिव अनुभव होगा।

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

तो जबकि मुझे वास्तव में पसंद है कि कैसे '|' हास्केल पैटर्न मिलान जैसी चीजों में लाइन की शुरुआत को देखता है:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
यह पावरशेल के लिए काम नहीं करेगा।

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

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

एक तरफ के रूप में, मैं नरम रिटर्न के बिना प्रॉम्प्ट में निम्नलिखित असफल होने की उम्मीद / ठीक हूं, जैसा कि एक गैर-कडलेड अगर / और करता है:

Get-Process
| Select-Object -First 1

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

@JamesWTruher को संबोधित करने के लिए - मैं उम्मीद करता हूं कि लोग निरंतरता लाइनों को इंडेंट नहीं करेंगे यदि पाइप सामने की तरफ था जो कि हो रहा था, इसके संकेत के रूप में:

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

@ ब्रूसपे तो, ठीक है। इंटरैक्टिव अनुभव _explicitly_ इसका समर्थन नहीं करेगा।

यदि आप लोग वास्तव में सोचते हैं कि इंटरैक्टिव और स्क्रिप्ट के बीच कोई अंतर नहीं है, तो आपको कभी-कभी PSReadLine के बिना PowerShell का उपयोग करने का प्रयास करना चाहिए।

आईएसई या वीएस कोड में कंसोल का उपयोग करने का प्रयास करें

जब तक आपके पास "लापता विवरण ब्लॉक" या "खाली पाइप तत्व" प्रकार के अपवादों को संभालने के लिए PSReadline नहीं है, आप एक पाइप के बाद एक नई लाइन नहीं डाल सकते हैं, न ही ऑलमैन-शैली ब्रेसिज़ लिख सकते हैं। आप निश्चित रूप से इनमें से कोई भी नहीं लिख सकते हैं:

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

तो हाँ, यह एक और जगह होगी जहां आप स्क्रिप्ट में लाइन ब्रेक कर सकते हैं लेकिन कंसोल पर नहीं। लेकिन हमारे पास पहले से ही उनमें से बहुत से हैं (_विशेषकर_ यदि आप PSReadLine का उपयोग नहीं कर रहे हैं)।

उस कोड को संदर्भित करने के लिए जो @Jaykul 1 और @JamesWTruher 2 के पास था, मैं इसका उपयोग करता हूं:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

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

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

PSReadline के साथ कंसोल में कॉपी और पेस्ट करने से मुझे कोई समस्या नहीं हुई (मैं याद कर सकता हूं) इसलिए ऐसा कुछ नहीं है जिसे मैं बीच में लाने जा रहा हूं और चर्चा में जोड़ दूंगा।

एक पंक्ति के अंत के बजाय पाइप को अगली पंक्ति में रखना एक बहुत ही F # जैसा विचार है, जहाँ आप इस तरह से काम कर सकते हैं:

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

और मैं सब कुछ के लिए हूं जो पीएस को थोड़ा अधिक कार्यात्मक बनाता है (सजा का इरादा);)

न केवल F# बल्कि Elm , Haskell , Elixir , और यहां तक ​​​​कि Google की शेल स्टाइल गाइड (और यहां ध्यान दें कि उन्हें इसे करने के लिए न्यूलाइन से बचना होगा ...)

@michaeltlombardi यूनिक्स के गोले की तरह, यदि आप चाहें तो PowerShell में नई पंक्तियों से बच सकते हैं

Get-Process | Where CPU | Where Path `
| Get-Item | Where FullName -match "AppData" `
| Sort-Object FullName -Unique

एफ # व्हाइटस्पेस-संवेदनशील (ऑफसाइड नियम) है जिस तरह से पावरशेल नहीं है। एल्म, हास्केल और अमृत, निश्चित रूप से, गोले नहीं हैं।

_खराब मेजबानों के बारे में शिकायतें_...

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

यदि आप लोग वास्तव में सोचते हैं कि इंटरैक्टिव और स्क्रिप्ट के बीच कोई अंतर नहीं है, तो आपको कभी-कभी PSReadLine के बिना PowerShell का उपयोग करने का प्रयास करना चाहिए।

मैंने PSReadLine के बिना एक दशक से अधिक समय तक PowerShell का उपयोग किया। क्या यह पर्याप्त है?

जब तक सॉफ्ट रिटर्न का उपयोग नहीं किया जाता है, तब तक यह त्रुटि दो रिक्त पंक्तियों पर ध्यान दें;

यह कैसे संभाला जाता है यह मेजबान कार्यान्वयन पर निर्भर करता है। यदि आप इसे बदलना चाहते हैं तो आपत्तिजनक मेजबानों पर एक मुद्दा खोलें।

बिल्कुल वही मुद्दा जो अगर/अन्यथा प्रॉम्प्ट में निष्पादित होने पर करता है।

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

@ जयकुल तो क्या आप F # के #light निर्देश के विपरीत चाहते हैं? #heavy जैसा कुछ जहां रिक्त स्थान अप्रासंगिक हैं और अर्धविराम अनिवार्य हैं?

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

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

मैं उस फॉर्म का उपयोग करूंगा यदि बैकटिक गलतियों का पता लगाना घास के ढेर में सुई खोजने जैसा नहीं था। नहीं, मुझे लगता है कि लाइन से बचने के बिना, पाइप-ए-द-शुरुआत प्रारूप को शैली के रूप में अपने अधिकार में अनुमति देना बेहतर होगा। :/

@ vexx32 जबकि मैं मानता हूं कि '`' देखना मुश्किल है, '|' नहीं है।

@ जयकुल तो क्या आप F # के #light निर्देश के विपरीत चाहते हैं? #heavy जैसा कुछ जहां रिक्त स्थान अप्रासंगिक हैं और अर्धविराम अनिवार्य हैं?

नहीं @BrucePay , मुझे बस इस तरह की एक और सिंटैक्स ट्रिक चाहिए:

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

जो मुझे इस बात की चिंता किए बिना कि क्या यह काम करता है जब आप कंसोल में टाइप कर रहे हैं या नहीं, मैं स्क्रिप्ट में _नीटली_ चीजें लिखता हूं।

@BrucePay सही है, और मेरे पास उन @ vexx32 सूचीबद्ध।

यह बताना पूरी तरह से उचित है कि पावरशेल में कई मौजूदा व्यवहार जिन पर लोग भरोसा करते हैं, वास्तव में मेजबान कार्यान्वयन का परिणाम हैं, इसलिए उन चीजों को स्पष्ट करने के लिए धन्यवाद! दूसरी ओर, इसका मतलब यह भी है कि भाषा में ऐसी चीजें हैं जो पहले से ही उन अपेक्षाओं को तोड़ती हैं जब तक कि मेजबान कार्यान्वयन उन्हें संभालने के लिए अतिरिक्त काम नहीं करता है, है ना?

@michaeltlombardi खराब मेजबान कार्यान्वयन के परिणामस्वरूप खराब इंटरैक्टिव अनुभव होगा लेकिन भाषा को ही प्रभावित नहीं करेगा। उस ने कहा, इंटरैक्टिव अनुभव अति महत्वपूर्ण है क्योंकि अधिकांश पावरशेल 'स्क्रिप्ट' अंतःक्रियात्मक रूप से टाइप किए जाते हैं।

हम यहां उनके बिना कोड लिखने की क्षमता की तलाश कर रहे हैं

मेरा कहना यह है कि यदि आप पंक्ति के अंत में | डालते हैं, तो निरंतरता निहित है और आपके अनुरोध के अनुसार किसी निरंतरता वर्ण की आवश्यकता नहीं है। और | प्रतीक को देखना आसान है। और कोड की संरचना को स्पष्ट रूप से दृश्यमान बनाने के लिए इंडेंटेशन का उपयोग करें। F# या Python के विपरीत, हम इंडेंटेशन को लागू नहीं करते हैं क्योंकि PowerShell एक शेल है और कभी-कभी आपको बहुत सघन कोड लिखने की आवश्यकता होती है।

@जयकुल

कंसोल में टाइप करते समय यह काम करता है या नहीं, इस बारे में चिंता किए बिना।

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

मैं पूरी तरह से समझता हूं कि कंसोल का अनुभव प्राथमिक है। मेरा कहना बस इतना है कि यह कंसोल को नहीं तोड़ना

इसे कंसोल _उसी तरह से व्यवहार करना चाहिए जैसा कि दूसरा catch ऊपर करता है: आप इसे केवल एक कंसोल में टाइप कर सकते हैं जहां आपके पास PSReadLine की तरह एक बहु-पंक्ति रीडलाइन है और इंजेक्शन लगाने के लिए Shift+Enter कर सकते हैं अतिरिक्त लाइन (या आप इसे पेस्ट कर सकते हैं) - इसे मौजूदा व्यवहार को बिल्कुल भी बदलने की आवश्यकता नहीं है।

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

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

सही। लेकिन कॉपी-पेस्ट की बात वर्तमान में केवल _full_ सच है, जब तक आप PSReadLine के Ctrl+V में पेस्ट कर रहे हैं और राइट-क्लिक के माध्यम से नहीं - और यह परिवर्तन वहां भी काम करेगा । यानी, इसके लिए मल्टी-लाइन पेस्ट सक्षम रीडलाइन की आवश्यकता होगी, लेकिन यह पावरशेल 5+ . में डिफ़ॉल्ट रूप से काम करेगा

जैसा कि मैंने ऊपर उल्लेख किया

मेरी राय यह है कि गैर-PSReadLine होस्ट के साथ समस्याओं की सूची में एक और बढ़त का मामला एक सुविधा को बाहर करने का एक बड़ा कारण नहीं है - आखिरकार, यह सिंटैक्स वैसे भी PowerShell 4 या 5 में काम नहीं करेगा, इसलिए यह ' ISE या गैर-PSReadline होस्ट में कभी भी काम नहीं करेगा। यह _मुझे थोड़ा पागल कर रहा है_ कि हम एक _more_ समस्या पर बहस करने के लिए इतना प्रयास खर्च कर रहे हैं {{not-our-problem}} में चिपकाने के साथ लेकिन हम इस तथ्य से ठीक हैं कि यह सिंटैक्स होगा जो पुराने में काम नहीं करता है पावरशेल के संस्करण ...

पीएस मैंने पेस्टिंग तर्क का उपयोग स्ट्रॉस्ट्रुप या ऑलमैन पर ओटीबीएस

काश _really_ हम OTBS साथ चला गया था। डीएसएल बहुत आसान होता।

OTBS, निश्चित रूप से, एक सच्चा तरीका है....

@BrucePay - मुझे यकीन है कि अभी भी कुछ लोग हैं जो मल्टी-लाइन कमांड लाइन पेस्ट करते हैं और Ctrl+v का उपयोग नहीं करते हैं, लेकिन मैं अनुमान लगा रहा हूं कि इतने सारे लोग नहीं हैं, और उन्हें बिना राइट क्लिक या Alt+Spacebar के चिपकाना चाहिए

मुझे लगता है कि इस बदलाव पर विचार करना बहुत ही उचित है।

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

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

यह शायद काम नहीं करेगा, लेकिन आपको शुरू करना चाहिए:

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

तुम सही हो, यह काफी वहाँ नहीं मिलता है। कम से कम आंशिक रूप से क्योंकि वर्तमान में पार्सर न्यूलाइन की संख्या की परवाह नहीं करता है; इतने सारे बयान कभी निष्पादित नहीं होते हैं । आगे बढ़ने के बारे में मेरे कुछ संभावित विचार हैं, इसलिए आपने मुझे एक पेचीदा पहेली दी है, धन्यवाद! मैं

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

ऊपर @Jaykul ने जो कहा,

@RichardSiddaway यह पठनीयता के बारे में है - यह कई बार प्रथाओं और स्टाइल रेपो में लाइन-रैपिंग के बारे में चर्चा में आया है। कुछ लोग पहले से ही इस तरह लिख रहे हैं, बस लाइन के अंत में बैकटिक्स का उपयोग कर रहे हैं।

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

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

बनाम

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

तो हाँ, मैं भविष्य में ऐसा करने में सक्षम होना चाहता हूँ

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

मुझे इसे जल्द ही किसी बिंदु पर एक और प्रयास देने की आवश्यकता है। यह एक पेचीदा पहेली है, लेकिन मैं वास्तव में यह नहीं जानता कि अभी तक कैसे हल किया जाए। मैं

मैं @किलासूट दोनों से सहमत हूं कि यह बहुत बढ़िया है अब हमारे पास

मैं @RichardSiddaway से भी सहमत हूं कि लाइन की शुरुआत में लाइन निरंतरता चरित्र का उपयोग करने के लिए _option_ प्राप्त करने में सक्षम होना अच्छा होगा। मैं पठनीयता के लिए कोडिंग में एक बड़ा वकील हूं इसलिए इंडेंटेशन (यानी पहला विकल्प) मैं उपयोग करता हूं और मैं इससे खुश हूं। मुझे वास्तव में दूसरे विकल्प का रूप पसंद नहीं है (मुझे लगता है कि यह बदसूरत दिखता है :)) लेकिन इसमें से कोई अस्पष्टता नहीं है। और मैं उन सभी लोगों के लिए हूं जिनके पास विकल्प हैं यदि यह पठनीयता में सुधार करता है!

कल रात मुझे लगा कि मैं पार्सर के साथ छेड़छाड़ कर रहा हूं, और इसने मुझे हमेशा परेशान किया ( मैंने हमेशा लाइन की शुरुआत में पाइप को प्राथमिकता दी है )। यहाँ परिणाम है:

मेरे पास एकमात्र सवाल यह है कि क्या इसे प्रयोगात्मक ध्वज के पीछे छुपाया जाना चाहिए या नहीं। यदि परीक्षण पर्याप्त हैं, तो इसे प्रयोगात्मक क्यों बनाएं, क्योंकि यह किसी मौजूदा कार्यक्षमता को प्रभावित नहीं करता है? विचार?

अब इसे कुछ पेस्टर परीक्षणों में समेटने के लिए...

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

यह वास्तव में ऐसा नहीं लगता कि डिजाइन पर कोई विवाद है, या तो।

एक साइड नोट के रूप में, यह बहुत बुरा है कि पावरशेल कमांड नामों को "-" से शुरू करने की अनुमति देता है। अन्यथा हम शायद बैकटिक्स के बिना भी न्यूलाइन पर पैरामीटर लपेट सकते हैं। निश्चित रूप से हमारे पास छींटे हैं, लेकिन यह काम कर सकता है _with Intellisense और सिंटैक्स हाइलाइटिंग_ यदि कमांड नाम पैरामीटर नामों से मेल नहीं खा सकते हैं:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

मैं अलग-अलग सीक्वल का इंतजार कर रहा हूं, लेकिन निश्चित रूप से लगता है कि इसे पहले चरित्र के रूप में रखने का विकल्प बहुत अच्छा है। निश्चित रूप से यह इंटरैक्टिव और स्क्रिप्ट के बीच अलग है, लेकिन यह इस बात के अनुरूप है कि पावरशेल पहले से ही कैसा है।

मेरे पास एकमात्र सवाल यह है कि क्या इसे प्रयोगात्मक ध्वज के पीछे छुपाया जाना चाहिए या नहीं। यदि परीक्षण पर्याप्त हैं, तो इसे प्रयोगात्मक क्यों बनाएं, क्योंकि यह किसी मौजूदा कार्यक्षमता को प्रभावित नहीं करता है? विचार?

मुझे नहीं पता कि पिछली बार MSFT टीम इतनी निष्क्रिय क्यों है, लेकिन यदि आप कोड प्रायोगिक टैग के तहत होंगे तो मैं तेजी से समीक्षा कर सकता हूं। इसके अलावा हम powershell.config.json में डिफ़ॉल्ट रूप से सुविधा को सक्षम कर सकते हैं।

यह बहुत बुरा है कि पावरशेल कमांड नामों को "-" से शुरू करने की अनुमति देता है।

मैं पूर्ण सहमत हूँ। मुझे लगता है कि नए मुद्दे पर पूरी तरह से चर्चा करना इसके लायक है। (ऐसे अन्य पात्र हैं जिन्हें हम दूर कर सकते हैं।)

"एक खाली पाइप तत्व की अनुमति नहीं है", इसलिए कोई ब्रेकिंग-संगतता समस्या नहीं होनी चाहिए यदि एक ही समय में लाइन निरंतरता और अगली पंक्ति की शुरुआत के लिए एक पाइप का उपयोग किया गया था:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

जो कई शिकायतों का समाधान करता है - निरंतरता के दृश्य संकेत के लिए लाइन की शुरुआत में कोई बैकटिक्स, पाइप नहीं; पहली पंक्ति टाइप करने के बाद इंटरेक्टिव प्रॉम्प्ट व्यवहार में कोई बदलाव नहीं क्योंकि यह बता सकता है कि क्या एक सतत लाइन की अपेक्षा करना है; आरक्षित || ऑपरेटर के साथ बहुत भ्रम नहीं है क्योंकि यह कई लाइनों में विभाजित है; बैकटिक और पाइप का उपयोग करने से ज्यादा टाइपिंग नहीं है; जयकुल के if/else , try/catch उदाहरणों के अनुसार बीच में एक टिप्पणी लाइन के साथ समस्या होने की आवश्यकता नहीं है।

@HumanEquivalentUnit - मैं यह नहीं कह सकता कि मैं उस सुझाव का प्रशंसक हूं क्योंकि मैं एक स्क्रिप्ट लेखक के रूप में यह तय कर सकता हूं कि मैं cmdline उपयोग के लिए एक स्क्रिप्ट के भीतर नई लाइनों को हटाना चाहता हूं और एक अव्यवहारिक और गैर-सहज ज्ञान युक्त सिंगल लाइन के साथ छोड़ दिया जाएगा वह आईएमओ
अत्याचारी लग रहा है

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

कौन

@kilasuit कि संपादित लाइन अजीब लग रही है (मेरे लिए अत्याचारी नहीं लगती है, बस अजीब है), लेकिन क्या यह वास्तव में बैकटिक्स वाले कोड से अलग है जो अब मान्य है, अगर आपने लाइन निरंतरता को हटाए बिना लाइनों को हटा दिया है? क्या आप वर्तमान में बैकटिक कोड के साथ उस समस्या से पीड़ित हैं?

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

यदि आप मुझसे पूछें, तो ईमानदार होने के लिए किर्क के पीआर का स्वागत करने का यह एक स्पष्ट कारण है। लाइनों को संघनित करते समय बैकटिक्स या अतिरिक्त पाइप की आवश्यकता नहीं होती है।

प्रारंभिक अनुरोध लागू किया गया था।
अब हम चर्चा करते हैं https://github.com/PowerShell/PowerShell-RFC/pull/179