PowerShell در برابر cmd؛ کدام را کی استفاده کنیم؟

سؤال PowerShell بهتر است یا cmd معمولاً بد طرح می‌شود. بهتر این است: برای این کار، کدام مفسر کمتر اصطکاک و خطای پنهان می‌سازد؟ cmd هنوز در اسکریپت‌های قدیمی، نصب‌کننده‌ها و عادت‌های سازمانی زنده است. PowerShell زبان و شِل مدرن ویندوز برای اتوماسیون است و با اشیاء، نه فقط متن خام، کار می‌کند.

این مقاله مدل ذهنی هر دو، جدول تصمیم، دام‌های مهاجرت، و تفاوت Windows PowerShell 5.1 با PowerShell ۷ را روشن می‌کند. فهرست فرمان‌های روزمره در ۱۸۴ می‌آید؛ اینجا انتخاب ابزار مهم است.

پاسخ کوتاه

برای کار جدید روی ویندوز، PowerShell را پیش‌فرض ذهنی‌تان کنید — مخصوصاً نسخهٔ ۷ در صورت دسترسی. cmd را وقتی لازم است لمس کنید که با فایل bat موجود، ابزار فقط-cmd، یا محیط با محدودیت نصب روبه‌رو هستید. PowerShell خروجی ساخت‌یافته و cmdletهای یکدست می‌دهد؛ cmd سریع و ساده برای فرمان‌های کلاسیک و سازگاری قدیمی است.

مهاجرت یعنی اسکریپت جدید را درست بنویسید، نه اینکه همهٔ batهای دنیا را یک‌شبه بازنویسی کنید.

cmd چیست و چرا هنوز هست؟

Command Prompt مفسر سنتی فرمان ویندوز است که ریشه در دورهٔ DOS/Windows NT دارد. فایل‌های .bat و .cmd، بسیاری مستندات قدیمی، و بعضی ابزارهای نصب هنوز به آن وابسته‌اند. فرمان‌هایی مثل dir، copy، netstat و sc برای نسل‌ها در همین فضا آموزش داده شده‌اند.

نقطهٔ قوت cmd سادگی و فراگیری است. نقطهٔ ضعفش وقتی است که بخواهید خروجی را دقیق پارس کنید، خطای ساخت‌یافته بگیرید، یا با JSON و اشیاء سیستم کار کنید. برای آن کارها به ابزارهای جانبی یا اسکریپت شکننده می‌رسید.

cmd

dir /a where python netstat -ano | findstr :3000

PowerShell چیست؟

PowerShell شِل و زبان اسکریپت مایکروسافت است که دور اشیاء .NET طراحی شده. cmdletها معمولاً با الگوی Verb-Noun می‌آیند: Get-Process، Set-Service، Get-ChildItem. پایپ‌لاین به‌جای عبور متن خام، اشیاء را پاس می‌دهد تا انتخاب ویژگی و فیلتر دقیق‌تر شود.

دو خانواده را قاطی نکنید: Windows PowerShell 5.1 که با ویندوز می‌آید، و PowerShell ۷+ که چندسکویی است و جدا نصب می‌شود. برای اسکریپت جدید، ۷ معمولاً مسیر بهتر است؛ برای سازگاری با ماژول‌های قدیمی سازمانی گاهی ۵.۱ هنوز اجبار است.

powershell

Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Get-ChildItem Env:PATH

تفاوت مدل: متن در برابر شیء

در cmd و یونیکس کلاسیک، پایپ اغلب متن است و با find/findstr و برش ستون زندگی می‌کنید. در PowerShell می‌توانید مستقیم روی ویژگی شیء فیلتر کنید:

powershell

Get-Process | Where-Object { $_.WorkingSet64 -gt 200MB } | Select-Object Name, Id, WorkingSet64

این یعنی کمتر regex شکننده برای جدول‌های متنی، و اسکریپت‌هایی که با تغییر جزئی قالب خروجی کمتر می‌شکنند. هزینه: باید مدل شیء و گاهی نوع داده را بفهمید؛ کپی کورکورانه از bash همیشه کار نمی‌کند.

جدول تصمیم سریع

سازگاری و دام‌های مهاجرت

خیلی از فرمان‌های cmd در PowerShell از طریق alias یا توابع سازگاری در دسترس‌اند، ولی رفتار ۱۰۰٪ یکسان نیست. مثال کلاسیک: در PowerShell کلمهٔ curl ممکن است به Alias برای Invoke-WebRequest اشاره کند نه باینری curl.exe — بسته به نسخه و تنظیمات. وقتی رفتار عجیب دیدید، Get-Command را چک کنید.

powershell

Get-Command curl curl.exe --version

دام دیگر: نقل‌قول و escaping. قواعد cmd با PowerShell فرق دارد. اسکریپت مهاجرت‌شده‌ای که نیمه‌کاره هر دو نحو را مخلوط کند، دیباگ دردناکی می‌سازد. یک فایل، یک زبان.

Batch در برابر اسکریپت PowerShell

فایل bat برای کارهای کوتاه و سازگاری عالی است. وقتی منطق شرطی تودرتو، کار با API، JSON، یا مدیریت خطا جدی می‌شود، PowerShell خواناتر و امن‌تر نگه داشته می‌شود. سیاست اجرا (Execution Policy) گاهی مانع اجرای ps1 می‌شود؛ آن را بفهمید نه اینکه کورکورانه Bypass دائمی روی کل ماشین بگذارید.

powershell

Get-ExecutionPolicy -List # برای یک نشست آزمایشی، نه سیاست دائمی بی‌فکر: Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Windows PowerShell 5.1 در برابر PowerShell ۷

• ۵.۱: همراه ویندوز، مبتنی بر .NET Framework، سازگاری ماژول‌های قدیمی.
• ۷+: نصب جدا، مبتنی بر .NET مدرن، چندسکویی، بهبودهای زبان و عملکرد.
• در Windows Terminal برای هرکدام پروفایل جدا بسازید تا اشتباه نگیرید.

اگر تیمی دارید، در README بنویسید اسکریپت با کدام نسخه تست شده است. فرض pwsh همه جا هست روی لپ‌تاپهای قفل‌شده همیشه درست نیست.

نمونه‌های هم‌ارز برای حس تفاوت

لیست فایل‌های اخیر:

cmd

dir /o-d

powershell

Get-ChildItem | Sort-Object LastWriteTime -Descending | Select-Object -First 10

یافتن فرایند:

cmd

tasklist | findstr /i node

powershell

Get-Process -Name node -ErrorAction SilentlyContinue

در دومی نتیجه شیء است؛ می‌توانید مستقیم | Stop-Process بدهید بدون پارس PID از متن.

چه وقت عمداً cmd را نگه دارید؟

• نصب‌کننده یا سند رسمی فروشنده فقط فرمان cmd داده و وقت اعتبارسنجی بازنویسی ندارید.
• محیط بسیار مینیمال بدون PowerShell ۷ و محدودیت نصب.
• کار یک‌خطی که سال‌ها در runbook سازمانی با cmd پایدار مانده.

نگه داشتن cmd نشانهٔ عقب‌ماندگی نیست؛ بازنویسی اجباری همه چیز بدون ارزش تجاری نشانهٔ تعصب است.

اشتباه‌های رایج

• فرض اینکه هر فرمان لینوکس در PowerShell همان معنی را دارد.
• مخلوط کردن نحو درصدمتغیر٪ سبک cmd داخل اسکریپت ps1.
• نادیده گرفتن Execution Policy و بعد بی‌اعتماد شدن به کل PowerShell.
• یکی‌گرفتن Terminal با شِل — مقالهٔ ۱۸۲ را ببینید.
• اجرای همیشگی Elevate به‌جای طراحی درست مجوز.

سوالات متداول

آیا cmd منسوخ شده است؟

مایکروسافت PowerShell را مسیر اتوماسیون مدرن معرفی می‌کند، ولی cmd هنوز جزء ویندوز است و حذف کاملش در افق نزدیک برای همه سناریوها فرض امنی نیست. عملیاتی فکر کنید نه تیتروار.

باید bash روی WSL را به‌جای هر دو بگذارم؟

برای ابزار یونیکس عالی است. برای مدیریت خود ویندوز — سرویس، رجیستری، Event Log، ACL — PowerShell معمولاً مناسب‌تر است.

از کجا شروع به یادگیری PowerShell کنم؟

مدل Verb-Noun، پایپ‌لاین شیء، و Get-Help را یاد بگیرید؛ بعد فرمان‌های ضروری ۱۸۴ را تمرین کنید.

اگر راه‌حل شما تغییر سطح Machine بود، بگویید چرا User کافی نبود. اگر Force کردید، بگویید چرا توقف ملایم شکست. این انضباط کوچک کیفیت عملیاتی تیم را بالا می‌برد.

قبل از اینکه مشکل را بسته‌شده اعلام کنید: نشست جدید را تست کنید، مسیر یا پورت یا سرویس را دوباره با ابزار ساخت‌یافته تأیید کنید، و یک خط در یادداشت تیمی بنویسید که علت ریشه‌ای چه بود. بدون این سه قدم، همان تیکت هفتهٔ بعد برمی‌گردد.

چک‌لیست پایانی قبل از بستن تیکت

اگر نیمی از تیم bat و نیمی ps1 می‌نویسند بدون قرارداد، onboarding و بازبینی اسکریپت دردناک می‌شود. یک README کوتاه در پوشهٔ scripts بنویسید: زبان پیش‌فرض، نسخهٔ PowerShell، و استثناهای cmd. ابزار را شخصی نکنید تا حدی که همکار نتواند اجرا کند.

تصمیم تیمی نه سلیقهٔ فردی

برای کار روزمرهٔ وب، همین که Get-Process و Get-NetTCPConnection و مدیریت فایل را روان باشید کافی است. عمیق شدن در همهٔ ماژول‌ها لازم نیست؛ عمیق شدن در کمک‌خوانی لازم است.

قدرت PowerShell در ماژول‌هاست: شبکه، مدیریت سرویس، Active Directory در محیط‌های دامنه، و ابزارهای ابری. Get-Module -ListAvailable و Find-Module نقطهٔ شروع کشف‌اند. cmd این اکوسیستم را ندارد و نباید انتظار همان سطح را از آن داشت.

ماژول‌ها و کشف‌پذیری

فایل‌های ps1 را با امضای کد یا حداقل کنترل تغییر در git نگه دارید. Execution Policy دشمن شما نیست؛ لایهٔ اصطکاک در برابر اجرای تصادفی اسکریپت دانلودشده است. Bypass سراسری دائمی را فقط وقتی سیاست امنیتی اجازه می‌دهد انجام دهید.

در CI، کد خروج مهم است. PowerShell با $ErrorActionPreference و -ErrorAction رفتار غنی‌تری از cmd دارد ولی اگر ناآگاهانه Continue بگذارید، پایپ‌لاین سبز دروغین می‌سازد. برای قدم‌های حساس Stop را ترجیح دهید و نتیجه را صریح تست کنید.

اتوماسیون و خروج غیرصفر

برای اسکریپت‌های مهاجرت، جدول هم‌ارزی داخلی تیم بسازید: dir در برابر Get-ChildItem، findstr در برابر Select-String، set در برابر $Env. این جدول زمان onboarding را نصف می‌کند.

وقتی یک فرمان در cmd درست و در PowerShell غلط است، اول Get-Command بزنید تا ببینید Alias یا تابع جایگزین باینری شده یا نه. دوم quoting را مقایسه کنید. سوم بررسی کنید متغیر محیطی را با نحو درصد یا $Env اشتباه نگرفته‌اید.

خطایابی تفاوت خروجی‌ها

نسخه‌بندی اسکریپت‌های عیب‌یابی را جدی بگیرید. یک gist شخصی یا پوشه در ریپو داخلی با تاریخ و پیش‌فرض‌های ایمن، بهتر از حافظهٔ شفاهی است.

مستند رسمی را نخواندن و اعتماد به اولین نتیجهٔ جستجو، اجرای همیشگی Elevated، و تغییر Machine برای مشکل User، سه الگوی پرهزینه‌اند. هزینهٔ واقعی‌شان معمولاً ساعت‌ها بعد معلوم می‌شود؛ وقتی محیط برای همکار یا CI می‌شکند.

اشتباه‌های سطح بالاتر

در پایان تمرین، همه چیز را به حالت اول برگردانید: فرایند تست را ببندید، متغیر موقت را رها کنید، و سرویس را اگر تغییر دادید به Startup Type قبلی برگردانید. پاک‌سازی بخشی از حرفه‌ای‌گری است.

یک سرور محلی بالا بیاورید، پورتش را پیدا کنید، فرایند را بشناسید، یک متغیر محیطی موقت ست کنید، PATH را فقط مشاهده کنید بدون تغییر مخرب، وضعیت یک سرویس بی‌خطر را بخوانید، و پنج رویداد اخیر Application را ببینید. این مدار بسته، دانش را از حالت خواندنی به حالت عضلانی می‌برد.

تمرین پیشنهادی سی‌دقیقه‌ای

اگر از لینوکس آمده‌اید، معادل ذهنی بسازید ولی فرمان را عیناً ترجمه نکنید. مدل سرویس ویندوز با systemd شباهت مفهومی دارد و تفاوت ابزاری. مدل env با export شباهت دارد و تفاوت سطح Machine و User.

مفاهیم این مقاله را با Terminal، PowerShell، فرایند، پورت، env، PATH، سرویس و Event Viewer به‌صورت حلقه ببینید نه جزایر جدا. بیشتر تیکت‌های واقعی دو یا سه حلقه از این زنجیره را درگیر می‌کنند.

ارتباط با بقیهٔ سری ویندوز

تفاوت محیط خانگی و لپ‌تاپ سازمانی را دست‌کم نگیرید. آنتی‌ویروس، پروکسی، و سیاست اجرای اسکریپت رفتار ابزارها را عوض می‌کنند. اگر فقط روی یک ماشین تست می‌کنید، نتیجه را حقیقت مطلق ندانید.

هر بار که راه‌حل موقتی پیدا می‌کنید، همان را به یک فرمان قابل‌کپی در یادداشت شخصی تبدیل کنید. هفتهٔ بعد همان فرمان را از حافظه نمی‌نویسید؛ از دفترک می‌آورید و خطا کمتر می‌شود.

در کار واقعی، مشکل‌ها ترکیبی‌اند: پورت اشغال، PATH کهنه، سرویس متوقف، و ترمینال با پروفایل غلط همزمان ظاهر می‌شوند. به‌جای تغییر همزمان همه چیز، یک متغیر را ثابت نگه دارید و فقط یک فرض را آزمایش کنید. این نظم علمی سرعت عیب‌یابی را بیشتر از هر میانبر افزایش می‌دهد.

عمق عملی بیشتر برای کار روزانه

خلاصه

cmd مفسر سنتی و سازگار است؛ PowerShell شِل و زبان اتوماسیون شی‌گرا. برای کار جدید و عیب‌یابی ساخت‌یافته PowerShell را انتخاب کنید، cmd را برای میراث و سازگاری نگه دارید، و نسخهٔ ۵.۱ را با ۷ اشتباه نگیرید. ترمینال مدرن فقط ظرف است؛ انتخاب شِل کیفیت اسکریپت و دیباگ شما را عوض می‌کند.

منابع و مراجع

• Microsoft Learn — PowerShell documentation — https://learn.microsoft.com/powershell/
• Microsoft Learn — PowerShell vs. Windows PowerShell — https://learn.microsoft.com/powershell/scripting/whats-new/differences-from-windows-powershell
• Microsoft Learn — about_Pipelines — https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_pipelines
• Microsoft Learn — about_Execution_Policies — https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_execution_policies
• Microsoft Learn — Windows commands reference — https://learn.microsoft.com/windows-server/administration/windows-commands/windows-commands