PATH در ویندوز چیست و چطور درست تنظیمش کنیم؟

پیام‌هایی شبیه «node is not recognized» یا اینکه python در یک ترمینال کار می‌کند و در دیگری نه، تقریباً همیشه به PATH یا PATHEXT برمی‌گردند. PATH فهرست پوشه‌هایی است که سیستم هنگام جست‌وجوی فرمان اجرایی می‌گردد. روی ویندوز جداکننده نقطه‌ویرگول (;) است نه کولون، و ترتیب پوشه‌ها نتیجه را عوض می‌کند.

این مقاله مدل جستجو، تفاوت User و Machine، ابزار where.exe، روش ویرایش امن، و اشتباه‌هایی مثل خرد کردن PATH با setx را پوشش می‌دهد. قوانین سطح متغیر محیطی همان مقالهٔ ۱۸۷ است؛ اینجا روی PATH به‌عنوان حساس‌ترین متغیر روزمره تمرکز می‌کنیم.

پاسخ کوتاه

وقتی فرمانی بدون مسیر کامل می‌زنید، ویندوز در پوشه‌های PATH به‌ترتیب می‌گردد و با پسوندهای PATHEXT فایل اجرایی را پیدا می‌کند. مقدار مؤثر معمولاً ترکیب Machine و User است. بعد از ویرایش پایدار، نشست جدید لازم است. برای دیباگ، where.exe و چاپ جداگانهٔ User و Machine را استفاده کنید نه حدس.

اول ببین کدام python پیدا می‌شود؛ بعد نصب دوباره را شروع کن.

مسئله‌ای که PATH حل می‌کند — و می‌سازد

بدون PATH باید برای هر ابزار مسیر کامل بنویسید: C:\Program Files\nodejs\node.exe. PATH اجازه می‌دهد فقط node بزنید. همین راحتی وقتی خراب می‌شود گران تمام می‌شود: نسخهٔ اشتباه سایه می‌اندازد، نصب‌کننده مسیر را دوبل می‌نویسد، یا setx مقدار را قطع می‌کند و نصف ابزارهای سیستم ناپدید می‌شوند.

• ابزار نصب شده ولی «not recognized» است.
• دو نسخهٔ Python/Node هم‌زمان؛ همیشه نسخهٔ غلط اجرا می‌شود.
• در Windows Terminal کار می‌کند، در VS Code یا JetBrains نه.
• بعد از یک اسکریپت «تعمیر»، حتی notepad از PATH خارج شده.

PATH چگونه کار می‌کند؟

هر ورودی یک پوشه است، مثلاً مسیر نصب Node. وقتی می‌نویسید node، سیستم آن پوشه‌ها را به ترتیب جلو می‌رود تا node با یکی از پسوندهای PATHEXT مثل .EXE پیدا شود. اولین تطبیق برنده است. به همین دلیل نسخهٔ قدیمی‌تر اگر زودتر در PATH باشد، نسخهٔ جدید را سایه می‌اندازد.

powershell

$Env:PATH -split ';' | ForEach-Object { $_ } $Env:PATHEXT

جداکننده را با لینوکس اشتباه نگیرید. کولون روی ویندوز معنای دیگری دارد و وارد کردن آن به‌جای نقطه‌ویرگول یکی از خرابکاری‌های کلاسیک کپی از آموزش یونیکس است. فاصله در مسیر (مثل Program Files) مجاز است؛ نیازی به نقل‌قول داخل خود مقدار PATH نیست، ولی هنگام ساخت رشته در اسکریپت باید مراقب باشید.

نقش PATHEXT

PATHEXT می‌گوید کدام پسوندها «اجرایی» شمرده می‌شوند: معمولاً .COM;.EXE;.BAT;.CMD;.VBS و مشابه. اگر فقط node بنویسید، where و شِل به ترتیب پسوندها را امتحان می‌کنند. اسکریپت .ps1 به‌طور پیش‌فرض مثل .exe در PATHEXT نیست؛ اجرای مستقیم به سیاست ExecutionPolicy و میزبان powershell.exe وابسته است.

User در برابر Machine در برابر Process

powershell

$user = [System.Environment]::GetEnvironmentVariable('PATH','User') $machine = [System.Environment]::GetEnvironmentVariable('PATH','Machine') "USER:`n$user`n`nMACHINE:`n$machine"

نصب‌کننده‌های per-user معمولاً User را عوض می‌کنند. ابزارهای سیستمی Machine را. مقدار Process همان چیزی است که نشست فعلی می‌بیند — ترکیب ارث‌بری به‌علاوه تغییرهای موقت session. اگر دو جا نسخهٔ متفاوت باشد، ترتیب ترکیب مهم است؛ رفتار دقیق را با where در نشست واقعی بسنجید نه با حدس.

ویرایش پایدار با SetEnvironmentVariable روی User یا Machine، روی پنجره‌های از قبل باز اثر نمی‌گذارد. IDEها اغلب env را هنگام شروع قفل می‌کنند؛ بعد از تغییر PATH، Terminal و IDE را از نو باز کنید.

where.exe؛ دوست دیباگ

طبق مستندات Microsoft Learn، where محل فایل را با جستجو در پوشهٔ جاری و مسیرهای PATH نشان می‌دهد و در صورت نبود پسوند، PATHEXT را اعمال می‌کند. در PowerShell حتماً where.exe بنویسید؛ where بدون پسوند Alias برای Where-Object است.

powershell

where.exe node where.exe python Get-Command node -All

where ممکن است چند مسیر نشان دهد؛ اولی همانی است که معمولاً اجرا می‌شود. Get-Command در PowerShell هم مسیر را می‌گوید و اگر Alias یا Function وسط باشد لو می‌دهد. این دو ابزار را قبل از نصب دوباره عادت کنید.

افزودن امن یک پوشه به PATH کاربر

powershell

$dir = 'C:\Tools\bin' $old = [System.Environment]::GetEnvironmentVariable('PATH','User') if (-not $old) { $old = '' } if ($old -notlike "*$dir*") { $new = if ($old) { "$old;$dir" } else { $dir } [System.Environment]::SetEnvironmentVariable('PATH',$new,'User') }

قبل از نوشتن، از مقدار فعلی پشتیبان متنی بگیرید. ویرایش GUI (Settings → System → About → Advanced system settings → Environment Variables) همان کار را می‌کند؛ برای تیم اسکریپت شفاف‌تر است. سپس Terminal جدید باز کنید و where را دوباره بزنید.

1. مسیر نصب واقعی را با Explorer یا Get-ChildItem تأیید کنید.
2. پشتیبان User و Machine را در فایل متنی ذخیره کنید.
3. فقط یک پوشهٔ bin اضافه کنید؛ کل Program Files را در PATH نریزید.
4. نشست جدید + where.exe برای تأیید.

چرا setx خطرناک است؟

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

برای اسکریپت مدرن، System.Environment.SetEnvironmentVariable معمولاً شفاف‌تر و قابل‌پیش‌بینی‌تر است؛ باز هم با پشتیبان. از set PATH=... در cmd فقط برای نشست فعلی استفاده کنید، نه به‌عنوان «تعمیر دائمی».

علائم و تشخیص

تعمیر وقتی PATH خراب شده

1. از پشتیبان یا از Machine سالم مقدار را بخوانید.
2. حداقل‌های ویندوز مثل C:\Windows\System32 و C:\Windows را حذف‌شده فرض نکنید.
3. آرام ورودی‌های ابزار توسعه را یکی‌یکی اضافه کنید.
4. با where صحت هر ابزار حیاتی را بسنجید.

خالی کردن کامل PATH سطح Machine خطرناک است و می‌تواند خود ویندوز را برای مدیریت بعدی سخت کند. بدون پشتیبان و بدون فهم اینکه کدام ورودی‌ها سیستمی‌اند دست نبرید. اگر در دامنه هستید، گاهی Policy سازمانی PATH را بازنویسی می‌کند؛ تغییر محلی بعد از gpupdate برمی‌گردد.

مقایسه کوتاه با لینوکس

در لینوکس جداکننده : است، معمولاً یک export در shell profile، و which/command -v برای دیباگ. در ویندوز جداکننده ؛، سه سطح Machine/User/Process، و where.exe/Get-Command. مفهوم یکی است؛ قراردادها فرق دارند. اگر تیم دوگانه دارید، منطق «کدام باینری» را در مستند پروژه بنویسید نه فقط در ذهن یک نفر.

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

• کپی PATH لینوکس با کولون داخل مقدار ویندوز.
• افزودن مسیر فایل به‌جای پوشهٔ حاوی exe.
• دوباره‌کاری نصب به‌جای where و اصلاح ترتیب.
• ویرایش فقط Process و تعجب از اینکه بعد از بستن ترمینال اثر رفته.
• گذاشتن مسیرهای شبکهٔ کند یا پوشه‌های عظیم در ابتدای PATH (تأخیر هر فرمان).
• اعتماد به نصب‌کننده بدون تأیید where در Terminal تازه.

چه وقت دست ببرید / نبرید

دست ببرید وقتی ابزار درست نصب شده ولی پیدا نمی‌شود، یا نسخهٔ غلط سایه انداخته، یا می‌خواهید مسیر ابزار داخلی تیم را استاندارد کنید. دست نبرید وقتی مشکل از ExecutionPolicy، آنتی‌ویروس، یا App execution aliases ویندوز است — اول همان‌ها را رد کنید. همچنین برای هر پروژهٔ موقت، بهتر است از مسیر کامل در اسکریپت CI استفاده کنید تا PATH ماشین را شکننده نکنید.

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

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

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

برای Task Scheduler متغیرها را در تعریف کار یا اسکریپت wrapper مشخص کنید تا به PATH مبهم نشست وابسته نباشید.

سرویس و کار زمان‌بندی‌شده لزوماً همان PATH کاربر تعاملی را ندارند. اگر ابزار در Terminal شما هست ولی در سرویس not found می‌شود، یا مسیر کامل بدهید یا محیط سرویس را صریح تنظیم کنید. این تفاوت منبع بسیاری از «روی سیستم من کار می‌کند» است.

PATH در سرویس و Task Scheduler

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

مقدار خیلی بلند می‌تواند در ابزارهای قدیمی یا برخی APIها مشکل بسازد. اگر PATH شما صفحه را پر می‌کند، وقت تمیزکاری است: نسخه‌های متروک SDK، مسیرهای uninstall‌شده، و تکرارها را حذف کنید. پشتیبان بگیرید، بعد هرس کنید.

طول PATH و محدودیت‌های تاریخی

پوشه‌های خالی یا مسیرهای مرده در PATH را تمیز کنید. هر ورودی اضافه یعنی کمی کار بیشتر هنگام هر فرمان و کمی سردرگمی بیشتر هنگام دیباگ.

وقتی where چند مسیر می‌دهد، اولی برنده است. نصب موازی Python از Store و از python.org نمونهٔ کلاسیک سایه انداختن است. به‌جای حذف عجولانه، ترتیب را بفهمید و تصمیم بگیرید کدام باید اول باشد؛ بعد بقیه را از PATH بردارید یا عقب برانید.

ترتیب جستجو و سایه انداختن نسخه‌ها

خلاصه

PATH در ویندوز فهرست مرتب پوشه‌ها با جداکنندهٔ نقطه‌ویرگول است که همراه PATHEXT تعیین می‌کند کدام باینری با نام کوتاه اجرا شود. User و Machine را جدا ببینید، با where.exe دیباگ کنید، با SetEnvironmentVariable و پشتیبان ویرایش کنید، و از setx برای PATH دوری کنید مگر دقیقاً بدانید چه می‌کند. بعد از هر تغییر پایدار، نشست جدید بگیرید.

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

چرا where چند مسیر نشان می‌دهد؟

چون چند فایل هم‌نام در پوشه‌های مختلف PATH هست. اولی معمولاً اجرا می‌شود. برای اجبار به نسخهٔ خاص، ترتیب را عوض کنید یا در اسکریپت مسیر کامل بدهید.

App execution aliases چیست؟

در Settings ویندوز، Aliasهایی مثل python.exe می‌توانند به Microsoft Store اشاره کنند و قبل از PATH واقعی شما قرار بگیرند. اگر where به WindowsApps می‌رود، Alias را خاموش یا درست کنید.

آیا باید System32 را دستی به PATH اضافه کنم؟

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

تفاوت PATH کاربر با PATH در CI چیست؟

Agentهای CI اغلب PATH را از image و stepها می‌سازند. روی لپ‌تاپ User PATH شخصی شما ممکن است ابزارهایی داشته باشد که در CI نیستند — برای بیلد تکرارپذیر به نصب صریح در pipeline تکیه کنید.

منابع و مراجع

• where — Microsoft Learn: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/where
• about_Environment_Variables — Microsoft Learn: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables
• Environment.SetEnvironmentVariable — .NET API: https://learn.microsoft.com/en-us/dotnet/api/system.environment.setenvironmentvariable