هسته‌ ابزارهای مایکروسافت سرانجام هشت فرمانی را به ویندوز داد که به‌خاطرشان لینوکس را باز می‌کردم

هفتهٔ گذشته، WSL را برای کار روزانه‌ام با Coreutils مایکروسافت جایگزین کردم. این یعنی اجرای بومی فرمان‌هایی مثل ls و grep و find و cat و بقیه روی ویندوز؛ همان فرمان‌هایی که در لینوکس استفاده می‌کنم. با این حال، تنها کنجکاو نبودم بدانم کار می‌کنند یا نه؛ می‌خواستم بدانم آیا می‌توانند برای مدیریت فایل، فیلتر کردن لاگ‌ها و اسکریپت‌های کوچک، جای یک زیرسیستم کامل لینوکس را بگیرند. در عمل توانستم کارهای زیادی را بدون ترک ترمینال ویندوز انجام دهم.

لینوکس نبود که دلم برایش تنگ شده بود؛ هشت فرمان بود

ویندوز هرگز زبان ترمینالیِ موردنیازم را در اختیارم نگذاشت

هنگام کار روی پروژهٔ یک مشتری، باید فایل پیکربندی‌ای را پیدا می‌کردم که چند روز پیش نامش را تغییر داده بودم. پیش از آن‌که آگاهانه تصمیمی بگیرم، یک تب WSL باز کرده بودم. همان لحظه به ذهنم رسید که به‌جای آن‌که آگاهانه به نیازم به لینوکس فکر کنم، دستم ناخودآگاه به‌سوی فرمان find می‌رود. انگشت‌هایم پیش از پایان استدلال حرکت می‌کردند. این عادت بود: به‌محض گم شدن چیزی، WSL را باز می‌کردم و فرمانی را که از پیش بلد بودم تایپ می‌کردم.

بنابراین، پس از معرفی Coreutils توسط مایکروسافت، ابزار جدیدش را بیشتر با دیدهٔ تردید آزمایش می‌کردم. اگر تمام چیزی که ویندوز واقعاً کم داشت چند فرمان بود، آن‌گاه WSL در گردش کار من به راه‌حلی موقتی برای پر کردن جای خالیِ پراستفاده‌ترین فرمان‌ها تبدیل شده بود: ls و grep و find و cat و sort و head و tail و wc.

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

پرسشی که می‌خواستم به آن پاسخ دهم این نبود که آیا Coreutils کار می‌کند؛ می‌خواستم بدانم آیا از WSL به‌خاطر لینوکس استفاده می‌کردم یا صرفاً به‌خاطر همین هشت فرمانی که به آن‌ها عادت کرده بودم.

ترمینالم دیگر تمرکزم را برهم نمی‌زد

دیگر مجبور نبودم پنجره را ترک کنم

بسیاری از چیزها کار می‌کردند و صادقانه، آن‌قدر عادی به نظر می‌رسیدند که همین عادی بودن نشان می‌داد همه‌چیز درست کار می‌کند. ls -la روی ویندوز بومی کار می‌کرد و find بازگشتی نیز همین‌طور. grep -r را بی‌وقفه روی پوشهٔ یک پروژه استفاده کردم و خط لوله‌ای که برای دسته‌بندی لاگ به‌کار می‌برم — cat access.log | grep ۵۰۰ | sort | uniq | wc -l — بی‌نقص کار می‌کرد.

انتظار نداشتم اسکریپت‌نویسی هم به این خوبی جواب دهد. افزون بر این، برای انتقال آن چند اسکریپت یک‌خطی به‌سبک bash که برای تغییر نام دسته‌ای فایل‌ها و کوتاه کردن خروجی لاگ استفاده می‌کنم، تقریباً به هیچ ویرایشی نیاز نبود. اگر می‌خواستم همان اسکریپت را با PowerShell بازنویسی کنم، باید نحو جدید و منطق خط لولهٔ شیء‌محور آن را یاد می‌گرفتم. Coreutils بدون آن‌که چیزی را از نو بیاموزم، همان چیزی را که داشتم اجرا کرد.

عملکرد بومی سیستم‌فایل مزیت دیگری بود. توانستم نتیجهٔ عملیات بازگشتی grep و find را روی یک پروژهٔ بزرگ، سریع‌تر از اجرای همان فرمان‌ها در WSL دریافت کنم. این را به حذف لایه‌ای میان ابزار و درایو بومی نسبت می‌دهم که دیگر نیازی به ترجمه نداشت؛ پاداشی کوچک، هرچند دلیل اصلی‌ام برای کنار گذاشتن WSL نبود.

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

ویندوز دائماً یادآوری می‌کرد که لینوکس نیست

میان‌برها پنهان نماندند

روز دوم آزمایش Coreutils، در پنجرهٔ PowerShell دستور ls را تایپ کردم و به‌جای باینری Coreutils که تازه نصب کرده بودم، خروجی خودِ Get-ChildItemِ PowerShell را دیدم. این نام مستعاری است که از پیش به PowerShell تعلق دارد. یک دقیقه طول کشید تا فهمیدم باید صریحاً ls.exe بنویسم. در نهایت باید یا ترتیب PATH را اصلاح می‌کردم یا نام‌های مستعار متعارض را از پروفایلم حذف می‌کردم. هر دو کار را انجام دادم.

مایکروسافت در مستنداتش جدولی برای سازگاری دارد و فهرستی از ابزارها را برای PowerShell ۷.۴ و بالاتر با عنوان «همراه است، اما تداخل دارد» علامت‌گذاری کرده است. در CMD وضعیت بهتر است؛ آنجا این ابزارها با هیچ نام مستعار داخلی درگیر نمی‌شوند. کاش وضعیت برعکس بود، اما ابزاری که بهترین کارایی را دارد در پوسته‌ای قرار گرفته است که کمترین استفاده را از آن می‌کنم.

شکاف‌های کوچک دیگری هم وجود دارند که با هم انباشته می‌شوند. چون مجوزهای ویندوز به chmod و chown نگاشت نمی‌شوند، این دو فرمان وجود ندارند. kill و timeout هم غایب‌اند، زیرا در ویندوز سیگنال‌های POSIX وجود ندارد. مایکروسافت dir و more و whoami را حذف کرده است تا نگارش‌های ویندوزی‌ای که به آن‌ها تکیه دارید جای‌گزین نشوند. سرانجام به پایان‌خط‌های CRLF می‌رسید و وسط انجام کاری دیگر، نبودِ /dev/null را احساس می‌کنید (اینجا NUL است).

چه چیزی باقی می‌ماند که واقعاً هنوز به لینوکس نیاز دارد؟

برای مدیریت روزمرهٔ فایل، پردازش متن و اسکریپت‌نویسی، WSL برای من اختیاری شده است. این به آن معنا نیست که Coreutils جای WSL را می‌گیرد. برای کارهای توسعه‌ای هیچ‌چیز تغییر نکرده است. تا زمانی که کاری به کنترل پیشرفتهٔ فرایندها یا مجوزهای ویژهٔ لینوکس نیاز دارد، جای آن در WSL است. اگر کارتان با مدیرهای بسته و کانتینرها سروکار دارد، این مقاله برای شما نیست.

عده‌ای می‌گویند «کافی است از WSL یا MSYS2 استفاده کنید» و گروهی دیگر آن را راه‌حلی واقعاً سودمند می‌دانند. هر دو دیدگاه، بسته به روال روزانه‌تان، معقول است.

منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Afam Onyimadu است. مشاهده مقاله اصلی