ماذا عن شيء مثل: (New-TemporaryFile) .DirectoryName

@ lukeb1961 : ينتج عن ذلك بالفعل الدليل المؤقت الخاص بالمنصة ، ولكن له تأثير جانبي غير مرغوب فيه: New-TemporaryFile دائمًا _ يُنشئ_ الملف الذي ينتج عنه تمثيله [System.IO.FileInfo] .

بمعنى آخر: في كل مرة تقوم فيها بتنفيذ (New-TemporaryFile).DirectoryName ، فإنك تترك وراءك ملفًا مؤقتًا غير مستخدم.

بالإضافة إلى ذلك ، إنه نهج مكلف من الناحية الحسابية.

لقد ناقشنا هذا باختصار. شكرا لك على فتح العدد.

داخليا لدينا بالفعل "TemporaryDirectory" ، فقط "GetTporaryDirectory ()" و "CreateTporaryDirectory ()". يمكننا جعلها عامة.

ماذا عن استخدام $ Env: TMP على جميع المنصات؟ هذا ليس تمامًا مثل Windows أو Mac أو Linux. لا حرب على العشب.

Liturgist : $Env:TMP ليس خيارًا ، لأنه من غير المستحسن إما (أ) امتلاك متغيرات PowerShell تلقائيًا _define__environment أو (ب) التظاهر بأن متغيرات البيئة غير موجودة.

المتغير التلقائي _PowerShell_ مثل $TMP هو خيار ، على الرغم من أن الشيء الذي يجب أخذه في الاعتبار هو أن إدخال المتغيرات التلقائية بأثر رجعي هو تقنيًا تغيير جذري.

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

في https://github.com/PowerShell/PowerShell/issues/3571 اقترحت متغيرات أخرى بالإضافة إلى TEMP

@ SteveL-MSFT:

نقطة جيدة؛ مساحة الاسم $interop: هي بالفعل طريقة لتجنب الاصطدامات.

إذا اتخذنا خطوة إلى الوراء: إذا أردنا أن يصبح PowerShell اللغة المشتركة لعالم الصدفة ، فهل نريد حقًا تأطير الأشياء على أنها "interop"؟

ماذا عن الوثوق بمتغيرات PowerShell التلقائية للقيام بالشيء الصحيح (TM) _ Generically_ ، والتي قد تتطلب مساحة اسم مثل $ps: ؟

@ mklement0 تم اقتراح البادئة / مساحة الاسم $ps: من قبل. سيكون من الرائع لو استخدمنا ذلك من البداية :)

أنا شخصياً أفضل $ps: لمنطقك بالضبط. ربما تكون هذه نقطة مناقشة في مكالمة المجتمع التالية.

cc @ بوويرشيل / بوويرشيل-جنة

أنا سعيد لسماع ذلك ، @ SteveL-MSFT.

في ملاحظة ذات صلة ، أعتقد أن مساحة اسم منفصلة لجميع المتغيرات _preference_ ستكون مفيدة أيضًا ، مثل $pspref:

التحذير هو أنه على الرغم من أن احتمالية حدوث الاصطدامات أقل بكثير من احتمال حدوث تصادمات مع أسماء المتغيرات غير المؤهلة ، إلا أن أحدهم _ يمكنه فعل شيء كالتالي:

# Define custom drive 'ps:'
New-PSDrive 'ps' FileSystem '/tmp'; Get-ChildItem ps:

لماذا لا يمكننا استخدام [system.io.path]::GetTempPath() ؟

https://github.com/dotnet/coreclr/blob/6ba74dc2a7194f8d6c86c3aeab572a074ef645c8/src/mscorlib/shared/System/IO/Path.Unix.cs#L153
https://github.com/dotnet/coreclr/blob/6ba74dc2a7194f8d6c86c3aeab572a074ef645c8/src/mscorlib/shared/System/IO/Path.Windows.cs#L94

@ iSazonov :

يعمل هذا ، لكن من الصعب تذكره ومن الصعب كتابته.
من الجيد أن تعرف كحل بديل ، رغم ذلك.

إذا كان لدينا New-TemporaryFile يتوقع المستخدمون Get-TemporaryPath من Get-TemporaryDirectory .

@ iSazonov :

نظرًا لأن المصطلح _path_ غامض (على الرغم من استخدامه في .NET API للإشارة إلى مسار _directory_ في هذه الحالة) ، فإن تفضيلي سيكون Get-TemporaryDirectory ، وبالتأكيد لن أمانع في الحصول على مثل هذا الأمر cmdlet .

ومع ذلك ، فإن الأمر cmdlet صعب بعض الشيء بالنسبة لشيء يعرض جزءًا واحدًا من المعلومات دون أي اختلافات في الوظائف.

ضع في اعتبارك الثنائي الحالي Get-Host / $Host : هل وجدت نفسك يومًا تستخدم Get-Host بدلاً من $Host ؟

$ps:Temp المفترض أن يُرجع Get-TemporaryDirectory المفترض أن يقوم $ps:temp . أنا شخصياً أعتقد أن امتلاك محرك PS temp: قد يكون أكثر فائدة. ربما يتم تنظيفها تلقائيًا عند الخروج من العملية.

temp: - فكرة جيدة. إذا قبلناها ، فيجب أن يكون لدينا أوامر cmdlets لها. وأعتقد أنه يمكننا تحسين * -PSDrive cmdlets.

temp: - مهيأ إلى [io.path]::GetTempPath() .

سنجني temp: اختياريًا لكل مساحة تشغيل.

أفضل طريقة متسقة لرسم خرائط متغيرات البيئة التي يتم التعبير عنها بشكل مختلف تمامًا. هل نقول أننا سنقوم بتعيين جميع متغيرات المسار إلى محركات الأقراص ، مثل Home: \؟

@ mklement0 - لست متأكدًا تمامًا من سبب Env:TMP فكرة سيئة. فيما يتعلق أ) يقوم PowerShell بإنشاء Env:PSModulePath . فيما يتعلق ب) لا أعرف أي متغيرات بوويرشيل سوف تتظاهر. أود أن أفهم.

Liturgist أعتقد أن الفكرة هي أن أي شيء في مساحة الاسم $Env: يجب أن يكون فقط متغيرات بيئة فعلية على هذا النظام الأساسي. سيكون أيضًا محيرًا جدًا أن يتم تعريف $Env:TEMP و $Env:TMP في نفس الوقت. كيف يمكنني معرفة أيهما يجب استخدامه للتشغيل على Linux و OSX و Windows بمجرد النظر إليه؟

تعمل المقترحات الخاصة بمساحة اسم منفصلة أو محرك أقراص على التخلص من هذه المشكلة لأنها تسمح لـ PowerShell بأن يكون لها متغيرات محددة بشكل عام يمكن استخدامها عبر الأنظمة الأساسية ولا تمنع الوصول إلى متغيرات البيئة الحقيقية.

فكرة أخرى على الرغم من مساحة الاسم يمكن أن تكون $PSEnv: . لها معنى ضمنيًا أن أي شيء في مساحة الاسم هذه يأتي من PowerShell وليس من النظام. بعد ذلك ، يمكنك تعيين جميع متغيرات البيئة الشائعة بشكل واضح وتسهيل رؤية ما هو متاح للاستخدام من IntelliSense.

@ dragonwolf83 - هل سيتم نقل Env:PSModulePath إلى PSEnv:PSModulePath ؟ أوافق تمامًا على عدم وجود متغيرات متعددة مثل Env:TEMP و Env:TMP . يجب أن يكون هناك واحد جيد ودعنا نذهب مع ذلك. الحصول على PSEnv:TEMP أو PSEnv:TMP سيكون أمرًا جيدًا.

للذهاب مع New-TemporaryFile سيكون من المفيد أن يكون لديك New-TemporaryDirectory . لإجراء ذلك ، سيكون من المفيد الحصول على معلمة -Path على New-TemporaryFile لتحديد الدليل الذي سيتم إنشاء الملف المؤقت فيه.

لا ، لا أعتقد أن فريق PowerShell سينتقل $Env:PSModulePath لثلاثة أسباب.

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

بمعنى آخر ، إنه موجود بالضبط حيث ينتمي.

ألق نظرة على لقطة الشاشة أدناه. يعرض متغيرات البيئة المحددة في نظام Windows الخاص بي. يحتوي على TEMP و TMP كمتغيرات بيئة لمسار المستخدم المؤقت. كما أن لديها PSModulePath. لذلك كل هذه المتغيرات الأخرى ، أتوقع أن أرى مساحة الاسم $Env: . يمكنك الذهاب إلى cmd وترى أن كل هذه المتغيرات ، بما في ذلك PSModulePath موجودة هناك أيضًا.

@ ليتورجست :

للإضافة إلى تعليقات @ dragonwolf83 المفيدة وللرد على تعليقك الموجه إلي:

لا أعرف المتغيرات التي سيتخيلها PowerShell. أود أن أفهم.

كانت وجهة نظري التي ربما تكون واضحة بشكل صارخ - لست بحاجة إلى قول ذلك - أنه في حالة عدم وجود PowerShell في الواقع _ تعريف_ متغير البيئة هذا (والذي ، كما هو مذكور ، سيكون غير حكيم - انظر أيضًا أدناه) ، يجب على PowerShell تفسير أنه موجود.

يحترم PowerShell / يحدد متغيرين من متغيرات البيئة فقط ، وفقًا لـ Get-Help about_Environment_Variables :

• $env:PSExecutionPolicyPreference ، عند التعيين _ خارجيًا_ ، _before_ استدعاء powershell ، يمكن استخدامه لتعيين سياسة التنفيذ للجلسة (حاليًا: Windows PowerShell فقط).

  • إذا لم يتم تعيينه خارجيًا ، فلن يتم تعريف هذا المتغير في جلسة PowerShell ، ويتم تطبيق القيمة الافتراضية / المكونة باستمرار.

• $env:PSModulePath ، عند التعيين _ خارجيًا_ ، _before_ استدعاء powershell ، يمكن استخدامه لتعريف الدلائل لمسار بحث وحدة PowerShell (قائمة الدلائل التي يبحث فيها PowerShell عن الوحدات التي تم تحميلها بواسطة _name_ فقط).

  • إذا لم يتم تعيينه خارجيًا ، يقوم PowerShell بتعريفه بقائمة من الدلائل القياسية (المستخدم الحالي ، جميع المستخدمين ، ولكن النظام _ لا).

    • على نظام W10 / PSv5.1 الخاص بي ، هذا المحيط. متغير _is_ محدد مسبقًا ، كبيئة _system-level_. متغير ، مع دليل الوحدات النمطية _system_ ، $PSHOME/Modules ، مع تحديد الدلائل القياسية المتبقية عند بدء تشغيل PowerShell ، _prepended_ إلى وحدات النظام النمطية dir.

    • يبدو أن تحديد دليل غير قياسي في متغير على مستوى النظام يؤدي إلى إدخاله بعد قيمة المستخدم الحالية.

    • لا تحتوي عمليات تثبيت PowerShell Core على منصات Unix على متغير محدد مسبقًا.

  • إذا تم تعيينه خارجيًا على مستوى _process_ (مع set PSModulePath=... & powershell ... من cmd.exe أو PSModulePath=... powershell ... من قذائف تشبه POSIX):

    • يستخدم Windows PowerShell v5.1 _just_ القيمة الخارجية _as-is_.
    • PowerShell Core _injects_ القيمة الخارجية في قائمة الدلائل القياسية ، بعد القيمة الحالية للمستخدم.

هذه المتغيرات هي متغيرات بيئية لسبب وجيه: فهي تسمح لك بالتحكم في سلوك بدء تشغيل PowerShell _ خارجيًا_.

على النقيض من ذلك ، لا يوجد سبب وجيه لتعريف الدليل للملفات والدلائل المؤقتة كمتغير بيئة:

• القيمة ثابتة ويمكن اشتقاقها (النظام الأساسي على وجه التحديد) من البيئة _ الموجودة _ ، _ القياسية _ ( $env:TMP على Windows ، $env:TMPDIR على macOS) / اصطلاحات النظام الأساسي ( /tmp على Linux ).

  • لا يوجد سبب وجيه لفضح هذه القيمة إلى _عمليات الأطفال _ عبر _ البيئة _ ، لأنه (أ) إذا لم تكن هذه العمليات الفرعية عمليات PowerShell ، فلن يعرفوا متغيرات البيئة التي يحددها PowerShell و (ب) يمكن لأي جلسة PowerShell اشتقاق القيمة بشكل مستقل.

  • على العكس من ذلك ، فإن أي متغير بيئة يحدده PowerShell يحمل مخاطر تضارب الاسم مع متغير يحمل نفس الاسم تستخدمه البيئات الأخرى بشكل مختلف. بينما يمكن التخفيف من هذه المشكلة باستخدام بادئة الاسم _ by-Convention_ - مثل PS - فإن أفضل طريقة هي تجنب تحديد متغيرات البيئة تمامًا ، إذا لم تكن هناك حاجة إليها.

^{إذا كان القارئ مألوفًا بشكل أساسي مع cmd.exe ، فمن الجدير الإشارة إلى أن cmd.exe -بخلاف PowerShell و POSIX-like shells on Unix - يعرف _ فقط_ متغيرات البيئة: أي متغير تحدده في cmd.exe هو _بشكل ضمني أيضًا_ متغير بيئة ، بينما تميز الأصداف الشبيهة بـ PowerShell و POSIX بين متغيرات _shell_ الخاصة بالجلسة فقط ( على سبيل المثال ، $foo في PowerShell) ومتغيرات البيئة _ المعينة صراحة على هذا النحو (على سبيل المثال ، $env:foo في PowerShell).}

تعجبني بالتأكيد فكرة مساحات الأسماء _multiple_ لمتغيرات PowerShell التلقائية (مثل $PSPref: لمتغيرات التفضيل) ، لذا فإن وضع الدليل للملفات المؤقتة في $PSEnv: فكرة جيدة ، على الرغم من أننا ' d يجب أن يوضح أنه - على الرغم من وجود كلمة "Env" - فهذه ليست متغيرات _بيئة_ فعلية بالمعنى الراسخ للنظام (يمكن الوصول إليها لجميع العمليات الفرعية ، بغض النظر عما يتم تشغيله القابل للتنفيذ).

يبدو أنه كان هناك ما يكفي من المناقشة الجيدة التي ربما ينبغي أن تكون RFC؟

أنا بالتأكيد أحب فكرة مساحات الأسماء المتعددة لمتغيرات PowerShell التلقائية

في [io.path] :: GetTempPath () ، يعد [io.path] مساحة اسم - هل يجب أن نقدم مساحات أسماء Powershell "أصلية" مثل $PSEnv: ؟

@ SteveL-MSFT:

قبل أن نتعامل مع RFC ، اسمحوا لي أن أحاول تلخيص ما أعتبره حالات استخدام وربما أحصل على فهم أفضل لنطاق مثل هذا RFC:

• [x] أنشئ ملف _ مؤقتًا (في الموقع المناسب للنظام الأساسي ، باسم فريد يتم إنشاؤه عشوائيًا):

  • New-TemporaryFile يوفر ذلك بالفعل.

  • [] إنشاء _ملف _ مؤقت بامتداد اسم ملف محدد _ راجع # 4215

• [] أنشئ _directory_ مؤقتًا (في الموقع المناسب للنظام الأساسي ، باسم فريد تم إنشاؤه عشوائيًا):

  • طلب # 3442 هذه الإمكانية ، واقترح إضافة مفتاح -Directory إلى New-TemporaryFile

• [] _Determine_ _path_ الخاص بدليل النظام الأساسي (الجذر) المناسب للملفات والأدلة المؤقتة.

  • الموضوع الأساسي لهذه المشكلة ، مع إدخال مساحة (مساحات) أسماء جديدة يتم التحكم فيها بواسطة PowerShell.

• [] امتلاك القدرة على إنشاء ملف مؤقت وملف يحذف ذاتيًا ضمن نطاق الأوامر ، وذلك لتقديم إخراج أحد الأوامر كملف عند استدعاء الأدوات المساعدة الخارجية (على غرار استبدال عملية Bash) - راجع # 4284

• [] من المحتمل تقديم محرك أقراص temp: معرّف ضمنيًا.

  • أعتقد أن هذا سيكون مفيدًا فقط إذا كان محرك الأقراص هذا _script / function-scoped_ بدلاً من نطاق الجلسة ؛ على سبيل المثال ، إذا كان بإمكان البرنامج النصي / الوظيفة الكتابة على محرك الأقراص هذا دون خوف من تضارب الأسماء ، على غرار التنظيف التلقائي لمحرك الأقراص TestDrive: الذي يوفره Pester.

  • ومع ذلك ، أخشى أن يكون القيام بذلك مكلفًا للغاية وأن النطاق ليس واضحًا كما هو الحال في حالة بيستر.

بالنسبة لإدخال مساحات الأسماء التي يتحكم فيها PowerShell :

لاحظ أن تدوين مساحة الاسم الحالي - على سبيل المثال ، $env:PATH يعتمد فعليًا على _امتلاك محرك PS أساسي_: تشير جميع البادئات المدعومة حاليًا $<prefix>: إلى _ محركات بنفس الاسم_؛ على سبيل المثال ، $env:HOME هو نفسه (Get-Item Env:/Home).Value .

إذا قدمنا ​​الآن مساحات أسماء مثل $PSEnv: بدون محرك أساسي - ويمكن القول إن محرك الأقراص الأساسي سيكون مبالغة - فسوف نبتعد عن هذا النموذج.
أنا شخصياً لا أعتقد أنها مشكلة ، لكن يجب أن يكون قراراً واعياً وموثقاً.

إذن ما الذي يجب أن يغطيه RFC؟

• مقدمة من مساحات الأسماء التي يتحكم فيها PowerShell؟

  • فقط من أجل متغيرات "البيئة" الخاصة بنطاق PS ، أو ، كما ذكرنا ، ربما لمتغيرات التفضيل أيضًا؟

• محرك أقراص معرف ضمنيًا temp: ؟

يمكنني التعامل مع الأول ، لكنني لست متأكدًا من أنني أستطيع التوصل إلى نهج معقول تجاه الأخير (وقد لا يستحق ذلك).

@ mklement0 شكرا لتلخيص جميع المناقشات المختلفة ذات الصلة. أعتقد أن مجرد تحديد قسم Motivation من RFC للعنصر الأول كافٍ. يمكنك أن تذكر صراحة أن temp: خارج نطاق RFC.

@ mklement0 - ملخص جميل

أفضل استخدام New-TemporaryDirectory على إضافة مفتاح -Directory إلى New-TemporaryFile . New-TemporaryDirectory أكثر وضوحًا وقابلية للاكتشاف. إذا لم يكن كلاهما ممكنًا ، فأنا أصوت لـ New-TemporaryDirectory .

شكرا يا ليتورجست.

أسمع أنك تعيد New-TemporaryDirectory (على الرغم من وجود تقليد Unix الفخور والمربك المتمثل في استدعاء _any_ عنصر نظام الملفات "ملف" ....).

على الطرف الآخر من الطيف ، يمكنك أن تجادل (كما فعل شخص ما بالفعل ، لكني نسيت أين) أنه يجب أن يكون هناك عام واحد فقط New-TemporaryItem cmdlet مع -Type File و -Type Directory المعلمات (من المتصور ، يمكن لكل مزود محرك أقراص تنفيذ مواقعه المؤقتة الخاصة به ، على الرغم من أنه من بين المواقع التي يتم شحنها مع PowerShell ، فإنه من المنطقي فقط لمزود FileSystem ).

في كلتا الحالتين ، أقترح أن تجعل صوتك مسموعًا في # 3442.

@ SteveL-MSFT: شكرًا لك على التوجيه ، ولكن على الرغم من رغبتي الأولية في التعامل مع طلب التعليقات هذا ، أود الانسحاب من هذه المهمة [الذاتية].
آمل أن يتولى شخص آخر ذلك.

بعد بعض المناقشة ، تميل @ PowerShell / powershell-Committee نحو cmdlet بدلاً من مساحة اسم متغيرة جديدة من أجل توفير إمكانية اكتشاف وإكمال علامة تبويب أفضل وما إلى ذلك.

في الوقت الحالي ، تعمل طريقة .NET الثابتة للقيام بذلك ، لكننا نريد في النهاية إنشاء نمط أفضل باستخدام أوامر cmdlets. أعتقد أن هؤلاء سيعيشون في وحدة "توافق" ، يتم شحنها في المعرض ، والتي تعمل في 3/4/5 ، وقد يتم شحنها في النهاية كجزء من 6.x.

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

أيضًا ، هذا هو بالضبط فئة المشكلات التي يُراد معالجتها بواسطة https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0019-PowerShell-Core-Interop-Module.md (كتبها بواسطة darwinJS). سيكون من الرائع أن يتمكن المزيد من الأشخاص من تقديم ملاحظات في PowerShell / PowerShell-RFC # 68

@ mklement0 - شكرا لك على -Temporary إلى New-Item ؟ سأبحث عن # 3442.

joeyaiello : شكرًا على المؤشر إلى RFC والمناقشة المصاحبة.

يميل نحو cmdlet بدلاً من مساحة اسم متغير جديدة

لا أعتقد أن الاثنين متنافيان.

لإعطاء مثال عليه سياق هذه المناقشة المحددة:

من السهل أن يكون لديك أوامر cmdlets تحميك من الاضطرار إلى معرفة موقع النظام الأساسي لـ temp. الملفات (مثل New-TemporaryFile ) _و_ ، في بعض الأحيان ، لتكون لديك القدرة على تحديد هذا الموقع بوضوح (على سبيل المثال ، $ps:TEMP ).
(أيضًا ، على الأقل فيما يتعلق بإكمال علامة التبويب $ps: و $pspref: يجب أن يعمل بشكل جيد.)

@ ليتورجست : تعجبني الفكرة. لطالما شعرت أن New-TemporaryFile كأنه خدعة بالنسبة لي.

ملاحظة: على الرغم من أن القدرة على استدعاء طرق .NET مباشرة دائمًا خيار رائع (خيار يميز PowerShell عن الأصداف الأخرى) ، إلا أنه يجب أن يكون ضروريًا فقط للسيناريوهات غير العادية ، نظرًا للصياغة المختلفة والمعرفة المتقدمة يتطلب وأن يكون هناك تنانين .

PPS (آخر واحد - أقسم الخنصر ،joeyaiello):

لقد قلت سابقًا أن تقديم مساحات أسماء مثل $ps: و $pspref: بدون _drive_ ضمني سيكون خروجًا عن تدوين مساحة الاسم الحالي ، مما يوحي بأن تقديم مثل هذه محركات الأقراص قد يكون صعبًا للغاية.

على الجانب الآخر ، إذا كانت مساحات الأسماء الجديدة هذه مدعومة بمحرك أقراص ، فستعالج مخاوف الاكتشاف ، لأنه يمكنك بعد ذلك تشغيل أوامر مثل Get-ChildItem ps: و Get-ChildItem pspref: لاكتشاف كل هذه المتغيرات.

@ mklement0 - نهج آخر هو مقدمة مشتركة. لقد قمت بذلك لتحديد جميع المتغيرات التي تعد جزءًا من رمز القالب الخاص بي في ملف تفريغ. ثم يمكنك القيام بما يلي:

gci variable:PREPEND* 

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

ربما ينبغي علينا نقل هذه المحادثة إلى RFC الفعلي حتى لا نفقد هذه الأفكار.

أفضل $psvar بدلاً من $pspref .
أيضًا لاكتشاف الأوصاف - Get-Help $psvar:pstableversion .
ضع قائمة بجميع متغيرات النظام Get-Variable -ListPowerShellEngineVariables .

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

السيناريو 1:

1. قم بإنشاء ملف مؤقت.
2. استخدم الملف.
3. ننسى الملف - نتوقع أن يقوم النظام بإزالة الملف. إذا نظرنا إلى٪ temp٪ أو٪ WINDIR٪ temp ، فإننا نرى أطنانًا من الملفات غير المحذوفة.

الاستنتاج 1: الدليل المؤقت الصريح غير مطلوب. يجب أن نضيف تحسينًا لإزالة ملفاتنا المؤقتة.

السيناريو 2:

1. قم بإنشاء دليل مؤقت لنطاق (مثيل كتلة / برنامج نصي / وحدة / فئة).
2. قم بإنشاء ملف مؤقت في دليل temp.
3. استخدم الملف.
4. انسَ الملف والدليل - نتوقع أن يقوم النظام بإزالة الملف والدليل.

الاستنتاج 2: دليل مؤقت صريح غير مطلوب. يجب أن نضيف تحسينًا لإزالة الدلائل المؤقتة الخاصة بنا.

السيناريو 3:

1. قم بإنشاء دليل مؤقت
2. استخراج أرشيف في الدليل المؤقت. هنا يتعين علينا استخدام بادئة temp.
3. معالجة الملفات.
4. انسَ الملفات والدليل - نتوقع أن يقوم النظام بإزالة الملفات والدليل.

الاستنتاج 3: دليل مؤقت صريح _ربما _ مطلوب. يجب أن نضيف تحسينًا لإزالة الدلائل المؤقتة الخاصة بنا.

استنتاج مشترك.

1. يجب علينا تنظيف الملفات / الدلائل المؤقتة الخاصة بنا.
   قد يكون الحل - يقوم تطبيق PowerShell بإنشاء دليل فرعي في٪ temp٪ كـ ps-{New-GUID} ، وإنشاء ملفات / أدلة مؤقتة فيه وإزالة الدليل في وقت الإنهاء.
2. يمكننا أن نرى أن السيناريو 3 فقط يتطلب دليلًا مؤقتًا صريحًا والانضمام إلى بادئة مؤقتة.
   هل يجب أن نتناول السيناريو؟ إذا كانت الإجابة بنعم ، فإن الحل الشبيه بـ Pester يبدو رائعًا - يمكننا الاعتماد على * -Drive cmdlets لإنشاء أدلة مؤقتة محددة النطاق تحت٪ temp٪ واستخدامها كبادئة مؤقتة. كما أنه يفتح الطريق لإدخال مؤقت محدد النطاق.

مجرد تعليقين.

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

ثانيًا ، إليك الكود الذي أستخدمه لإنشاء متغير TEMP ومتغيرات اسم الكمبيوتر على PowerShell Core. حتى الآن ، كل أمثلتي هي لجعل تجريدات الويندوز موجودة على لينكس لأن لدي الكثير من الأكواد المكتوبة لنظام ويندوز.

أيضًا ، لمعرفة المتغيرات التي يجب نقلها عبر ، أحاول بشكل أساسي الحكم على ما هو شائع جدًا في البرامج النصية الخاصة بي والموجود ككيان على جانب Linux (على سبيل المثال ، اسم المضيف ، درجة الحرارة) ، ولكن ببساطة لم يتم الكشف عنها بالطريقة التي يتوقعها نصي النصي.

في رأيي ، الفكرة الكامنة وراء التوافق هي تسهيل التبني من خلال [أ] إعادة استخدام الكود الحالي ، [ب] القدرة على إعادة استخدام التجريدات المألوفة و [ج] القدرة على كتابة نصوص عبر النظام الأساسي.

آمل ألا يتم التغاضي عن [أ] من منظور الحقول الخضراء بشكل مفرط لأنه هذا هو أكثر ما استخدمته.

If ((Test-Path variable:IsWindows) -AND !$IsWindows)
{
  If (Test-Path '/tmp')
  {
    write-output 'running on PowerShell Core, setting up TEMP environment variable'
    $env:temp = '/tmp'
    $env:computername = hostname
    $env:computername = ($env:computername).split('.')[0]
  }
  Else
  {
    Throw "Cannot find standard temp folder '/tmp' on non-windows platform."
  }
}

DarwinJS : نعم ، فحوى RFC الخاص بك مختلف تمامًا ، لذلك أوافق على أن ما انجرفت إليه المناقشة هنا (على الرغم من تركيزها الأولي على جزء واحد فقط من معلومات البيئة) يجب أن يكون RFC الخاص به.

بالمختصر:

• يحاول RFC الخاص بك تسهيل نقل البرامج النصية القائمة على Windows ، من خلال توفير polyfill ، كوحدة نمطية اختيارية.

• ما اتجهت إليه المناقشة هنا هو جعل المعلومات المستخرجة من النظام الأساسي حول البيئة جزءًا لا يتجزأ من PS Core ، كمساحة اسم جديدة ، غير مقيدة بالتعابير الحالية على الأنظمة الأساسية المدعومة (لقد خطر لي أنه ربما $psenv أفضل من $ps ).

  • المناقشات الثانوية التي انبثقت:
    
    
    
    • توفير مساحة اسم جديدة لمتغيرات PowerShell _preference_ (حسنًا ، لذلك كان _I_ فقط من تحدث عن ذلك :)
    
    
    • [معلمات] cmdlet الجديدة التي توسع القدرة على إنشاء عناصر مؤقتة إلى _directories_ وبامتداد اسم ملف معين (كلاهما مغطى بمشكلات موجودة مسبقًا).
    
    
    • التنظيف التلقائي للملفات المؤقتة / dirs.
    
    

النهجين لا يستبعد أحدهما الآخر.

ما يهمني الوحيد في منهجك المحدد هو أنك تنشئ متغيرات _بيئة_ على أنظمة Unix الأساسية ، والتي تراها جميع العمليات الفرعية ، على الرغم من أن المتغيرات تستخدم فقط _PowerShell-داخليًا_ (لإعادة التعبير عن القلق الذي تم التعبير عنه في تعليق سابق ).

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

بشكل عام ، أعتقد أنه سيساعد الاعتماد إذا لم يكن هناك نوع بيانات جديد داخل PowerShell للقيام بأشياء أساسية مثل تحديد موقع القرص المؤقت. تبدو "متغيرات البيئة" و "متغيرات اللغة" طبيعية ومألوفة لكلا جانبي المنزل.

إذا تم تحديد مساحة اسم ، فلن أستخدم "psenv" إذا كان عليك الالتفاف وعدم تفسير المعنى الضمني الواضح عالميًا لسلسلة "env" - يبدو وكأنه نمط مضاد للتعلم. يمكن إدراج توضيح في أي وقت في التسمية الأولية ، فهو يوفر مليارات التكرارات اللفظية والمكتوبة للمؤهلات التالية:

"التخلي عن معنى اسم 'psenv' ، لا علاقة له بمتغيرات بيئة نظام التشغيل لديك."

أدرك أن polyfill الخاص بك يتوقف على تحديد متغيرات البيئة ، ونظرًا لأن TEMP ولا COMPUTERNAME هي متغيرات بيئة محددة من POSIX ، وبالنظر إلى أننا نتحدث عن وحدة المشاركة ، فهذا ربما بخير.

بشكل عام ، لا يتعلق الاهتمام بالعمليات الفرعية _تجاهل_ متغيرات البيئة ، ولكن حول _ تسمية التعارضات_: استخدام أدوات مساعدة مختلفة متغير بيئة يحمل نفس الاسم لأغراض مختلفة ، دون علم بعضها البعض.

مساحة اسم متغيرات البيئة مشتركة وليست مقيدة بأي شكل من الأشكال (باستثناء التركيب النحوي) ، والطريقة الوحيدة لتجنب الاصطدامات هي من خلال اعتماد تسمية _اختراعات_ - بادئة مثل PS تكون ذات اتجاه واحد - ولكن ليست طريقة مضمونة .

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

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

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

بالنسبة إلى مساحة الاسم psenv : بالنسبة لي ، تقترح البادئة ps أنها تشير إلى بيئة _PowerShell-scoped_ ، لذا فهي تبني على_ المعنى المحدد لـ env - والتي سوف من الواضح أنها تستمر في الوجود كمساحة اسم لمتغيرات البيئة الحسنة النية.
ومع ذلك ، الأسماء قابلة للتفاوض.

نقاط جيدة - أنا متأكد من أن TEMP قد حان للتعارض - لذلك من خلال كونه وحدة اختيارية متوافقة مع "Win to Linux" ، نأمل أن يكشف اختبار البرنامج النصي عن ذلك.

الألفة ليست هي القيمة الوحيدة التي تسمى بالطرق "القديمة" - فهي تمتلك أيضًا أكثر طرق التنفيذ انتشارًا. ويمكن تصميم طرق "جديدة" بشكل مبالغ فيه - ففي الأسبوع الماضي فقط ساعدت زميلًا في استبدال 13 سطرًا من التعليمات البرمجية التي تلقوها من شركة كبيرة بسطر واحد. استخدم الكود الجديد CMDLets "* ScheduledJob" بشكل استثنائي شديد التعقيد وغير المطبق بشكل كامل. إذا ركزت التطبيقات الجديدة بشكل مفرط على "نقاء التصميم" ، فيمكن أن تكون خطوة إلى الوراء. أنا لا أقول أن هذا هو الحال مع اقتراح مساحة اسم جديدة - فقط إذا لم تكن "القابلية للتبني" في طليعة تطبيق جديد ، فيمكن أن ينتهي بها الأمر إلى أن تكون برامج تخزين.

هناك اعتبار آخر لمساحة الاسم الجديد وهو أنه إذا لم يتم نقله إلى PSH 5 ، فلن يكون موجودًا في كل مكان لبعض الوقت. سأظل بحاجة إلى "اكتشاف" ما إذا كان بإمكاني الاعتماد على مساحة الاسم للرمز الذي أكتبه والذي يجب أن يكون PSH 5 / PSH 6 + متعدد الأنظمة. ثم سأحتاج إلى رمز مخصص في وقت ما لـ PSH 5. في الواقع ، من المحتمل أن يكون Windows PSH 5 هو حالة الاستخدام السائدة في المستقبل المنظور.

ولكن ربما هذا من شأنه أن يوجه التنفيذ نحو وحدة نمطية بحيث يمكن لمن يرغبون في تشغيلها على إصدارات أقدم من 6؟

انقسمت مناقشتنا إلى ثلاثة اتجاهات رئيسية:

1. تنفيذ التوافق مع الإصدارات السابقة وإمكانية النقل لنصوص Windows النصية الحالية باستخدام TEMP.
2. إنشاء تجريدات جديدة لـ TEMP لكتابة نصوص متعددة المنصات.
3. تحسين إمكانية اكتشاف متغيرات PowerShell. # 4394

@ mklement0 هل يمكنك من فضلك فتح عدد (قضايا) جديدة (للعدد 1. و 2.)

@ iSazonov :

إعادة 1: هذا مغطى من خلال طلب RFC الحالي الخاص بـ
فيما يتعلق بالسؤال 2: قبل أن نحيي ذلك ، أقترح أن نحصل على توضيح حول النهج العام المقترح في # 4394.

DarwinJS :

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

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

أقترح أن نواصل الحديث على # 4394.

$ env: tmp أو $ env: temp هي حالة الاستخدام السائدة اليوم.

الترويج لهذا على منصات أخرى أمر تافه. سواء كنت تعتبرها interop أو الإرث غير ذي صلة. يدعم هيمنة جميع البرامج النصية الموجودة.

إجابة مختصرة: [IO.Path]::GetTempPath() هي الإجابة الوحيدة.

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

ومع ذلك ، فأنا أحب _ الفكرة _ التي يجب أن نجعل هذا الأمر أسهل في المستقبل ، على الرغم من أن أي شيء نتوصل إليه لن يكون قابلاً للاستخدام بشكل موثوق لسنوات ، لأن PowerShell Core 6 و 6.1 قد تم شحنهما بالفعل بدونه.

من بين جميع الأفكار التي تم التعبير عنها أعلاه ، فإن الفكرة الوحيدة التي أحبها ( وأحبها ) هي فكرة إنشاء محرك أقراص Temp: وتوجيهه إلى (مجلد جديد باسم GUID و / أو تاريخ في) تم إرجاع الموقع بمقدار [IO.Path]::GetTempPath() (وربما تنظيفه عند خروج PowerShell). يعد إنشاء محرك أقراص Temp أمرًا يمكننا القيام به بسهولة في كل من PowerShell Core وفي وحدة التوافق للإصدارات التي تم إصدارها بالفعل. من غير المحتمل أن تتسبب في مشكلة (إنها مجرد مسألة ما إذا كان من المحتمل أن يكون أي شخص قد أنشأ محرك أقراص Temp:) وإذا حدث ذلك ، فسيكون إصلاحه في البرنامج النصي حيث تحدث هذه المشكلة أمرًا بسيطًا.

من الواضح أنه يمكننا أيضًا إضافة New-TempDirectory إلى الأمر New-TempFile - ولكن يجب أن يتم ذلك في وحدة خارجية لتبدأ بها بحيث يمكن أن تكون متوافقة بطبيعتها عبر الأنظمة الأساسية ومتوافقة مع الإصدارات السابقة.

بينما أحب البساطة والاتساق (كثيرًا) مع [IO.Path]::GetTempPath() ، فمن الضروري تمكين خيار PowerShell-Style لمستخدمي PowerShell. في هذه الحالة ، أقوم بإنشاء محرك أقراص Temp: بأمر يحتمل أن يكون ذا صلة.

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

إن مطالبة كاتب النص لاستخدام [IO.Path] :: GetTempPath () أمر فاحش. إنه غير قابل للاكتشاف ، وليس واضحًا ، وليس بوويرشيل.

أنا شخصياً أعتقد أن الترويج لـ $ env: tmp هو الحل الصحيح ، لكن يمكن لأي شخص أن يجادل بأنه ليس كذلك بوويرشيل. بعد بعض الاعتبارات الشخصية ، أعتقد أن الأمر cmdlet الجديد Get-TemporaryDirectory (أو اسم مشابه) هو الإجابة الصحيحة.

أنا لا أفهم "New-TempDirectory". حالة الاستخدام العادية لا تقوم بإنشاء دليل (الذي يشير إليه New- *) - إنها تسترجع اسم دليل موجود (والذي يشير إليه Get- *).

أنا "meh" حول temp: drive لأنه ، لكي يكون قابلاً للاكتشاف ، يتطلب أيضًا واحدًا أو أكثر من أوامر cmdlets. بدلاً من تقديم المزيد من "الحرية" للناسخ ، تشعر القيادة المؤقتة بأنها مقيدة.

نظرة أخرى لتكون من مواليد PowerShell بالكامل. هل يمكننا تجنب الاستخدام الصريح للأدلة المؤقتة؟

# Create the file in temporary directory
$temp= New-Item -Path xyz.txt -Temporary

# Get the file and copy it to temporary directory
$var2 = Get-Item -Path sample.txt; $tempVar2 = Copy-Item $var2 -Temporary

# The temporary directory is automatically created and dropped for the scope 

أشعر أنه يجب ببساطة تجريد النظام الأساسي الحالي مع تفضيل مراجع منصة powerhell الأطول بقاءً بحيث يمكن إعادة استخدام الكود طويل الأمد بسهولة أكبر.

مثله:

If (!(test-path env:temp)) 
{
 If (test-path env:tmpdir) {$env:TEMP = $env:tmpdir}
 elseif (test-path '/var/tmp') {$env:TEMP = '/var/tmp'
}

بالنظر إلى موضوع هذا الموضوع ، قد يرغب البعض في الحصول على ما يمكن اعتباره دليل "tmp" التقليدي. قد يؤدي هذا إلى إرجاع [System.IO.Path] :: GetTempPath (). هذا من شأنه أن يغني عن الحاجة إلى مساحة اسم أو مزود جديد (ملاحظة: ، PSEnv: ، إلخ).

Get-TempDirectory

إذا أراد أحد المطورين استخدام $ Env: TEMP أو $ Env: TMPDIR أو / tmp ، فإنهم أحرار في فعل ذلك. سوف يجعلون منصة الكود الخاصة بهم معتمدة.

تحتاج التطبيقات إلى آلية لإنشاء أدلة وملفات فريدة لتخزين الأشياء فيها. ماذا لو قمنا بتوسيع عنصر جديد حتى نتمكن من إنشاء مجلد واحد أو أكثر من المجلدات والملفات المؤقتة. سيعيد قائمة بأسماء العناصر. سيتم بالفعل إنشاء أسماء العناصر التي تم إرجاعها وهي جاهزة للاستخدام.

New-Item -TempDirectory -NamePrefix [string[]]
New-Item -TempFile -NamePrefix [string[]]

فقط لتلخيص المناقشة حتى الآن:

نتحدث هنا عن حالتين من حالات الاستخدام التكميلي ، على الرغم من أن إحداهما أكثر أهمية بكثير:

• (أ) _الأهم _ - لكن لاحظ أن هذا _ليس _ ما كانت هذه المشكلة تدور حوله في الأصل - نحتاج إلى القدرة على _direct_ إنشاء ملفات ومجلدات مؤقتة بمسارات مضمونة لتكون فريدة - دون الحاجة إلى القلق بشأن التفاصيل - إذا كان الأمر cmdlet ينشئ الملف / dir. بالنسبة لك ، لا داعي للقلق بشأن مكان تخزينه وما هو الدليل الجذر للنظام الأساسي. للملفات المؤقتة.

  • New-TemporaryFile يفعل ذلك بالفعل لـ _الملفات_.
    
    
    
    • # 4215 اقترح تعزيزه بالقدرة على تحديد امتداد اسم الملف لمسار الملف الذي تم إرجاعه.
    
    
    • Liturgist ، هل يمكنك قول المزيد حول الوقت الذي سيكون فيه -NamePrefix مفيدًا؟
    
    
  • # 3442 يدور حول دعم إنشاء درجة الحرارة. _directory_ أيضًا.

  • دعم كل من الملفات و dirs. عبر New-Item هو خيار (شيء اقترحته سابقًا في # 3442 أيضًا ، Liturgist ، مع خيار تحديد الدليل المستهدف للعنصر المؤقت) ، ولكن بالنظر إلى أن لدينا New-TemporaryFile بالفعل ، ربما يكون من الأسهل ببساطة تنفيذ New-TemporaryDirectory للتناظر - بدلاً من ذلك ، يمكن أن يكون كلاهما دالات وكيل (على غرار mkdir على Windows) التي تتأخر إلى New-Item محسّن.

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

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

• (ب) _ في بعض الأحيان_ - وهذا هو الموضوع الأصلي لهذا الموضوع - قد يكون من المفيد _ معرفة الدليل الجذر لمنصة معينة بشكل صريح لإنشاء ملفات مؤقتة و dirs._ - على سبيل المثال ، لكتابة أداة مساعدة تقوم بتنظيف العناصر المؤقتة عند الطلب ، أو إذا كنت بحاجة إلى التحقق مما إذا كان المسار المحدد يشير إلى عنصر مؤقت.

  • كما تمت مناقشته بالتفصيل من قبل ، فإن محاكاة متغير بيئة أو تعريفه بنشاط على الأنظمة الأساسية التي ليس لها معنى محدد مسبقًا أمر غير حكيم ، لذلك ، كما هو مألوف مثل $env:TEMP ، فهو ليس حلاً مناسبًا عبر الأنظمة الأساسية.

  • إن تسطيح هذا الدليل الجذر عبر Get-Temp[orary]Directory _cmdlet_ ، كما يقترح Liturgist ، هو بالتأكيد خيار.

    • سيسمح ذلك أيضًا بدعم التمييز بين المجلدات المؤقتة _user_ و _system_ (Windows و macOS) ، عن طريق معلمات لطلب أحدهما أو الآخر (يجب أن يكون المسار الافتراضي هو دليل المستخدم).
    • لاحظ أن [io.path]::GetTempPath() يدعم فقط استرداد درجة حرارة المستخدم. dir. ، لذلك بالنسبة للنظام ، يجب استخدام [environment]::GetEnvironmentVariable('TEMP', 'Machine') على Windows ، والمسار الثابت /tmp على نظام macOS. (ليس لدى Linux هذا التمييز ، على الرغم من أن الأنظمة الشبيهة بـ Unix تحتوي على أنواع أخرى من المجلدات المؤقتة (راجع https://superuser.com/a/332616/139307) ، على الرغم من أننا ربما لا داعي للقلق بشأن دعمها ).

  • خيار آخر (ليس بالضرورة حصريًا) هو إظهار مسار الدليل هذا عبر مساحة الاسم $sf للمجلدات الخاصة المقترحة في # 6966 ، على غرار $sf:Temporary

    • لاحظ أن هذا من شأنه أن يبني على الطريقة التي اختارها _CoreFx_ لإظهار المواقع المستخرجة من النظام الأساسي (على الرغم من أنها كانت في الأصل ميزة خاصة بـ Windows فقط): [System.Environment]::GetFolderPath() - سيكون امتدادًا _ ، ومع ذلك ، نظرًا لأن المجلد المؤقت (ق) غير مشمولة حاليًا.

@ mklement0 شكرا على التلخيص الكبير!

أعتقد أنه يمكننا الاستمرار في التفكير في السيناريوهات التي يمكن أن تكون فيها كل هذه الخيارات مفيدة (مثل "الحصول على ملف من الويب / الشبكة ، ووضعه مؤقتًا ، ومعالجة الملف (فك / فك التشفير ...) ، وإزالة درجة الحرارة"). أعتقد أنه يمكننا القيام بأشياء رائعة أكثر من مجرد إعادة الدليل المؤقت.

لقد ضربت هذا مؤخرًا أثناء اللعب بوظائف Azure. أنا معتاد على وجود TestDrive: في Pester وأعتقد أنه سيكون من الجيد أن يكون لديك محرك آلي Temp: . بالطبع ، على عكس TestDrive: لن يقوم PowerShell بالتنظيف التلقائي. أفكار؟ اسمح لي بالعمل عليها كميزة تجريبية ... https://github.com/PowerShell/PowerShell/pull/8696

بناءً على المناقشة أعلاه ، يبدو التعيين البسيط إلى Temp: drive غير مفيد جدًا ولا يحل السيناريوهات الشائعة. (يمكن للمستخدمين تنفيذ هذا بأمر واحد في ملف التعريف. في Azure ، من الممكن ببساطة أن يكون القرص المضغوط مؤقتًا.)
أفضل أن يعرض PowerShell Core المزيد من الأشياء السحرية للمستخدمين.

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

@ SteveL-MSFT - ربما ينبغي إعادة تسمية هذه المشكلة وإعادة تحديد نطاقها إلى "حيادي التنفيذ" لتغطية أشياء مثل أصداف السحابة دون الإشارة إلى أنها نظام أساسي بنفس طريقة نظام التشغيل.

يساعد تغيير الاسم في عكس عرض القيمة الأوسع عند إدخال تطبيقات بدون خادم / غير نظام تشغيل في النطاق.

شكرا لرعايتك لهذه القضايا ، مايكل كليمنت

يبدو أن تقليد دليل tmp / temp هو أن كل برنامج يمكنه ذلك بأي طريقة يريدها. يعمل ذلك حتى تضارب الأسماء أو توجد مثيلات متعددة لنفس البرنامج. في الحالة الأولى ، يجب أن تختار التطبيقات أسماء مختلفة. في الثانية ، قد يحدد التطبيق ملفاته عن طريق تضمين معلومات فريدة مثل PID في اسم الملف.

(أ) أوافق تمامًا على أنه مع ضمان التفرد ، يجب ألا يهتم التطبيق بمكان وجود ملف أو دليل مؤقت أو الاسم.

يجب أن يكون القيد هو أنه من الممكن تحديد موقع الملفات والأدلة المؤقتة بعد الوفاة لتمكين معالجة الشذوذ (إيجاد الأخطاء وإصلاحها). هل يشير هذا إلى أن التنظيف التلقائي لدرجة الحرارة يجب أن يكون أحد إعدادات التفضيل؟

استند اقتراح -NamePrefix إلى أن يكون التطبيق قادرًا على التعرف على الملفات المؤقتة الخاصة به في مجموعة واحدة. على الرغم من أن التفرد المضمون يلغي هذا كشرط ، قد يجد المطور الراحة في التعرف على foo_xxxx.tmp و bar_xxxx.tmp و bosh_xxxx.tmp وغيرها عند استخدام ملفات مؤقتة متعددة.

أوافق على أنه إذا كان لدينا New-TemporaryFile ، فيجب أن يكون لدينا New-TemporaryDirectory.

بالتأكيد لا يحل TEMP: المجلد المؤقت الفريد الذي سيحله New-TemporaryDirectory ويكون الاثنان متعامدين. من المؤكد أن التفرد مفيد خاصة إذا كانت لديك عمليات متعددة أو حتى مساحات تشغيل ، لكن هذا ينحرف عما قصدته هذه المشكلة الأصلية.

ماذا كانت نتيجة هذا النقاش؟

New-TemporaryDirectory هو https://github.com/PowerShell/PowerShell/issues/3442

محرك أقراص Temp: يحل هذه المشكلة.

@ SteveL-MSFT - حسنًا. لا أرى محرك أقراص Temp: من Get-PSDrive في 6.2.1. هل أبحث في المكان الخطأ ، أو متى سيصبح محرك الأقراص Temp: متاحًا؟ يبدو أن # 3442 تظهر Waiting - DotNetCore .

هل سيكون محرك الأقراص Temp: عالميًا للنظام بنفس طريقة /tmp على أنظمة * NIX حاليًا؟

هل سيكون هناك New-TemporaryDirectory ليكون متعامدًا مع New-TemporaryFile ؟

Liturgist لقد كانت ميزة تجريبية. الآن هو في 7.0. يمكنك تنزيل الإصدار اليومي والعثور عليه هناك. إنه "عالمي" في جلسة PowerShell.
لا توجد خطط فورية لتنفيذ New-TemporaryDirectory - يمكنك المناقشة في # 3442.

Liturgist إذا كنت ترغب في تجربته على 6.2.1 ، فقط افعل هذا:

Enable-ExperimentalFeature PSTempDrive

ثم أعد تشغيل pwsh.

: tada: تمت معالجة v7.0.0-preview.2 .: tada:

روابط مفيدة:

• ملاحظات الإصدار

أحاول TEMP:\ لكني اكتشفت أنه لا يمكنني استخدام TEMP:\ مباشرة في طرق C # أو في الأدوات الخارجية ، على سبيل المثال

[System.IO.Compression.ZipFile]::ExtractToDirectory($path, "TEMP:\foo")

أو

unzip foo -d TEMP:\foo

يجب أن أستخدم Get-Item TEMP:\ أو أي شيء لتحقيق ذلك ...

@ LYP951018 :

TEMP: هو محرك أقراص _PowerShell-only_ (يمكنك إدراجه بـ Get-PSDrive ) وهذه المحركات غير مرئية للعالم الخارجي ، بما في ذلك .NET

يجب ترجمة المسارات المستندة إلى محرك PS إلى مسارات نظام الملفات "الأصلية" الخاصة بها ، وهو ما يعنيه Convert-Path .

لاحظ أن هناك مأزق آخر مرتبط بتمرير مسارات نظام الملفات إلى طرق .NET (وإن لم يكن إلى البرامج الخارجية): يرى .NET عادةً دليل عمل مختلفًا عن PowerShell ، لذلك لا يعمل تمرير المسارات _ النسبية عادةً على النحو المنشود - فمن الأفضل اجتياز المسارات _full_ دائمًا ، والتي يمكن أن يساعدها أيضًا Convert-Path .

باختصار: من الجيد تكوين عادة لتمرير مسارات نظام الملفات إلى طرق .NET عبر
Convert-Path -LiteralPath .

إذا بقيت في عالم PowerShell ، فلن تواجه هذه المشكلة ؛ على سبيل المثال ، يمكنك استخدام Expand-Archive .