شب فرخنده🌃
🐧 ۸۰٪ کاربران لینوکس دیگر از Wayland استفاده می‌کنند!

طبق آمار جدید منتشرشده، Wayland حالا به انتخاب اصلی کاربران لینوکس تبدیل شده و حدود ۸۰ درصد کاربران دسکتاپ، X11 را کنار گذاشته‌اند. این آمار نشان می‌دهد مهاجرتی که سال‌ها درباره آن صحبت می‌شد، حالا عملاً اتفاق افتاده است.

دلایل این رشد:

عملکرد بهتر روی نمایشگرهای چندگانه و HiDPI

امنیت بیشتر نسبت به X11

پیش‌فرض شدن Wayland در توزیع‌ها و دسکتاپ‌های بزرگی مثل GNOME و KDE Plasma

بهبود چشمگیر پشتیبانی از درایورهای گرافیکی، به‌ویژه در سال‌های اخیر (مخصوصا انویدیا)

البته X11 هنوز نمرده است و سگ جان است. برخی کاربران همچنان به‌دلیل نرم‌افزارهای قدیمی، سخت‌افزار خاص یا نیازهای حرفه‌ای از آن استفاده می‌کنند، اما روند توسعه اکثر پروژه‌های بزرگ لینوکسی حالا کاملاً به سمت Wayland است و بسیاری از آن‌ها در حال حذف تدریجی پشتیبانی از X11 هستند.

- @MainPenguins | Source

دلِ شب نکو💫
آپدیت Wayland 1.26 RC1 منتشر شد

اولین نسخه Release Candidate از Wayland 1.26 منتشر شد و پروژه وارد مرحله نهایی آماده‌سازی این نسخه شده.

این آپدیت بیشتر برای توسعه‌دهنده‌هاست و شامل بهبود مستندات، رفع باگ‌ها و تغییرات داخلی در پروتکل Wayland میشه.

- @MainPenguins | Source

امروز یه نگاهی به Detector جدید Miggo Security انداختم که برای شناسایی سوءاستفاده از آسیب‌پذیری CVE-2026-23111 در کرنل لینوکس منتشر شده.

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

- @MainPenguins | Source

بامداد جان‌بخش🌄

تیم AMD می‌خواهد مصرف باتری لپ‌تاپ‌های OLED را در لینوکس کمتر کند

تیم AMD روی قابلیت جدیدی به نام CACP (Content Adaptive Control Policy) برای درایور AMDGPU کار می‌کند؛ قابلیتی که قرار است مصرف انرژی نمایشگرهای OLED را کاهش دهد.

ویژگی CACP بسته به محتوایی که روی صفحه نمایش داده می‌شود، تنظیمات پنل را به‌صورت هوشمند تغییر می‌دهد تا بدون افت محسوس کیفیت تصویر، مصرف باتری کمتر شود. این قابلیت به‌ویژه روی لپ‌تاپ‌های مجهز به نمایشگر OLED بیشترین تأثیر را خواهد داشت.

این ویژگی بخشی از تغییرات جدید AMDGPU Display Core (DC) است و در کنار «Power Module» که قبلاً به لینوکس اضافه شده بود، هدفش نزدیک‌تر کردن مدیریت مصرف انرژی لینوکس به نسخه ویندوز در لپ‌تاپ‌های AMD است.

- @MainPenguins | Source

شادروز باشید🔆
پس از مدت‌ها، ELinOS 8 منتشر شد؛ تمرکز ویژه روی امنیت سیستم‌های Embedded

شرکت SYSGO نسخه جدید ELinOS 8 را معرفی کرد؛ یک توزیع لینوکسی تجاری که برای سیستم‌های Embedded و کاربردهای حساس مثل تجهیزات صنعتی، پزشکی، حمل‌ونقل و دفاعی توسعه داده می‌شود.

مهم‌ترین قابلیت‌های این نسخه:

پشتیبانی از Linux 6.12 LTS

تولید خودکار SBOM برای مدیریت زنجیره تأمین نرم‌افزار

ابزارهای بررسی Hardening مطابق استاندارد ANSSI

فعال بودن GCC Fortification Level 3

وجود Buildهای Reproducible برای کرنل و RootFS

پشتیبانی بهتر از سخت‌افزارهای Intel، ARM و RISC-V

هدف ELinOS 8 این است که سازندگان تجهیزات Embedded بتوانند راحت‌تر الزامات امنیتی جدید مثل Cyber Resilience Act (CRA) اروپا را رعایت کنند و در عین حال تا ۱۰ سال از کرنل LTS و به‌روزرسانی‌های امنیتی بهره ببرند.

- @MainPenguins | Source

نوستراداموس (گوگل) پروژه Open Health Stack را به Linux Foundation واگذار کرد

نوستراداموس (گوگل) اعلام کرده که پروژه Open Health Stack (OHS) را به Linux Foundation منتقل می‌کند تا از این پس تحت یک بنیاد مستقل با نام Open Health Stack Software Foundation (OHS-SF) توسعه پیدا کند. هدف این کار، توسعه آزادتر و مشارکت بیشتر جامعه متن‌باز در حوزه سلامت دیجیتال است.

پروژه Open Health Stack مجموعه‌ای از ابزارهای متن‌باز برای ساخت نرم‌افزارهای سلامت، پرونده‌های پزشکی دیجیتال و سرویس‌های مبتنی بر استاندارد HL7 FHIR است و در کشورهای مختلف برای توسعه زیرساخت‌های درمانی استفاده می‌شود. بنیاد جدید همچنین روی ابزارهای چندسکویی و زیرساخت‌های هوش مصنوعی در حوزه سلامت تمرکز خواهد داشت.

نوستراداموس (گوگل) علاوه بر انتقال کامل کدها و دارایی‌های پروژه، ۳ میلیون دلار هم از طریق Google.org برای حمایت از این بنیاد اختصاص داده است. سازمان WHO و چندین شرکت و سازمان دیگر نیز از این پروژه پشتیبانی می‌کنند تا توسعه آن به‌صورت کاملاً جامعه‌محور ادامه پیدا کند.

- @MainPenguins | Source | Source

به نظر می‌رسه توسعه‌دهنده‌های COSMIC در حال Merge کردن قابلیت Frosted Blur (Frosted Glass) روی شاخه اصلی پروژه هستن و اگر همه‌چیز طبق برنامه پیش بره، نسخه بعدی COSMIC این افکت رو به‌صورت رسمی دریافت می‌کنه.

این تغییر فقط محدود به یک بخش نیست و Pull Requestهای مربوط به COSMIC Store، Settings، Panel، Terminal و حتی xdg-desktop-portal-cosmic هم در حال Merge شدن هستن؛ یعنی این افکت قراره به‌صورت یکپارچه در کل دسکتاپ استفاده بشه، نه فقط روی چند پنجره.

- @MainPenguins | Source | Source | Source | Source | Source

پسین نکو🌞
معرفی Virtual Surround Manager؛ صدای فراگیر مجازی برای لینوکس

اگر از هدفون استفاده می‌کنید ولی دلتان یک تجربه نزدیک‌تر به صدای Surround می‌خواهد، پروژه virtual-surround-manager یک ابزار جالب برای مدیریت صدای فراگیر مجازی در لینوکس است.

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

کاربردها:

بهبود تجربه بازی‌ها با هدفون

ایجاد حس Spatial Audio بدون سخت‌افزار خاص

مدیریت پروفایل‌های صوتی مختلف

استفاده در کنار سیستم‌های صوتی لینوکس مثل PipeWire و PulseAudio

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

- @MainPenguins | Source

معرفی ابزار Komikku؛ یکی از بهترین مانگاخوان‌های لینوکس

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

از قابلیت‌های مهمش:

مطالعه آنلاین و آفلاین

پشتیبانی از فایل‌های CBZ، CBR، CBT، EPUB و PDF

حالت‌های مختلف مطالعه مثل Webtoon، Vertical، RTL و LTR

دانلود خودکار فصل‌های جدید

همگام‌سازی پیشرفت مطالعه با MyAnimeList، AniList و MangaUpdates

تاریخچه مطالعه، دسته‌بندی کتابخانه و تم روشن/تاریک

نکته خوبش اینه که از طریق Flathub نصب میشه و روی اکثر توزیع‌های لینوکسی بدون دردسر اجرا میشه. اگر دنبال یک مانگاخوان کامل و خوش‌ساخت برای دسکتاپ لینوکس هستید، Komikku قطعاً ارزش امتحان کردن رو داره.

- @MainPenguins | Source

خردمند و روشن‌اندیش باشد✨️
آپدیت KDE Frameworks 6.28 منتشر شد

نسخه KDE Frameworks 6.28 منتشر شد و مثل همیشه مجموعه‌ای از بهبودها و رفع باگ‌ها را برای اپلیکیشن‌ها و کتابخانه‌های KDE به همراه دارد.

مهم‌ترین تغییر این نسخه مربوط به KRunner است؛ از این به بعد می‌توانید مستقیماً واحدهای انرژی مثل وات‌ساعت (Wh)، کیلووات‌ساعت (kWh) و سایر واحدهای مشابه را هم داخل KRunner به یکدیگر تبدیل کنید.

علاوه بر این، مشکلات مربوط به نمایش تار شدن آیکون‌ها و Thumbnailها در مقیاس‌بندی کسری (Fractional Scaling) برطرف شده و مدیریت برنامه‌هایی که نام یکسان دارند در منوی برنامه‌ها هم بهبود پیدا کرده است.

اگر از Plasma استفاده می‌کنید، این نسخه به‌زودی از طریق مخازن توزیع شما در دسترس قرار می‌گیرد.

- @MainPenguins | Source

شل یه برنامه است! (۲/۱۰)

اما نکته‌ی جالب اینجاست که دیگه خبری از اون دستگاه‌های بزرگ و کیبوردهای سنگین و رول‌های کاغذی نیست. چیزی که باز می‌کنیم درواقع یک Terminal Emulator(شبیه‌ساز ترمینال) ـه؛ یعنی برنامه‌ای که رفتار همون ترمینال‌های قدیمی رو شبیه‌سازی می‌کنه.

برای همین هم هنوز توی لینوکس با اسم‌هایی مثل tty، pts و ترمینال سروکار داریم. این‌ها یادگار همون دورانی هستن که ترمینال واقعاً یک دستگاه فیزیکی بود، نه صرفاً یک پنجره‌ی نرم‌افزاری.

ولی خب خود ترمینال هم به تنهایی دستورات رو اجرا نمی‌کنه. الان هم تقریباً همون کار سنتیشو انجام می‌ده و وظیفه‌اش فقط گرفتن ورودی و دادن خروجیه.

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

مثلاً وقتی توی ترمینال دستور ls رو می‌زنید، شل این متن رو می‌خونه و بررسی می‌کنه که اصلاً ls چی هستش. چطوری انجامش می‌ده؟ دقیقاً درست حدس زدین! با استفاده از متغیر PATH مسیرهای اجرایی ممکن رو پیدا می‌کنه. اگه توی لینوکستون(درواقع منظورمون اکثر شبه‌یونیکس‌هاست) دستور زیر رو بزنید به شما محتوای متغیر PATH رو نشون می‌ده و بسته به سیستم‌عامل یه سری موارد دیگه که بعداً بهش اشاره می‌کنیم ممکنه خروجیش متفاوت باشه.

% echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin

این‌ها مسیرهایی هستن که برنامه‌های ما اونجا ذخیره شدن و شل محترم هم از اونجا دنبال فایل باینریشون می‌گرده؛ و دقیقاً سر این موضوعه که اگه توی یه پوشه یه فایل باینری داشته باشیم فقط با نوشتن اسمش نمی‌شه اجراش کرد و لازمه اشاره کنیم که منظورمون همون فایل اینجاست تا اجرا شه:

% ./my_cool_app

و سر اینه که هکر نامحترم نمی‌تونه یه فایل به اسم sudo بنویسه و بذاره داخل پوشه‌ای که از گیت‌هاب کلون کردین و شما هم اونجا به اشتباه sudo داخل پوشه رو بزنید و رمزتون بره تو آرشیو ایشون.

شل یه برنامه است! (۳/۱۰)

احتمالاً براتون سوال بشه که مگه چند تا شل داریم؟ اصلاً فرقشون چیه؟
همون‌طور که اول مسیر گفتیم، شل فقط یه برنامه‌ست. پس هرکسی می‌تونه شل خودش رو بنویسه! در طول تاریخ هم شل‌های مختلفی برای نیازهای مختلف نوشته شدن:

‏۱. sh (Bourne Shell): پدربزرگ شل‌های مدرن که سال ۱۹۷۷ معرفی شد. خیلی ساده‌ست و هنوز هم به عنوان استاندارد پایه‌ی برای نوشتن اسکریپت‌های سیستمی استفاده می‌شه.

‏۲. bash (Bourne Again Shell): شل پیش‌فرض اکثر توزیع‌های لینوکس. قابلیت‌های خیلی بیشتری نسبت به sh مثل تاریخچه دستورات و کامل کردن خودکار با کلید Tab رو اضافه کرد.

‏۳. zsh (Z Shell): شل بسیار قدرتمند و مدرن که این روزها شل پیش‌فرض macOS و بعضی توزیع‌های لینوکسه. به خاطر پلاگین‌ها و تم‌های فوق‌العاده‌ش (مثل Oh My Zsh) خیلی بین برنامه‌نویس‌ها محبوبه.

‏۴. fish (Friendly Interactive Shell): شلی که تمرکزش روی راحتی کاربره. بدون نیاز به تنظیمات خاصی، قابلیت‌های جذابی مثل پیشنهاد خودکار دستورات بر اساس تاریخچه رو بهتون می‌ده.

شما هر وقت ترمینال رو باز می‌کنید، می‌تونید با تایپ کردن اسم هر کدوم از این‌ها (اگه نصب باشن)، شل فعلیتون رو عوض کنید. مثلاً کافیه بنویسید fish تا وارد دنیای رنگارنگ و قشنگ شل فیش بشید! و برای تغییر دائمی شلتون هم می‌تونید از دستور chsh استفاده کنید.

شل یه برنامه است! (۴/۱۰)

یکی از جذاب‌ترین و قدرتمندترین ویژگی‌های شل، مفهومی به اسم Pipeline هستش. توی فلسفه یونیکس یه قانون معروف هست که می‌گه یه برنامه ساده ولی خوب بنویسید که فقط یک کار انجام بده ولی همون رو درست و به بهترین نحو ممکن انجام بده.
و شل اینجا وظیفه ارتباط بین این دستورها رو داره، چطوری؟ با هدایت کردن ورودی‌ها و خروجی‌ها. هر برنامه‌ای که توی شل اجرا می‌شه، سه تا کانال ارتباطی استاندارد داره:

‏Standard Input (stdin): ورودی برنامه (معمولاً کیبورد شما).
‏Standard Output (stdout): خروجی معمولی برنامه (معمولاً مانیتور شما).
‏Standard Error (stderr): پیغام‌های خطای برنامه (که این هم روی مانیتور میاد ولی کانالش جداست).

حالا فرض کنید می‌خوایم لیست تمام فایل‌های یه پوشه رو بگیریم، اما فقط اون‌هایی رو ببینیم که اسمشون شامل کلمه “report” هست. به جای اینکه یه برنامه بزرگ بنویسیم، دو تا برنامه کوچیک رو با | به هم وصل می‌کنیم:

cat /var/log/mylog | grep -I "error"

اینجا شل میاد خروجی استاندارد (stdout) دستور cat /var/log/mylog رو می‌گیره و مستقیم می‌فرسته به ورودی استاندارد (stdin) دستور grep. به همین سادگی، برنامه‌ها مثل قطعات لگو به هم وصل می‌شن!

توی پست «چرا توی unix همه چیز فایله» بیشتر درموردش صحبت کردیم.

شل یه برنامه است! (۵/۱۰)

وقتی Enter می‌زنیم دقیقاً چه چیزی به شل می‌رسه؟

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

اول، ترمینال ورودی صفحه‌کلید را می‌گیره. این ورودی در نهایت از طریق TTY به برنامه‌ای می‌رسه که در پیش‌زمینه‌(FG) اوه ترمینال قرار داره. اگر شل در FG باشد، این متن به شل می‌رسه. یعنی شل مستقیماً «کیبورد» را نمی‌خونه؛ بلکه از FD استاندارد ورودی خودش می‌خونه که معمولاً به همان ترمینال وصله.

پس وقتی می‌نویسیم:

% echo myfile

چیزی که شل دریافت می‌کنه اول فقط یک رشته‌ متنیه. هنوز هیچ برنامه‌ای اجرا نشده، هیچ echo ای هم صدا زده نشده. شل باید اول این خط را بخونه بفهم، تکه‌تکه کنه و تصمیم بگیره اصلاً منظورمون چه بوده. اینجا شل فقط یک launcher نیست؛ یک مفسر زبان هم هست.

شل یه برنامه است! (۶/۱۰)

شل اول حرف ما را parse می‌کنه، بعد از اون اجرا.

خیلی‌ها ناخودآگاه فکر می‌کنن که شل فقط فاصله‌ها را نگاه می‌کنه و بعد برنامه را اجرا می‌کنه، ولی در واقع شل قبل از اجرا، روی خط فرمانمون یک مرحله‌ی کامل parsing و expansion انجام می‌ده.

مثلاً این دستورها ظاهراً شبیه هم‌ان، ولی برای شل یکی نیستن:

% echo $HOME
% echo "$HOME"
% echo '$HOME'
% echo *.txt

در اینجا شل باید بفهمه کجا quote باز شده، کجا بسته شده، چه چیزی باید به عنوان متغیر expand شه. کدوم * باید به اسم فایل‌ها تبدیل شن و کدوم بخش باید عیناً به برنامه تحویل داده بشه. یعنی چیزی که برنامه نهایی می‌بینه، الزاماً همون چیزی نیست که ما تایپ کردیم.
این تفاوت‌ خیلی مهمه. چون بسیاری از رفتارهای shell از همین‌جا شکل می‌گیره. echo هیچ درکی از $HOME یا *.txt نداره؛ این خود شله که قبل از اجرا، این موارد رو به چیزی که باید باشن تبدیل می‌کنه. ودر عمل شل اول از متن خاممون یک چیز با «معنا» می‌سازه و بعدش تازه اونو اجرا می‌کنه.

شل یه برنامه است! (۷/۱۰)

خب، تا اینجا دیدیم که شل چطور دستورات ما رو پیدا می‌کنه. اما بعد از پیدا کردنش چه اتفاقی می‌افته؟ چطوری اون برنامه رو اجرا می‌کنه؟
اینجاست که با دو تا از مهم‌ترین مفاهیم سیستم‌عامل‌های شبه‌یونیکس آشنا می‌شیم: fork و exec.

وقتی شما دستوری مثل ls یا هر برنامه دیگه‌ای رو تایپ می‌کنید و اینتر می‌زنید، شل خودش رو کپی می‌کنه! به این کار می‌گن fork کردن. یعنی یه پروسه جدید (فرزند) از روی خودش می‌سازه. بعد، این پروسه فرزند با استفاده از سیستمی به اسم exec خودش رو با برنامه مورد نظر شما (مثلاً همون ls) جایگزین می‌کنه. در تمام این مدت، شل اصلی (والد) منتظر می‌مونه تا کار فرزند تموم بشه و بعد دوباره کنترل ترمینال رو به دست می‌گیره و منتظر دستور بعدی شما می‌مونه. برای اینکه قشنگ درک کنیم چه اتفاقی می‌افته، بیاید با هم یک کد ساده به زبان C بنویسیم که دقیقاً همین کار رو انجام میده:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

int main(void) {
    pid_t pid = fork();

    if (pid < 0) {
        // Fork failed
        perror("fork");
        return 1;
    } else if (pid == 0) {
        // Child process: replace image with ls
        execlp("ls", "ls", "-l", NULL);
        // Exit if exec fails
        exit(1);
    } else {
        // Parent process: wait for child to finish
        wait(NULL);
        printf("Parent: Child finished.\n");
    }
    return 0;
}

توی این کد چه اتفاقی افتاد؟

۱. تابع fork کل فضای حافظه شل رو کپی می‌کنه (یا به اصطلاح ازش فورک می‌گیره)
۲. شرط pid == 0 مشخص می‌کنه کدوم بخش مربوط به فرزنده. توی این بخش، تابع execlp تمام حافظه‌ی فرزند رو پاک می‌کنه و برنامه ls رو توش بارگذاری می‌کنه. برای همین برنامه ls اجرا میشه.
۳. تابع wait توی بخش والد باعث میشه شل اصلی (والد) تا زمانی که فرزند تموم نشده، دست از پا خطا نکنه و منتظر بمونه. دقیقاً برای همین وقتی شما ls رو می‌زنید، شل شما به اصطلاح «فریز» میشه تا لیست فایل‌ها چاپ بشه و بعد دوباره افسار پرامپت به شما برمی‌گره.


اما یه نکته ظریف وجود داره! همه دستورات اینطوری اجرا نمی‌شن. یه سری دستورات هستن که اصلاً فایل باینری خارجی ندارن و توی خود دل شل ساخته شدن. به این‌ها می‌گن Shell Builtins.

مثلاً دستور cd رو در نظر بگیرین. چرا cd باید داخل خود شل باشه؟ چون اگه cd یه برنامه خارجی بود، طبق چیزی که گفتیم شل براش یه پروسس فرزند می‌ساخت، پوشه کار اون فرزند عوض می‌شد، کارش تموم می‌شد و از بین می‌رفت؛ ولی پوشه کار شل اصلی شما هیچ تغییری نمی‌کرد! برای همین دستوراتی مثل cd یا pwd و alias مستقیماً توسط خود شل اجرا می‌شن و نیازی به رفتن سراغ دیسک و متغیر PATH ندارن.

شل یه برنامه است! (۸/۱۰)

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

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

name="Ali"
echo "$name"

if [ -f /etc/passwd ]; then
  echo "exists"
fi

یا مثلاً:

for file in *.txt; do
  echo "$file"
done

اینجا دیگه ماجرا فقط «اجرای یک برنامه» نیست. شل متغیر نگه می‌داره، شرط بررسی می‌کنه، حلقه اجرا می‌کنه و بر اساس syntax خودش تصمیم می‌گیره چیکار باید بکنه. برای همین shell script عملاً یک زبان اسکریپت‌نویسیه و نه فقط یک محیط برای زدن commandهای پراکنده. شما می‌تونید با استفاده از اون، چندین برنامه را کنار هم بگذارید، روی خروجی‌شان تصمیم بگیرید، شرط و حلقه بنویسید، و کارهای تکراری را خودکار کنید. شاید همین‌جاست که shell از یک command runner ساده جدا تمیز می‌ده. چون shell فقط واسطه‌ شما و برنامه‌ها نیست؛ یک لایه‌ی منطقی هم روی آن‌ها می‌ذاره و یعنی هم می‌تونه برنامه رو اجرا کند و هم می‌تواند به اجرای اونا ساختار بده.