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

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

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

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

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

بنابراین، پس از معرفی Coreutils توسط مایکروسافت، بیشتر با رویکرد متهم کردن تا ابزار جدید آن را آزمایش می‌کردم. اگر تمام چیزی که ویندوز واقعاً thiếu داشت چند فرمان بود، آن‌گاه برای گردش کار من، 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 یعنی خروج از یک زمینه ذهنی و ورود به زمینه‌ای دیگر، و بعد خروج از آن زمینه برای بازگشتن. این رفت‌وبرگش بود که 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 has become optional for me for everyday file management, text processing, and scripting . This isn't the same as saying Coreutils replaces WSL. Nothing has changed for development work. As long as something still needs advanced process control or Linux-specific permissions, it belongs to WSL. If your work involves package managers and containers, this article isn't for you.

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

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