वर्तमान विकल्प उपयोगकर्ताओं को पथ सामान्य करने के लिए मजबूर कर रहा है

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

सबसे अच्छा अभ्यास शाब्दिक पथों के उपयोग से बचना और पथ cmdlets का उपयोग करना है।

@iSazonov हाँ और नहीं।

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

विंडोज़ पर पावरशेल 7 पूर्वावलोकन 3 में, टैब पूर्णता बैकस्लैश का उपयोग करके पथ पूर्ण करती है। यही वह जगह है जहां मुझे लगता है कि हम अब गलत कर रहे हैं कि पावरशेल क्रॉस प्लेटफॉर्म है। टैब पूर्णता के भाग के रूप में विंडोज़ पर आपके द्वारा उपयोग किए जाने वाले निर्देशिका विभाजक चरित्र का चयन करने के लिए कम से कम एक विकल्प होना चाहिए: या तो [System.IO.Path]::DirectorySeparatorChar या [System.IO.Path]::AltDirectorySeparatorChar । यह देखते हुए कि हम आज कहां हैं, मुझे संदेह है कि अधिकांश लोग जो किसी भी क्रॉस प्लेटफॉर्म का काम करते हैं, वे चाहते हैं कि डिफ़ॉल्ट रूप से विंडोज़ पर AltDirectorySeparatorChar का उपयोग करने के लिए पथों का टैब पूरा हो, लेकिन जहां तक ​​​​मुझे पता है कि ऐसा करने का कोई तरीका नहीं है। .

@chriskuech : पथों के टैब पूर्ण होने के अलावा, क्या ऐसे अन्य स्थान हैं जहां आपको लगता है कि AltDirectorySeparatorChar का उपयोग नहीं किया जा रहा है जहां आप DirectorySeparatorChar के बजाय इसका उपयोग करने का विकल्प चाहते हैं? मैं किसी के बारे में नहीं सोच सकता।

@ किर्कमुनरो , क्या आप कह रहे हैं कि आज पावरशेल में पथ सामान्य करने का एक (कम से कम आंशिक रूप से कार्यान्वित) तरीका है? यदि हां, तो क्या यह नवीनतम 6.x पर कार्य करेगा? जिन मामलों में मुझे समस्या हो रही थी, वे स्वचालित चर और *-Path कमांड थे।

@iSazonov , प्रस्तावित समाधान ने मेरे परिदृश्य के लिए काम नहीं किया होगा क्योंकि मैंने विंडोज़ पर पथों की एक सूची तैयार की, लिनक्स पर पथों की एक सूची तैयार की, फिर उनकी तुलना करने का प्रयास किया, जो विभाजकों के कारण विफल रहा।

स्वचालित चर में लगातार अनुगामी निर्देशिका विभाजक का अभाव होता है, इसलिए PowerShell खूबसूरती से शाब्दिक के साथ पथ बनाने की अनुमति देता है। भूतपूर्व:

$RepoRoot = "$PSScriptRoot/../.."
$SourceRoot = "$RepoRoot/src"
$BuildRoot = "$RepoRoot/.build"

मुझे लगता है कि यह इससे कहीं अधिक स्पष्ट है

$RepoRoot = Join-Path $PSScriptRoot "../.."
$SourceRoot = Join-Path $RepoRoot "src"
$BuildRoot = Join-Path $RepoRoot ".build"

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

@chriskuech मेरी निजी आदत कुछ इस तरह बन गई है:

$SourceRoot = $RepoRoot | Join-Path -ChildPath 'src'

यह थोड़ा स्पष्ट है लेकिन हाँ यह सही नहीं है।

Join-Path में AdditionalChildPath है जो स्ट्रिंग सरणी को स्वीकार करता है।

@chriskuech अतिरिक्त जानकारी के लिए धन्यवाद।

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

अगर मैं इसे बदलने के लिए कुछ सेटिंग बदल सकता हूं ताकि डिफ़ॉल्ट रूप से विंडोज़ पथों पर भी फॉरवर्ड स्लैश का उपयोग किया जा सके, तो मैं वह बदलाव करूँगा, और यह एक ऐसा स्थान है जहां मुझे लगता है कि क्रॉस प्लेटफॉर्म पावरशेल काम को आसान बनाने का अवसर हो सकता है। Join-Path पथ विभाजक के रूप में भी [System.IO.Path]::DirectorySeparatorChar $ का उपयोग करता है। आदर्श रूप से यदि स्क्रिप्ट लिखते समय वांछित पथ विभाजक सेट करने के लिए एक सेटिंग थी (क्योंकि हमें स्क्रिप्ट को आसानी से लिखने में सक्षम होना चाहिए जिस तरह से हम चाहते हैं कि जिस प्लेटफॉर्म पर हम उन्हें लिखना चाहते हैं), यह दोनों टैब पूर्णता में दिखाई देगा पथ और Join-Path भी।

उन व्यक्तिगत जरूरतों को एक तरफ, मुझे आश्चर्य है कि Compare-Path cmdlet उपयोगी होगा या नहीं। यह पथ विभाजकों को सामान्य कर सकता है, और तुलना करने से पहले सापेक्ष पथों को हल करके सापेक्ष पथों के साथ पूर्ण पथ की तुलना भी कर सकता है यदि पथों में से एक पूर्ण है।

खैर, हमें Convert-Path और Resolve-Path में _platform-specific_ सामान्यीकरण मिलता है:

PS> Convert-Path C:/Windows
C:\Windows # normalized to Windows-native "\"

तो, शायद Compare-Path cmdlet शुरू करने के विकल्प के रूप में, Convert-Path और Resolve-Path को -UseSlash स्विच (नाम परक्राम्य) का समर्थन करने के लिए बढ़ाया जा सकता है।

अलग से और पूरक रूप से, किर्क द्वारा सुझाए गए विंडोज़ पर / का उपयोग करने के लिए ऑप्ट-इन वरीयता तंत्र तब Convert-Path और Resolve-Path पर भी लागू हो सकता है (टैब पूर्णता और Join-Path के अतिरिक्त)

इस समय पकड़ यह है कि Convert-Path और Resolve-Path केवल _मौजूदा_ रास्तों के साथ काम करते हैं, लेकिन यह अपने आप में बदलने लायक कुछ है, जैसा कि @jaykul ने कुछ समय पहले सुझाव दिया था - #2993 देखें

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

तो विंडोज़ पर, c:\w c:\Windows\ तक पूरा होता है और c:/w 'c:/Windows/' तक पूरा होता है।

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

@lzybkr , मुझे यह विचार पसंद है, कॉन्फ़िगरेशन-/वरीयता-चर-आधारित समाधान के संबंध में चिंता के प्रकाश में भी जिसे मैंने उल्लेख करने के लिए उपेक्षित किया: स्कोपिंग मुद्दा; सामान्य _dynamic_ स्कोपिंग के साथ, कोड जो पथ विभाजकों के बारे में निश्चित धारणा बनाता है, टूट सकता है (जिसमें https://github.com/PowerShell/PowerShell-RFC/issues/7 की गूँज है)।

@lzybkr और जब दोनों स्लैश का उपयोग किया जाता है? C:\Program Files/A -> ?

इतने सारे विकल्प - यादृच्छिक, हर एक को वैकल्पिक, हमेशा आगे स्लैश b/c यह एक सच्चा पथ विभाजक है, आदि।

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

@lzybkr : हालांकि, एक पकड़ है:

यदि आप _बिना_ एक पथ विभाजक प्रारंभ करते हैं, तो _current निर्देशिका_ में किसी फ़ाइल/फ़ोल्डर को संदर्भित करने के लिए, पावरशेल को आपके लिए चुनाव करना होगा, कम से कम वर्तमान पूर्णता एल्गोरिदम के आधार पर जो .\<filename> या ./<filename> तक फैलता है .\<folder>\ या ./<folder>/ , प्लेटफॉर्म-उपयुक्त।

_files_ के रूप में _arguments_ के लिए, हम fil को केवल file तक विस्तारित करके उस समस्या को दूर कर सकते हैं, उदाहरण के लिए (कोई .\ / ./ उपसर्ग)।

हालाँकि:

• _executables_ के लिए, स्वचालित रूप से जोड़ा गया .\ / ./ उपसर्ग एक मूल्यवान सुविधा है यदि इरादा वास्तव में वर्तमान निर्देशिका में स्थित एक स्क्रिप्ट को निष्पादित करने का है।

• _directories_ के लिए, इसी तरह, _trailing पथ विभाजक_ ( <folder>\ या <folder>/ ) के साथ किसी चीज़ का विस्तार करना भी मूल्यवान है।

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

उस ने कहा, शायद समाधान यह है: यदि आप विभाजक को नियंत्रित करना चाहते हैं, तो _ मैन्युअल रूप से _ ./ या .\ से शुरू करें और टैब को पूरा करने का सम्मान करें।

इस मुद्दे को उत्तर के रूप में चिह्नित किया गया है और 1 दिन से कोई गतिविधि नहीं हुई है। इसे हाउसकीपिंग उद्देश्यों के लिए बंद कर दिया गया है।

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

मुझे लगता है कि मैंने सभी प्रश्नों को मुझे संबोधित किया, लेकिन अगर मैंने नहीं किया तो मुझे बताएं। मुझे भी यकीन नहीं है कि यह मुद्दा क्यों बंद किया गया है। यह एक चर्चा सूत्र के रूप में नहीं था, बल्कि एक फीचर अनुरोध था।

हाथ में मूल मुद्दा:

• क्या क्रॉस-प्लेटफ़ॉर्म टूल में डिफ़ॉल्ट रूप से गैर-क्रॉस-प्लेटफ़ॉर्म व्यवहार होना चाहिए?
• यदि हां, तो क्या वैश्विक स्तर पर पावरशेल को "क्रॉस-प्लेटफ़ॉर्म" मोड में चलाने का कोई तरीका होना चाहिए?

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

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

@chriskuech : मेरा बुरा, मैंने विशेष रूप से आपसे सवाल नहीं किया। मैं सोच रहा था कि क्या आपको लगता है कि Conpare-Path cmdlet आपकी मदद करेगा। हालांकि यह सवाल एक तरफ है, मैं सामान्यीकरण विकल्प भी देखना चाहता हूं।

@KirkMunro मुझे यकीन नहीं है कि Compare-Path मदद करेगा, क्योंकि मूल उपयोग के मामले में (लिनक्स और विंडोज़ पर पथों की तुलना करना), रूट फाइल सिस्टम अलग है, इसलिए मुझे Resolve-Path -Relative पर कॉल करना होगा। उस समय तुलना उपयोग का मामला सिर्फ एक-लाइनर है: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} ।

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

@KirkMunro @mklement0 मुद्दा बंद नहीं है और हर कोई टिप्पणी कर सकता है।
नई टिप्पणियों और प्रगति के बिना हमारे पास बहुत सारे मुद्दे हैं। खुली स्थिति ने अपना अर्थ खो दिया है।
एक अनुरक्षक के रूप में, मैं चर्चाओं को और अधिक कठोर विनिर्देश बनने के लिए प्रोत्साहित करने के लिए और अधिक सटीक होने का इरादा रखता हूं जो आसानी से पीआर में बदल सकते हैं।
मुद्दे के लिए, यह अनंत में बदल जाता है - प्रारंभिक अनुरोध "विंडोज़ पर फॉरवर्ड स्लैश का उपयोग करें", फिर "पथों की तुलना करें"। आगे क्या है? रिमोटिंग? यह जारी रखने के लिए खुला है लेकिन बंद रहेगा।
जबकि जेसन से केवल एक वास्तविक प्रस्ताव ऊपर था (पूर्णता बढ़ाने के लिए) और हम एक ट्रैकिंग समस्या खोल सकते थे और इसे वास्तविक पीआर द्वारा बंद कर सकते थे।

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

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

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

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

खुली स्थिति ने अपना अर्थ खो दिया है।

कौन कहता है? यह बिल्कुल सच नहीं है। एक खुला मुद्दा खुला है, और एक बंद मुद्दा बंद है। उन दो भेदों का बहुत स्पष्ट अर्थ है। मैं केवल बंद मुद्दों को देखता हूं यदि वे मेरे अपने हैं और मैं कुछ जांचने के लिए वापस जाना चाहता हूं। एक दुर्लभ अवसर पर मैं एक निश्चित विषय पर चर्चा के लिए बंद मुद्दों की खोज कर सकता हूं। लेकिन मुद्दों में मेरा 90% या उससे अधिक समय खुले मुद्दों में है, जैसा कि होना चाहिए। दोनों के बीच की रेखा को धुंधला करने और खुले मुद्दों को अपना अर्थ खो देने वाली एकमात्र चीज उन्हें हल करने से पहले संक्षेप में बंद करना है, जैसे आपने इस मुद्दे के साथ किया है।

(चर्चा) जारी रखने के लिए खुला है लेकिन बंद रहेगा।

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

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

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

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

वफादार लिनक्स उपयोगकर्ता? समझ से बाहर सलाह।
आप माइक्रोसॉफ्ट को मना सकते हैं। उन्हें सिस्टम फ़ाइल पथ के रूप में बैकस्लैश का उपयोग करने के लिए कहें।

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

मैं सिर्फ एक स्क्रिप्ट लिख रहा था जहां मैं ज़िप अभिलेखागार में हेरफेर करने और बनाने के लिए .net एपीआई का उपयोग कर रहा था। इस एपीआई के साथ ज़िप फ़ाइल में प्रविष्टियाँ जोड़ना:

    [System.IO.Compression.ZipFileExtensions]::CreateEntryFromFile(
        $zip, $file, $entry,
        [System.IO.Compression.CompressionLevel]::Optimal
    ) > $null

इस विशेष मामले में, $ entry ज़िप संग्रह के भीतर एक पथ है। यदि मैं विभिन्न पथ cmdlets द्वारा लौटाए गए विंडोज़ पथ को आसानी से पास करता हूं, तो ग्रह पर प्रत्येक ज़िप उपयोगिता मेरी ज़िप फ़ाइल में गलत स्लैश होने के बारे में चेतावनी देगी।

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

लेकिन यह अभी भी मुझे दुखी करता है कि मेरे सभी टैब पूर्ण बैकस्लैश के साथ फिर से लिखे गए हैं।

मैं हर समय विंडोज़ पर /users/foo/somefile जैसे पथों का उपयोग करता हूं और यही वह है जिसका मैं उपयोग करना चाहता हूं।

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

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

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

@iSazonov उपयोगकर्ता स्लैश का उपयोग कर सकते हैं, जो प्लेटफॉर्म की परवाह किए बिना वे सहज हैं।

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

@aaronfranke , नहीं, वर्तमान में इस तरह से PowerShell को कॉन्फ़िगर करने का कोई तरीका नहीं है; मुझे लगता है कि @iSazonov जो कहना चाह रहा था, वह यह है कि जब आप मैन्युअल रूप से एक पथ टाइप करते हैं, तो आप \ और / के बीच चयन करने के लिए स्वतंत्र होते हैं (और आप उन्हें एक ही पथ में मिला भी सकते हैं) .

बहुमुखी प्रतिभा को ध्यान में रखते हुए / के बजाय एक नया पथ प्रतीक सक्षम किया जाना चाहिए और पारंपरिक प्रतीकों से प्लेटफार्मों में रूपांतरण की कठिनाई बढ़ जाती है

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

हाँ, यह पॉवरशेल डिज़ाइन है।

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

@rkitover मैंने सालों पहले ऐसे परिदृश्यों के बारे में पूछा था (आप इस मुद्दे को ढूंढ सकते हैं) बिना किसी संकल्प के। यह मुझे विश्वास दिलाता है कि यह एक कॉस्मेटिक बदलाव है, हालांकि इसके लिए बहुत प्रयास की आवश्यकता होती है। यदि आप इस क्षेत्र में निवेश करने और पीआर खींचने के लिए तैयार हैं, तभी एक नई चर्चा खोलने का कोई मतलब है।

CP/M और क्लोन विकल्पों के लिए / का उपयोग करते हैं, उदाहरण: DIR/P , CMD/CECHO । ये वैध आदेश हैं। अगर हम हर जगह \ को / से बदल दें, तो मुझे डर है कि गलत गलतफहमियां हो सकती हैं।

1. अब कोई भी CP/M का उपयोग नहीं करता है।

2. एक ही समय में दोनों विकल्पों और पथों के लिए / का उपयोग करना मेरे परीक्षण में विंडोज़ पर ठीक काम करता है।

3. आधुनिक उपकरण इसके बजाय विकल्पों के लिए - का उपयोग करते हैं, जिसमें PowerShell उपकरण और अन्य Microsoft उपकरण जैसे .NET शामिल हैं। पश्चगामी संगतता के लिए विकल्पों के लिए / का उपयोग करना चाहिए, लेकिन उपयोगकर्ताओं को आधुनिक उपकरणों के साथ कोई भ्रम नहीं होगा।

साथ ही, मैं यह नोट करना चाहूंगा कि फॉरवर्ड स्लैश / Win32 फ़ाइल नामों में एक अमान्य वर्ण नाम है:

https://gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3

सार

Windows फ़ाइल नामों के लिए अमान्य वर्ण

Windows फ़ाइल नाम के लिए अमान्य वर्ण। GitHub Gist: तुरंत कोड, नोट्स और स्निपेट साझा करें।

मैं केवल यह बताना चाहता हूं कि मैंने केवल क्रॉस-प्लेटफ़ॉर्म स्क्रिप्ट आदि में फ़ॉरवर्ड स्लैश का उपयोग करना शुरू किया और प्रतीकात्मक लिंक के साथ एक समस्या का सामना किया।

एक उदाहरण के रूप में, भागो

new-item -itemtype SymbolicLink -path TestScript8.ps1 -target ./TestScript.ps1

विंडोज़ पर और आप विंडोज़ पर वीएस कोड में TestScript8.ps1 नहीं खोल पाएंगे।

@markm77 , आपने एक _bug_ खोजा है - क्या आप कृपया इसके लिए एक नया मुद्दा बना सकते हैं ? [_अपडेट_: #13064 देखें]

ऐसा नहीं है कि यह / , @aaronfranke को डिफ़ॉल्ट करने के लिए एक ऑप्ट-इन तंत्र के खिलाफ एक तर्क है, लेकिन ध्यान दें कि कुछ किनारे के मामले हैं जहां / के बजाय \ अभी भी टूटता है विंडोज़ पर चीजें; उदाहरण:

PS> cmd /c dir C:/
Invalid switch - ""

पथ को दोहरा-उद्धृत करना केवल _directory_ पथों के साथ मदद करता है, उत्सुकता से - https://stackoverflow.com/a/43297482/45375 देखें , जो यह भी दर्शाता है कि एक्सेल COM ऑटोमेशन लाइब्रेरी / समर्थन नहीं करती है।

स्टैक ओवरफ़्लो

PowerShell मेरी फ़ाइल को CSV के रूप में सहेजना क्यों नहीं चाहता है

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # एक्सेल दस्तावेज़ खोलें और 'शीट1' वर्कशीट में खींचें $Excel = New-Object -Com Excel.Application $वर्कबुक...

@markm77 , आपने एक बग खोजा है - क्या आप कृपया इसके लिए एक नया मुद्दा बना सकते हैं?

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

एनबी सिम-लिंक लक्ष्यों पर convert-item चलाकर इस मुद्दे के आसपास काम करना काफी आसान है, जिसमें सिम-लिंक पॉइंट को पूर्ण पथ (शायद उपयुक्त) सुनिश्चित करने का अतिरिक्त लाभ है।

एनबी सिम-लिंक लक्ष्यों पर convert-item चलाकर इस मुद्दे के आसपास काम करना काफी आसान है, जिसमें पूर्ण पथ (शायद उपयुक्त) के लिए सिम-लिंक बिंदु सुनिश्चित करने का अतिरिक्त लाभ है।

अनुपयुक्त, रिमाउंट करने पर टूट जाएगा

अनुपयुक्त, रिमाउंट करने पर टूट जाएगा

उचित टिप्पणी, मैं रिमाउंट नहीं करता (यह स्थानीय देव कार्य के लिए है) और मेरे पास लिंक पुन: पीढ़ी के लिए एक स्क्रिप्ट है जिसे मैं किसी भी समय चला सकता हूं। join-path स्पष्ट रूप से अन्य समाधान है या इससे भी बेहतर एक new-item विकल्प होगा ताकि यह सुनिश्चित किया जा सके कि लिंक प्लेटफॉर्म-उपयुक्त हैं।

देखें #12797

लेकिन क्या यह पॉवरशेल बग है?

जबकि आप यह तर्क दे सकते हैं कि _Windows_ पर यह एक WinAPI बग है, यह देखते हुए कि \ और / आमतौर पर परस्पर समर्थित हैं, यह निश्चित रूप से यूनिक्स जैसे प्लेटफॉर्म पर एक बग है यदि आप रिवर्स करते हैं और पास करते हैं \ आधारित पथ के रूप में -Target पथ - ऐसे प्लेटफार्मों पर, केवल / मूल रूप से समर्थित है (यह केवल पावरशेल है जो आपको \ के रूप में उपयोग करने की अनुमति देता है एक विकल्प, जो अपनी समस्याओं के साथ आता है - #9244 देखें), और सिमलिंक बनाते समय .\TestScript.ps1 से ./TestScript.ps1 जैसी किसी चीज़ का अनुवाद करना पावरशेल की ज़िम्मेदारी है।

इसे ठीक करना - पावरशेल को (प्राथमिक) _platform-native_ विभाजक का उपयोग करने के लिए पथ को सामान्य बनाने से - विंडोज़ पर भी समस्या ठीक हो जाएगी।

@iSazonov , #12797 सिम्लिंक लक्ष्य के रूप में _relative_ पथों के लिए मौलिक रूप से सक्षम समर्थन, लेकिन हाथ में समस्या प्लेटफ़ॉर्म-नेटिव सेपरेटर सामान्यीकरण की कमी है, जो परिणामी सिम्लिंक को तोड़ता है।

@iSazonov कृपया # 13064 देखें जो अभी भी पावरशेल कोर 7.1.0-पूर्वावलोकन.4 के रूप में टूटा हुआ है (जिसमें # 12797, दाएं शामिल होना चाहिए)?

धन्यवाद @ mklement0 सापेक्ष सिम्लिंक व्यवहार की गहन जांच और मुद्दे को उठाने के लिए https://github.com/PowerShell/PowerShell/issues/13064। मैंने उस विशेष मुद्दे और इस चर्चा को आगे बढ़ाने के लिए एक नोट बनाया था, लेकिन वास्तव में ऐसा लगता है कि आपने https://github.com/PowerShell/PowerShell/issues/13064 में सब कुछ कवर कर लिया है और वास्तव में मुझे सिखाया है कि कैसे पावरशेल परीक्षण लिखने के लिए (मैं पावरशेल में नया हूं)... चीयर्स!

मैंने इस मुद्दे का विस्तार से पालन नहीं किया है, इसलिए अगर मुझे कुछ याद आती है तो मुझे क्षमा करें। प्रारंभिक मुद्दा एक क्रॉस प्लेटफॉर्म स्टैंडराइज्ड पाथ सेपरेटर (संभावित रूप से एक फॉरवर्ड स्लैश) था। @iSazonov ने अब इस मुद्दे को बंद कर दिया है। क्या आप कृपया एक सिंहावलोकन दे सकते हैं कि आपको क्यों लगता है कि यह अब मान्य नहीं है, ताकि जिन लोगों को करीबी घटनाओं के मुद्दे पर सदस्यता दी गई, वे साथ चल सकें?

https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 के अनुसार यह कभी भी मान्य नहीं था।

जैसा कि ऊपर प्रस्तावित @lzybkr अभी भी पूरी तरह से उचित है - और संभवतः आसान - लागू करने की बात है; संक्षेप में दुहराना:

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

यह तब उपयोगकर्ता की जिम्मेदारी है कि वह उन दुर्लभ-किनारे वाले मामलों से बचें जहां / अभी भी विंडोज़ पर टूटता है ( ऊपर देखें)।

पावरहेल के माध्यम से wsl बैश स्क्रिप्ट चलाते समय यह वास्तविक सिरदर्द का कारण बनता है। पसंद:

bash .\updateTemplate.sh

यह करने के लिए स्वत: पूर्ण किया जाना चाहिए

bash ./updateTemplate.sh

क्या इस समस्या का कोई अन्य समाधान है? विशेष रूप से मैं पूरी तरह से ठीक हो जाऊंगा यदि पीएस केवल बैश/डब्लूएसएल संदर्भ पर आगे की स्लैश के साथ पथ स्वत: पूर्ण करता है।

क्या इस समस्या का कोई अन्य समाधान है?

बैश के लिए कस्टम कंप्लीटर बनाएं।

क्या इस समस्या का कोई अन्य समाधान है?

बैश के लिए कस्टम कंप्लीटर बनाएं।

आप यह कैसे करते हैं?

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