هذا يجعل استخدام rm ، ls ، إلخ. مزعجًا ، نظرًا لعدم تنفيذ globbing:

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

بلاه.

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

• متغير بيئة لإيقاف تشغيل جميع الأسماء المستعارة التي تتعارض مع * nix الثنائيات
• حرف واحد (مثل ^ ) يقع تلقائيًا في المسار الأصلي
• أخبر الأشخاص أن عليهم استخدام bash -c (قال الكثيرون إن هذا عدد كبير جدًا من الأحرف بحيث لا يمكن استخدامه)
• أخبر الناس أن عليهم توفير المسار الكامل (هذه التجربة تعمل بالفعل من الناحية الفنية ، لكنها سيئة للغاية)
• اقتراح جانبي: استفد من "النظام الفرعي للتلميح" لإخبار الأشخاص بأنهم قد يرغبون في استخدام الأمر الأصلي إذا استخدموا مجموعات المعلمات التي تطابق الأنماط مع الثنائيات الأصلية * nix. هذا لا يزال يعمل فقط عندما يفشل الأمر ( rm -e ، على سبيل المثال ، لن يفشل).

أعتقد أن هذا شيء نريد اكتشافه عاجلاً وليس آجلاً ، لذلك قمت بنقله إلى الإصدار 0.5.0. في رأيي ، يعد إعداد PowerShell لتبديل الأوضاع هو أفضل خطوة أولى.

andschwa والافتراضي سيكون ....؟

@ ضد رأيي _personal_: تمكين الأسماء المستعارة لـ PowerShell ؛ لأنك تقوم بتشغيل PowerShell.

في النهاية ، سنحتاج إلى دليل "بدء التشغيل" لأول مرة لـ PowerShell على أي حال ، وسنذكر أن هذا إعداد متاح.

BrucePay أي تحديثات على هذا؟

كررت مزامنة سهولة الاستخدام اليوم أن الأسماء المستعارة يجب أن تعود مرة أخرى (الأنابيب إلى sort هي نقطة بيانات أخرى في تجربة PS معطلة تمامًا.)

ترك بروس كمسؤول لتحديد أفضل مسار للمضي قدمًا باستخدام عوامل التخفيف المذكورة أعلاه. andschwa : ربما نحتاج إلى شخص آخر يتم تعيينه للقيام بالعمل لإعادة الأسماء المستعارة.

لقد أجريت للتو محادثة مع jpsnover وهو واضح جدًا أننا لا نعيد الأسماء المستعارة. يجب أن ننشئ ملف البريد الوارد aliases.ps1 وأن نشجع على تحديد مصادره.

ربما يجدر الإشارة إلى أن ls في bash عادةً ليس ببساطة ls ، إنه اسم مستعار مع بعض الوسائط الافتراضية ، وربما يكون أبرزها هو الإخراج باستخدام اللون.

لا تعمل الأسماء المستعارة لـ PowerShell على الإطلاق مثل الأسماء المستعارة في Linux ، لذلك سنحتاج إما إلى تعريف ls كدالة ، أو تحسين الأسماء المستعارة لدينا للعمل مثل الأسماء المستعارة bash.

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

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

يبدو أن لدينا قصة ، أغلق القضية.

2p الخاص بي على هذا - إعدادات PowerShell جديدة متغيرة مشابهة لـ $ PSModuleAutoLoadingPreference الذي تم تقديمه في PSv3 سيسمح للمستخدم النهائي بالتحكم في ملفات التعريف الخاصة به (يمكن أيضًا وضع مثال بسيط يوضح بعض الأوامر التي تعمل مع وبدون PS الأسماء المستعارة جيدة

الاسم الموحي $ PSUsePowerShellAliases وإذا لم يتم تعيينه بشكل صريح على صحيح (داخل الملف الشخصي أو بشكل تفاعلي) ، فسيتم استخدام الأسماء المستعارة القياسية * nix في المكان.
أعتقد أن هذا من شأنه أن يعطي أيضًا تجربة مستخدم أفضل لأولئك الذين قد يقررون الآن اختبار المياه باستخدام PowerShell الذي لم يكن ليحدث من قبل لأنه لا يسلب ما يعرفونه ولكنه يتيح لمن يعرف طريقة PS القدرة للقيام بذلك أيضًا.

لا يأخذ ما يعرفونه

إطلاقا. إذا كان يجب أن يكون هناك حل وسط ، فيجب أن يكون لصالح مستخدمي Linux Bash ، أي مستخدمي PowerShell الجدد المحتملين. يمكن للمؤمنين في PowerShell الحاليين إعادة إنشاء الأسماء المستعارة * nix الخاصة بهم بسهولة كافية أو أفضل من ذلك ، فطموا أنفسهم عن تلك الأسماء المستعارة.

في الواقع ، بعد أن أصبح لدينا الآن PowerShell على Linux ، أود أن أرى الأسماء المستعارة المضمنة * nix تمت إزالتها من جميع إصدارات نظام التشغيل من PowerShell Core - إذا لم تكن كذلك بالفعل. سيؤدي ذلك إلى ترك أسماء مستعارة مضمنة تتطابق مع أوامر PowerShell المضمنة ولا تحاول "خداعك".

أنا معجب بإزالة الأسماء المستعارة الشائعة من ps على Linux افتراضيًا - لست معجبًا بـ "إصلاح" هذا على Windows كما يقترح Keith. حجتي لهذا هو أنك إذا ربحت مستخدم Linux لـ PowerShell ثم قرروا تجربته أيضًا على Windows ، فلن يكون لديهم الأسماء المستعارة الشائعة.

هل يمكن إضافة هذا إلى PSReadline ، القدرة على تمكين الأسماء المستعارة Linux أم لا؟ بالنسبة لي ، من السهل إصلاح الكود الخاص بي الذي يستخدم أسماء قصيرة للوظائف. مع ذلك ، سأكتب دائمًا LS أولاً وأتوقع أن يعمل مثل الاسم المستعار PowerShell LS مقابل Get-ChildItem .

لا تتردد في استخدام هذه المشكلة للتعبير عن رأيك حول ما يجب أن يكون عليه سلوك PowerShell.

أعتقد أن ما لمسهkilasuit و rkeithhill و @ 1RedOne يبدو أنه الحل الأفضل - قم بتعطيله افتراضيًا على Linux و macOS ولكن في نفس الوقت ، اجعل من السهل علينا تمكينه في وحدة التحكم أو في نصوصنا.

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

خارج الموضوع - غير متحمس بشأن توفر PowerShell على منصات أخرى! 😄

فيما يتعلق بـ PSReadLine ، يجب أن يكون juneb لا يستخدم PSReadline على الإطلاق

يمكنني بالتأكيد نشر عينة لـ PSReadline لاستبدال الأسماء المستعارة المحددة باستخدام PowerShell cmdlet ، وستستند إلى هذه العينة: https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354

بعد قولي هذا ، لا أعتقد أنه حل حقيقي ..

أكبر مشكلة في ذهني هي التعارض بين قابلية نقل البرنامج النصي والألفة. لقد قدمنا ​​إرشادات مفادها أن البرامج النصية يجب ألا تستخدم الأسماء المستعارة ، لكنها لا تزال ممارسة شائعة. قد تكون بعض الأسماء المستعارة أكثر إشكالية من غيرها ، على سبيل المثال ، يمكن استخدام sort أكثر من ps أو ls في البرامج النصية.

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

إن استبدال أوامر PowerShell بملفات تنفيذية أصلية بدون دعم متواصل بالتأكيد لن يساعد في إقناع رجال bash باستخدام PowerShell.

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

باعتباري مستخدمًا * لا شيء بالكاد لمس النوافذ ، أود أن أجري تصويتًا قويًا لترك الأسماء المستعارة فيها. لقد علمتني سنوات عديدة من الذاكرة العضلية استخدام ls ، rm ، إلخ. لا أريد إعادة تعلم ذاكرتي العضلية (ثم إعادة تعلمها كلما انتهى بي الأمر في باش) للحصول على تجربة Powershell الأصلية.

صححني إذا كنت مخطئًا هنا ، لكن هل يختلف هذا عن dir على windows؟ في PS على Windows ، dir ليس dir.exe . إنه Get-ChildItem . في * لا شيء ، لماذا يجب أن يكون ls /bin/ls بدلاً من Get-ChildItem ؟

Gaelan لقد فهمت وجهة نظرك ، ولكن يرجى مراعاة أنه لا يوجد ملف dir.exe في Windows. dir أمر داخلي لمعالج الأوامر cmd ، مشابه لـ bash المدمج. ربما يكون هذا هو السبب (الوحيد) لأن PowerShell لم يتم تصميمه لاستدعاء الأمر الخارجي dir.exe مباشرة.

Gaelan ، ForNeVeR : بينما

بشكل عام ، لا أعتقد أن هناك _ هي _ طريقة آمنة للاحتفاظ بالأسماء المستعارة و _ لا _ تحطيم الأشياء لأن كل اسم مستعار نظريًا (باستثناء تلك التي لا يمكن أن توجد في نظام الملفات ، مثل ? ) يمكن أن تحجب ملفًا تنفيذيًا أصليًا ثم لم يعد من الممكن تسميته (على الأقل ليس باسمه الأساسي).

PS> gal|?{gcm "$_.exe" -ea 0}

CommandType     Name
-----------     ----
Alias           fc -> Format-Custom
Alias           sc -> Set-Content
Alias           sort -> Sort-Object
Alias           where -> Where-Object
Alias           write -> Write-Output

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

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

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

إذا نظرت إلى السجل هنا ، فقد اقترحت ما أعتقد أنه الحل الأفضل من منظور UX للأسماء المستعارة التي تعين لأوامر مكافئة بخلاف Windows

هذه مشكلة PowerShell طويلة الأمد. أشتكي من أنه لا يحتوي على أمر مشابه لـ cmd dir أو حتى ls . الرد ، في كل مرة ، هو "ولكن هناك اسم مستعار!".

الأسماء المستعارة ليست ولم تكن أبدًا حلاً لهذه المشكلة. لا توفر الأسماء المستعارة dir و ls الوظائف التي يوفرها dir و ls . وينطبق الشيء نفسه على الأسماء المستعارة wget و curl .

يجب إعادة التفكير في النهج الكامل للأسماء المستعارة ، وهذا يعني كسر التغييرات.

لماذا لا يمكن أن تكون الأسماء المستعارة المعرفة من قبل النظام مجرد مواطنين من الدرجة الثانية للثنائيات في PATH؟

أود أن أقول أزل جميع الأسماء المستعارة * nix على Linux ، يبني OS X حتى تعرف ما يجب فعله.

تحرير: شكرا لتوضيح أن هذا قد تم بالفعل ، آسف للمقاطعة.

okket التي تم القيام بها بالفعل. نحن نناقش ما إذا كان هناك شيء يحتاج إلى التغيير.

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

bash-aliases.ps1
dos-aliases.ps1
initial-aliases.ps1

إذا لم يكن هناك شيء آخر ، فإن ذلك يعمل على تذكير الأشخاص بأنه ليس لدى كل شخص نفس الأسماء المختصرة.

دعونا لا ننسى (sleepypikachu) أن الأسماء المستعارة بوويرشيل لن تفعل أي شيء ما عدا _do_ إعادة تسمية الأمر وتجاوز قرار قيادة النظام. تتطلب وظيفة Bash alias _functions_ في PowerShell.

Gaelan تجعلك ذاكرتك العضلية تستخدم الاسم المستعار ، ولكن هل

هذه هي المشكلة الحقيقية هنا و DrPizza موجودة على الفور. مثال رائع ، _dir / s_. فشل هذا الأمر في PowerShell لذا عليك تغييره إلى dir -recurse.

هناك بالفعل ثلاث قضايا ذات صلة هنا:

1. ليست كل المعلمات ذات أسماء مستعارة
2. لم يتم تعيين كافة المعلمات الأصلية أو السلوك في PowerShell CmdLet.
3. بحاجة إلى طريقة لتشغيل الأمر الأصلي إذا كان الاسم المستعار موجودًا

لا أعتقد أن رقم 1 سيء للغاية بالنسبة لمشكلة ما وسيزيد الأمور سوءًا إذا تم تسميتها باسم مستعار. Dir -recurse هو معامل أكثر قابلية للقراءة من dir / s على أي حال. بالإضافة إلى ذلك ، فهو يجعل البرامج النصية غير متسقة عند محاولة الانتقال من Windows إلى Linux والعكس.

2 و 3 هي الأكثر أهمية. لم أستخدم curl أبدًا ، لكنني أعلم أنني واجهت قيودًا مع Invoke-WebRequest أتوقع أن يكون curl قادرًا على القيام به. (لا تتذكر من أعلى الرأس).

على المدى القصير ، أعتقد أنك بحاجة إلى كل من خيار التكوين وكذلك طريقة لاستدعاء الأمر الأصلي إذا تم تمكين الاسم المستعار.

افتراضي ، اتركه ممكّنًا. هذا بوويرشيل .... على لينكس. يجب أن يتصرف مثل PowerShell حتى يتمكنوا من معرفة استخدام CmdLets. وجد زميلي في العمل الذي لديه خلفية من Linux و Perl أنه من الأسهل بكثير معرفة أوامر cmds التي يحتاجها لتشغيل البرنامج النصي. أعتقد أنه كان grep، ls، and man هو المفتاح بالنسبة له. يجب أن يساعدهم استخدام الرجل في معرفة كيفية استخدام cmd بشكل صحيح.

على المدى الطويل ، قم بإضافة تغطية لأسطر الأوامر cmdlets الأصلية للحصول على كافة معلمات وقدرات الأوامر الأصلية. يعمل هذا على تحسين PowerShell لنظامي التشغيل Windows و Linux من خلال منحنا المزيد من الخيارات القوية. من المحتمل أن تحتاج بعض السلوكيات إلى تحويلها إلى عدة CmdLets واستخدام كائنات وخطوط أنابيب ، لكن هذا شيء عظيم! إذا لم تفعل ذلك ، فما الفائدة من PowerShell؟

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

يعد توفير خيار أفضل ، ولكن تقديم جميع الأسماء المستعارة كخيارات ... حسنًا ، ليس مستحيلًا.

IMHO وجود اسم مستعار لـ dir أمر منطقي ، حيث يمكنني بسهولة استخدام Where-Object لتصفية الملفات. لقد كنت من مستخدمي Linux منذ سنوات وكتابة dir ليست طبيعية مثل استخدام ls.

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

لا ، أنا أؤيد بشدة أن PS توفر الأسماء المستعارة افتراضيًا ، ولكن الشيء الحقيقي أدناه يجب أن يكون له نفس الوظيفة تمامًا (وربما توافق المعلمات) مع الثنائيات الأصلية ، باستثناء دعم الكتابة.
PowerShell بدون أنواع غير مجدية.

سيؤدي استخدام ثنائيات النظام الأساسية واعتماد فلسفة أدوات يونكس إلى تعزيز التبني. كشخص يقوم بالتطوير في متاجر يونكس ، فوجئت بسرور عندما وجدت أن ثنائيات يونكس العادية تعمل إلى حد ما في هذا التطبيق. فيما يتعلق بمسألة الشخصية * ، أعتقد أن معظم الأشخاص في الجانب * nix سيكونون مرتاحين لاستخدام حرف الهروب أمام * عند الإشارة إلى * nix shell glob بدلاً من أي سلوك يكون حاليًا في بوويرشيل. من المحتمل أن يكون حلاً مقبولاً لـ | كأنبوب ينتج كائنًا بدلاً من دفق من الثماني بتات يمر بين الملفات يتعارض مع المعايير المنشورة ويعيق التبني. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis يرجى ملاحظة: لن يقوم أحد بإزالة الأنواع من PowerShell ؛ يبقى إما gci و Get-ChildItem كما هو في كل من Windows PowerShell و Linux PowerShell. نحن هنا نتحدث فقط عن ما إذا كان الاسم المستعار المدمج مثل ls -> Get-ChildItem يجب أن يكون موجودًا على Linux أم لا. يجب ألا تستدعي البرامج النصية الخاصة بك ls أو gci على أي حال إذا كنت تقصد الاتصال بـ Get-ChildItem (لأن استخدام الأسماء المستعارة في البرامج النصية غير مستحسن ولم يوصى به مطلقًا). ls و gci هي أسماء مستعارة ملائمة فقط لاستخدام سطر الأوامر ، ويمكن أن تربك مستخدم Linux إذا تم تغيير اسم ls فجأة إلى Get-ChildItem وليس له القيادة الأم المفضلة ؛ سوف يربكه أكثر إذا لم يكن لديه طريقة مختصرة لاستدعاء هذا الأمر مباشرة.

أنا لأمر يستخدم لتمكين الاسم المستعار على بوويرشيل.
احتفظ بجميع الأسماء المستعارة وقم بإهمالها ببطء على Windows Powershell.

أعتقد باستخدام الأمر مثل

Enable-Alias Unix
Enable-Alias dos

لتمكين الاسم المستعار من المزايا التالية

1. إنه يحل مشكلة الأشخاص الذين يريدون استخدام الضفيرة الأصلية
2. إنه لا يشجع الناس على استخدام الاسم المستعار في النصوص (مما يفسد سهولة قراءة النص).
3. كما أنه من السهل جدًا على الأشخاص الذين يحبون هذه الأسماء المستعارة تمكينها
4. وهو بالكاد يضر بأي أداء.

ForNeVeR أستخدم ls كـ gci طوال اليوم لأنه حرف واحد أقصر ...
ومع ذلك ، فإن إدخال هذا التغيير (إزالة الأسماء المستعارة unix-y و dos-y) هو بالتأكيد تغيير جذري (ليس مثل curl ). قد يكون الحل "المثالي" هو تنفيذ هذه الأوامر لتحسين مكتوب للأدوات الموجودة.
بالنسبة للنصوص ، ربما ... بيان using ؟

ForNeVeR أعتقد أنك أسأت فهم @ be5invis . إنه مؤيد قوي لـ بوويرشيل. أعتقد أن ما يعنيه بعبارة "بوويرشيل بدون نوع عديم الفائدة" هو أنه لا ينبغي للناس استخدام الضفيرة الأصلية في بوويرشيل.

@ be5invis أيضًا أعتقد أن فكرتك عن توافق الضفيرة الأصلية بعيدة المدى. قواعد بوويرشيل غير متوافقة مع قواعد يونكس القياسية ، على سبيل المثال يمكنك أن تفعل rm -rf في يونكس لكن في بوويرشيل عليك أن تفعل rm -r -fo .
لذلك لن تصل أبدًا إلى توافق المعلمات مهما حدث.

chantisnake فلماذا لا نضيف -recurse -force ؟

@ be5invis يتعارض هذا مع كيفية عمل المعلمات في PowerShell. إنها متعامدة ، وإذا لم تكن كذلك ، فهناك مجموعات مختلفة من المعلمات. لديهم أيضًا أسماء طويلة فقط وبدلاً من الأسماء المختصرة يمكن اختصارها بشكل فردي طالما أنها لا لبس فيها. في حالتك ، ستحتاج أيضًا إلى إضافة اسم مستعار إلى هذه المعلمة ، fr . أيضا فجأة -Recurse لن تكون قادرة على اختصارها إلى -r ولكن بدلا من ذلك يجب أن يكون -re لعدم الصدام مع الخاص المقترح -rf المعلمة.

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

تذكر: الغلاف الموجود على جهازك ملكك. تمامًا مثل الاسم المستعار للأشخاص rm إلى rm -i لراحتهم ، لا يوجد شيء يمنعك من إزالة الاسم المستعار rm ولديك وظيفة التفاف Remove-Item تسمى rm -rf بمعامل

لكن محاولة تغيير PowerShell بالكامل لتكرار كل أداة من أدوات Unix أمر مضلل إلى حد ما.

تم تحديد وظيفة ومخرجات ls جيدًا لسنوات عديدة. يقوم الأمر ls بإخراج تدفق ثماني بتات بتنسيق معروف. الأمر ls لا ينتج كائنات DirectoryInfo و FileInfo. إن الحصول على مخرجات ls شيء مختلف أمر محير على الأقل وربما خادع بعض الشيء.

عندما يكون المستخدم جاهزًا للاستفادة من مزايا الكائنات الموجودة في خط الأنابيب ، سيتعرف المستخدم على Get-ChildItem و gci. إذا كان المستخدم لا يريد الحصول على مزايا الكائنات الموجودة في خط الأنابيب أو التعامل معها ، فقد يكون المستخدم أفضل حالًا باستخدام bash و ksh و csh و sh وما إلى ذلك.

يمكن قول الشيء نفسه عن الأمر DIR على Windows.

دعونا لا يكون * لا شيء * لا شيء وجعل Powershell أفضل ما يمكن أن يكون.

تضمين التغريدة

عندما يكون المستخدم جاهزًا للاستفادة من مزايا الكائنات الموجودة في خط الأنابيب ، سيتعرف المستخدم على Get-ChildItem و gci. إذا كان المستخدم لا يريد الحصول على مزايا الكائنات الموجودة في خط الأنابيب أو التعامل معها ، فقد يكون المستخدم أفضل حالًا باستخدام bash و ksh و csh و sh وما إلى ذلك.

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

أتفق معGaelan.
إذا كان شخص ما لا يريد أشياء ، فيمكنه ببساطة التبديل إلى bash أو zsh.
إنهم يريدون مزايا الكائنات ، وتسمية أشياء مثل ls إلى إصدار متوافق ولكن مكتوب سيمنحهم بالضبط ما يريدون.

Gaelan و @ be5invis ، أفهم الرغبة في الحد من مقدار التغيير الذي يجب على المستخدم القيام به لاستخدام Powershell. يبدو أن أصابعي تكتب ls قبل أن يرسل عقلي إشارة إليهم.

المشكلة هي أن تلك الأوامر الأساسية الموجودة لا تنتج كائنات. التغيير الفعلي الذي سيتم إجراؤه ليس من ls إلى gci . التغيير الأكبر هو من التفكير الذي تم القيام به لمعالجة سطور النص إلى التفكير في خصائص والطرق التي يمكن تطبيقها على كائن.

من حق كل مستخدم إنشاء أي أسماء مستعارة يريدها. أوافق على أنه يمكن تسهيل قيام المستخدم بذلك عن طريق إضافة طريقة وخاصية إلى $ Host (System.Management.Automation.Internal.Host.InternalHost) لتمكين أو تعطيل استبدال الأمر الأصلي. لقد رأيت آخرين ، ولكن هل هناك أداة تكوين ملف تعريف واجهة المستخدم الرسومية المضمنة في Powershell؟

إذا كان شخص ما لا يريد أشياء ، فيمكنه ببساطة التبديل إلى bash أو zsh.

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

لا يمكنني إخبارك بعدد المرات التي اضطررت فيها إلى استخدام السطر "_PowerShell is a shell . سيتم تنفيذ المرافق الأصلية المفضلة لديك على ما يرام _" لجعل الأشخاص يتخطون فكرة أنه يمكنهم استخدام PowerShell فقط مع تلك الأوامر الصوتية المضحكة وحملهم على تجربة PowerShell بالفعل. يحتاج PowerShell إلى احترام المرافق المحلية الشائعة والعمل معها بأفضل ما يمكن - فترة. هذا هو بعد كل شيء ، واحدة من الوظائف الأساسية "شل".

rkeithhill لذا دعني /bin/ls ، لا يمكنها التواصل مع الأنواع. لذلك ، التحول إلى غلاف مكتوب ، ولكن بدون أدوات مكتوبة ، فإن التغيير لا معنى له.

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

1. ضع بروتوكول IPC مكتوبًا واطلب من Linus تحديث أدواتهم - لا ، لن يفعلوا ذلك ، لأنه من صنع عدوهم ، الشر ، مدمر العالم الحر ! سوف "يحتضنون ويطمدوننا"! أو...
2. الاسم المستعار ls لمُدمج مع معلمات متوافقة.

بالنسبة للمستخدمين الذين يرغبون في استخدام Powershell ، يريدون أنواعًا ، أليس كذلك؟

في النهاية ، ربما سيفعلون. ومع ذلك ، أعمل مع عدد من المطورين الذين بدأتهم في PowerShell من خلال بيعهم فقط عند استخدامه مع Git و Posh-Git (شيء لا تستطيع CMD توفيره). نادرًا ما يقومون بتوصيل أي شيء في هذه المرحلة ، لكنني أتوقع منهم الوصول إلى هناك. هذه النقطة هي أن الأداة المساعدة git.exe تعمل تحت PowerShell تمامًا كما تتصرف في ظل CMD. انتقال سهل.

بالنسبة لي ، ls (مثل ps ، grep ، sed ، awk ، gcc ، curl ، إلخ) هي مجرد أداة أصلية أخرى يجب أن تكون أي "shell" قادرة على تشغيلها. الآن ، إذا كان شخص ما جاهزًا ويريد أمر إصدار الكائن لسرد محتويات الحاوية ، فيمكنه استخدام Get-ChildItem أو اسمه المستعار gci . إذا كانوا عازمين على عدم استخدام الأداة المساعدة الأصلية ls ، فيمكنهم إنشاء اسم مستعار ls لـ Get-ChildItem في ملفهم الشخصي.

راجع للشغل لا أعتقد أن محاولة جعل معلمة Get-ChildItem متوافقة مع ls ممكنة. ستتوقف بسرعة كبيرة مع معلمات PowerShell التي لا تكون حساسة لحالة الأحرف ، مثل -c / -C، -d / -D، -i / -I. ولا يدعم PowerShell المعلمات التي تجمع بين مثل ls -rt. إنه وصول وينتهك مبدأ Monad الخاص بـ PowerShell. سيتم تنفيذ مهمة مثل الفرز بواسطة أمر cmdlet منفصل (Sort-Object) وليس بواسطة Get-ChildItem نفسه.

rkeithhill لن أجعل Get-ChildItem متوافقًا مع ls . أنا أهدف إلى أمر cmdlet آخر ، يمكن تسميته UnixCompatibles-ls كاسمه الكامل ، ولدي محلل أوامر منفصل يقبل نكهة GNU getopt ، بدلاً من PowerShell.

@ be5invis أليس الخيار الأسهل عند هذه النقطة هو وظيفة منفصلة تعمل ls ، وتمريرها جميع وسائطها ، وتوزع المخرجات وتخلق كائنات منها؟ محلل أوامر منفصل تمامًا (جنبًا إلى جنب مع بيانات تعريف الأوامر المنفصلة تمامًا ، التنسيق لـ Get-Help ، ...) هو مبالغة قليلاً (بصرف النظر عن تكرار الكثير من أعمال PowerShell الداخلية بطريقة غير متوافقة.

سيكون هناك دائمًا عالمان منفصلان هنا ، أحدهما أصلي والآخر مكتوب. يخدم PowerShell بالفعل كلاهما ، من خلال القدرة على تنفيذ البرامج الأصلية وأوامر cmdlets. أنا شخصياً لا أرى أي فائدة (مجرد مهمة ضخمة في جهود التطوير) في محاولة إضافة طبقة فوق الأوامر الأصلية التي تكرر البيانات الوصفية للمعلمات داخل PowerShell. بالإضافة إلى ذلك ، ماذا ستفعل بشأن tar أو find (والعديد من البرامج الأخرى) ، والتي لا تلتزم AFAIK باتفاقيات GNU. تنفيذ محلل الأوامر yet_another_ ، جنبًا إلى جنب مع وظائف المجمع لاستدعاء هؤلاء؟ لاحظ أيضًا أنه لكي يعمل محلل الأوامر ، يجب تحليل وسيطات البرنامج الأصلي داخل PowerShell ويجب ألا تتعارض مع اللغة. شيء قد يكون صعبًا مع أشياء غريبة مثل [ .

ygra لا بأس أيضًا.

بالنسبة للمستخدمين الذين يرغبون في استخدام Powershell ، يريدون أنواعًا ، أليس كذلك؟

@ be5invis ، ربما هذا هو المكان الذي يحدث فيه القليل من الانفصال. لا ، لا يريدون أنواعًا. يريد المستخدم إنجاز عمله أو اللعب. يعرف المستخدم أن ls ينتج دفقًا من النص.

هل UnixCompatibles فعل؟ هل سيؤدي هذا إلى تغيير البرنامج النصي $ PROFILE للمستخدم بشكل دائم ، أم فقط لهذه الجلسة؟ لا أريد أن يكون Get-ChildItem متوافقًا. دع ls يكون ls وافعل ما يفعله ls . يبدو أن هذا سيعطي المستخدم خيارًا لاستبدال ls بـ Get-ChildItem . هذا جيد. لست متأكدًا من أنني أريد ذلك ، لكن بالنسبة لأولئك الذين يريدون ذلك ، فلا بأس بذلك.

Liturgist أعتقد أن ما تعنيه @ be5invis هو أنه إذا واجه الناس مشكلة التحول إلى Powershell (بدلاً من البقاء مع Bash) ، فذلك لأنهم يريدون شيئًا توفره Powershell. إذا أراد الأشخاص دفقًا من النص من ls ، (على Linux أو macOS) فلن يزعجهم Powershell أبدًا.

Gaelan لذا لا يجب أن أستخدم PowerShell إذا كنت بحاجة إلى استخدام gcc أو git؟ ما الخطأ في السماح للأشخاص بتحديد ما إذا كانوا يريدون نصًا (ls) أو كائنات (gci)؟ هناك المزيد من الأسباب لاستخدام PowerShell أكثر من مجرد طبيعة OO - فهي قوية كما هي. هيك ، أفضل استخدام PowerShell فقط من أجل C / C # مثل عبارات تدفق التحكم (مقابل if / fi و switch case / esac) ونظام النوع المناسب (حيث تكون الأرقام أرقامًا وليست سلاسل).

تضمين التغريدة

لذلك لا يجب علي استخدام PowerShell إذا كنت بحاجة إلى استخدام gcc أو git؟

في نظام * nix ، إذا أراد المستخدمون فقط استخدام shell لـ gcc أو git فلن يزعجوا أنفسهم باستخدام PowerShell ، لأن الصدفة التي تأتي مع نظام التشغيل الخاص بهم تعمل بشكل جيد تمامًا.

هيك ، أفضل استخدام PowerShell فقط من أجل C / C # مثل بيانات تدفق التحكم (مقابل if / fi و switch case / esac)

ربما إذا كان شخص ما يستخدم بالفعل PowerShell ، فسيفضل ذلك بسبب ذلك ، لكنني أشك في أن شخصًا ما سيقوم بتثبيت PS من أجل ذلك فقط.

نظام النوع المناسب (حيث تكون الأرقام أرقامًا وليست سلاسل)

/bin/ls مع نظام النوع أيضًا: إذا قمت بتشغيل ls -l ، فسأحصل على أحجام الملفات كسلسلة بدلاً من رقم PS مناسب.

أشعر أن أسباب قيام مستخدم جديد بالتبديل إلى PS on * nix تدور إلى حد كبير حول OO ونظام الكتابة. يجب أن نجعل الأمر سهلاً قدر الإمكان للمستخدمين الجدد لبدء استخدام PS - إذا رأيت شيئًا عن PS ، حاولت التحقق منه ، فقط لاكتشاف أنني بحاجة إلى إعادة تعلم كل شيء عن سطر الأوامر لاستخدامه ، فمن المحتمل أن تقل احتمالية إزعاجها لتعلمها مما لو كان بإمكاني تشغيل PS ، واكتب ls وشاهد على الفور نظام الكتابة قيد التشغيل. نعم ، يمكنني استخدام الأسماء المستعارة ، ولكن إذا كنت أجرب PS في بضع دقائق إضافية ، فمن غير المحتمل أن أرغب في إجراء الكثير من التهيئة قبل أن أقفز وأبدأ اللعب.

في نظام * nix ، إذا أراد المستخدمون فقط استخدام shell لـ gcc أو git فلن يزعجوا أنفسهم باستخدام PowerShell ، لأن الصدفة التي تأتي مع نظام التشغيل الخاص بهم تعمل بشكل جيد تمامًا.

ربما إذا كان شخص ما يستخدم بالفعل PowerShell ، فسيفضل ذلك بسبب ذلك ، لكنني أشك في أن شخصًا ما سيقوم بتثبيت PS من أجل ذلك فقط.

آسف ، لكنني أعارض بشدة. كمستخدم لينكس، وأريد أن استخدام بوويرشيل بدلا من قذيفة التي تأتي مع نظام التشغيل الخاص بي. لكل شيء. لأنه رائع ، كما تعلم :)

هيك ، أنا أقوم بتعبئة PowerShell لـ

يرجى مراعاة أن مستخدمينا المستهدفين ليسوا فقط مستخدمي يونكس أصليين يستخدمون Windows + PowerShell عن طريق الخطأ ، ولكن أيضًا مستخدمي Windows الذين يستخدمون Unix + PowerShell بطريق الخطأ ؛)

حرف واحد (مثل ^) يقع تلقائيًا في المسار الأصلي

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

في الواقع ، هناك نقطة أخرى لاستخدام حرف واحد للهروب: bash يقوم بذلك بالفعل. https://twitter.com/climagic/status/806536501232340992

\ls يتجاهل كافة الأسماء المستعارة.

هل تم حل الإجابة على الأسماء المستعارة عن طريق تمكين WSL (نظام Windows الفرعي لنظام Linux)؟ سيوفر هذا أوامر sed و awk و ls وما إلى ذلك في غلاف bash.

في حين أنه لا يزال رمزًا تجريبيًا لنظام التشغيل Windows 10 ، فمن المؤكد أنه سيأتي وسيُتاح في Server 2016 و 2012.

Liturgist حاليًا ، WSL هي بيئة منفصلة جدًا عن PowerShell. الأوامر غير قابلة للاستدعاء من جلسة PowerShell. بالإضافة إلى ذلك ، من المحتمل أن يعتبر هذا انحدارًا من قبل العديد من مستخدمي Windows PowerShell الحاليين حيث أن العديد من البرامج النصية قد تتعطل إذا تلقوا المخرجات من GNU ls سبيل المثال بدلاً من ls -> Get-ChildItem . في حين أن استخدام الأسماء المستعارة لم يكن موصى به أبدًا في البرامج النصية ، إلا أن الحقيقة تظل أنها قد تم استخدامها وأن الكسر قد يسبب صعوبة للعديد من الأشخاص.

@ ليتورجست : bgshacklett موجود هنا. المشكلة ليست أن شيئًا ما يحدث عند كتابة ls ، السؤال هو ما هي المعلمات التي تتوقعها أثناء استخدام ذلك ، وما إذا كان الناتج المنبعث قابل للاستهلاك بطريقة موجهة للكائنات بواسطة أوامر PowerShell cmdlets الأخرى (مثل ls | Where-Object Name -like *foo* لن يعمل إذا كنت تستخدم WSL ls ).

تمت معالجة المشكلة الأصلية ذات الأسماء المستعارة المتضاربة مع cmds الأصلية. إذا كانت هناك حاجة إلى امتلاك القدرة على إضافة الأسماء المستعارة الشائعة لـ Windows PowerShell ، فيجب أن تكون هذه مشكلة منفصلة.

تم فتح https://github.com/PowerShell/PowerShell/issues/3610 لالتقاط المشكلة الثانوية