البديل الحالي هو إجبار المستخدمين على تطبيع المسارات

يقوم PowerShell بالفعل بالعمل نيابة عنك ولا تحتاج إلى تطبيع المسارات.
يعد PowerShell سهل الاستخدام للغاية هنا - يمكن للمستخدمين استخدام خطوط مائلة مريحة بغض النظر عن النظام الأساسي.
أفضل ممارسة هي تجنب استخدام المسارات الحرفية واستخدام أوامر cmdlets للمسار.

أفضل ممارسة هي تجنب استخدام المسارات الحرفية واستخدام أوامر cmdlets للمسار.

@ iSazonov نعم ولا.

بالتأكيد ، إذا كنت تقوم بدمج مقاطع المسار ، فيمكنك استخدام أوامر cmdlets للمسار. ولكن إذا كنت تكتب برنامجًا نصيًا يشير إلى مسار نسبي بمقاطع متعددة ، وإذا كنت تنوي أن يعمل البرنامج النصي عبر النظام الأساسي ، فلن تفعل ذلك.

في معاينة PowerShell 7 3 على Windows ، يكمل إكمال علامة التبويب المسارات باستخدام شرطة مائلة للخلف. هذا هو المكان الوحيد الذي أعتقد أننا نخطئ فيه الآن لأن PowerShell عبارة عن منصة مشتركة. يجب أن يكون هناك على الأقل خيار لتحديد حرف فاصل الدليل الذي تريد استخدامه على Windows كجزء من إكمال علامة التبويب: إما [System.IO.Path]::DirectorySeparatorChar أو [System.IO.Path]::AltDirectorySeparatorChar . بالنظر إلى ما وصلنا إليه اليوم ، أظن أن معظم الأشخاص الذين يقومون بأي عمل عبر النظام الأساسي سيرغبون في إكمال علامات التبويب الخاصة بالمسارات لاستخدام AltDirectorySeparatorChar على نظام التشغيل Windows افتراضيًا ، ولكن بقدر ما أعرف لا توجد طريقة للقيام بذلك .

chriskuech : بصرف النظر عن استكمال المسارات بعلامة تبويب ، هل هناك أماكن أخرى تشعر فيها أن AltDirectorySeparatorChar لا يتم استخدامه حيث تريد أن يكون لديك خيار لاستخدامه بدلاً من DirectorySeparatorChar ؟ لا أستطيع التفكير في أي شيء.

KirkMunro ، هل تقول أن هناك طريقة (تم تنفيذها جزئيًا على الأقل) لتطبيع المسارات في PowerShell اليوم؟ إذا كان الأمر كذلك ، فهل سيعمل على الإصدار 6.x الأخير؟ كانت حالات الاستخدام التي كنت أواجه مشكلة فيها عبارة عن متغيرات تلقائية وأوامر *-Path .

iSazonov ، الحل المقترح لم يكن لينجح مع السيناريو الخاص بي لأنني أنشأت قائمة بالمسارات على Windows ، وأنشأت قائمة بالمسارات على Linux ، ثم حاولت مقارنتها ، والتي فشلت بسبب الفواصل.

تفتقر المتغيرات التلقائية باستمرار إلى فاصل دليل لاحق ، لذلك يسمح 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 شكرًا على المعلومات الإضافية.

لم أكن أقترح أن PowerShell يدعم جزئيًا تطبيع المسارات. كنت أستدعي ببساطة أنني شخصياً لا أحب أن إكمال علامة التبويب هذه يستخدم شرطة مائلة للخلف بشكل افتراضي على Windows ، وشرطة مائلة للأمام بشكل افتراضي على Linux أو macOS.

إذا كان بإمكاني تعديل بعض الإعدادات لتغيير ذلك بحيث يتم استخدام الشرطة المائلة للأمام حتى على مسارات Windows افتراضيًا ، فسأقوم بإجراء هذا التغيير ، وهذا هو المكان الذي أعتقد أنه قد تكون هناك فرصة لجعل عمل PowerShell عبر النظام الأساسي أسهل. يستخدم $ Join-Path [System.IO.Path]::DirectorySeparatorChar كفاصل للمسار أيضًا. من الناحية المثالية ، إذا كان هناك إعداد لتعيين فاصل المسار المطلوب عند كتابة البرامج النصية (لأننا يجب أن نكون قادرين على كتابة البرامج النصية بسهولة بالطريقة التي نريدها بغض النظر عن النظام الأساسي الذي نختار الكتابة عليه) ، فسوف ينعكس ذلك في كلا الجدولين المسارات و Join-Path أيضًا.

بغض النظر عن تلك الاحتياجات الشخصية ، أتساءل عما إذا كان cmdlet Compare-Path سيكون مفيدًا. يمكنه تسوية فواصل المسار ، وحتى مقارنة المسارات المطلقة بالمسارات النسبية عن طريق حل المسارات النسبية قبل إجراء المقارنة إذا كان أحد المسارات مطلقًا.

حسنًا ، نحصل على تسوية خاصة بالمنصة في Convert-Path و Resolve-Path :

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

لذلك ، ربما كبديل لإدخال cmdlet Compare-Path # $ 3 $ # $ ، يمكن تمديد Convert-Path و Resolve-Path لدعم التبديل -UseSlash (الاسم قابل للتفاوض).

بشكل منفصل ومتكامل ، يمكن أيضًا تطبيق آلية تفضيل الاشتراك لاستخدام / على Windows التي يقترحها Kirk على Convert-Path و Resolve-Path (بالإضافة إلى إكمال علامة التبويب و Join-Path ).

المهم في الوقت الحالي هو أن Convert-Path و Resolve-Path يعملان فقط مع المسارات _ الحالية ، لكن هذا شيء يستحق التغيير في حد ذاته ، كما اقترح jaykul منذ وقت طويل - انظر # 2993

أعتقد أنه سيكون من الجيد أن يستخدم إكمال المسار فاصل المسار الذي يظهر بوضوح في نص الإكمال ، وإذا لم يكن هناك أي شيء ، فسيتم استخدام فاصل النظام الأساسي بشكل افتراضي.

لذلك في Windows ، يكتمل c:\w إلى c:\Windows\ $ ويكمل c:/w إلى 'c: / Windows /'.

أعتقد أن هذا سيغطي غالبية الإزعاج دون الحاجة إلى خيار تكوين ، وهو في الواقع مفضل لأنك قد تحتاج أحيانًا إلى النموذج الآخر لأي سبب من الأسباب.

lzybkr ، تعجبني الفكرة ، أيضًا في ضوء القلق المتعلق بالحل القائم على التكوين / التفضيل الذي أهملت ذكره: مشكلة تحديد النطاق ؛ باستخدام النطاق الديناميكي المعتاد ، قد ينكسر الكود الذي يضع افتراضات ثابتة حول فواصل المسار (والذي له أصداء https://github.com/PowerShell/PowerShell-RFC/issues/7).

lzybkr ومتى يتم استخدام الشرطتين المائلتين؟ C:\Program Files/A ->؟

الكثير من الخيارات - عشوائي ، بديل لكل واحد ، دائمًا مائل للأمام b / c هو فاصل المسار الحقيقي ، إلخ.

الأكثر جدية ، ربما فقط اختر آخر واحد مستخدم ، ربما كتبه المستخدم بينما قد لا يكون الآخرون كذلك.

lzybkr : هناك مشكلة واحدة ، على الرغم من:

إذا بدأت _ بدون _ فاصل مسار ، للإشارة إلى ملف / مجلد في _current directory_ ، فسيتعين على PowerShell تحديد الخيار لك ، على الأقل بناءً على خوارزمية الإكمال الحالية التي تتوسع إلى .\<filename> أو ./<filename> / .\<folder>\ أو ./<folder>/ ، النظام الأساسي مناسب.

بالنسبة إلى _الملفات _ _ الوسائط _ ، يمكننا تجنب هذه المشكلة عن طريق توسيع fil إلى file فقط ، على سبيل المثال (لا توجد بادئة .\ / ./ ).

ومع ذلك:

• بالنسبة للملفات القابلة للتنفيذ_ ، فإن البادئة التي تمت إضافتها تلقائيًا .\ / ./ هي راحة قيمة إذا كان القصد بالفعل هو تنفيذ برنامج نصي موجود في الدليل الحالي.

• بالنسبة إلى _directories_ ، بالمثل ، فإن التوسيع إلى شيء ما باستخدام فاصل مسار المسار _ ( <folder>\ أو <folder>/ ) يعد أيضًا ذا قيمة.

في كلتا الحالتين ، لا يوجد أي إجراء من جانب المستخدم يشير ضمنًا إلى الفاصل المفضل.

ومع ذلك ، ربما يكون الحل هو: إذا كنت تريد التحكم في الفاصل ، فابدأ يدويًا بـ_ ./ أو .\ واجعل إكمال علامة التبويب مناسبًا لذلك.

تم وضع علامة "تمت الإجابة" على هذه المشكلة ولم يكن لها أي نشاط لمدة يوم واحد . تم إغلاقه لأغراض التدبير المنزلي.

iSazonov : لم تتم الإجابة على هذا السؤال حقًا ، ويجب إعادة فتحه للسماح للمناقشة المستمرة بمواصلة العمل على حل هذه المشكلة. لم تتح لـ OP حتى الفرصة للرد على الأسئلة المطروحة عليه.

أعتقد أنني وجهت جميع الأسئلة إلي ، لكن أعلمني إذا لم أفعل. أنا أيضًا لست متأكدًا من سبب إغلاق هذه المشكلة. لم يكن المقصود منه أن يكون موضوع مناقشة ، بل طلب ميزة.

المشكلة الجذرية المطروحة:

• هل يجب أن يكون للأداة التي تعمل عبر الأنظمة الأساسية سلوك غير مشترك بين الأنظمة بشكل افتراضي؟
• إذا كان الأمر كذلك ، فهل يجب أن تكون هناك طريقة لتشغيل PowerShell عالميًا في وضع "عبر الأنظمة الأساسية"؟

أعتقد أن إجبار المطورين على تطبيع السلاسل يدويًا باستخدام أوامر cmdlets هو خطوة خاطئة بالتأكيد. لا أرى أي سيناريوهات حيث يؤدي استخدام / افتراضيًا إلى حدوث مشكلات على Windows لأن PowerShell ، كما ذكرنا سابقًا ، جيد جدًا في التعامل مع كلا النوعين من الشرطات المائلة. ما لم يتمكن أي شخص من تقديم مواقف مقنعة حيث قد يتسبب ذلك في حدوث خطأ ، فلماذا لا تستخدم فقط / افتراضيًا؟ ربما تحتاج هذه المشكلة إلى الانتقال إلى RFC.

مع انتقال المزيد من الأشخاص إلى السحابة ، يقوم المزيد والمزيد من الأشخاص بتطوير كود PowerShell على Windows وتشغيله على Linux. ستكون هناك بالتأكيد نقطة في المستقبل (إذا لم يتم تجاوزها بالفعل) حيث يتجاوز عدد المستخدمين الذين يفضلون السلوك الحقيقي عبر الأنظمة الأساسية أي شخص يشعر بقوة بضرورة الاحتفاظ بـ \ على Windows.

chriskuech : سيئتي ، لم أطرح السؤال عليك على وجه التحديد. كنت أتساءل عما إذا كنت تشعر أن cmdlet Conpare-Path سيساعدك. بغض النظر عن هذا السؤال ، أود أن أرى خيارات التطبيع أيضًا.

KirkMunro لست متأكدًا من أن Compare-Path سيساعد ، لأنه في حالة الاستخدام الأصلية (مقارنة المسارات على Linux و Windows) ، يختلف نظام الملفات الجذر ، لذلك يجب أن أتصل بـ Resolve-Path -Relative . في هذه المرحلة ، تكون حالة استخدام المقارنة مجرد سطر واحد: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

ومع ذلك ، أنا متردد للغاية في تأييد أي حل قائم على cmdlet ، لأنه لا يحل مشكلة الجذر وسيحظر إما استيفاء السلسلة للمسارات أو يتطلب تغييرات في التعليمات البرمجية لكل تعريف لسلسلة المسار. على وجه التحديد ، لن يصلح Compare-Path كل مساراتي المسجلة بشرطة مائلة مختلطة.

KirkMunro @ mklement0 المشكلة ليست مقفلة ويمكن للجميع سحب التعليقات.
لدينا الكثير من القضايا دون تعليقات جديدة والتقدم. الوضع المفتوح فقد معناه.
بصفتي مشرفًا ، أعتزم أن أكون أكثر دقة من أجل تشجيع المناقشات على أن تصبح مواصفات أكثر صرامة يمكن أن تتحول بسهولة إلى علاقات عامة.
أما بالنسبة للمسألة ، فقد تحولت إلى لانهائية - الطلب الأولي كان "استخدام الشرطة المائلة للأمام على Windows" ، ثم "مقارنة المسارات". ما التالي؟ عن بعد؟ إنه مفتوح للمتابعة ولكن سيتم إغلاقه.
بينما كان هناك اقتراح حقيقي واحد فقط من Jason أعلاه (لتعزيز الإكمال) ويمكننا فتح مشكلة تتبع وإغلاقها من خلال علاقات عامة حقيقية.

لتوضيح الأمر ، لا تزال المشكلة "استخدام الشرطة المائلة للأمام على Windows". تم طرح "مقارنة المسارات" فقط كواحد (من عدة أمثلة) محفزة.

عرض
نفِّذ سلوكًا حقيقيًا عبر الأنظمة الأساسية ، حيث يتم تعيين محدد المسار افتراضيًا على / على جميع الأنظمة الأساسية ما لم يكمل المستخدم علامة تبويب مسارًا يحتوي بالفعل على \ . أتوقع إخفاء هذا كميزة تجريبية في الوقت الحالي ، لكن يجب أن أكون قادرًا على الأقل على تمكين ميزة "تعظيم السلوك عبر الأنظمة الأساسية" في الكود الخاص بي لتحسين تجربة مطوري Windows التي تستهدف Linux.

إذا كان هذا غير معقول ، أود أن أعرف لماذا وما إذا كانت هناك وثائق توجيهية عندما يتباعد تصميم PowerShell عبر الأنظمة الأساسية.

iSazonov : لا ينبغي أن يتجاهل القائمون على صيانة PS repo مشكلات المستخدمين دون مناقشة. لقد قمت بالرد في الأصل دون أخذ الوقت الكافي لفهم احتياجات OP ، مع وضع علامة على المشكلة على أنها تمت الإجابة عليها ، ولكن لم يتم نشر المشكلة كسؤال ، وتم نشرها كطلب ميزة ، وكما يمكن رؤيته من خلال المناقشة ، فمن الواضح بلا جواب".

الوضع المفتوح فقد معناه.

من يقول ذلك؟ هذا ليس صحيحًا على الإطلاق. تم فتح قضية مفتوحة وإغلاق قضية مغلقة. هذان التمييزان لهما معنى واضح للغاية. أنا أنظر فقط إلى القضايا المغلقة إذا كانت خاصة بي وأريد أن أعود للتحقق من شيء ما. في مناسبة نادرة ، قد أذهب للبحث في القضايا المغلقة للمناقشات حول موضوع معين. لكن 90٪ أو أكثر من وقتي في القضايا يكون في القضايا المفتوحة ، كما ينبغي أن يكون. الشيء الوحيد الذي يطمس الخط الفاصل بين الاثنين ويجعل المشكلات المفتوحة تفقد معناها هو إغلاقها بإيجاز قبل حلها ، كما فعلت مع هذه المشكلة.

(المناقشة) مفتوحة للمتابعة ولكنها ستغلق.

استنادًا إلى هذا النهج لإدارة المشكلات ، فأنت تجبر الأشخاص على فقدان التمييز بين الفتح والمغلق ، بحيث يتعين عليهم البحث في جميع المشكلات بدلاً من التركيز على المشكلات المفتوحة ، مما يعني التحقق من المشكلات المفتوحة 2K بالإضافة إلى مشكلات 4K المغلقة للمناقشات ذات الصلة بهم بدلاً من مجرد التركيز على القضايا المفتوحة. هذه إستراتيجية إدارة مشكلة معيبة ومعطوبة.

أما بالنسبة للمسألة ، فقد تحولت إلى لانهائية - الطلب الأولي كان "استخدام الشرطة المائلة للأمام على Windows" ، ثم "مقارنة المسارات". ما التالي؟ عن بعد؟

هذا سخيف. تركز المناقشة على التعامل مع Windows الذي يحتوي على شرطة مائلة للخلف كخيار افتراضي عندما تكتب نصوصًا عبر الأنظمة الأساسية. لقد ظل يركز على هذا الموضوع. أنت تحاول جعل الأمر يبدو وكأنه لا يركز على الإطلاق.

iSazonov ، أوافق على وجود عدد كبير جدًا من المشكلات المفتوحة ؛ ومع ذلك ، فإن حقيقة وجود عدد كبير جدًا من المشكلات المفتوحة لا تعني أنه يجب علينا رفض وإغلاق المحادثة قبل الأوان بشأن القضايا الجديدة. يجب أن نستمر في تشجيع التعليقات وأن نكون منفتحين للمناقشة حول PowerShell في المشكلات المفتوحة ، ونغلقها فقط بمجرد حلها حقًا. يجب التعامل مع حجم القضايا المفتوحة بشكل مختلف.

مستخدمي لينكس المخلصين نصيحة غير مفهومة.
يمكنك إقناع مايكروسوفت. اطلب منهم استخدام الخطوط المائلة العكسية كمسارات ملفات النظام.

أود أن أشير هنا إلى أن هناك حالات استخدام تتطلب مسارات حرفية ذات خطوط مائلة للأمام ، حتى على Windows.

كنت أكتب للتو نصًا حيث كنت أستخدم واجهات برمجة تطبيقات .net لمعالجة وإنشاء أرشيفات مضغوطة. إضافة إدخالات إلى ملف zip باستخدام واجهة برمجة التطبيقات هذه:

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

في هذه الحالة بالذات ، يعد $ entry مسارًا داخل أرشيف مضغوط. إذا قمت ببساطة بتمرير مسار windows كما تم إرجاعه بواسطة أوامر cmdlets المختلفة للمسار ، فإن كل أداة مضغوطة على الكوكب ستصدر تحذيرات حول احتواء ملف zip على مائل خاطئة.

أيضًا بصفتي مستخدمًا ومطورًا لنظام Linux لفترة طويلة ، أحب بوويرشيل وقد استمتعت كثيرًا بتعلمه. لقد كنت أستمتع باللعب مع خادم windows الجديد الخاص بي عبر ssh إلى بوويرشيل 7 أيضًا ، وقد قمت بنشر نصوص تعمل بشكل مثالي مع بوويرشيل على لينكس. لقد فوجئت بمدى نجاح ذلك. في الواقع ، سيكون بوويرشيل خياري الأول لبعض البرامج / البرامج النصية التي أريد أن تكون مشتركة بين الأنظمة الأساسية.

ولكن ما زلت أشعر بالحزن عندما أرى جميع عمليات استكمال علامات التبويب الخاصة بي تُعاد كتابتها بشُرط مائلة للخلف.

أستخدم مسارات مثل / users / foo / somefile على النوافذ طوال الوقت وهذا ما أريد استخدامه.

تدعم معظم واجهات برمجة تطبيقات Windows الخطوط المائلة للأمام بشكل جيد. أدرك أن هناك بعض الاستثناءات ، مع الأدوات المساعدة وربما واجهات برمجة التطبيقات ، أي بعض استدعاءات cmd.exe ، لكنني أريد فقط تعيين شيء ما في ملف التعريف الخاص بي بحيث يكون لجميع مساراتي بشكل افتراضي خطوط مائلة للأمام ، ما لم أستخدم الخطوط المائلة العكسية بشكل صريح.

سيكون هذا غير مؤذٍ لمستخدمي Windows والمطورين الذين اعتادوا استخدام الخطوط المائلة العكسية لأنهم ببساطة لن يستخدموا هذا الإعداد ، وسيكون افتراضيًا إيقاف التشغيل. بالطبع ، قد يقررون استخدامه أيضًا إذا قرروا ، على سبيل المثال ، كتابة المزيد من البرامج النصية والوحدات النمطية عبر الأنظمة الأساسية.

أريد هذا الإعداد للنصوص والوحدات النمطية أيضًا ، حتى لا أواجه مشكلات غير متوقعة مثل تلك التي عرضتها أعلاه.

يمكن لمستخدمي iSazonov استخدام خطوط مائلة مريحة بغض النظر عن النظام الأساسي.

هل هذا يعني أنه يمكنني تكوين PowerShell لاستخدام الخطوط المائلة للأمام لأن ذلك أكثر راحة بالنسبة لي كمستخدم؟ أرغب في تغيير المسار المعروض في الموجه بالإضافة إلى الإكمال التلقائي لعلامة التبويب الذي يغير حاليًا الشرطات المائلة للأمام إلى خطوط مائلة عكسية.

aaronfranke ، لا ، لا توجد حاليًا طريقة لتكوين PowerShell بهذه الطريقة ؛ أعتقد أن ما كان يحاول iSazonov قوله هو أنه عندما تكتب مسارًا يدويًا ، فأنت حر في الاختيار بين \ و / (ويمكنك حتى مزجهم في مسار واحد) .

بالنظر إلى تعدد الاستخدامات ، يجب تمكين رمز مسار جديد بدلاً من / و تزيد الرموز التقليدية من صعوبة التحويل عبر الأنظمة الأساسية

أعتقد أن ما كان يحاول iSazonov قوله هو أنه عندما تكتب مسارًا يدويًا ، فأنت حر في الاختيار بين و / (ويمكنك حتى مزجها في مسار واحد).

نعم ، إنه تصميم PowerShell.

هذا ليس حلاً للمشكلات التي أثيرت هنا ، مثل الاستبدال القسري لفواصل المسار أثناء الإكمال ، أو القدرة على تكوين أوامر cmdlets الخاصة بالمسار لاستخدام فاصل المسار الذي تختاره ، في حالة فتح مشكلات منفصلة ومحددة لهم ؟

rkitover لقد سألت عن مثل هذه السيناريوهات منذ سنوات (يمكنك العثور على المشكلة) دون أي حل. هذا يقنعني أن هذا تغيير تجميلي ، رغم أنه يتطلب الكثير من الجهد. إذا كنت مستعدًا للاستثمار في هذا المجال وسحب العلاقات العامة ، فمن المنطقي فقط فتح مناقشة جديدة.

CP / M والنسخ تستخدم / للخيارات ، أمثلة: DIR/P ، CMD/CECHO . هذه أوامر صالحة. إذا استبدلنا \ بـ / في كل مكان ، أخشى أن سوء الفهم يمكن أن يحدث.

1. لا أحد يستخدم CP / M بعد الآن.

2. استخدام / لكل من الخيارات والمسارات في نفس الوقت يعمل بشكل جيد على Windows في الاختبار الخاص بي.

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

على Windows ولن تتمكن من فتح TestScript8.ps1 في VS Code على Windows.

@ markm77 ، لقد اكتشفت _bug_ - هل يمكنك إنشاء إصدار جديد له من فضلك ؟ [_update_: انظر # 13064]

لا يعني ذلك أنه حجة ضد آلية التقيد بالتخلف عن / ، aaronfranke ، لكن لاحظ أن هناك حالات قليلة حيث لا يزال هناك فواصل / بدلاً من \ أشياء على Windows ؛ على سبيل المثال:

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

إن الاقتباس المزدوج للمسار يساعد فقط في مسارات _directory_ ، بشكل غريب - راجع https://stackoverflow.com/a/43297482/45375 ، والذي يوضح أيضًا أن مكتبة Excel COM Automation لا تدعم / .

مكدس الفائض

لماذا لا يريد PowerShell حفظ ملفي كملف CSV

$ Path = 'D: /ETL_Data/TwitchTVData.xlsx' $ csvPath = 'D: /ETL_Data/TwitchTVData2.csv' # افتح مستند Excel واسحب في ورقة العمل 'Sheet1' $ Excel = New-Object -Com Excel.Application المصنف ...

@ markm77 ، لقد اكتشفت خطأ - هل يمكنك إنشاء عدد جديد له من فضلك؟

ولكن هل هذا خطأ في PowerShell؟ يقوم PowerShell بإنشاء ارتباط sym الصحيح بشرطة مائلة محددة كما تم التحقق من خلال فحص رابط sym باستخدام dir . يبدو أن رابط sym الذي تم إنشاؤه بنوع مائل خاطئ يمكن أن يكون غير قابل للاستخدام في تطبيقات مثل VS Code. وهو أيضا ربما يكون مفهوما.

ملحوظة: من السهل جدًا حل هذه المشكلة عن طريق تشغيل convert-item على أهداف sym-link التي لها فائدة إضافية تتمثل في ضمان أن روابط sym تشير إلى مسارات مطلقة (ربما تكون مناسبة).

ملحوظة: من السهل جدًا حل هذه المشكلة عن طريق تشغيل convert-item على أهداف sym-link التي لها فائدة إضافية تتمثل في ضمان أن روابط sym تشير إلى مسارات مطلقة (ربما تكون مناسبة).

غير مناسب ، سوف ينكسر عند إعادة العد 😞

غير مناسب ، سوف ينكسر عند إعادة العد 😞

تعليق عادل ، لا أقوم بإعادة التحميل (هذا لعمل مطور محلي) ولدي برنامج نصي لإعادة إنشاء الروابط يمكنني تشغيله في أي وقت. من الواضح أن join-path هو الحل الآخر أو الأفضل أن يكون خيار new-item للتأكد من أن الروابط مناسبة للنظام الأساسي.

انظر # 12797

ولكن هل هذا خطأ في PowerShell؟

على الرغم من أنك قد تجادل بأنه في _Windows_ فهو خطأ في WinAPI ، نظرًا لأن \ و / يتم دعمهما عادةً بالتبادل ، فمن المؤكد أنه خطأ في الأنظمة الأساسية الشبيهة بـ Unix إذا قمت بالعكس وتمرير مسار يستند إلى \ كمسار -Target - على مثل هذه الأنظمة الأساسية ، يتم دعم / فقط (فقط PowerShell هو الذي يسمح لك باستخدام \ مثل بديل ، يأتي مع مشاكله الخاصة - راجع # 9244) ، وتقع على عاتق PowerShell مسؤولية ترجمة شيء مثل .\TestScript.ps1 إلى ./TestScript.ps1 عند إنشاء الارتباط الرمزي.

إصلاح هذا - عن طريق جعل PowerShell يقوم بتطبيع المسار لاستخدام فاصل _platform-native_ (الأساسي) - سيؤدي أيضًا إلى حل المشكلة على Windows.

iSazonov ، # 12797 ممكّن بشكل أساسي من دعم المسارات _ النسبية كأهداف للرابط الرمزي ، لكن المشكلة المطروحة هي الافتقار إلى تسوية فاصل النظام الأساسي الأصلي ، مما يجعل الارتباطات الرمزية الناتجة معطلة.

iSazonov @ يرجى الاطلاع على # 13064 لمعرفة ما لا يزال مكسورًا اعتبارًا من PowerShell Core 7.1.0-preview.4 (والذي يجب أن يتضمن # 12797 ، أليس كذلك)؟

شكرًا @ mklement0 على ما يبدو أنه تحقيق شامل لسلوك الارتباط الرمزي النسبي وإثارة المشكلة https://github.com/PowerShell/PowerShell/issues/13064. لقد قمت بتدوين ملاحظة لمتابعة المشكلة المحددة التي لدي وهذه المناقشة ولكن في الحقيقة يبدو أنك غطيت كل شيء في https://github.com/PowerShell/PowerShell/issues/13064 وفي الواقع علمتني كيف لكتابة اختبارات PowerShell (أنا جديد في PowerShell) .... ابتهاج!

لم أتابع هذا الموضوع بكل التفاصيل ، لذا أعذرني إذا فاتني شيء. كانت المشكلة الأولية عبارة عن فاصل مسار قياسي عبر النظام الأساسي (يحتمل أن تكون خطوط مائلة للأمام). iSazonov الآن إغلاق هذه القضية. هل يمكنك من فضلك إعطاء نظرة عامة عن سبب اعتقادك أن هذا لم يعد صالحًا حتى يتمكن الأشخاص الذين اشتركوا في أحداث إغلاق المشكلة من المتابعة؟

لم يكن صالحًا أبدًا ، وفقًا لـ https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471.

شيء مثل ما اقترحه lzybkr أعلاه لا يزال شيئًا معقولًا تمامًا - ويفترض أنه سهل - للتنفيذ ؛ إلى خلاصة:

أعتقد أنه سيكون من الجيد أن يستخدم إكمال المسار فاصل المسار الذي يظهر بوضوح في نص الإكمال ، وإذا لم يكن هناك أي شيء ، فسيتم استخدام فاصل النظام الأساسي بشكل افتراضي.

عندئذٍ ، تقع على عاتق المستخدم مسؤولية تجنب حالات الحافة - النادرة - حيث لا يزال يتعطل / على Windows (انظر أعلاه ).

هذا يسبب صداع حقيقي عند تشغيل البرامج النصية wsl bash عبر بوويرشيل. مثل:

bash .\updateTemplate.sh

يجب إكمال هذا تلقائيًا إلى

bash ./updateTemplate.sh

هل هناك أي حل آخر لهذه المشكلة؟ على وجه التحديد ، سأكون على ما يرام تمامًا إذا أكمل PS المسار تلقائيًا بشرطة مائلة للأمام في سياق bash / WSL فقط.

هل هناك أي حل آخر لهذه المشكلة؟

إنشاء مكمل مخصص لباش.

هل هناك أي حل آخر لهذه المشكلة؟

إنشاء مكمل مخصص لباش.

كيف تفعل هذا؟

ألا ندخل في مزيد من النقاش حول الإغلاق الذي لا أساس له من الصحة لهذه القضية؟ هذا مصدر إزعاج كبير للعمل عبر الأنظمة الأساسية. في كل مرة أقوم فيها بإكمال المسارات تلقائيًا التي يتم تغذيتها بأدوات عبر الأنظمة الأساسية أو بشكل غير مباشر من خلال wsl إلى أدوات Linux ، يتعين علي تحريك المؤشر للخلف عبر المسار بالكامل واستبدال كل شرطة مائلة للخلف بشكل فردي بشرطة مائلة. لا ينبغي لأحد أن يعمل بهذه الطريقة على الإطلاق ، وهو ما يجعل حقًا Powershell كسطر أوامر لا يمكن الدفاع عنه تقريبًا.